C++11
Как пример:
{
auto FuncName(int x, int y) -> int;
};
auto SomeStruct::FuncName(int x, int y) -> int
{
return x + y;
}
Это что такое? Зачем? Тем более, что особой компактности они не добились. Но это ладно. Но вот еще:
int x;
double y;
};
struct AltStruct {
AltStruct(int x, double y) : x_{x}, y_{y} {}
private:
int x_;
double y_;
};
BasicStruct var1{5, 3.2};
AltStruct var2{2, 4.3};
Ну вот зачем?
Короче, там много всего (примеры взял из вики, что бы не морочиться), но моё мнение, что читабельность кода падает, а стоимость поддержки возрастет.
PS: Кто-то свалил из сих замечательных групп по стандартизации, кто-то помер, нарисовалась полная свобода действий. За них можно только порадоваться.
auto - с одной стороны вроде и удобно, с другой - палка о двух концах (имхо).
А вообще, что из того, что пока пригодилось и порадовало:
лямбды
более удобный for по коллекциям
то, что в вики "Ссылки на временные объекты и семантика переноса" (в том числе и косвенно - по сравнению с бустовым shared_ptr, например, стандартный имеет значительное преимущество)
PS: Кто-то свалил из сих замечательных групп по стандартизации, кто-то помер, нарисовалась полная свобода действий. За них можно только порадоваться.
Мне тоже показалось, что все эти навороты приняты в угоду незначительной группе товарищей. Или же язык полностью отдан им на растерзание, если угодно. Это можно было бы понять, если бы языку было лет 5 и он не нес бы на себе весь груз наработок. А так - ну создали бы ответвление, какой-нить C&& и веселились бы как хотели. Зачем сразу в консерваторию-то?
Не, я согласен, что дыры надо штопать, но как объяснить рекомендуемое использование того же auto в случае, если тип возвращаемого значения неизвестен? Сильно часто такое происходит? Как говорит один товарищ-невролог: "Это ж с ума ...уякнуться можно".
Вот в этом и всё разочарование. Поставили в положение инвалида-догоняющего.
Если бы шаблонами... А то ведь ни на цвет, ни на запах - это уже не шаблоны.
Если говорить о std::initializer_list, то тут уже одуряющий амбре WinApi ощущается. Хотя, конечно, вариант: запихал & передал, может показаться удобным, но код напрочь лишается элегантности. ИМХО!!!
А вообще, что из того, что пока пригодилось и порадовало:
лямбды
Ну, может быть. Не пользовался в полный рост, поэтому не испытывал особенных неудобств.
более удобный for по коллекциям
И менее наглядный. Будут в фаворе программеры с фотографической памятью. :)
то, что в вики "Ссылки на временные объекты и семантика переноса" (в том числе и косвенно - по сравнению с бустовым shared_ptr, например, стандартный имеет значительное преимущество)
Где-то на хабре (вроде) это преимущество частично подтвеждается. Но по сравнению с монструозным boost, это и не удивительно.
А вот, кстати, они же хотели упростить изучение языка для новичков? Раз позиция пошатнулась, логичнее упростить синтаксис и предложить более ясную (понятную) семантику - и этим самым снизить порог вхождения и поднять массовость. Но тут ребятки малость обдристались.
Короче моё мнение: epic fail.
Короче моё мнение: epic fail.
Щаз придет хардкейс и безапелляционно и заявит нечто вроде "С++ изначально был говном, говном и остался" :)
На самом деле, мне стало несколько проще и удобнее писать код. Не знаю правда, насколько он потом будет проще в сопровождении, но я бы про феил не говорил.
Причем, говорю это с позиции не студента, а человека, который уже почти год, как каждый рабочий день только тем и занимается, что пишет на с++ :)
Я думаю, больше всего подосрало нововведениям стремление сохранить обратную совместимость со старым стандартом. Оно вроде и понятно и хорошо, но и заведомо ставит язык в позицию догоняющего, да. Кстати, если вспомнить, изначально именно обратная совместимость с С убила расово верную объектно-ориентированность языка.
1. extern templates - годится.
2. noexcept - годится.
3. constexpr - хрен его знает, но пока пойдет.
4. alignment - годится.
5. virtual void foo() const final и override - годится.
6. list<vector<string>> lvs - годится.
7. In-class member initializers - неплохо на первый взгляд.
8. nullptr - для глаз более приятен, чем ни о чем не говорящий 0, мозголомный (void*)0, или "удивительно органичный" NULL
9. Inline namespace - хм, ну наверное, единственная помощь в поддержке завещанного предками.
В остальном пока не определился.
g++, который gcc
4.5.1(много плюшек не поддерживаются) и 4.6.4
auto mul(T x, U y) -> decltype(x*y)
{
return x*y;
}
Так лучше, согласен. Сталкивался с такой синтаксической пробкой. Стало нагляднее, да.
upd: но все равно, контроль типов - только держись. :)
upd2: И опять же, с multithread'ингом наговнякали. Одна из самых интересных и нужных вещей, и так черезжопно.
upd2: И опять же, с multithread'ингом наговнякали. Одна из самых интересных и нужных вещей, и так черезжопно.
а что с ним не так?
З.Ы. про многопоточность, почитать перед сном
а что с ним не так?
Попозжа скажу, чего не понравилось. Надо мысль оформить, тема обширная.
А чтиво читал, да.
Уход аффтаров в вакуумное метапрограммирование, притягивание функциональщины за уши и ломание основ синтаксиса ни есть подлинный путь. И не надо говорить про х*вый дизайн языка, C++ 2003 вполне себе гармонично ложится на C не ломая синтаксиса. От господ требовалось закрыть дыры в языке аля new int[2] = { 0, 1 } и др. и успокоиться для начала, но длиной органа в таком случае помериться сложно.
PS: Уточняю, йа не против изменений как таковых, но не в том виде в котором они были сделаны. Также наиболее полезным, за иключением мелочей, вида constexpr, являются concepts, но, опять же, не в предложенном виде.