Здравствуйте, jazzer, Вы писали:

J>Ты как-то огульно кучу полезных вещей записал в сказочные конструкции, не очень понятно, с какой целью
J>Навскидку, не заглядывая в реальный список — auto, rvalue references, variadic templates, variadic macros, memory model, threads, локальные классы как аргументы шаблонов, range-based loop, атрибуты функций/классов/переменных, initializer lists.

Названные Вами вещи безусловно полезны. Возможно, я не совсем точно выразил свою точку зрения. Мне не нравится не факт введения новых конструкций, а то, что они перекрывают существующий синтаксис и раздувают его. Хотя, конечно, при обязательном условии совместимости вычистить старьё не удастся.

J>В общем, если действительно интересно — читай интервью по поводу выкидывания концепций из _этого_ стандарта.

Я в курсе, что концепты перенесли в следующий TR (предварительно). Спасибо, поищу, почитаю.

Здравствуйте, Мишень-сан, Вы писали:

МС>Я вместо этих извратов с break-continue предпочёл бы нормальные локальные функции.

Плюс полноценные замыкания, что уже реализовано например в D http://www.digitalmars.com/d/2.0/function.html#nested

Здравствуйте, Caracrist, Вы писали:

МС>>Я вместо этих извратов с break-continue предпочёл бы нормальные локальные функции.

C>а выход через несколько исключениями реализовать, и все необходимое by-ref передавать?
C>вся идея локальных скоупов в конструкторах/деструкторах, break/continue/loop/if-else и visibility других локальных переменных, можно от них отказаться, но по моему это не правильный путь.

Если есть первоклассные функции то циклы не очень то и нужны.

Здравствуйте, _nn_, Вы писали:

__>Мне хотя бы constexpr и возможность манипулировать строками (массивами) во времени компиляции.

__>

__>const int hash_abc = hash("abc"); // compile time :)
__>

В D есть http://www.digitalmars.com/d/2.0/function.html#interpretation

Здравствуйте, Мишень-сан, Вы писали:


МС>Там, ЕМНИП, не простой текстовый препроцессор, а полноценная компайл-тайм логика. в D есть отголосок — компайл-тайм функции.

Там и шаблоны вполне уже человеческие.
Ну и тот же static if и т. п. вполне себе компайл-тайм логика.

Здравствуйте, Мишень-сан, Вы писали:

МС>Кстати, наткнулся как-то на интересную идею (где-то на форуме Nemerle кажется): расширить семантику типа void, в частн. позволить единственное значение этого типа — например (). И соответственно позволить конструкции вида return (); в функциях возвращающих void. Это позволило бы не писать для некоторых случаев делегирования в шаблонах отдельную специализацию.

Ну это наверно отголоски ML в немерле

Здравствуйте, Caracrist, Вы писали:

C>1. break [what]; continue [what];
C>возможность делать break(и continue) из любого скоупа, а не только цикла. Плюс параметризировать.
C>число говорит сколько скоупов оборвать, а назавание цыкла говорит какой первый встречающийся цикл оборвать. Через запятую перечисление последовательных обрывов.

В D можно задавать перед циклом метку и break (или continue) может получить параметром эту метку, что означает выход из помеченного цикла (на произвольную метку при этом перейти нельзя)

http://www.digitalmars.com/d/2.0/statement.html#BreakStatement

tst: for(int i = 0; i < 10; ++i)
{
    while(true)
    {
        break tst; // выходим из for
    }    
}

Здравствуйте, jazzer, Вы писали:

J>Это не D и не Python, где один человек принимает все решения и сует в язык каждую понравившуюся ему фичу, а потом чешет репу, глядя на зоопарк несовместимых друг с другом фич, который у него получился, и переписывает все нафиг, делая несовместимые версии языка. Тут люди задумываются над когерентностью языка. С++0x полностью совместим с С++03, с поправкой на неизбежную проблему с новыми ключевыми словами.

Да все так, но уже несколько раз когда нужно было делать сложную конструкцию на шаблонах я делал прототип на D а потом переносил на C++ что было на порядок проще чем делать сразу на C++. Совместимость конечно нужно поддерживать, но это может в конце концов просто убить язык из-за слишком большой сложности.
Может быть даже правильнее было бы объявить существующие шаблоны на C++ устаревшими, поддерживать их как есть и ввести новые с не пересекающимся синтаксисом например с таким же синтаксисом как в D, в свое время например борланд в дельфи не постеснялись даже объектную систему полностью поменять, не отменяя при этом поддержку старой.

Здравствуйте, FR, Вы писали:

FR>Да все так, но уже несколько раз когда нужно было делать сложную конструкцию на шаблонах я делал прототип на D а потом переносил на C++ что было на порядок проще чем делать сразу на C++. Совместимость конечно нужно поддерживать, но это может в конце концов просто убить язык из-за слишком большой сложности.

