Завершилась длительная эпопея по принятию нового стандарта на язык Си++. Комитет ISO по стандартизации языка C++ единогласно утвердил (http://herbsutter.com/2011/08/12/we-have-an-international-st.../) спецификацию C++0X (http://www2.research.att.com/~bs/C%2B%2B0xFAQ.html) в качестве международного стандарта "C++11". Стандарт C++0X планировалось выпустить еще в 2008 году, но его принятие постоянно откладывалось. Большинство представленных в стандарте возможностей уже поддерживаются (http://wiki.apache.org/stdcxx/C++0xCompilerSupport) в таких компиляторах, как GCC (http://gcc.gnu.org/projects/cxx0x.html), IBM C++ (http://www2.research.att.com/~bs/C%2B%2B0xFAQ.html), Intel C++ (http://software.intel.com/en-us/articles/c0x-features-suppor.../) и Visual C++ (http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-...). Поддерживающие C++11 стандартные библиотеки (http://www2.research.att.com/~bs/C%2B...URL: http://herbsutter.com/2011/08/12/we-have-an-international-st.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=31476
>>Вместо макроса NULL для обозначения нулевого указателя введено ключевое слово nullptr;Забавно... А чем плох NULL?
> Забавно... А чем плох NULL?ключевое слово и макрос - разницу чувствуете?
Для повышения читабельности кода, лучшего обнаружения ошибок и определения перегрузок процедур и функций. Более подробно http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n148...
>14/88Я всегда знал что тут что-то не чисто.
> Для повышения читабельности кода, лучшего обнаружения ошибок и определения перегрузок
> процедур и функций. Более подробно http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n148...Ага, примерно понятно, спасибо.
> Для повышения читабельности кода, лучшего обнаружения ошибок и определения перегрузок
> процедур и функций. Более подробно http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n148...Кстати, вот ссылка на более свежую ревизию, пара интересных пояснений добавилось - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n243...
NULL не имеет типа.
А какой тип у nullptr?
у него тип указатель. например есть перегруженная функция:int foo(int a);
int foo(Type* a);сейчас при вызове foo(0) будет неоднозначность и нужно будет 0 явно кастить. в 0х можно будет написать foo(nullptr) и компилятор разберется.
Дык, а чем foo(nullptr) лучше, чем foo(NULL) ? Там ведь, вроде, каст к указателю уже встроен в макрос. Или нет?
#ifndef __cplusplus
#define NULL ((void *)0)
#else /* C++ */
#define NULL 0
#endif /* C++ */Я так думаю, nullptr - не просто указатель, а указатель на объект _любого типа_ - то, вместо чего сейчас используется костыль #define NULL 0.
> #ifndef __cplusplus
> #define NULL ((void *)0)
> #else /* C++ */
> #define NULL 0
> #endif /* C++ */
> Я так думаю, nullptr - не просто указатель, а указатель на объект
> _любого типа_ - то, вместо чего сейчас используется костыль #define NULL
> 0.Это откуда код? Как я понял из приведённого выше документа, реализация сильно разнится от компилятора к компилятору, в частности в GCC вообще
#define NULL __nullА ценность именно nullptr, как я понял, именно в том, что оно ключевое слово, а не макрос, объект и иже с ними, то есть до компилятора гарантированно доходит в первоначальном виде.
А ещё там есть забавный момент - nullptr не может быть приведён к целому (и дробному, разумеется =)) типу, и в том числе к bool. В связи с этим возникает вопрос: а можно ли будет писать if(my_ptr), или придётся писать if(my_ptr != nullptr)? По идее должно быть можно, потому что запрет на приведение типа должен работать только для этого ключевого слова, а нулевой указатель по-прежнему имеет значение 0 и может быть приведён к целому типу, но мало ли...
> Это откуда код? Как я понял из приведённого выше документа, реализация сильно
> разнится от компилятора к компилятору, в частности в GCC вообще
> #define NULL __nullЭто код из GCC. Полностью так:
/* A null pointer constant. */
#if defined (_STDDEF_H) || defined (__need_NULL)
#undef NULL /* in case <stdio.h> has defined it. */
#ifdef __GNUG__
#define NULL __null
#else /* G++ */
#ifndef __cplusplus
#define NULL ((void *)0)
#else /* C++ */
#define NULL 0
#endif /* C++ */
#endif /* G++ */
#endif /* NULL not defined and <stddef.h> or need NULL. */
#undef __need_NULL
__null в GCC, я так думаю, - это и есть nullptr.> А ценность именно nullptr, как я понял, именно в том, что оно
> ключевое слово, а не макрос, объект и иже с ними, то
> есть до компилятора гарантированно доходит в первоначальном виде.Не понял, что значит "в первоначальном виде". Вообще по стандарту NULL - это указатель, который гарантированно не равен любому указателю на объект или функцию, и, по идее, ((void*)0) должно быть достаточно для большинства приложений. Не знаю, почему это нельзя использовать в С++.
> Не знаю, почему это нельзя использовать в С++.На самом деле, да, нельзя - из-за перекрываемых функций.
>>Не понял, что значит "в первоначальном виде".Ну в том смысле, что макрос разворачивается препроцессором и компилятор в процессе работы не знает, что именно там было написано программистом - 0 или NULL, а с объектом вообще по дороге фиг знает что произойти может (мало ли что программисту придёт в голову), а с ключевым словом ничего сделать нельзя и компилятор в процессе компилирования чётко знает, что тут должен быть именно нулевой указатель и ни что другое и на основе этого может матюгаться на программиста или выводить типы.
А что касается почему не ((void*)0) см. пункт 1.2 приведённого выше документа. Хотя там, конечно, несколько не очевидно написано.
> NULL не имеет типа.Правильно, есть только низкий и высокий потенциал на проводнике,
а остальное флуд, так как у напряжения не бывает типов.
Точнее бывает, переменное и постоянное, но это по времени.
А человек существо тупое - оно ещё со статическим программирование
не разобралось, чего уж говорить про написание программ с модифицирующимися
во времени алгоритмами.
> а остальное флуд, так как у напряжения не бывает типов.Ну просто некоторым хочется извратиться :). Господи, эти извращенцы даже для нуля с типом определиться не могут.
Ошибка на миллиард.
теперь еще до конца года ждать пока выпустят официальную документацию в виде книг
> теперь еще до конца года ждать пока выпустят официальную документацию в виде
> книгА потом еще пару лет, пока Мейерс и Саттер литературу выпустят :)
> Реализация ключевого слова "constexpr", позволяющего указать, что выражение (функция или конструктор) возвращает константу и данные выражения можно использовать как константы, например: "constexpr int GetFive() {return 5;}". В дальнейшем GetFive можно указать, например, при определении массива "int some_value[GetFive() + 7];";Не понимаю, зачем это. Не проще ли использовать константы как константы?
Очевидно для сверхзаумных констант, которые на препроцессоре выглядят нехорошо, и тип отслеживается
Я так понимаю, что для того, чтобы можно было удобно рассчитать какие-то константы во время компиляции. Вот есть у тебя несколько констант. И некоторые от них зависят от других сложным образом (т.е. в одну строчку не запишешь), просто пишешь constexpr функцию, которая всё это аккуратно считает и используешь её потом.
Так написано же, для чего(в качестве примера)...
int val[getElementsCount()];
Сейчас так делать нельзя (это вам не жаба)
ну то на русском тока, на английском я думаю гораздо раньше выйдут. Наверняка у Мейерса, Саттер, Джосаттиса есть уже заготовки :). А вот Александреску вроде совсем на D свалил
до конца года хотя бы на инглыше
на русском годика через два три
Ну в D есть много понятного и разумного. В С++ уже нет...
С++ переусложнённый язык. Boost — это вообще монстр макроопределений и шаблонов.
> С++ переусложнённый язык.не осилил, так и скажи
но всех тонкостей знать не обязательно> Boost — это вообще монстр макроопределений и шаблонов.
библиотека != язык
ps
и да, java гадость ;)
Как-будто так много изменилось… Лучше объясните мне какой прок от лямбда-функций. >_<
> Как-будто так много изменилось… Лучше объясните мне какой прок от лямбда-функций.
> >_<Вроде для быстрых собраных на на коленке компактных однострочников в стиле Pearl, [вброс]ну и вообще обфускация кода выйдет на новый уровень[/вброс]
>> Как-будто так много изменилось… Лучше объясните мне какой прок от лямбда-функций.
>> >_<
> Вроде для быстрых собраных на на коленке компактных однострочников в стиле Pearl,
> [вброс]ну и вообще обфускация кода выйдет на новый уровень[/вброс]В С++, на мой взгляд, не нужны.
Угу. И шаблоны тоже. Не говоря уже про классы. Зачем они вообще нужны? Структур вполне хватает.
> Лучше объясните мне какой прок от лямбда-функций.Теоретики на них любят фапать. В остальном - можно и без них прекрасно обойтись. Хотя для написания неочевидного кода в стиле брейнфака - самое оно :)
>> Лучше объясните мне какой прок от лямбда-функций.
> Теоретики на них любят фапать.Лоровские, что ли?
> В остальном - можно и без них прекрасно обойтись.
Без математики тоже можно программировать, несмотря на складывавшийся в совейское время стереотип. Только вот он не зря складывался.
Ммм... вот одни в школе алгебраическую задачку решают и пишут присваивание каждой строчкой, а другие в голове и пишут каждую вторую-третью строку продолжением (как чекпоинт для дебуга ;-). Так вот в программировании без возможности сделать делалку не получается прыгать через ступеньку, так и останешься кодером.
Думаю не так много до окончательного разделения ( разраб/кодер ), т.к. для проверки своих мыслей и набросок исполняемого кода при разработке многих алгоритмов уже не нужно знание низкоуровневых языков, почему-то кажется что скоро появится профессия "интеллектуальный транслятор кода в ... из высокоуровневых систем разработки"
ну очевидно ж, чтобы по нормальному использовать stl-ные алгоритмы.
> Как-будто так много изменилось… Лучше объясните мне какой прок от лямбда-функций.
> >_<Можно писать вполне читаемые фанкторы:
find_if( a.begin(), a.end(), []( int i ) { return f1(f0(i)); } );
На ISO/IEC-2003 придётся нарисовать класс с operator ()( int i ){ ... } внутри. По тексту (в старом написании) получится гораздо многословнее и будет гораздо менее очевидно --- что оно делает.
> Можно писать вполне читаемые фанкторы:
> find_if( a.begin(), a.end(), []( int i ) { return f1(f0(i)); } );Взаимоисключающие параграфы.
>> Можно писать вполне читаемые фанкторы:
>> find_if( a.begin(), a.end(), []( int i ) { return f1(f0(i)); } );
> Взаимоисключающие параграфы.Т.е. Вы, сударь, утверждаете, что
struct foo
{
bool operator()( int i )
{ return f1(f0(i)); }
};/* ... a lot of lines ... */
find_if( a.begin(), a.end(), foo() );
будет читаемей?
Читаемые? Ха-ха три раза. Зачем из С++ делать Питон? Может быть, лучше сразу писать на Питоне?
К С++ прицепили парашут тормозной и вышел Питон?
Лямбды не делают из C++ питона. А на питоне лучше вообще ничего не писать.
> Лямбды не делают из C++ питона. А на питоне лучше вообще ничего
> не писать.так называемые «лямбды» не делают из c++ ничего, кроме очередного монстрика-уродца. потому что о каких лямбдах вообще может идти речь в языке без gc, замыканий и вменяемых HOF?
а «нововведение» дико смешно: очнулись, наконец. цитата из документашек по gcc:
#define lambda(return_type, body_and_args) \
({ \
return_type __fn__ body_and_args \
__fn__; \
})Use it like this:
int (*max)(int, int) = lambda (int , (int x, int y) { return x > y ? x : y; });
Or with qsort:
qsort (array, 42, sizeof (int), lambda (int, (const void * a, const void * b)
{
return *(int*)a - *(int*)b;
}));
да и вообще — читать про compounds, typeof, local labels и прочие кошерные вещи, которые кучу лет уже как есть и работают. а тут, наконец, и до Зоркого Глаза допёрло, что у сарая стены нет.
Ну, ладно, ладно, не делают... Неудачный я пример с Питоном привёл, согласен. Смысл был в том, что не надо приспосабливать микроскоп для забивания свай.
Что за бред-то? Не умеете/не хотите использовать лямбды - не используёте, для вас в языке ничего не изменилось. А нормальные люди используют, и плевать они хотели на вас.
> Зачем из С++ делать Питон?При чём тут Питон и то, что Гвидо противится попыткам сделать из него этакий новый лисп?
но реальной замены ему пока что вроде бы нет
Реальная замена С++ - это Си.
> Реальная замена С++ - это Си.C не замена C++.
> C++ не замена C.fixed
Расслабься и учи. Других языков всё равно нет.
Есть, причем много. Хороших и разных.
> С++ переусложнённый язык. Boost — это вообще монстр макроопределений и шаблонов.Троли с LOR'а делают вбросы на опеннете.
Было уже обсуждение. Доболтались до того, что C++ отстой, но нет ничего лучше.
Ибо каждый идеальный для конкретной задачи инструмент имеет свой изъян (ограничение). Да и подход для каждой задачи свой идеальный инструмент означает, что для каждой задачи отдельный программист. Еще трудности возникнут про необходимости объединить инструменты (обмен данными между ними, например).
C++ переусложнен по причине наследства C и широты решаемых задач (от встраиваемых решений до реалтаймовых транзакций в кластерах бирж). Язык, ориентированный на более узкий круг задач, наверняка, можно сделать проще.
Стандарт C++0x ждал давно, доволен его официальным утверждением. Уже использую в своих проектах.
> Было уже обсуждение. Доболтались до того, что C++ отстой, но нет ничего
> лучше.Если бы это было так, то ничем, кроме С++, никто не пользовался бы.
> Ибо каждый идеальный для конкретной задачи инструмент имеет свой изъян (ограничение). Да
> и подход для каждой задачи свой идеальный инструмент означает, что для
> каждой задачи отдельный программист. Еще трудности возникнут про необходимости объединить
> инструменты (обмен данными между ними, например).Именно так. Только отдельный программист\инструмент не для каждой конкретной задачи, а для каждого класса задач. Это называется специализация. С++ же пытается решать все классы задач, в результате чего получился раздутый переусложнённый монстр.
> C++ переусложнен по причине наследства C и широты решаемых задач (от встраиваемых
> решений до реалтаймовых транзакций в кластерах бирж). Язык, ориентированный на более
> узкий круг задач, наверняка, можно сделать проще.С++ переусложнён не по причине наследства Си. Си сам по себе довольно простой язык. Переусложнение возникает когда бабушке пытаются приделать яйца и сделать из неё дедушку.
Добрый день!>Большинство представленных в стандарте возможностей уже поддерживаются в таких
>компиляторах, как GCC........
>Возможность вызывать одни конструкторы класса из других конструкторов этого же
>класса, что позволяет создавать конструкторы, использующие другие конструкторы
>без дублирования кода;Хочу. Только вот у меня gcc на это дело ругается... Может ему чего-то включить нада?
Знающие люди подскажите PLS.ps:
Если "Inheriting Constructors" это оно - тогда вопрос исчерпан.pps: Разобрался.
Фича называется "Delegating Constructors" Но без патча gcc ее не ест.Таким образом говорить про описание, видимо, рановато. Надо, чтобы еще и компиляторы всё это дело понимали.
g++ -std=c++0x
> Кроме того, язык стал проще для изучения и освоения новичками.Ага
cout << x << (2 << *y) << endl;
или для понимания:
cout << x shl (2 shl *y) << endl;
Precedence << - слева направо, так чтоcout << x << (2 shl *y) << endl.
> cout << x << (2 shl *y) << endl.Вставил цитирование "язык стал проще для изучения и освоения новичками. "
Мне надо:
x << (2 << *y)
1) 2 сдвинуть на то, что находиться по адреcу *y.
2) x сдвинуть на то, что получилось в предыдущем выражении.
3) вывести на консоль.
4) добавить конец строки.в С++ нет оператора shl.
можно подумать в других проще.
вот так лучше что ли будет?
>{
> char hex[] = { '0', '1, '2', '3', '4', '5', '6',
> '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f };
> byte b = (byte) 0xf1;
> System.out.println("b = 0x" + hex[(b >> 4) & 0x0f] + hex[b & 0x0f]);
> }http://khpi-iip.mipk.kharkiv.edu/library/oop/kart/05.html
офигенно понятно для новичка. что доказывает:
- что чтение доки лишним никогда не бывает;
- предметную область знать нужно;
- и не стоит писать плохо понятный код (где из твоего кода понятно что y не класс к примеру с переопределенным оператором?) в одну строчку, даже если С++ это позволяет (для кого инлаййн придумали? да даже макросы?)
А если в алгебраическом выражении скобки забудешь, математика тоже станет "сложной и неудобной"?
> 1) 2 сдвинуть на то, что находиться по адреcу *y.
> 2) x сдвинуть на то, что получилось в предыдущем выражении.
> 3) вывести на консоль.
> 4) добавить конец строки.Вы вообще не знаете языка, я правильно понял?
std::cout << (x << (2 << *y)) << std::endl;
> в С++ нет оператора shl
Вы сами первый его написали. Отвечающие любезно продолжили его использовать чтобы вам было понятнее.
> std::cout << (x << (2 << *y)) << std::endl;Вот позовите к экрану блондинку изучавшую в универе только Паскаль,
и попросите объяснить написанное.Так же добавьте, что сама конструкция с "<<", работает по разному,
в зависимости от операнда.
#define x (x << (2 << *y))// где-то через строчек 200
std::cout << x << std::endl;// и ещё через 200
#undef x// а потом
std::cout << x << std::endl;// и в конце
#endif
...У неё моск раком встанет. И правильно сделает, потому что двоякая
интерпретация это не есть хорошо.Та же фигня с операцией ","
int x = -5;
int y = 3;
int z = -7;Чему будет равно z
при
z = (x, y);
при
z = x,y;
при
z = !x,!y;
при
z = (!x,!y);---
Уже вижу, как Вы, стоят у доски в качестве преподавателя, ловите
бурные овации с потоком тухлых помидоров.
Я порадуюсь, если у нее мозг раком встанет. Ибо блондинок не надо.
Пущай лучше она пишет ..в твиттер, например. :)
> Я порадуюсь, если у нее мозг раком встанет. Ибо блондинок не надо.
> Пущай лучше она пишет ..в твиттер, например. :)К Сожалению C++ появился тогда когда люди решали не только проблему какой сделать синтаксис, но и проблему "сколько символов для реализации задачи понадобится" поэтому так и вышло, 90% кода который попадается не на c++ читается нормально, c++ постоянно ловишь себя на мысли что приходиться задумываться "что же в этом месте происходит".
> К Сожалению C++ появился тогда когда люди решали не только проблему какой
> сделать синтаксис, но и проблему "сколько символов для реализации задачи понадобится"ты спутал его с C.
>> К Сожалению C++ появился тогда когда люди решали не только проблему какой
>> сделать синтаксис, но и проблему "сколько символов для реализации задачи понадобится"
> ты спутал его с C.ну т.к. с++ возник как дополнение к c это не сильно принципиально, но в начале 80-х тема объёма исходников ещё была актуально, в середине 90-х уже нет.
> cout << x << (2 << *y) << endl;
> или для понимания:
> cout << x shl (2 shl *y) << endl;А я своему коллеге по этому поводу скажу просто и ясно - иннах поспи и не выеживайся. Как проспишься - проходи, обсудим. Это если в реале. Ну а в теории - да, по настроению, буду сопли наматывать на локти лишь бы пофлеймить на пустом месте.
Два года уже весь продакшн код только на 0x. Без rvalue references/move semantics C++ вообще не нyжен.
в какой конторе?
> в какой конторе?Anonymous, Gmbh -- очевидно же.
> Anonymous, Gmbh -- очевидно же.Broken & Late, ltd ;)
Все ясно... Как в свое время ползли мобильники и смартфоны друг к другу. Так сейчас ползет C++ к Java. Ну осталось совсем немного подождать... Пока доползут...
Судя по тому, что в сомнительных комментариях к статье ничего кроме Java не упоминают, я делаю вывод, что народ ничего другого и не знает.Сейчас что в школах/колледжах только Java преподают?
> Судя по тому, что в сомнительных комментариях к статье ничего кроме Java
> не упоминают, я делаю вывод, что народ ничего другого и не
> знает.
> Сейчас что в школах/колледжах только Java преподают?просто при разработке синтаксиса Java уже знали о проблемах предшественников, хотя и своих немного добавили
C++ станет таким же быстрым, как Java, а Java станет такой же надёжной и простой, как C++.
> Все ясно... Как в свое время ползли мобильники и смартфоны друг к
> другу. Так сейчас ползет C++ к Java.Скорее нет. Я вот в итоговом документе 'java-измов' не наблюдаю.
> Ну осталось совсем немного подождать... Пока доползут...
Из того, что сейчас оформилось, в процессе подготовки выкинули сильно лоббированный одной фирмой garbage collector.
> Из того, что сейчас оформилось, в процессе подготовки выкинули сильно лоббированный одной
> фирмой garbage collector.И абсолютно правильно сделали. RAII и смарт-поинтеры и без gc справляются.
Всем привет!
Я очень рад, что наконец стандарт С++11 утвержден, будем теперь только ждать доки и с удовольствием изучать. Мы застали новую ступень эволюции С++!
То что С++ становится похож на Java - не факт. Java не настолько гибка как С++, в то время как с появлением стандарта С++11 - C++ становится еще гибче чем был. Меня например очень радует появоение возможности создавать шаблоны с переменным числом аргументов.
не гибче, а монструозней.
Нет, тут есть одна деталь.С одной стороны:
новичку, изучить базовые конструкции С++ и начать ими пользоваться, думаю сейчас станет легче. Но это не сделает его професионалом, т.к. все эти нововведения (новая конструкция for, и пр.) - верхушка айсберга.с другой стороны:
для того чтобы стать професионалом - теперь надо знать куда больше чем раньше - так как язык значительно расширился.
Здесь можно посмотреть поддержку компиляторами нового стандарта
http://wiki.apache.org/stdcxx/C++0xCompilerSupport
А как насчет поддержки MinGW?
> А как насчет поддержки MinGW?а кого волнует винда? у вас есть свой компилятор, от m$ — вот к ним и пишите, пусть поддержку пилят.
правда, учитывая, что C99 они не смогли осилить за более чем десять лет… ну, я бы не надеялся.
учитывая что большенство плюшек С99 используется в linux ядре
то вопрос о том кто его проталкивает более чем очевиден
и что?
не, нужно оставновить развитие всяких сейпласплас и срочно пересесть на дотнет/моно?зыж
а какое отношение С99 имеет к С++0X (да и просто С++) вообще, и к ядру линуха в частности?
опять ограничение знаний подвело "удачный" тролизм счастливого обладателя винды?
анонимы как всегда весь треид не читают
ишут подходящее выражение что бы вставить именно свое словцо?
Ха! вопрос про мингв (который таки и с++ и таки соотносится с сабжем) только таких умников как ты может привести к гцц специфик в ведре, который исключительно на С.
Пиши ищё. :D
ты таки в пролете, потому что я отвечал на плюшки c99
и то, почему M$ особо не спешит их осваивать
в M$ на плаин C только ядро, и то не все, остальная часть драйверов итд на c++
поэтому закидоны насчет c99, идите пишите в комитет
этот стандарт развивают отдельно и с++ он никак не касается
> учитывая что большенство плюшек С99 используется в linux ядреДа хоть в чьем ядре. Он тупо удобнее предшественников. А если до MS как до жирафа - пусть это будет их проблемой, а не моей.
>у вас есть свой компилятор, от m$M$ как раз по ссылке http://wiki.apache.org/stdcxx/C++0xCompilerSupport половину поддерживает, я понял что задал глупый вопрос потому, что MinGW порт GCC и пока очередную версию GCC портируют пройдет время, причем не известно сколько.
> причем не известно сколько.но долго, долго. потому что всем лень.
Мой комент потерли. Ладно, задам вопрос по другому. :(
Сейчас параллельно с C++0X разрабатывается очередной стандарт программирования Си под кодовым названием C1X. Мне вот интересно, они их как нибудь будут синхронизировать, дабы исключить возможность появления несовместимости, или таки решили развиваться обособленно?
Несовместимости и раньше были. И развиваются они параллельно.
Кто-нибудь понял зачем они wchar_t сделали независимым от char16_t и char32_t типом? Для того чтобы старые платформо-зависимые Unicode-ные велосипеды остались нетронутыми, но при этом и несовместимыми с новыми типами?
Да возрадуйтесь-же !!!u8"I'm a UTF-8 string."
u"This is a UTF-16 string."
U"This is a UTF-32 string."
L"This is a wide string."
... L"", produces a null-terminated array of type const wchar_t, where wchar_t is a wide-character. Neither literal type offers support for string literals with UTF-8, UTF-16, or any other kind of Unicode encodings.Поддержка L"" никуда не делась и не денется, но L"" это сферический конь в вакууме. Из за этого постоянно приходилось внешние костыли/преобразователи в unicode использовать.
> Поддержка L"" никуда не делась и не денется, но L"" это
> сферический конь в вакууме. Из за этого постоянно приходилось внешние костыли/преобразователи
> в unicode использовать.Если говорить о Linux, то там всё станет прозрачно - юзай Utf-8 везде и всё зашибись.
А в виндах WinAPI по прежнему на wchar_t, и чего с ним делать - непонятно.
То есть по-прежнему придётся писать для него костыли, ибо с char16_t оно 'не дружит', хотя по сути - оно и есть на виндах.
Наконец-то !
Особенно радует:
1. Стандартизация регекспов
2. Возможность создания шаблона функции, возвращаемый тип которого определяется автоматически на основании другой функции или выражения;
3. Возможность создавать шаблоны с переменным количеством аргументов;
4. Расширенная поддержка символов в Unicode;
5. Возможность вызывать одни конструкторы класса из других конструкторов этого же класса, что позволяет создавать конструкторы, использующие другие конструкторы без дублирования кода; (Наконец-то!!!)
6. Возможность использования локальных и безымянных типов в качестве аргументов шаблонов;
7. alignments
8. constexpr
9. decltype
10. control of defaults: default and delete && control of defaults: move and copy
11. Preventing narrowing
12. override controls: override
13. override controls: final
14. Static (compile-time) assertions -- static_assert - изумительно. Хотя вобщем-то обходились раньше своими средствами.
15. template alias - О ДА !!!
16. Container improvements: Initializer lists, Move operators, Improved push operations, Scoped allocatorsНеоднозначно:
1. atomic operations - с одной стороны хорошо: стандартизация атомарных операций; с другой плохо: атомарные операции будут определены в userland. Непонятно как это скажется на производительности по сравнению с POSIX mutex-ами. Но уже хорошо, что для использования атомарных операций, необходим специфический синтаксис, - пересечений и конфликтов с существующей кодовой базой использующей POSIX threads wrappers небудет ... Или всё-таки будет если код будет смешаным ? Неясно.
2. Rvalue references - зрэ это они. Стандартная семантика lvalue/rvalue проста как топор, и слава богу! Введение move запутает семантику, и в резулътате уменьшает прозрачность кода.
Пугает:
1. Вместо макроса NULL для обозначения нулевого указателя введено ключевое слово nullptr. При этом nullptr не является зарезервированым. Это страшно ...
2. attributes. Обязательно найдутся вендоры, которые создадут диалекты.
В общем стандарт как стандарт, хорошо что уже приняли наконец-то.
> Неоднозначно:
> 1. atomic operations - с одной стороны хорошо: стандартизация атомарных операций; с
> другой плохо: атомарные операции будут определены в userland. Непонятно как это
> скажется на производительности по сравнению с POSIX mutex-ами. Но уже хорошо,
> что для использования атомарных операций, необходим специфический синтаксис, - пересечений
> и конфликтов с существующей кодовой базой использующей POSIX threads wrappers небудет
> ... Или всё-таки будет если код будет смешаным ? Неясно.atomics и mutexes --- это, мммм, совсем разные вещи. В связи с атомиками в стандарте описаны 'модели памяти' (с отсылками к понятиям причинности событий --- см. работы по 'виртуальной синхронности'). Если их не читать/не понимать, то получается ... --- см. пост выше. Т.н. 'гарантии', в зависимости от модели памяти, в атомиках весьма сложны и нетривиальны для понимания (и неочевидны). А будут ли эти 'неочевидности' вылезать --- сильно от железа зависит.
Видимо, пришлось вводить атомики из-за весьма распространёённых (в большинстве некорректных и опасных) практик со smart-указателями и т.н. lock-free алгоритмами.
> 2. Rvalue references - зрэ это они. Стандартная семантика lvalue/rvalue проста как
> топор, и слава богу! Введение move запутает семантику, и в
> резулътате уменьшает прозрачность кода.Rvalue references совершенно необходимы для вменяемого описания move-семантики (практическое применение --- оооочень влияет на производительность, если объект удовлетворяет определённым ограничениям).
>> atomics и mutexes --- это, мммм, совсем разные вещи.Спасибо К.О. А то я незнал что атомики и mutex разные вещи. Однако все "атомарные" операции реализуются mutex-ами за неимением атомарных типов/операций в языке. То-есть mutex-ом вы осуществляете лок/анлок. Я к сожалению прямо сейчас в код gcc зелезть не могу, поэтому незнаю использованы ли старые грин-тред наработки для реализации атомиков, то-есть юзерлэнд или используются средства ОС. для меня актуальны *nix, соответственно , - POSIX.1c вообще и mutex-ы в частности. Если использован POSIX.1c, то песня одна, а если юзерлэнд, то совсем другая. У меня большая кодовая база завязана на POSIX.1c wrappers.
>> Rvalue references совершенно необходимы для вменяемого описания move-семантики (практическое применение --- оооочень влияет на производительность, если объект удовлетворяет определённым ограничениям).
По поводу Rvalue references, вы неправы, это совсем другой move. Почитайте внимательно документацию.
> >> atomics и mutexes --- это, мммм, совсем разные вещи.
> Спасибо К.О. А то я незнал что атомики и mutex разные вещи. Однако все "атомарные" операции реализуются mutex-ами за неимением атомарных типов/операций в языке.Какие мутексты, какие атомарные типы/операции?!
Если мне память не изменяет, то уже лет 15+ известные мне архитектуры имеют соответствующие ассемблерные инструкции для атомарной работы с "переменными" в памяти.
На х86 атомарными инструкциями можно работать с 8,16,32 битовыми ячейками, на х86-64 еще и с 64битовыми.
А через мутексы атомарные операции реализуются только для типов, которые не подпадают под вышеназванные размеры для целевой платформы.
Яволь TSL инструкция зовётся :) (test and set lock)
На этой инструкции базируются все синхронизационные механизмы, такие как мутексы и семафоры. Без неё это просто не работало бы, ибо нужно всегда быть уверенным что флажок отвечающий за занятость критической секции будет переписано только одним потоком.
> Без неё это просто не работало бы, ибо нужно всегда быть
> уверенным что флажок отвечающий за занятость критической секции будет переписано только
> одним потоком.а мужики-то не знают
гуглите алгоритм дейкстры
Слышал звон, не знаю где он? :D
"Алгоритм дейкстры" совершенно никак сюда не относится к данной проблеме.
Дейкстра ввёл понятие семафоров, с операциями probeer и verhoog (отсюда P и V) - но это ниразу не его алгоритм. (во всём мире под алгоритмом Дейкстры понимают алгоритм поиска кратчайших путей во взвешенном графе).
Только вот как не поверни, но без TSL инструкции семафор работать НЕ будет. Поскольку изменение счётчика семафора и проверка его должны выполняться атомарно и всё тут.Специально для вас:
http://en.wikipedia.org/wiki/Semaphore_(programming)
".... This approach does not work on multiprocessor systems where it is possible for two programs sharing a semaphore to run on different processors at the same time. To solve this problem in a multiprocessor system a locking variable can be used to control access to the semaphore. The locking variable is manipulated using a test-and-set-lock (TSL) command."
Мне ваши сообщения напоминают пересказ содержимого обрывков старой газеты с гвоздика в сельском сортире, поясню почему. Дело в том, что инструкцию tsl описывал Таненнбаум в 80х-90х годах, во всех изданиях и всех версиях всех кирпичей содержащих в названии "операционные системы" содержится одна и та же глава про синхронизацию процессов. Но, если читать полностью, то рядом же описывался алгоритм Петерсона, не требующий данной инструкции, то есть, если читали Таненнбаума - то читали не полностью, читали обрывок газеты в условиях отсутствия других источников информации. Опять же, почему газета была старая - в наше время, при наличии проблемы неконсистентности памяти на многопроцессорных системах, инструкция tsl немного устарела, это была б актуальная ремарка в середине - конце 90х, не позже.
Читал я про этот алгоритм, газетка того же года из той же деревни, название запамятовал.
Busy-waiting не самый эффективный способ, но не важно.
Окей, если не TSL, то CMPXCHG.
> Спасибо К.О. А то я незнал что атомики и mutex разные вещи.
> Я к сожалению прямо
> сейчас в код gcc зелезть не могу, поэтому незнаю использованы ли
> старые грин-тред наработки для реализации атомиков, то-есть юзерлэнд или используются
> средства ОС. для меня актуальны *nix, соответственно , - POSIX.1cне надо лезть в код gcc своими грязными руками.
они специально для вас выложили наружу инстриники.
которые, естественно, никакого отношения к libpthread не имеют.
> 5. Возможность вызывать одни конструкторы класса из других конструкторов этого же класса,
> что позволяет создавать конструкторы, использующие другие конструкторы без дублирования
> кода; (Наконец-то!!!)Что наконец-то? Ещё одна ложка синтаксического сахара? Ничего не слипнется?
Дублирование кода можно избежать, если вынести его в отдельную функцию.
> Дублирование кода можно избежать, если вынести его в отдельную функцию.Да, но.. Инициализация в отдельной функции не отменяет инициализацию в конструкторе. Двукратная инициализация может дорогого стоить.
>> Дублирование кода можно избежать, если вынести его в отдельную функцию.
> Да, но.. Инициализация в отдельной функции не отменяет инициализацию в конструкторе. Двукратная
> инициализация может дорогого стоить.Ничего не понял. Какая двухкратная инициализация?
Пример:
// функция инициализации для избавления от дублирования кода
void foo:init (список параметров)
{
код_инициализации;
}// первый конструктор
foo::foo (список_параметров)
{
init (аргументы);
}// второй конструктор
foo::foo (список_параметров)
{
код;
init (аргументы);
код;
}По новому стандарту, это будет выглядеть так:
// первый конструктор
foo::foo (список_параметров)
{
код_инициализации;
}// второй конструктор
foo::foo (список_параметров)
{
код;
foo (аргументы); // первый конструктор
код;
}Я правильно понимаю идею?
class Bar
{
члены класса
void initialize( аргументы );public:
Bar( аргументы ); // конструктор
};Bar::Bar( аргументы ) // инициализация членов класса значениями по-умолчанию, все равно что
: member1()
, member2()
// etc
{
initialize( аргументы ); // инициализация
}void Bar::initialize( аргументы )
{
// что-то инициализируется
}
Здесь члены класса инициализируются два раза: один раз в конструкторе значениями по-умолчанию, второй раз - в методе initialize.Теперь понятно?
Да, понятно. Спасибо.