C++, который мы потеряли

1) Ну по сопрограммам там вроде аргументы разумные. Не понятно как сделать как следует. И довод «у нас есть возможность сделать в с++ впервые это как следует. Давайте не будем торопится» вполне себе норм довод.

2) Вот работы с сетью жаль что нет...

3) дедуктивный вывод параметров шаблона - не самая большая потеря.

4) рефлекшен - слишком глобально и серьезно, что бы принимать не обдуманно.

5) А вот модулей жалко, что нет=(

Алсо по сопрограммам всегда можно заюзать буст. Да и для сети тоже. А вот модули должны быть сделаны на уровне стандарта таки.

Перебьемся. Для половины перечисленного есть буст. Это белоручкам-хипстерам фич побольше подавай, а мы и на C++98 сидели сколько лет.

Я думаю, сейчас многие плюсовики будут поглядывать на rust. Если нужны фичи, то почему бы и нет, стоит попробовать.

Это белоручкам-хипстерам фич побольше подавай

Ну просто как по мне так модули в С++ нужны. И это бустом не решишь.

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

Стиви, ну ты о числах с плавающей точкой почитал?

раз не будет, значит не нужно

Я думаю, сейчас многие плюсовики будут поглядывать на rust.

год на него уже поглядываю. и даже либу запилил. не вижу пока причин на него переходить. реального чего-то он не дает.

поглядывать на rust
Если нужны фичи

толсто

По поводу constexpr if не все так однозначно. Вот, что сказал Герб Саттер по итогам последнего митинга коммитета:

Evolution also approved the following features that were not voted in at this meeting, but are currently on track for possible approval for C++17 at our next meeting in June for inclusion in the C++17 international comment ballot (note the links are to the pre-meeting paper versions; for example, in the paper that proposed constexpr_if the committee changed the syntax to if constexpr at the meeting):

* if constexpr to allow branches that are evaluated at compile time. This is very powerful.

* Template parameter deduction for constructors, so that you can write just pair p(2, 5); instead of pair<int,double> p(2, 4.5); or auto p = make_pair(2, 4.5);. This is sweet, including that it obsoletes many “make” helpers.

* Defining the order of expression evaluation to reduce portability and usability bugs.

* operator. (dot) to allow smart references (in parallel with smart pointers) and much more.

* Defaulted comparisons, to generate ==, !=, <, <=, >, >= for types that don’t write them by hand.

Т.е. часть предложений (в частности constexpr if, а так же автоматический вывод типов для конструкторов) не были еще включены в драфт стандарта, но это может произойти на следующем митинге в июне.

Кроме того, ведутся разговоры о том, чтобы следующий стандарт вышел не в 2020-ом, а в 2019-ом (т.е. после C++17 может быть C++19, а не C++20). Так что это может быть даже лучший сценарий, с учетом опыта того, как долго фичи из C++11 и C++14 доходили до большинства мейнстримовых C++ных компиляторов. Пусть лучше C++17 включает в себя меньше, но зато будет сразу доступен в основных компиляторах (gcc, clang, vc++).

Ага, уже поглядываем. Но за фичами это как раз в плюсы. По крайней мере пока не будет genericity over integer values, variadic templates и implementation inheritance.

щито?

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

Так они там разные... Это не порядок.

успокойся уже, жирдяйка

Кто мешает всё это реализовывать в каком-нибудь clang?

Кто мешает всё это реализовывать в каком-нибудь clang?

Потому что не будет работать в gcc, msvc, intel c++, etc...?

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

мешает кому? мне - то что я с той стороны баррикады, где язык и платформа - это в первую очередь стандарт языка и стандарт платформы. Компилятор языка - это то, что реализует стандарт.

Компилятор языка - это то, что реализует стандарт.

Ну вообще говоря все современные компиляторы расшираяют стандарт. Как clang имеет фичи которых нет в стандарте, так и msvc тоже самое...

Стиви, а тебе не пох? Ты же жаба-макака. Или это хобби такое - задрачивать кресты.

половина жабы написана на крестах. это хобби крестов - задрачивать меня..

пофиксить флоат (0.1+0.2 должен == 0.3)
stevejobs ★★★★★ (18.06.2015 8:55:42)

Тебя как жаба-макаку это вообще никак не касается. Лечись.

Жалко только модули и концепты, остальное - либо ерунда, либо есть в boost, либо действительно слишком рано.

вся суть звезд

#include <boost/rational.hpp>
rational<int> n01(1,10);
rational<int> n02(2,10);
rational<int> n03(3,10);
assert(n01 + n02 == n03);

впиливание в компилятор интринсики на число1.число2'RT' -> rational<long> - домашнее задание

Ты, пожалуйста, от темы не уходи. 0.1, 0.2 и 0.3 - это константы типа double.

Кастомные суффиксы литералов «3.14_rt» можно уже сейчас, но это другой разговор.

Он был потерян ещё до рождения.

§13.5.8

The declaration of a literal operator shall have a parameter-declaration-clause equivalent to one of the following:

const char*
unsigned long long int
long double
char
wchar_t
char16_t
char32_t
const char*, std::size_t
const wchar_t*, std::size_t
const char16_t*, std::size_t
const char32_t*, std::size_t

а нам нужно взять все что левее кастомного суффикса и попарсить как строку, на которую уже применить длинную арифметику через boost:rational

нет, Solace так просто не отделается, придется ему все же впиливать это прям в парсер =)

