Но закладываться на порядок инициализации глобалов плохо. Если нужно, пиши глобалы статически в функциях, инициализируй их там, и функции, возвращающие ссылки на них, вызывай в нужном порядке. Может так и не всегда надо делать, не в каждом случае, но кое-где это может помочь упорядочить инициализацию, причём гарантированно, поскольку тут уже инициализация произойдёт при первом вызове этой содержащей фукнции, ЖЕЛЕЗНО.

А когда-то было в алфавитном порядке...

никогда не было, придумал

никогда не было, придумал

Ну было. Я не вру. Я так объходил проблемы с порядком инициализации, просто префиксы переменным давал AA_ BB_ CC_, ну, их немного было зависимых. И все проблемы уходили. Да это и объяснимо, в таблице глобальных имён модуля они же упорядочены по алфавиту, так и инициализировались

Ну было. Я не вру. Я так объходил проблемы с порядком инициализации, просто префиксы переменным давал AA_ BB_ CC_, ну, их немного было зависимых. И все проблемы уходили. Да это и объяснимо, в таблице глобальных имён модуля они же упорядочены по алфавиту, так и инициализировались

Ильюх, не было!!!

Ильюх, не было!!!

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

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

строго по стандарту, в порядке определения в одной единице трансляции

Ну было. Я не вру. Я так объходил проблемы с порядком инициализации, просто префиксы переменным давал AA_ BB_ CC_, ну, их немного было зависимых. И все проблемы уходили. Да это и объяснимо, в таблице глобальных имён модуля они же упорядочены по алфавиту, так и инициализировались

Мб в нестандартном компиляторе так было?

Мб в нестандартном компиляторе так было?

Так до 98 го года все компиляторы были нестандартными...

Да.

Ну и после тоже были некоторые :)

Так до 98 го года все компиляторы были нестандартными...

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

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

А ты думаешь, кто С++ придумал ?

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

Мб это в фортране было, а? Там любят всякие префиксы и вообще трюки с именами.

Нет. И не любят

Нет. И не любят

Ага, поэтому у них переменные с именем i или j имеют тип integer а с именами d или f - float

Ну, это уж очень давно было.

Ага, поэтому у них переменные с именем i или j имеют тип integer а с именами d или f - float

Кстате, вот В FORTRAN-е -то МОДУЛИ УЖЕ ДАВНО ЕСТЬ!

Поддержка фортрана и в clion'е есть. То есть перспективность и распространенность фортрана примерно как у раста :-)

Поддержка фортрана и в clion'е есть. То есть перспективность и распространенность фортрана примерно как у раста :-)

Неа, распространённость фортрана больше - на нем есть как минимум 10 программ :)

Ждем поддержки Ады в clion'e!

У меня пропосал в стандарт, давайте, чтобы не нужно было писать так: if (Qt::DisplayRole == role) сделаем возможность писать в операторе сравнения сколько угодно равенств, больше одного. Т.е. чтобы можно было писать что-то типа if ( role ============= Qt::DisplayRole) Уж тогда-то точно невозможно будет спутать == и = ...

У меня пропосал в стандарт, давайте, чтобы не нужно было писать так: if (Qt::DisplayRole == role) сделаем возможность писать в операторе сравнения сколько угодно равенств, больше одного. Т.е. чтобы можно было писать что-то типа if ( role ============= Qt::DisplayRole) Уж тогда-то точно невозможно будет спутать == и = ...

Ты PHP какой-то изобретаешь.

У меня пропосал в стандарт, давайте, чтобы не нужно было писать так: if (Qt::DisplayRole == role) сделаем возможность писать в операторе сравнения сколько угодно равенств, больше одного. Т.е. чтобы можно было писать что-то типа if ( role ============= Qt::DisplayRole) Уж тогда-то точно невозможно будет спутать == и = ...

Убираем operator= и нет проблем, делов то

Убираем operator= и нет проблем, делов то

А присваивать как? LET ?

А присваивать как? LET ?

memcpy)))))

std::assign

Чтобы типобезопасно

int a = 42; int b; let b = a; ?

memcpy)))))

memcpy не присваивает...

memcpy не присваивает...

ну создаешь обьект, потом из другого все копируешь

ну или через copy constructor

int a = 42; int b; let b = a; ?

std::assign(b, a), долой всякий сахар

Да!

кроме того, введение еще одного ключевого слова (let) никогда не пройдет через комитет, ибо точно ломает чей-нибудь код.

У меня пропосал в стандарт, давайте, чтобы не нужно было писать так: if (Qt::DisplayRole == role) сделаем возможность писать в операторе сравнения сколько угодно равенств, больше одного. Т.е. чтобы можно было писать что-то типа if ( role ============= Qt::DisplayRole) Уж тогда-то точно невозможно будет спутать == и = ...

Давайте еще знак > в конце разрешим

Давайте еще знак > в конце разрешим

оператор меч: ==|————>

Парни, а есть перевод той штуки от саттера? 3 дня назад что. Чёт я не понял про контракты. Они стандартную библиотеку хотят на контракты переписать?

Ждем поддержки Ады в clion'e!

А они уже поддерживают С++ ? :)

А они уже поддерживают С++ ? :)

ну, говорят что вот прям c++17 уже ага. плюс они теперь clang'ом пользоваться научились для анализа кота.

ну, говорят что вот прям c++17 уже ага. плюс они теперь clang'ом пользоваться научились для анализа кота.

clang это из коробки или настраивать два часа?

