Comments 29
Как-же медленно развивается язык… когда они родят нормальные пользовательские атрибуты и рефлексию?
Нормально он развивается. Для 90% программ можно использовать любой другой язык, а в этом спешить не нужно, здесь откатить добавленные изменения будет уже почти нельзя — обратная совместимость и все дела.
Зато создаются библиотеки типа Boost в которых все фичи все равно есть, но не естественным путем, а через всевозможные метакостыли и хаки на шаблонах. В результате все начинают этим пользоваться и именно это и становится стандартом, а не естественная языковая реализация.
Что же до обратной совместимости… я вообще не вижу смысла молиться на нее как на священную корову. Если программа активно поддерживается и развивается, она все равно постоянно рефакторится и я предпочту переписать ее, если код в результате станет значительно более простым и изящным. Если не поддерживается или почти не поддерживается — значит она никому и не нужна, на крайний случай старые компиляторы никто не отменял.
Что же до обратной совместимости… я вообще не вижу смысла молиться на нее как на священную корову. Если программа активно поддерживается и развивается, она все равно постоянно рефакторится и я предпочту переписать ее, если код в результате станет значительно более простым и изящным. Если не поддерживается или почти не поддерживается — значит она никому и не нужна, на крайний случай старые компиляторы никто не отменял.
Если это становится действительно нужно, то это включается в язык. Как раз это хороший способ понять, что действительно нужно языку, через библиотеки типа Boost и т.д. Так было с умными указателями, к примеру. Зато то, что не нужно, не усложняет язык своей бесполезностью. Если нужно что-то, что реализовано в библиотеке, но нет в языке — используйте библиотеку, это хорошо и правильно.
Обратная совместимость — это базовая концепция С++. Опять же, может быть вам просто нужно использовать другой язык для каких-либо задач? С++ консервативен и это его плюс. Здесь не получится как с питоном в свое время, где есть 2 и 3, и никто просто так на 3-ку пересаживаться не хочет. Это не камень в огород питона, разумеется, но это такая вещь, на которую комитет по стандартизации С++ не может не обращать внимания.
Обратная совместимость — это базовая концепция С++. Опять же, может быть вам просто нужно использовать другой язык для каких-либо задач? С++ консервативен и это его плюс. Здесь не получится как с питоном в свое время, где есть 2 и 3, и никто просто так на 3-ку пересаживаться не хочет. Это не камень в огород питона, разумеется, но это такая вещь, на которую комитет по стандартизации С++ не может не обращать внимания.
Рефлексия может работать только если для всех типов будет RTI, соответственно нарушится один из базовых принципов языка — возможность писать «как на си» без оверхеда на рантайм.
Microsoft для этого изобрела свой велосипед
Мне всегда казалось, что велосипед — это когда оно уже есть, но кто-то решил сделать своё решение. C++14 только вышел, а MS успешно использует свою прагму уже несколько лет.
Беда в том, что Майкрософт продолжит использовать свой велосипед, в то время как в стандарт войдёт другое решение. И вот у нас уже две реализации одной фичи в рамках языка. По-хорошему Майкрософту нужно было продвигать своё решение в стандарт ну или использовать уже имеющиеся фичи языка для реализации необходимого функционала (на макросах или прагмах вполне можно было бы жить).
«две реализации в рамках языка»
В любом случае, пока не пройдет лет так дцать, и все мейнстрим компиляторы не станут поддерживать feature tests, все так и будут использовать BOOST_EXPORT, BOOST_CONSTEXPR, BOOST_DEPRECATED или что там еще (по возможности заменить на <любимый фреймворк>).
В любом случае, пока не пройдет лет так дцать, и все мейнстрим компиляторы не станут поддерживать feature tests, все так и будут использовать BOOST_EXPORT, BOOST_CONSTEXPR, BOOST_DEPRECATED или что там еще (по возможности заменить на <любимый фреймворк>).
А что еще им делать? Перерабатывать весь свой код, заменяя в нем собственные изобретения стандартными? Это же труд немалый, а потом еще большой риск регрессию получить. Заново тестировать код, который уже был оттестирован и стабилен. Мрак.
Ничего страшного в этом нет, просто MS вводит многие нужные фичи, к примеру static assert уже очень-очень давно был из коробки. А ещё есть различные директивы, к примеру goo.gl/rLha5T которая хоть и не реализует if этапа компиляции но уже кое что и таких «своих реализаций» нужного функционала до принятия стандарта везде полно, не только у MS.
P.S. «это вы ещё компиляторы для emmembed различного не видели» :) там часто даже основы сишные в виду специфики железа есть дополнительные, дополнительные memcpu, умеющие напрямую с флешем работать к примеру и т. п.
P.S. «это вы ещё компиляторы для emmembed различного не видели» :) там часто даже основы сишные в виду специфики железа есть дополнительные, дополнительные memcpu, умеющие напрямую с флешем работать к примеру и т. п.
И делает код неподдерживаемым другими компиляторами
Ну да, а есть разве какие то альтернативы? Ну т.е. кроме как встать в позу «поскольку этого в текущем стандарте языка нет — данного функционала не будет» :) Тут я серьёзно спрашиваю поскольку такие изменения в конечном итоге постепенно стандартизируются и начинают входить в стандарт, как не крути это прогресс и уж лучше так чем никак. С комитетом по языку и MS и другие компании работают, фичи постоянно предлагают, но комитет работает очень медленно, поэтому фичи включаются в язык очень медленно, но что поделать. Это проблема C++ и это его же огромное преимущество — обратная совместимость.
C++ благодаря сложности разработки полного компилятора (даже без упора на качество и скорость работы) далеко до какого-нибудь Scheme в плане расширения языка фичами, несовместимыми с другими реализациями. В то же время, у Microsoft есть возможность проталкивать свои решения.
В других компиляторах такое тоже встречается, у меня когда-то чуть глаз не выпал, когда студент в лабе написал if (a and b)… и оно работало после компиляции GCC gcc.gnu.org/onlinedocs/gcc/C-Extensions.html. С другой стороны, такие вещи как pragma deprecated не ломают совместимость с другими компиляторами, но, при этом, добавляют удобный функционал.
Вообще-то,
and и подобные есть в стандарте. Смотреть в стандарте C++11 2.6 Alternative tokens [lex.digraph] или на cppreference.Япона мать… 10 лет пишу на С++, а такого не знал. Думал — триграфы самая дичь, а оказывается и это есть. И даже Студия это компилирует, если с ключом /Za запускать.
Спасибо за новое знание!
Спасибо за новое знание!
Триграфы планируется задепрекейтить в C++17 (http://botondballo.wordpress.com/2014/07/17/trip-report-c-standards-committee-meeting-in-rapperswil-june-2014/), так что лучше не используйте
Самый полезный из альтернативных токенов — это not. Он может серьёзно повысить читаемость, когда заменяет неприметный восклицательный знак, зажатый между скобкой и идентификатором.
Ну, это было уже 7 лет назад, тогда C++11 только планировался.
А что вы на MS ополчились, в GCC вполне себе есть __attribute__ ((deprecated)) или __attribute__ ((deprecated(msg))) (см: gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html) и тот же FFmpeg их активно использует.
Другое дело, синтаксис в стриле attribute мне больше нравится чем [[]]
Другое дело, синтаксис в стриле attribute мне больше нравится чем [[]]
А можете пояснить, где вот тут объявление «deprecated»?
// помечаем шаблон
template <typename T> class templ;
Sign up to leave a comment.
Атрибут deprecated в С++14