LINUX.ORG.RU

C++14 готов к публикации, стандарт ISO/IEC 14882:2014(E)

 


1

8

Обновленный язык программирования C++14 уже подготовлен к публикации как новый стандарт «International Standard ISO/IEC 14882:2014(E) Programming Language C++». Приятной особенностью будет доступность компиляторов соотвествующих новому стандарту (реализации предыдущих выпусков C++11 и C++98 заняло 2 и 5 лет соотвественно). Автор языка Bjarne Stroustrup надеется, что это обновление, подготовленное достаточно быстро и в намеченные сроки, позволит поддержать для C++ репутацию современного.

>>> Подробности

★★★★★

Проверено: fallout4all ()
Последнее исправление: linuks (всего исправлений: 14)
Ответ на: комментарий от anonymous

1) Не может в управление памятью

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

это ты про что? про сборку мусора?

2) Не может в LALR грамматику

проблемы скорее не в грамматике, а в неожиданной необходимости использовать информацию о типах для разбора:

х у();

х у(е);

но тут, похоже, все это можно вылечить, запретив декларацию функций вне инклюдов (да и вообще лучше require/import)

3) Как следствие, не может в человеческий синтаксис

это разве следствие? это ты другими словами пересказал п.2

синтаксис да, так себе, но жить можно

4) Не может в денотационную семантику

а нахрена?

серьезно, мне интересны случаи, когда именно денотационная семантика означает понимание — а то почти всегда понимание языка — это понимание операционной семантики; а если уж дело доходит до оптимизаций под железо — то без нее никак

заодно, кстати, я совершенно не вижу смысла даже в тех зачатках денотационной семаники, что есть в с++

5) Не может в настоящие макросы (с темплейтами отсос - не могут в квазицитирование)

5.1. настоящие макросы — это, видимо, то, что умеет работать с таблицей символов (имеется в виду, например, узнать тип локальной переменной или добавить ее); если у тебя есть лучшее определение — то вперед

5.2. нахрена в темплетах квазицитирование? вообще квазицитирование переоценено

6) Следствие - не может в человеческий полиморфизм (не говоря про higher-order), только убогое кодовысерание.

6.1. не вижу следствия

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

вкратце:

А. делаем «кодовысерающий» List<T*>

В. обертываем его

template<class T> class PList: List<void*> 
{ 
....
};

короче — производим стирание типов вручную

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

7) Не может в referential transparency

8) Linear typing

емнип его даже и в скале нет

вообще-то оно конечно нужно, но с целью раскрутить тебя на полезные примеры я бы оспорил практическую полезность этого

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Pavval

Можно. Вернет 42, даже без UB

только если аргумент у нее будет 42

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

вообще, анонимус, я бы на первое место из недостатков с++ поставил его хомячизмы («жри-что-дают», случаи прибитости гвоздями) — скажем, в си можно написать свой printf через стандартизированные макросы, оперирующие аргуменами, а в с++ нельзя написать свою объектную систему вообще никак

ну и плюс к этому в с++ имеется хомячизмы, унаследованные из си — скажем,

то, что NULL рассматривается как false в операторе if, а не наоборот

то, что прибавление целого к указателю просто сдвигает его

то, что прибавление целого к указателю сдвигает его на sizeof

однако, для собственной реализации всех этих возможностей денотационная семантика, скорее, мешает — это к вопросу о семантиках

именно то, что пользователи (быть может неоправданно) воспринимают семантику с++ как операционную, и при этом не обламываются, как раз и является основным достоинством с++, которым он превосходит все прочие языки

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

то, что NULL рассматривается как false в операторе if, а не наоборот

Но это же логично. NULL - пустота (точнее, 0).

то, что прибавление целого к указателю просто сдвигает его

Это тоже замечательно, позволяет быстро скопировать нужную часть из буфера, например

# define OFFSET_BAR 73

memcpy(&foo.bar, buffer+OFFSET_BAR, sizeof(foo.bar));

anonymous9
()
Ответ на: комментарий от www_linux_org_ru

то, что NULL рассматривается как false в операторе if, а не наоборот

Упоролся?

Pavval ★★★★★
()
Ответ на: Обломись... от d_Artagnan

Ну и, «дартаньян»? Или «болван» будет точнее?

Virtuos86 ★★★★★
()
Ответ на: комментарий от Shadow1251

Не нужно порождать новый процесс и вызывать wc если есть exit code от grep. Так что таких «скриптеров» тоже надо увольнять.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от ozkriff

Куча всего написана на крестах. В головах менеджеров кресты тоже прочно засели

buddhist ★★★★★
()
Ответ на: комментарий от anonymous

там должно быть много вкусного

ты про попкорн или про еще какую... еду? :)

slackwarrior ★★★★★
()
Ответ на: комментарий от Pavval

Дебилы и дальше будут ржать, но в будущем я это вполне допускают.

timuaz
()
Ответ на: комментарий от anonymous

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

Может быть - за счет добавления нового типа указателей, man C++/CLI.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.