Ну сам понимаешь, это не простой выбор — упростить синтаксис, убив совместимость с бог знает какой горой кода (т.е. фактически сохдав новый язык, со стандартной проблемой нового языка, заключающейся в том, что им никто не пользуется, кроме создателей и фанатов), либо вводить новые фичи аккуратно, тщательно согласуя их с уже имеющимися.

Я думаю, Страуструп тоже был бы не против грохнуть совместимость с С, особенно с наиболее одиозными его частями, но он был мужиком умным и понимал, что без совместимости с С его новый язык нафиг никому нужен не будет.

Народ вон на стандартный С++98/03 переходил лет 10, и до сих пор еще не полностью перешел, куда уж там говорить о несовместимой версии языка.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

BZ>>вообще верит в макросы может только человек которыми ими никогда не пользовался. представь себе хотя бы отладку кода, используюшего макросы....

J>Вообще верить в безумную сложность отладки макросов может только человек, которыми ими никогда не пользовался.

не безумная, а большая чем у нормального кода

Здравствуйте, jazzer, Вы писали:

J>Ну сам понимаешь, это не простой выбор — упростить синтаксис, убив совместимость с бог знает какой горой кода (т.е. фактически сохдав новый язык, со стандартной проблемой нового языка, заключающейся в том, что им никто не пользуется, кроме создателей и фанатов),

Тык я же и говорю сделать не убивая совместимость, старые шаблоны останутся как были, но развиваться не будут, новые делать так чтобы они синтаксически не пересекались со старыми и не влияли на совместимость.

J>либо вводить новые фичи аккуратно, тщательно согласуя их с уже имеющимися.

Можно, но в результате накапливается критическая масса после которой это уже становится просто невозможным. C++ по моему уже до нее дошел.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, jamesq, Вы писали:

J>>Еще круто было бы иметь возможность отключить обязательность инициализированности полей.

VD>А она когда-то появлялась?


Вот код:

class FieldType {
public:
    FieldType(int);
};

class MyClass {
public:
    MyClass() {}
    FieldType tt; // Поле обязательно требует инициализации
};

Он не скомпилируется, т.к. поле tt обязательно требует инициализации.
Visual C++ пишет ошибку: error C2512: 'FieldType' : no appropriate default constructor available

Здравствуйте, jamesq, Вы писали:

J>Он не скомпилируется, т.к. поле tt обязательно требует инициализации.


Обязательно нужно сделать не инициализируемые поля, ведь в C++ наблюдается острый недостаток UB.

Здравствуйте, jamesq, Вы писали:

J>Он не скомпилируется, т.к. поле tt обязательно требует инициализации.
J>Visual C++ пишет ошибку: error C2512: 'FieldType' : no appropriate default constructor available
Он не инициализации требует, а требует чтобы был конструктор по умолчанию, который вы сами предварительно скрыли.
Тут ничего нет обязательного.

Здравствуйте, jamesq, Вы писали:

J>Здравствуйте, VladD2, Вы писали:

VD>>Здравствуйте, jamesq, Вы писали:

J>>>Еще круто было бы иметь возможность отключить обязательность инициализированности полей.

VD>>А она когда-то появлялась?


J>Вот код:
J>

J>class FieldType {
J>public:
J>    FieldType(int);
J>};

J>class MyClass {
J>public:
J>    MyClass() {}
J>    FieldType tt; // Поле обязательно требует инициализации
J>};
J>

J>Он не скомпилируется, т.к. поле tt обязательно требует инициализации.
J>Visual C++ пишет ошибку: error C2512: 'FieldType' : no appropriate default constructor available
И это правильно.

Здравствуйте, jamesq, Вы писали:

J>Он не скомпилируется, т.к. поле tt обязательно требует инициализации.
J>Visual C++ пишет ошибку: error C2512: 'FieldType' : no appropriate default constructor available

А если так попробовать:

class FieldType {
public:
    FieldType(int);
};

class MyClass {
public:
    MyClass() {}
    FieldType* tt;
};

G_>Тут ничего нет обязательного.

Я что хотел сказать.

Если брать код, который я написал, что мы видим:
класс FieldType, для инициализации объектов которого, в конструктор нужно обязательно передать параметр.
конструктор MyClass, в котором в списке инициализации явно не прописана инициализация поля tt.
Если это встретилось, инициализация поля должна быть сгенерирована компилятором неявно, используя
конструктор по умолчанию класса FieldType.
Однако, такого конструктора в коде нет, и поэтому возникла ошибка компиляции.

Если считать класс FieldType зафиксированным, и изменению не поддающимся, то для внедрения в класс MyClass поля
с типом FieldType, придется в конструкторе прописать инициализацию этого поля, с передачей в конструктор объекта поля нужного параметра.
Это я и имел в виду под словами "поле tt обязательно требует инициализации".