int a = 42; int b; let b = a; ?

что-то бейсиком попахивает)

года два назад они const в сигнатуре member function не показывали

clang это из коробки или настраивать два часа?

искаропки вроде. но можно и сторонний.

Парни, а есть перевод той штуки от саттера? 3 дня назад что. Чёт я не понял про контракты. Они стандартную библиотеку хотят на контракты переписать?

да, на контракты и концепты

да, на контракты и концепты

Слушай, а вот, например, vec.at(i) теперь не будет выкидывать out_of_range?

@antoshkka а вы не вспомните, не было proposal по разъобявлению с перемещением? Т.е. как move, только потом еще использовать нельзя

Слушай, а вот, например, vec.at(i) теперь не будет выкидывать out_of_range?

Будет Зато вот vector::operator[](unsigned i) будет обложен контрактом, что i < size()

@antoshkka а вы не вспомните, не было proposal по разъобявлению с перемещением? Т.е. как move, только потом еще использовать нельзя

чтобы как в расте?

чтобы как в расте?

чтобы ногу не отстреливать

@antoshkka а вы не вспомните, не было proposal по разъобявлению с перемещением? Т.е. как move, только потом еще использовать нельзя

Было, не взлетело :(

Было, не взлетело :(

А в чем проблема была?

Я для такого scope пихаю, но это не всегда спасает.

Будет Зато вот vector::operator[](unsigned i) будет обложен контрактом, что i < size()

Сейчас это даст мусор или упадёт. А что дадут контракты?

то же, что дал бы assert в этом месте

Но ассерт он только для дебага

Ну а тут чуть больше возможностей по конфигурации проверки.

Сможешь оставить в релизе

Но ассерт он только для дебага

Через пару часов должен выйти пост на хабр, там будет про контракты )

ERROR: S client not available

Ееееее

Cool!

Сможешь оставить в релизе

То есть все равно упаду с ассертом в релизе)

Напишешь свой violation handler, где будешь кидать исключение, и перехватишь где-нибудь. Тогда упадешь красиво

Не потеряв лицо

Напишешь свой violation handler, где будешь кидать исключение, и перехватишь где-нибудь. Тогда упадешь красиво

Хм... стоп! Проверки остаются в релизе или не остаются?

А в чем проблема была?

Само предложение http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf Его рассмотрели, сказали автору работать над ним дальше, и с конца 2014 года нет новостей

Само предложение http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf Его рассмотрели, сказали автору работать над ним дальше, и с конца 2014 года нет новостей

а какие возражения были?

Само предложение http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf Его рассмотрели, сказали автору работать над ним дальше, и с конца 2014 года нет новостей

Хм.. это не совсем то. Я хочу именно синтаксически запретить дальнейшее использование переменной (текущего scope?), при этом никак не влияя на что-либо остальное в коде.

Хм.. это не совсем то. Я хочу именно синтаксически запретить дальнейшее использование переменной (текущего scope?), при этом никак не влияя на что-либо остальное в коде.

по типу nodiscard, но наоборот?

Хм.. это не совсем то. Я хочу именно синтаксически запретить дальнейшее использование переменной (текущего scope?), при этом никак не влияя на что-либо остальное в коде.

Я тоже это когда-то хотел. Причём хотел запретить повторную операцию над переменной, например два раза складывать

Хм... стоп! Проверки остаются в релизе или не остаются?

Из того, что я помню - опции по конфигурации - implementation defined. Как задашь при компиляции, так и будет.

по типу nodiscard, но наоборот?

По типу auto temp1 = /*результат промежуточных вычислений*/; auto temp2 = foo(std::move(temp1)); /*вот это последнее использование temp1*/

Или что-то вроде async queue.post(move(msg)).

а какие возражения были?

Там предложение было в виде библиотекчной фигни. С ней возникали проблемыс lifetime при memcpy нетривиального объекта

т.е. технически я хочу foo(NO_MORE_USAGE(temp1)); со сложными условиями вроде foo(NO_MORE_USAGE(temp1), NO_MORE_USAGE(temp1)); //сразу CE foo(temp1, NO_MORE_USAGE(temp1)); //Implementation defined

при этом lifetime temp1 не меняется, просто компилятор плюется

Я тоже хочу :)

в общем, хочется как в растах всяких, чтобы: fn main() { let foo = Foo { value: 42 }; let bar = foo; println!("{}", foo.value); // compile time error: use of moved value: `foo.value` println!("{}", bar.value); }

Само предложение http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf Его рассмотрели, сказали автору работать над ним дальше, и с конца 2014 года нет новостей

Потому что вы все бюрократы!

Первая проблема - это иcользование между единицами трансляции // foo.hpp void foo(something& bar); // foo.cpp void foo(something& bar) { some_thing(std::move_destruct(bar)); } Как омпилятору понять, что после вызова foo пользоваться bar нельзя. Новый интаксис сделать?

Первая проблема - это иcользование между единицами трансляции // foo.hpp void foo(something& bar); // foo.cpp void foo(something& bar) { some_thing(std::move_destruct(bar)); } Как омпилятору понять, что после вызова foo пользоваться bar нельзя. Новый интаксис сделать?

Мои проблемы касались исключительно текущего scope (и да, отдельный оператор)

Да, го сделаем новую ссылку?) &&&

Да, го сделаем новую ссылку?) &&&

Это отдельный вопрос)

Ну или взять кусочек из управляемого C++ и заюзать ^

и destructive forwarding сделаем )

Да!

std::tru_move