Блин, Стиви, ты серьезно?

Сначала я тебе хотел написать «Несколько параметров не умеет. Пожалуй, через литералы это не выгорит.»

Но теперь я уже начинаю сомневаться, а нафига это вообще обсуждать, это оффтоп. А 0.1 - это литерал типа double, и все операции с ним соответствующие.

У подавляющего большинства языков нет никаких стандартов языков и платформ. И всем от этого только лучше. Зачем писать 20 компиляторов для одного языка я тоже не понимаю. Написали clang и используйте везде. Не нравится — доработай, благо лицензия позволяет.

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

Ага. И переписывать всё потом, когда стандартизируют не такую реализацию как сейчас.

ничего полезного не потеряли, да.

Написали clang и используйте везде. Не нравится — доработай, благо лицензия позволяет.

Весь этот винегрет с кучей вендоров начался задолго до того, как появился clang. И даже задолго до того, как у C++ появился первый стандарт.

Да и сам clang образец того, что дорабатывать чужое интересно далеко не всем. Ведь сделали же clang вместо того, чтобы дорабатывать gcc...

модули жалко, вывод параметров шаблонов, контракты — всё остальное правильно сделали, что не внесли: народ ещё к 11-14 стандартам не привык

что касается constexpr if, то эмулируется через тернарный оператор, пока и так поживём

У подавляющего большинства языков нет никаких стандартов языков и платформ.

факт заключается в том, что есть: с, лисп, форт, паскаль, питон, ява, руби, яваскрипт, С#, objc — что сходу приходят на ум.

то есть, все популярные языки

И каким же комитетом стандартизирован Objective C?

рефлекшен

Не нужно. Для дебилов, не умеющих в полиморфизм, уже есть friend и rtti.

с, лисп, форт, паскаль, питон, ява, руби, яваскрипт, С#, objc

Покажи стандарт на джаву, руби и обжектив С.

Не нужно. Для дебилов, не умеющих в полиморфизм, уже есть friend и rtti.

Что за бред? Рефлексия (на этапе компиляции) была бы весьма полезна.

https://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf

https://docs.oracle.com/javase/specs/jls/se8/jls8.pdf

с тебя 90 рублей за просмотр :)

с тебя 90 рублей за просмотр :)

Спека - это не стандарт.

Действительно, бред. Посмотрел на топикстартера и решил, что динамическая.

Да, статическая рефлексия в стандарте не помешает.

Это не тот ли самый стандарт Явы из которого не ясно — может ли интерпретатор байткода (JRE, оптимизатор, JiT-транслятор, ... Или ещё какая хрень) менять местами выполняемые операции в функции — даже в ситуациях, когда нарушается причинно-следственная связь (манипуляция с ссылками доступными из вне)...

Обычный OpenJDK-интерпретатор/оптимизатор — такое говно не проделывает ни когда, но Хабра-макаки во всё горло орут что якобы стандарт не запрещает вмешиваться (и ломать) в причинно следственные связи! И...

...и в доказательство своей праваты эти хабра-макаки — приводят какой-то там бажный устаревший и нестандартный интерпретатор Явы от левой фирмы (но наверняка сертифицированный, ведь серъёзный интерпрайз и бла бла бла :-))..

Ну вы поняли

если «неясно» - значит считаем, что такой гарантии нет, и пользоваться этой фичей нельзя. Что там делает реальная реализация - неважно

Ты хочешь чтоб прям стандарт ISO? Такой бюрократией редко кто упарывается, а спеки у всех вменяемых имеются.

ничего этого НЕ будет

все это НЕ нужно в крестах

кстати, почему я вижу этот тред в трекере, если c++ у меня в игнорируемых тегах?

Некоторые вещи могут казаться контр-интуитивными, но для них есть объяснение в формальной модели, например такое, и развернутый комментарий к ней на SO

с другой стороны, «чья бы корова мычала», учитывая что мы тут говорим о крестах