Мое предложение в том, чтобы иметь возможность изменить порядок инициализации и уничтожения поля.
Чтобы в конструкторе объекта FieldType не обязательно было бы прописывать инициализацию поля tt
(при условии пометки объявления этого поля специальным словом).
И тогда, при создании объекта FieldType, конструктор для поля tt не вызывался бы, и поле оставалось бы
неинициализированным. Однако, в памяти, выделенной объекту FieldType оставался участок для поля tt.
Его содержимое было бы undefined.
При уничтожении объекта FieldType, деструктор для поля tt тоже бы не вызывался (неявно, после завершения тела деструктора, если бы он был бы прописан в классе FieldType). Сейчас же по правилам C++, они же вызываются, так?
Однако, в коде должна быть возможность ручками где-угодно (хоть в какой-нибудь функции-члене) прописать
инициализацию поле tt, и ручками же его уничтожить (вызовами конструктора и деструктора).
А самое главное, чтобы была бы свободная возможность работать с таким полем, как с любым другим полем.

Т.е. пишем что-нибудь вроде:

void d(FieldType& x){
 x.tt.some_func(123); // подразумевается, что в определение класса FieldType добавлена функция some_func()
}

и ура, при вызове d() с любым объектом FieldType, будет попытка вызвать функцию some_func() поля tt.
Причем, компилятору будет пофиг, что tt на момент вызова может быть не инициализировано. Код будет сгенерирован.
Программист должен самостоятельно обеспечить валидность объекта этот момент, ручками проинициализировав его
заранее.

VD>А если так попробовать:
VD>

VD>class FieldType {
VD>public:
VD>    FieldType(int);
VD>};

VD>class MyClass {
VD>public:
VD>    MyClass() {}
VD>    FieldType* tt;
VD>};
VD>

Я понимаю идею. Более того, сейчас, когда мне нужно было ручками управлять существованием полей,
так и поступал: заводил указатели, и выносил поля наружу.
Разумеется, тут могут быть разные вариации: просто указатели, как в приведенном примере,
умные указатели, которые в состоянии автоматически уничтожать объект. Более того, можно
заранее прописывать в объектах буферы, в которые с помощью placement new оператора
создавать объекты.

Недостатки описанных подходов:
В первых двух вариантах, память для вынесенного по указателю поля объекта оказывается в стороне от участка
памяти с самим объектом, что при обращении к полю создает проблемы с кэшированием. Дополнительно, появляются
проблемы с фрагментацией памяти. Понятно, что лучше один большой учаток памяти на объект и поле в нем, чем два
отдельных.

Во всех вариантах, которые мне приходят в голову, есть еще один недостаток — весь доступ к вынесенному полю
идет через указатель.
По-моему, косвенный доступ через адрес в указателе медленее чем прямой, когда относительный адрес может быть вычислен на этапе компиляции. Да и простора для оптимизаций в компиляторе здесь больше: компилятору сложно делать какие-либо предположении о конкретном значении указателя. Это для человека известно, что он указывает все время жизни родительского объекта на один и тот же объект вынесенного поля.
Компилятору вряд ли легко такие факты устанавливать.
Скорее, он будет считать, что значение указателя может поменяться где угодно и когда угодно.
Соответственно, он будет и генерировать код помедленнее.

Здравствуйте, jamesq, Вы писали:

J>и ура, при вызове d() с любым объектом FieldType, будет попытка вызвать функцию some_func() поля tt.
J>Причем, компилятору будет пофиг, что tt на момент вызова может быть не инициализировано. Код будет сгенерирован.
J>Программист должен самостоятельно обеспечить валидность объекта этот момент, ручками проинициализировав его
J>заранее.

Серьезно граблей не хватает?
Это можно было бы вводить если бы C++ поддерживал жесткое разделение на классы и POD структуры и только для
POD структур, но в обычных классах ничего кроме грабель не даст.

В том же D такое разделение есть http://www.digitalmars.com/d/2.0/struct.html

И есть возможность void инициализации, то есть именно то что ты хочешь, память выделятся и ничего больше не делается:

struct FieldType {

    this(int x)
    {
    }
}

struct MyClass {

    FieldType tt = void; 
}

Здравствуйте, jamesq, Вы писали:

J>Недостатки описанных подходов:
J>В первых двух вариантах, память для вынесенного по указателю поля объекта оказывается в стороне от участка
J>памяти с самим объектом, что при обращении к полю создает проблемы с кэшированием. Дополнительно, появляются
J>проблемы с фрагментацией памяти. Понятно, что лучше один большой учаток памяти на объект и поле в нем, чем два
J>отдельных.


boost::optional посмотри, в нем почти все твои проблемы разрешены, память выделяется сразу и на месте, не инициализируется
пока не попросишь, доступ любым нормальным компилятором оптимизируется до прямого и главное совершенно никаких UB.