Что нам C++14 готовит...
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 29.03.13 00:14
Оценка: 114 (12)
Появилась первая подборка нововведений планируемых к включению в C++14.
Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет
Re[5]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 29.03.13 14:42
Оценка: 1 (1) +4
Здравствуйте, niXman, Вы писали:

EP>>А зачем языку с lambda, higher-order functions, с библиотекой уровня STL, костыли типа OpenMP?

X>возможно ты не в курсе, но сейчас параллельные алгоритмы в GCC реализованы при помощи OMP.

Пусть реализация внутри использует что хочет
Если допустим для реализации std::thread какая-то библиотека использует win32 api, а другая posix threads — это же не повод тащить их в стандарт


EP>>Уж лучше N3554 или C++ AMP.

X>лучше. когда стандартизуют, вот тогда оно будет лучше. а пока что, OMP, замечательный стандартизованный инструмент, поддерживаемый всеми топовыми компиляторами.

Так я не спорю, сам раньше использовал — пусть живёт себе как extension.
Но тащить его в ISO C++ это как-то уже слишком: добавлять в язык новые keyword'ы, для того что прекрасно реализуется библиотекой — это не C++ way
Re[2]: Что нам C++14 готовит...
От: Nikita.Trophimov  
Дата: 31.03.13 08:17
Оценка: 12 (1) +2
A>и еще конструктор/деструктор переименовать в this и ~this

Зачем?
Re[3]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 31.03.13 09:15
Оценка: 1 (1) +1 -1
Здравствуйте, Nikita.Trophimov, Вы писали:

A>>и еще конструктор/деструктор переименовать в this и ~this


NT>Зачем?


DRY.
In Zen We Trust
Re[8]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 29.03.13 11:52
Оценка: +1 -2
Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, Abyx, Вы писали:


A>>а что в ASIO не продумано?


KP>ASIO — это не более чем часть BOOST.

нет, ASIO это не часть буста.

KP>ACE, как было верно подмечено выше, это полноценный фрэймворк, который по ряду функций превосходит BOOST. Так, к примеру, при работе с ACE у тебя сразу решены такие мелочи как логирование, TLS (этот вопрос вроде отпал с C++11), межпроцессное взаимодействие (в виде TAO, т.е. CORBA),

а если мне этого всего не надо?

KP>пул потоков

пул потоков пишется в 2 строчки кода, для этого библиотека не нужна
    std::vector<std::shared_ptr<std::thread>> v(pool_size);
    std::generate(v.begin(), v.end(), [&]{ return std::shared_ptr<std::thread>(new std::thread([&]{ iosrv.run(); }), [](std::thread* t){ std::unique_ptr<std::thread> _(t); t->join(); }); });
In Zen We Trust
Re[2]: Что нам C++14 готовит...
От: Kluev  
Дата: 02.04.13 13:57
Оценка: -2 :)
Здравствуйте, Cyberax, Вы писали:

C>В основном, там библиотечные изменения (вполне разумные — полиморфные аллокаторы рулят). Языковых почти нет.


Надо же. 13 лет кормили пользователей stl говном и вдруг прозрели. Полагаю в следующей итерации прийдут к контейнеру как к некопируемому объекту с виртуальными функциями аллокации. Т.е. к старому доброму ООП.
Re: Что нам C++14 готовит...
От: The Passenger Голландия  
Дата: 24.09.13 15:33
Оценка: -2 :)
Здравствуйте, kaa.python, Вы писали:

C# и жабу уже вроде изобрели, зачем все эти жалкие потуги, когда половина программеров 98х не знает и наполовину?
И почему расширение стандартной библиотеки называют фичами языка ?

вот например — auto или новый for — это вроде как фича
а бинды функторы и потоки — это вроде как расширения библиотеки, какого хрена они делают в стандарте.

по мне так плюсы используют люди, которые хотят иметь уверенность как это работает под капотом вплоть до ассемблерных инструкций,
а когда пошли эти высокоуровневые навороты — то проще уж на жабу перейти и не мучаться.
Весь мир — Кремль, а люди в нем — агенты
Re[4]: Что нам C++14 готовит...
От: Vzhyk  
Дата: 15.10.13 13:34
Оценка: +1 :))
15.10.2013 15:19, slava_phirsov пишет:

> Собеседуя (ну и просто беседуя) программеров на C++ (вт.ч. с профильным

> образованием, сертификатами и прочими понтами), приходилось массово
> сталкиваться с людьми, не понимающими, как целое число хранится в
> памяти, не знающими, что такое двоичная система счисления, не
> понимающими, что тип строки "foo" — не std::string, ну ит.д.
Почему-то после вопросов о пересечении двух отрезков оное меня не
удивляет. Ты просто не то спрашивал, надо было про сортировки и гномиков.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 29.03.13 09:37
Оценка: +2
Здравствуйте, kaa.python, Вы писали:

KP>Я, может быть, несколько старомоден, но мне ACE несравненно больше чем boost.asio нравится

неповоротливый монстр. фреймворк, одним словом.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[3]: Что нам C++14 готовит...
От: denisko http://sdeniskos.blogspot.com/
Дата: 29.03.13 09:49
Оценка: +2
Здравствуйте, niXman, Вы писали:

X>Здравствуйте, denisko, Вы писали:


D>>OpenMP тоже лишнее.

X>это еще почему? оО
А нафига оно нужно на уровне языка? Мое мнение -- если что-то включается в язык C++, то в идеале программист должен представлять во что это скомпильнется с точностью до инструкции (пока не берем оптимизированный код, но и его надо уметь читать. В случае с OpenMP это практически невозможно, т.к. она классический черный ящик, который делает под капотом кучу небесплатной работы, и который со временем развивается. Та поддержка ее, которая есть сейчас имхо оптимальна, да и читать прагмы гораздо легче, чем очередной вариант for'a.
<Подпись удалена модератором>
Re[6]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 29.03.13 15:00
Оценка: +1 :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Пусть реализация внутри использует что хочет

EP>Если допустим для реализации std::thread какая-то библиотека использует win32 api, а другая posix threads — это же не повод тащить их в стандарт
свою фразу я приводил для того, чтоб показать что OMP отлично справляется со своей задачей, и что нереально сильно экономит и время и нервы.

EP>Но тащить его в ISO C++ это как-то уже слишком: добавлять в язык новые keyword'ы, для того что прекрасно реализуется библиотекой — это не C++ way

Cilk+ точно войдет в gcc-4.9.x. и того, gcc и Intel будут поддерживать это расширение. а это, основные компиляторы для всех ОСей кроме масдайки. так что, думается мне, оно получит признание среди множества разработчиков.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[7]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 29.03.13 23:04
Оценка: +2
Здравствуйте, niXman, Вы писали:

X>Cilk+ точно войдет в gcc-4.9.x. и того, gcc и Intel будут поддерживать это расширение. а это, основные компиляторы для всех ОСей кроме масдайки. так что, думается мне, оно получит признание среди множества разработчиков.


посмотрел я на этот Cilk+

int fib(int n)
{
    if (n < 2)
        return n;
    int x = cilk_spawn fib(n-1);
    int y = fib(n-2);
    cilk_sync;
    return x + y;
}


чем это лучше

int fib(int n)
{
    if (n < 2)
        return n;
    auto x = std::async(fib, n-1);
    int y = fib(n-2);
    return x.get() + y;
}

?

не, может в Си это и нужно, но в С++-то это зачем?

тем более что сейчас синхронный код (c wait/sync) это не комильфо,
сейчас считается правильным использовать асинхронный код (await/async в С#, .then() в С++).
In Zen We Trust
Re[12]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 04.04.13 16:50
Оценка: +2
Здравствуйте, MTD, Вы писали:

A>>>>зато header-only.


MTD>>>Это минус.


A>>это почему?


MTD>Сильно увеличивает время компиляции.


сильно это насколько?
а с PCH?
In Zen We Trust
Re[10]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 10.04.13 13:16
Оценка: +2
Здравствуйте, niXman, Вы писали:

X>а кто-то видел, есть ли пропосал для for(), который принимает пару значений "от — до" ?

X>
X>for ( auto idx: {34..56} ) {}
X>for ( auto idx: {34,56} ) {}
X>


X>про boost.range знаю, спасибо


не нужно, ибо не добавляет ничего полезного.
In Zen We Trust
Re[2]: Что нам C++14 готовит...
От: jazzer Россия Skype: enerjazzer
Дата: 26.09.13 14:36
Оценка: +2
Здравствуйте, The Passenger, Вы писали:

TP>по мне так плюсы используют люди, которые хотят иметь уверенность как это работает под капотом вплоть до ассемблерных инструкций,

TP>а когда пошли эти высокоуровневые навороты — то проще уж на жабу перейти и не мучаться.

А кто сказал, что мы в С++ не понимаем, как работают лямбды "под капотом вплоть до ассемблерных инструкций"?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: Что нам C++14 готовит...
От: The Passenger Голландия  
Дата: 26.09.13 16:19
Оценка: :))
Здравствуйте, MasterZiv, Вы писали:

MZ>Здравствуйте, The Passenger,

MZ>по-моему вы просто сели не в тот поезд...

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

и тогда вообще непонятно почему в С еще не добавили поддержку LINQ
почему язык не развивается?
а почему в ассемблере нет делегатов и эвентов ?
Весь мир — Кремль, а люди в нем — агенты
Re[3]: Что нам C++14 готовит...
От: slava_phirsov Россия  
Дата: 15.10.13 12:19
Оценка: +2
Здравствуйте, jazzer, Вы писали:

J>А кто сказал, что мы в С++ не понимаем, как работают лямбды "под капотом вплоть до ассемблерных инструкций"?


Собеседуя (ну и просто беседуя) программеров на C++ (вт.ч. с профильным образованием, сертификатами и прочими понтами), приходилось массово сталкиваться с людьми, не понимающими, как целое число хранится в памяти, не знающими, что такое двоичная система счисления, не понимающими, что тип строки "foo" — не std::string, ну ит.д. Так что, боюсь, что число людей понимающих как работают лямбды "под капотом вплоть до ассемблерных инструкций" исчезающе мало (скоро будет мало и число людей, вообще знающих, что такое "ассемблерные инструкции").

Но с The Passenger согласен — язык и так уже раздут до предела всякими свистульками и бубенчиками, которые большинству кодеров либо не знакомы, либо знакомы, но не нужны, либо нужны, но можно обойтись и без них (как-то ж обходились с 98-го). А комитет всё продолжает и продолжает — видать, теплое местечко, уходить неохота. Боюсь, что кончится это все так же, как с POSIX.
Люди! Люди, смотрите, я сошел с ума! Люди! Возлюбите друг друга! (вы чувствуете, какой бред?)
Re[2]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 04.04.13 13:07
Оценка: 2 (1)
Здравствуйте, Мишень-сан, Вы писали:

МС>Лучше бы модули сделали нормальные.


Daveed Vandervoorde: "Modules in C++"
Re[3]: Что нам C++14 готовит...
От: CoolCmd Россия  
Дата: 19.04.13 19:30
Оценка: 1 (1)
Здравствуйте, Ops, Вы писали:

Ops>Это как?

так. и для while тоже.
простите, я убил небо
Re: Что нам C++14 готовит...
От: Erop Россия  
Дата: 29.03.13 08:32
Оценка: :)
Здравствуйте, kaa.python, Вы писали:


KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет


Это вроде как старая приплюснутая традиция -- стандарты таки парами выходят
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: Что нам C++14 готовит...
От: Erop Россия  
Дата: 29.03.13 11:30
Оценка: +1
Здравствуйте, Abyx, Вы писали:

A>и еще конструктор/деструктор переименовать в this и ~this

A>эх, мечты, мечты...

Вот что на самом деле было бы круто, так это возможность иметь именованные конструкторы.
Что бы конструктор можно было выьирать не только перегрузкой, но и явным именем.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: Что нам C++14 готовит...
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 29.03.13 11:30
Оценка: -1
Здравствуйте, Abyx, Вы писали:

A>а что в ASIO не продумано?


ASIO — это не более чем часть BOOST. ACE, как было верно подмечено выше, это полноценный фрэймворк, который по ряду функций превосходит BOOST. Так, к примеру, при работе с ACE у тебя сразу решены такие мелочи как логирование, TLS (этот вопрос вроде отпал с C++11), межпроцессное взаимодействие (в виде TAO, т.е. CORBA), пул потоков, нормальный Proactor (тут не могу утверждать на все сто, но год-два назад ASIO лишь эмулировал Proactor на синхронном I/O).
Re[2]: Что нам C++14 готовит...
От: denisko http://sdeniskos.blogspot.com/
Дата: 29.03.13 11:43
Оценка: :)
Здравствуйте, Abyx, Вы писали:

A>и еще бы хорошо иметь decltype(return) для получения возвращаемого типа функции как в D

В каких ситуациях используется? вообще в ++11 уже есть такая порнография

auto func(arg1 val, arg2 val2)->decltype(val)
auto func(arg1 val, arg2 val2)->Traitor<decltype(arg1)>::value_type
<Подпись удалена модератором>
Re[3]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 29.03.13 12:10
Оценка: +1
Здравствуйте, denisko, Вы писали:

D>Здравствуйте, Abyx, Вы писали:


A>>и еще бы хорошо иметь decltype(return) для получения возвращаемого типа функции как в D

D>В каких ситуациях используется? вообще в ++11 уже есть такая порнография

decltype(return) используется внутри функции, чтобы убрать избыточность,
т.е. вместо
R foo() { R r; } // "R" встречается 2 раза
R foo() { decltype(foo()) r; } // "foo" встречается 2 раза

можно написать
R foo() { decltype(return) r; } // никакой избыточности


Такое нужно при использовании автоматически сгенерированного кода,
в частности макросов типа
#define IMPL ...
R foo() {IMPL;}
In Zen We Trust
Re[4]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 29.03.13 14:24
Оценка: -1
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>А зачем языку с lambda, higher-order functions, с библиотекой уровня STL, костыли типа OpenMP?

возможно ты не в курсе, но сейчас параллельные алгоритмы в GCC реализованы при помощи OMP.
зачем?/почему? — ну я право хз, как еще объяснить...чтоб упростить достижение цели.

EP>Уж лучше N3554 или C++ AMP.

лучше. когда стандартизуют, вот тогда оно будет лучше. а пока что, OMP, замечательный стандартизованный инструмент, поддерживаемый всеми топовыми компиляторами.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[4]: Что нам C++14 готовит...
От: denisko http://sdeniskos.blogspot.com/
Дата: 29.03.13 16:17
Оценка: +1
Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, denisko, Вы писали:


D>>Здравствуйте, Abyx, Вы писали:


A>>>и еще бы хорошо иметь decltype(return) для получения возвращаемого типа функции как в D

D>>В каких ситуациях используется? вообще в ++11 уже есть такая порнография

A>decltype(return) используется внутри функции, чтобы убрать избыточность,

естество, имхо

A>Такое нужно при использовании автоматически сгенерированного кода,

A>в частности макросов типа
A>
A>#define IMPL ...
A>R foo() {IMPL;}
A>

Макробесие.
<Подпись удалена модератором>
Re[11]: Что нам C++14 готовит...
От: MTD https://github.com/mtrempoltsev
Дата: 04.04.13 14:58
Оценка: +1
Здравствуйте, Abyx, Вы писали:

A>>>зато header-only.


MTD>>Это минус.


A>это почему?


Сильно увеличивает время компиляции.
Re[2]: Что нам C++14 готовит...
От: Kluev  
Дата: 04.04.13 15:35
Оценка: -1
Здравствуйте, Nikita.Trophimov, Вы писали:

NT>Ещё одна подборка


NT>http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-and-beyond-papers-part-3.html


Не читал, но инциализаторы в классах планируют сделать?

struct Foo
{
   T x = 0;
   T w = 1; // инициализируется в конструкторе по умолчанию
};
Re[3]: Что нам C++14 готовит...
От: jazzer Россия Skype: enerjazzer
Дата: 06.04.13 06:15
Оценка: +1
Здравствуйте, Nikita.Trophimov, Вы писали:

A>>и еще конструктор/деструктор переименовать в this и ~this


NT>Зачем?


А почему нет, собственно? Какое преимущество у констуктора/деструктора, называющегося точно как класс?
Имя в любом случае прибито гвоздями: Если класс называется Т, то и конструктор обязан называться Т, а деструктор — ~T. Это ровно то же самое, что this, за исключением того, что ты можешь при переименовании класса тебе не нужно будет лезть и переименовывать конструкторы и деструктор.
Единственный довод за старое имя, который я вижу — это явный вызов деструктора через ptr->~T(), но и тут тоже ~this нормально сработал бы, разве что не так наглядно (с другой стороны, сейчас есть возможность совершить ошибку, вписав не тот деструктор, а, например, деструктор базового класса, который, если не виртуальный, не сделает всего, что нам нужно — с ~this это будет невозможно — деструктор будет определяться по типу ptr).

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

Еще довод: сейчас при использовании макросов всюду надо передавать имя класса, а так не надо будет, можно будет просто иметь макрос с телом класса, который сгенерит все, что надо, пользуясь class-agnostic-именами типа this.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: Что нам C++14 готовит...
От: Кодт Россия  
Дата: 06.04.13 17:26
Оценка: +1
Здравствуйте, jazzer, Вы писали:

J>А почему нет, собственно? Какое преимущество у констуктора/деструктора, называющегося точно как класс?

J>Имя в любом случае прибито гвоздями: Если класс называется Т, то и конструктор обязан называться Т, а деструктор — ~T. Это ровно то же самое, что this, за исключением того, что ты можешь при переименовании класса тебе не нужно будет лезть и переименовывать конструкторы и деструктор.

Надо бы перечитать Строуструпа, я не помню, он как-то объясняет, зачем сделал именно так?
Видимо, по идейным соображениям, чтоб множественное наследование красиво выглядело:
class Foo : Bar, Buz
{
  Foo() : Bar(123), Buz(456) {}
  // versus:
  ctor() : super(123), ????(456) {}
  // хотя что мешало сделать
  ctor() : Bar(123), Buz(456)
};

Либо это экономия на синтаксисе, — чтобы минимизировать количество новых ключевых слов. Отсюда и ~T вместо dtor.

J>Единственный довод за старое имя, который я вижу — это явный вызов деструктора через ptr->~T(), но и тут тоже ~this нормально сработал бы, разве что не так наглядно (с другой стороны, сейчас есть возможность совершить ошибку, вписав не тот деструктор, а, например, деструктор базового класса, который, если не виртуальный, не сделает всего, что нам нужно — с ~this это будет невозможно — деструктор будет определяться по типу ptr).


Деструктор можно вызвать функцией
template<class T> void destruct(T* t) { if(t) t->~T(); }
// делать версию с T& опасно,
// т.к. при явном указании параметров мы можем отхватить пользовательское приведение типа

// деструктор полного типа
destruct(&foo);
// деструктор базы
destruct<Bar>(&foo);
destruct((Buz*)&foo);


J>Ну и можно сделать эту фичу дополнением и разрешать и то, и другое, так что старый код от этого ломаться не будет, а новый только выиграет.


Вот только не надо this. Это дурацкая экономия на спичках, перегрузка смысла ключевого слова.
Чем микрософтовские стандарто-совместимые __ctor и __dtor не приглянулись?

J>Еще довод: сейчас при использовании макросов всюду надо передавать имя класса, а так не надо будет, можно будет просто иметь макрос с телом класса, который сгенерит все, что надо, пользуясь class-agnostic-именами типа this.


Пока что могу предложить такой способ генерирования агностического класса
template<class T> class agnostic;

#define BEGIN_CLASS(K)  class K; \
                        template<> class agnostic<K> { \
                          typedef K target_type;
#define CTOR()            agnostic() { ..... }
#define CCTOR()           agnostic(const agnostic&) { ..... }
#define DTOR()            ~agnostic() { ..... }
#define ASSIGN()          agnostic& operator=(const agnostic&) { ..... }
................          ..............
#define END_CLASS(K)    }; \
                        class K : public agnostic<K> {};
Перекуём баги на фичи!
Re[4]: Что нам C++14 готовит...
От: rusted Беларусь  
Дата: 06.04.13 20:51
Оценка: +1
Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, Nikita.Trophimov, Вы писали:


A>>>и еще конструктор/деструктор переименовать в this и ~this


NT>>Зачем?


J>А почему нет, собственно?


В C++ и так уже полно мест, где одно и тоже ключевое слово означает совсем разное: и static, и template, и typename. Когда ты уже 20 лет наблюдаешь развитие языка, то подобное ре-использование ключевых слов вроде и не добавляет сложности. Но вот многих, кто только начинает изучать язык, это всё сильно запутывает, и самое неприятное то, что до того как они во всём разберуться, они уже успевают понаписать достаточно кода, который потом приходится поддерживать.
Может и стоит сделать независящие от имени типа конструкторы и деструкторы, но уж точно не как this/~this. __ctor и __dtor для такого подойдут гораздо лучше.
Re[7]: Что нам C++14 готовит...
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 10.04.13 13:04
Оценка: +1
Здравствуйте, niXman, Вы писали:

X>иначе С++ получается самым неподходящим ЯП для разработки многопоточных программ.


Господа, проявите терпение, Rust почти готов
Re[5]: Что нам C++14 готовит...
От: LuciferSingapore Россия  
Дата: 20.04.13 06:03
Оценка: :)
Здравствуйте, Кодт, Вы писали:

К>Либо это экономия на синтаксисе, — чтобы минимизировать количество новых ключевых слов. Отсюда и ~T вместо dtor.


старый добрый "синтаксический оверхед" (тм)
Re[3]: Что нам C++14 готовит...
От: artem.komisarenko Украина  
Дата: 17.10.13 08:26
Оценка: +1
Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, The Passenger, Вы писали:


TP>>по мне так плюсы используют люди, которые хотят иметь уверенность как это работает под капотом вплоть до ассемблерных инструкций,

TP>>а когда пошли эти высокоуровневые навороты — то проще уж на жабу перейти и не мучаться.

J>А кто сказал, что мы в С++ не понимаем, как работают лямбды "под капотом вплоть до ассемблерных инструкций"?


Я даже больше скажу, часто плюсовики настолько суровы, что знают и как эти йихние явы работают под капотом вплоть до ассемблерных инструкций
Re: Что нам C++14 готовит...
От: Cyberax Марс  
Дата: 29.03.13 00:24
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Появилась первая подборка нововведений планируемых к включению в C++14.

KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет
В основном, там библиотечные изменения (вполне разумные — полиморфные аллокаторы рулят). Языковых почти нет.

Доставляют пайплайны:
(pipeline::from(input_queue) |
  bind(grep, "^Error") |
  bind(vgrep, "test@example.com") |
  bind(sed, "'s/^Error:.*Message: //") |
  output_queue).run(&threadpool);
Sapienti sat!
Re[2]: Что нам C++14 готовит...
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 29.03.13 00:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В основном, там библиотечные изменения (вполне разумные — полиморфные аллокаторы рулят). Языковых почти нет.


STL — неотъемлимая часть языка. Так что изменения в библиотеке == изменения языка. Ну а в данном конкретном случае это вообще роли не играет
Re: Что нам C++14 готовит...
От: denisko http://sdeniskos.blogspot.com/
Дата: 29.03.13 08:50
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Появилась первая подборка нововведений планируемых к включению в C++14.

KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет
Сахар в основном. Аллокаторы -- узаконили традицию . Грустно что опять не договорились по концептам (http://isocpp.org/files/papers/n3580.pdf), это имхо вред — http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3538.html . OpenMP тоже лишнее.
<Подпись удалена модератором>
Re[2]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 29.03.13 08:58
Оценка:
Здравствуйте, denisko, Вы писали:

D>OpenMP тоже лишнее.

это еще почему? оО


кто-то вообще вкурсе, как обстоят дела с boost.filesystem и с boost.asio? их хоть когда-то уже примут?!
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[3]: Что нам C++14 готовит...
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 29.03.13 09:35
Оценка:
Здравствуйте, niXman, Вы писали:

X>кто-то вообще вкурсе, как обстоят дела с boost.filesystem и с boost.asio? их хоть когда-то уже примут?!


Я, может быть, несколько старомоден, но мне ACE несравненно больше чем boost.asio нравится
Re[5]: Что нам C++14 готовит...
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 29.03.13 09:40
Оценка:
Здравствуйте, niXman, Вы писали:

X>неповоротливый монстр. фреймворк, одним словом.


Полностью согласен. Но но оставляет ощущение доскональной продуманности, в отличие от того же ASIO.
Re: Что нам C++14 готовит...
От: nen777w  
Дата: 29.03.13 09:46
Оценка:
KP>Появилась первая подборка нововведений планируемых к включению в C++14.
KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет

Мне бы очень хотелось вот такого:

void foo(int n = 0, int k = 1, int m = 2);
foo(1,/*возможности пропускать аргумент по умолчанию*/,3);


И вот такого:

//foo.h
struct foo {
  struct doo {
  };
};

//another.h
// - форвардной декларации вложенных классов
struct foo::doo;

//для этого
class some {
  friend struct foo::doo; //теперь doo из foo друг класса some
}
Re[4]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 29.03.13 09:53
Оценка:
Здравствуйте, denisko, Вы писали:

D>А нафига оно нужно на уровне языка? Мое мнение -- если что-то включается в язык C++, то в идеале программист должен представлять во что это скомпильнется с точностью до инструкции (пока не берем оптимизированный код, но и его надо уметь читать. В случае с OpenMP это практически невозможно, т.к. она классический черный ящик, который делает под капотом кучу небесплатной работы, и который со временем развивается. Та поддержка ее, которая есть сейчас имхо оптимальна, да и читать прагмы гораздо легче, чем очередной вариант for'a.

а я хотел бы, чтоб у плюсов был пайтоновский синтаксис
так и с OMP и с Cilk+(который войдет в gcc-4.9.x). они упрощают достижение цели.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[6]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 29.03.13 11:14
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Полностью согласен. Но но оставляет ощущение доскональной продуманности, в отличие от того же ASIO.


а что в ASIO не продумано?
In Zen We Trust
Re[7]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 29.03.13 11:16
Оценка:
Здравствуйте, Abyx, Вы писали:

A>а что в ASIO не продумано?

не искаропки =)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 29.03.13 11:26
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Появилась первая подборка нововведений планируемых к включению в C++14.

KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет

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

void foo(A, B, C)
{
    std::tuple<__arg_types__...> args{__arg_values__...};
}

как если бы это была
template<typename... __arg_types__> void foo(__arg_types__... __arg_values__);


и еще бы хорошо иметь decltype(return) для получения возвращаемого типа функции как в D

-----

и еще конструктор/деструктор переименовать в this и ~this
эх, мечты, мечты...
In Zen We Trust
Re[8]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 29.03.13 11:27
Оценка:
Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Abyx, Вы писали:


A>>а что в ASIO не продумано?

X>не искаропки =)
зато header-only.
#include <asio.hpp>
и готово
In Zen We Trust
Re[3]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 29.03.13 11:34
Оценка:
Здравствуйте, Erop, Вы писали:

E>Вот что на самом деле было бы круто, так это возможность иметь именованные конструкторы.

E>Что бы конструктор можно было выьирать не только перегрузкой, но и явным именем.

для этого есть теги

разница между
Foo(Tag);
FooTag();

не велика,
те же самые символы, только в другом порядке
In Zen We Trust
Re[9]: Что нам C++14 готовит...
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 29.03.13 11:57
Оценка:
Здравствуйте, Abyx, Вы писали:

A>нет, ASIO это не часть буста.


А что это?

A>а если мне этого всего не надо?


В более-менее крупных проектах, необходимость во всем этом добре рано или поздно появляется. Но, ACE никто для мелких проектов и не будет использовать в силу его размера.

A>пул потоков пишется в 2 строчки кода, для этого библиотека не нужна


К сожалению, это жалкое подобие пула потоков
Re[10]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 29.03.13 12:12
Оценка:
Здравствуйте, kaa.python, Вы писали:

A>>нет, ASIO это не часть буста.

KP>А что это?
просто библиотека, у которой есть отдельный вариант который входит в буст
http://think-async.com/

KP>В более-менее крупных проектах, необходимость во всем этом добре рано или поздно появляется. Но, ACE никто для мелких проектов и не будет использовать в силу его размера.

в крупных проектах уже есть свои(другие) логгеры и т.п.
In Zen We Trust
Re[3]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 29.03.13 14:17
Оценка:
Здравствуйте, niXman, Вы писали:

D>>OpenMP тоже лишнее.

X>это еще почему? оО

А зачем языку с lambda, higher-order functions, с библиотекой уровня STL, костыли типа OpenMP?
Уж лучше N3554 или C++ AMP.
Re[7]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 29.03.13 15:15
Оценка:
Здравствуйте, niXman, Вы писали:

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


С какой именно задачей? С задачей реализации высокоуровневых параллельных алгоритмов? Ну и замечательно — пусть и используется внутри реализации.

EP>>Но тащить его в ISO C++ это как-то уже слишком: добавлять в язык новые keyword'ы, для того что прекрасно реализуется библиотекой — это не C++ way

X>Cilk+ точно войдет в gcc-4.9.x. и того, gcc и Intel будут поддерживать это расширение. а это, основные компиляторы для всех ОСей кроме масдайки. так что, думается мне, оно получит признание среди множества разработчиков.

Ну и пусть получает признание
Чтобы ты предпочёл увидеть в стандарте: высокоуровневую библиотеку по типу TBB, PPL, N3554 или низкоуровневое расширение языка по типу OpenMP? И почему?
Re[7]: Что нам C++14 готовит...
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 29.03.13 22:46
Оценка:
Здравствуйте, niXman, Вы писали:

X>Cilk+ точно войдет в gcc-4.9.x. и того, gcc и Intel будут поддерживать это расширение. а это, основные компиляторы для всех ОСей кроме масдайки. так что, думается мне, оно получит признание среди множества разработчиков.


И еще Mac OS X и FreeBSD, где основной компилятор Clang. Сдается мне, что это расширение получит признание в основном у Linux разработчиков.
Re[3]: Что нам C++14 готовит...
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 29.03.13 23:07
Оценка:
Здравствуйте, Erop, Вы писали:

A>>и еще конструктор/деструктор переименовать в this и ~this

A>>эх, мечты, мечты...

Имхо это было бы неплохо

E>Вот что на самом деле было бы круто, так это возможность иметь именованные конструкторы.

E>Что бы конструктор можно было выьирать не только перегрузкой, но и явным именем.

Статические методы чем не устраивают?
Маньяк Робокряк колесит по городу
Re[4]: Что нам C++14 готовит...
От: Erop Россия  
Дата: 30.03.13 05:20
Оценка:
Здравствуйте, Marty, Вы писали:

M>Статические методы чем не устраивают?


Возвращаемым значением...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: Что нам C++14 готовит...
От: jazzer Россия Skype: enerjazzer
Дата: 01.04.13 02:51
Оценка:
Здравствуйте, nen777w, Вы писали:

KP>>Появилась первая подборка нововведений планируемых к включению в C++14.

KP>>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет

N>Мне бы очень хотелось вот такого:


N>
N>void foo(int n = 0, int k = 1, int m = 2);
N>foo(1,/*возможности пропускать аргумент по умолчанию*/,3);
N>

+1. Тем более что уже есть подходящие ключевые слова типа default

N>И вот такого:


N>
N>//another.h
N>// - форвардной декларации вложенных классов
N>struct foo::doo;
N>


Как насчет прав доступа? Вложенный класс ведь может быть объявлен приватным...
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Что нам C++14 готовит...
От: PM  
Дата: 01.04.13 05:47
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Появилась первая подборка нововведений планируемых к включению в C++14.

KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет

Вот еще интересное предложение: Move &amp; Copy Destructors
Re: Что нам C++14 готовит...
От: Ku-ku  
Дата: 01.04.13 07:57
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Появилась первая подборка нововведений планируемых к включению в C++14.


Кем планируемых? Все эти предложения уже прошли процедуру отбора для включения в C++14?
Re: Что нам C++14 готовит...
От: Nikita.Trophimov  
Дата: 03.04.13 05:23
Оценка:
Новая подборка

http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-papers-part-2.html
Re[2]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 03.04.13 05:27
Оценка:
Здравствуйте, Nikita.Trophimov, Вы писали:

NT>http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-papers-part-2.html

уже порадовало.
вот только непонятно, почему boost.filesysytem так и не появился?!
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[2]: Что нам C++14 готовит...
От: B0FEE664  
Дата: 03.04.13 12:26
Оценка:
Здравствуйте, Nikita.Trophimov, Вы писали:

NT>Новая подборка


NT>http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-papers-part-2.html

Proposing a C++1Y Swap Operator

Я правильно понимаю, что в результате выполнения вот этого кода:
x :=: y :=: z;


z получит значение, которое было у y
y получит значение, которое было у x
x получит значение, которое было у z


w :=: x :=: y :=: z;

z получит значение, которое было у y
y получит значение, которое было у x
x получит значение, которое было у w
w получит значение, которое было у z

?
И каждый день — без права на ошибку...
Re[3]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 03.04.13 15:08
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Proposing a C++1Y Swap Operator


BFE>
BFE>w :=: x :=: y :=: z;
BFE>


Кстати, если swap реализован как 3 assignment'а (не важно — move или copy) — то получается три swap'а это 9 assignment (N-1)*3.
А если делать нормальный cycle/rotate по получается 5 assignment (N+1).

BFE>Я правильно понимаю


вроде да
Re: Что нам C++14 готовит...
От: Мишень-сан  
Дата: 04.04.13 12:30
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Появилась первая подборка нововведений планируемых к включению в C++14.

KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет

Лучше бы модули сделали нормальные. Пока что по моим впечатлениям в язык пихают кучу непонятной порнографии. Один свап оператор чего стоит...
Re[2]: Что нам C++14 готовит...
От: flаt  
Дата: 04.04.13 13:01
Оценка:
Здравствуйте, Мишень-сан, Вы писали:

МС>Лучше бы модули сделали нормальные. Пока что по моим впечатлениям в язык пихают кучу непонятной порнографии. Один свап оператор чего стоит...

Как быть с обратной совместимостью? С тоннами legacy кода?

Вряд ли кто рискнёт вручную или через http://code.google.com/p/include-what-you-use переконвертировать гигантскую кучу кода библиотек.
Re[9]: Что нам C++14 готовит...
От: MTD https://github.com/mtrempoltsev
Дата: 04.04.13 14:25
Оценка:
Здравствуйте, Abyx, Вы писали:

A>зато header-only.


Это минус.
Re[10]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 04.04.13 14:28
Оценка:
Здравствуйте, MTD, Вы писали:

MTD>Здравствуйте, Abyx, Вы писали:


A>>зато header-only.


MTD>Это минус.


это почему?
In Zen We Trust
Re[3]: Что нам C++14 готовит...
От: Abyx Россия  
Дата: 04.04.13 14:29
Оценка:
Здравствуйте, flаt, Вы писали:

F>Здравствуйте, Мишень-сан, Вы писали:


МС>>Лучше бы модули сделали нормальные. Пока что по моим впечатлениям в язык пихают кучу непонятной порнографии. Один свап оператор чего стоит...

F>Как быть с обратной совместимостью? С тоннами legacy кода?

F>Вряд ли кто рискнёт вручную или через http://code.google.com/p/include-what-you-use переконвертировать гигантскую кучу кода библиотек.


модули не отменяют #include.
In Zen We Trust
Re: Что нам C++14 готовит...
От: Nikita.Trophimov  
Дата: 04.04.13 15:15
Оценка:
Ещё одна подборка

http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-and-beyond-papers-part-3.html
Re[3]: Что нам C++14 готовит...
От: Alexey F  
Дата: 04.04.13 16:01
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Не читал, но инциализаторы в классах планируют сделать?


K>
K>struct Foo
K>{
K>   T x = 0;
K>   T w = 1; // инициализируется в конструкторе по умолчанию
K>};
K>


Оно? http://www.stroustrup.com/C++11FAQ.html#member-init
В C++11 уже есть, GCC с 4.7.(0?) поддерживает, Clang тоже.
Re[2]: Что нам C++14 готовит...
От: night beast СССР  
Дата: 04.04.13 16:28
Оценка:
Здравствуйте, Мишень-сан, Вы писали:

МС>Лучше бы модули сделали нормальные. Пока что по моим впечатлениям в язык пихают кучу непонятной порнографии. Один свап оператор чего стоит...


свап, это который из первоапрельского документа?
Re[2]: Что нам C++14 готовит...
От: Cyberax Марс  
Дата: 04.04.13 16:47
Оценка:
Здравствуйте, Мишень-сан, Вы писали:

KP>>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет

МС>Лучше бы модули сделали нормальные. Пока что по моим впечатлениям в язык пихают кучу непонятной порнографии. Один свап оператор чего стоит...
Делают в рамках разработки LLVM: http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf
Sapienti sat!
Re[4]: Что нам C++14 готовит...
От: flаt  
Дата: 04.04.13 19:03
Оценка:
Здравствуйте, Abyx, Вы писали:

A>модули не отменяют #include.

Это понятно. Или вы имеете ввиду весь старый код в PCH загнать?
Re[13]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 04.04.13 19:08
Оценка:
Здравствуйте, Abyx, Вы писали:

A>>>>>зато header-only.

MTD>>>>Это минус.
A>>>это почему?
MTD>>Сильно увеличивает время компиляции.
A>сильно это насколько?
A>а с PCH?

PCH, при сборке проектов с разными параметрами, нужны разные. При такой ситуации, когда PCH генерируется один раз при сборке всего проекта, если какой-то заголовок используется только один раз — то выигрыша не получается (для этого заголовка).
Аналогичная ситуация с Unity Builds — основной выигрыш происходит тогда, когда заголовок используется многократно.
Вот например, попробуй подключить Boost.Spirit, и скомпилируй "на холодную".

Да, и PCH и Unity Builds, реально помогают сократить время build'ов (на одном из проектов было 4x), но не являются панацеей против долгой сборки проектов.
Re[4]: Что нам C++14 готовит...
От: Kluev  
Дата: 05.04.13 20:29
Оценка:
Здравствуйте, Alexey F, Вы писали:

AF>Оно? http://www.stroustrup.com/C++11FAQ.html#member-init

AF>В C++11 уже есть, GCC с 4.7.(0?) поддерживает, Clang тоже.

отлично. ждем в VC++
Re[14]: Что нам C++14 готовит...
От: rusted Беларусь  
Дата: 05.04.13 22:39
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>PCH, при сборке проектов с разными параметрами, нужны разные. При такой ситуации, когда PCH генерируется один раз при сборке всего проекта, если какой-то заголовок используется только один раз — то выигрыша не получается (для этого заголовка).


Почему же не получается? PCH же можно собрать один раз, а при последующих компиляциях использовать готовый — вполне себе выигрыш.
Re[3]: Что нам C++14 готовит...
От: nen777w  
Дата: 05.04.13 23:21
Оценка:
N>>И вот такого:

N>>
N>>//another.h
N>>// - форвардной декларации вложенных классов
N>>struct foo::doo;
N>>


J>Как насчет прав доступа? Вложенный класс ведь может быть объявлен приватным...

Гм.. а они не и нарушаются. Дружба она ж в обратную сторону действует.
Т.е. суть в том что бы doo из foo получил доступ к закрытым полям/методам some.
Но вот к сожалению синтаксис объявления такой дружбы в языке не предусмотрен.
Re[15]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 05.04.13 23:31
Оценка:
Здравствуйте, rusted, Вы писали:

EP>>PCH, при сборке проектов с разными параметрами, нужны разные. При такой ситуации, когда PCH генерируется один раз при сборке всего проекта, если какой-то заголовок используется только один раз — то выигрыша не получается (для этого заголовка).

R>Почему же не получается? PCH же можно собрать один раз, а при последующих компиляциях использовать готовый — вполне себе выигрыш.

Выделенное это исходные данные. При описанной ситуации — выигрыша не получается.
Если же, например, сборка всего лишь одна, один компилятором, параметры define-ы всегда одни и те же (ну или например всего два набора) — то да, тут PCH вполне решают.
Re[3]: Что нам C++14 готовит...
От: nen777w  
Дата: 06.04.13 08:57
Оценка:
J>Как насчет прав доступа? Вложенный класс ведь может быть объявлен приватным...

Вообще ИМХО дружба классов в С++ немного недоделана.
Как известно другом может быть что угодно. Мне не нравится сам факт что если class лежит в namespace, то объявление дружбы уже требует форвардной декларации.

namespace ns {
    class foo {
       class doo {};
    };
}
class foo {};

//другой хидер

//fw
namespace ns {
  class foo;
};

class some {
  friend class foo;
  friend class ns::foo;
  //а вот с doo облом...
};


ИМХО раз уж после friend нужно писать class (или struct), то следовало бы оставить и слово namespase.
Объявление стало бы сложнее (но опять таки ИМХО никого ж не пугают километровый синтаксис с шаблонами), но и дружба стала бы более "широкой".
Т.е. типа такого:

// здесь никакого форвардного обявления класса из ns
class some {
  friend class foo; //осталось как и было
  friend namespace ns class foo; // это ns::foo
  friend namespace ns class foo class doo; //это ns::foo::doo
};


Как то так...
Re[4]: Что нам C++14 готовит...
От: Ops Россия  
Дата: 06.04.13 18:37
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Кстати, если swap реализован как 3 assignment'а (не важно — move или copy) — то получается три swap'а это 9 assignment (N-1)*3.

EP>А если делать нормальный cycle/rotate по получается 5 assignment (N+1).

Думаю, если это будет встроенным оператором, то оптимизатор справится. В простых случаях это будет сделано вообще без присваиваний, просто регистры начнут соответствовать другим переменным.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[5]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 06.04.13 20:07
Оценка:
Здравствуйте, Ops, Вы писали:

EP>>Кстати, если swap реализован как 3 assignment'а (не важно — move или copy) — то получается три swap'а это 9 assignment (N-1)*3.

EP>>А если делать нормальный cycle/rotate по получается 5 assignment (N+1).
Ops>Думаю, если это будет встроенным оператором, то оптимизатор справится.

1. Чтобы оптимизатор справился в общем случае, а не только для POD'ов — ему это нужно разрешить игнорировать side-effect's assignment дополнительными пунктами в стандарте, которые закрепят семантику assignment. Сейчас такое закрепление семантики есть для копий, которое разрешает copy elision.

2. Зачем делать плохой интерфейс, который не позволяет выразить всю мысль целиком, и соответственно требует усилий оптимизатора + дополнительных пунктов в ISO, чтобы быть эффективным? Почему сразу не сделать нормальное обобщение swap'а — cycle_left, как это сделал Александр Степанов? Тем более при наличии вариадиков. Да и выглядит оно красивее:
cycle(a,b,c,d,e);
vs
a:=:b:=:c:=:d:=:e;


Ops>В простых случаях это будет сделано вообще без присваиваний, просто регистры начнут соответствовать другим переменным.


swap крайне редко используется в случаях, где возможно просто "переосмысление" что чему соответствует.
Re[5]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 06.04.13 20:29
Оценка:
Здравствуйте, Кодт, Вы писали:

J>>Ну и можно сделать эту фичу дополнением и разрешать и то, и другое, так что старый код от этого ломаться не будет, а новый только выиграет.

К>Вот только не надо this. Это дурацкая экономия на спичках, перегрузка смысла ключевого слова.

Согласен, this перегружать не надо. Я думаю ноги у this растут из D:
class AbraCadAbRa
{
    this()
    {}
    ~this()
    {}
}


К>Чем микрософтовские стандарто-совместимые __ctor и __dtor не приглянулись?


имхо, имя должно быть одно, что то типа self_type (но более лаконичное, + нужно постараться поломать как можно меньше кода новым keyword'ом), и желательно, чтобы его можно было использовать как имя типа, например при CRTP:
struct Foo: CRTP<self_type>
{
    self_type();
    ~self_type();
};

Именно поэтому лучше не использовать this (как имя значения и имя типа).
Re[5]: Что нам C++14 готовит...
От: jazzer Россия Skype: enerjazzer
Дата: 07.04.13 07:33
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, jazzer, Вы писали:


J>>А почему нет, собственно? Какое преимущество у констуктора/деструктора, называющегося точно как класс?

J>>Имя в любом случае прибито гвоздями: Если класс называется Т, то и конструктор обязан называться Т, а деструктор — ~T. Это ровно то же самое, что this, за исключением того, что ты можешь при переименовании класса тебе не нужно будет лезть и переименовывать конструкторы и деструктор.

К>Надо бы перечитать Строуструпа, я не помню, он как-то объясняет, зачем сделал именно так?

К>Видимо, по идейным соображениям, чтоб множественное наследование красиво выглядело:
К>
К>class Foo : Bar, Buz
К>{
К>  Foo() : Bar(123), Buz(456) {}
К>  // versus:
К>  ctor() : super(123), ????(456) {}
К>  // хотя что мешало сделать
К>  ctor() : Bar(123), Buz(456)
К>};
К>

К>Либо это экономия на синтаксисе, — чтобы минимизировать количество новых ключевых слов. Отсюда и ~T вместо dtor.
Да не, вызов пусть будет таким же, это не критично. А вот само объявление конструктора — лень. В принципе, твоей третий вариант — о том же.

К>Вот только не надо this. Это дурацкая экономия на спичках, перегрузка смысла ключевого слова.

К>Чем микрософтовские стандарто-совместимые __ctor и __dtor не приглянулись?
Да пофиг, в общем-то. Мне именно this не принципиален.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: Что нам C++14 готовит...
От: Мишень-сан  
Дата: 10.04.13 08:41
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, Мишень-сан, Вы писали:


МС>>Лучше бы модули сделали нормальные.


EP>Daveed Vandervoorde: "Modules in C++"


Спасибо за видео, я пока только читал предложение Дэвида.
Поэтому и высказался, что лучше бы его добавили в TR.
Стрим мьютексы туда попали.
OpenMP туда попал.
А нормальная система модулей никому, похоже, не нужна. Ок, продолжаем жить при Header Hell.
Re[4]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 10.04.13 12:46
Оценка:
Здравствуйте, Мишень-сан, Вы писали:

МС>Поэтому и высказался, что лучше бы его добавили в TR.

МС>OpenMP туда попал.

Куда это OpenMP попал?
Я так понял это только proposal, и то там весь proposal это "а давай-те как-нибудь заюзаем OpenMP" без конкретики.
Надеюсь что никакое OpenMP в язык не пролезет.
Re[5]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 10.04.13 12:52
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Я так понял это только proposal, и то там весь proposal это "а давай-те как-нибудь заюзаем OpenMP" без конкретики.

EP>Надеюсь что никакое OpenMP в язык не пролезет.
зря надеешься =)
OpenMP стандартизован и развивается. нет причин не включать его в стандарт С++.

но признаюсь, тот способ которым OpenMP реализуется, ниразу не соответствует идеологии С++. но, с другой стороны, если так мыслить, то и Cilk+ там не нужен.
в общем поглядим... но определенно, нужна какая-то поддержка многопоточности/синхронизации на уровне языка. иначе С++ получается самым сложным ЯП для разработки многопоточных программ.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[6]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 10.04.13 12:53
Оценка:
Здравствуйте, niXman, Вы писали:

X>иначе С++ получается самым сложным ЯП для разработки многопоточных программ.

иначе С++ получается самым неподходящим ЯП для разработки многопоточных программ.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[8]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 10.04.13 13:05
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Господа, проявите терпение, Rust почти готов

жду с нетерпением.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[9]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 10.04.13 13:15
Оценка:
а кто-то видел, есть ли пропосал для for(), который принимает пару значений "от — до" ?
for ( auto idx: {34..56} ) {}
for ( auto idx: {34,56} ) {}


про boost.range знаю, спасибо
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[6]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 10.04.13 13:32
Оценка:
Здравствуйте, niXman, Вы писали:

X>зря надеешься =)

X>OpenMP стандартизован и развивается. нет причин не включать его в стандарт С++.

То есть ты предлагаешь включать в ISO C++ любой убогий костыль, в корне не соответствующую генеральной линии языка, который хоть как-то стандартизирован?

X>но признаюсь, тот способ которым OpenMP реализуется, ниразу не соответствует идеологии С++.


В смысле синтаксис? ну да, я о том и говорю.

X>но, с другой стороны, если так мыслить, то и Cilk+ там не нужен.

X>в общем поглядим... но определенно, нужна какая-то поддержка многопоточности/синхронизации на уровне языка. иначе С++ получается самым сложным ЯП для разработки многопоточных программ.

Поддержка нужна, и она прекрасно реализуется library-only. Microsoft PPL, Intel TBB — тому подтверждение.

Вот например:
1. В OpenMP Proposal они предлагают paralleltask, который по функциональности сильно пересекается с std::async. Но, почему-то их язык не устраивает — новый keyword подавай.

2. Предложенный ими "parallel for" — имеет свои семантические ограничения, ты не можешь любой for заменить на parallel for. Эти ограничения должны быть описаны в стандарте, захламляя core language.
В то время как library-only решение может забетонировать эти ограничения в API:
parallel_for_each( irange(0,100), [&](i) a[i]=i*2 );
or
parallel_transform( irange(0,100), a, [](i) i*2 );


Да, кстати, что делать например с parallel reduce, parallel transform/map? тоже вводить openmp'шные костыли?
Re[7]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 10.04.13 13:43
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>То есть ты предлагаешь включать в ISO C++ любой убогий костыль, в корне не соответствующую генеральной линии языка, который хоть как-то стандартизирован?

только самое необходимое.

EP>В смысле синтаксис? ну да, я о том и говорю.

не только синтаксис, но и "закулисная" реализация.

EP>Поддержка нужна, и она прекрасно реализуется library-only. Microsoft PPL, Intel TBB — тому подтверждение.

в отношении С++ и многопоточности — слова типа "хорошо"/"отлично"/"прекрасно" — вообще не соответствуют действительности. в С++ с многопоточностью полная жопа.
посмотри на такие компилируемые ЯП как haskell/Go/Rust — в них да, какое-то из этих слов может использоваться.

EP>Вот например:

EP>1. В OpenMP Proposal они предлагают paralleltask, который по функциональности сильно пересекается с std::async. Но, почему-то их язык не устраивает — новый keyword подавай.
цель проста: упростить реализаторам жизнь.

EP>2. Предложенный ими "parallel for" — имеет свои семантические ограничения, ты не можешь любой for заменить на parallel for. Эти ограничения должны быть описаны в стандарте, захламляя core language.

EP>В то время как library-only решение может забетонировать эти ограничения в API:
EP>
EP>parallel_for_each( irange(0,100), [&](i) a[i]=i*2 );
EP>or
EP>parallel_transform( irange(0,100), a, [](i) i*2 );
EP>

это же можно реализовать в Cilk+ или OpenMP. достаточно лишь научить их принимать пользовательское функторы/предикаты.

EP>Да, кстати, что делать например с parallel reduce, parallel transform/map? тоже вводить openmp'шные костыли?

нет же, строка выше.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[10]: Что нам C++14 готовит...
От: B0FEE664  
Дата: 10.04.13 14:02
Оценка:
Здравствуйте, niXman, Вы писали:

X>а кто-то видел, есть ли пропосал для for(), который принимает пару значений "от — до" ?

X>
X>for ( auto idx: {34..56} ) {}
X>for ( auto idx: {34,56} ) {}
X>


не нужно.

Я не использовал, но в стандарте есть operator "" и literal suffix identifier,
что, по идее, должно позволять писать так:

for ( auto idx: "34..56"_range ) {}
И каждый день — без права на ошибку...
Re[8]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 10.04.13 14:03
Оценка:
Здравствуйте, niXman, Вы писали:

EP>>То есть ты предлагаешь включать в ISO C++ любой убогий костыль, в корне не соответствующую генеральной линии языка, который хоть как-то стандартизирован?

X>только самое необходимое.

Настолько необходимое, что нужно включать ASAP, а не подождать нормального library-only proposal типа N3554?
Я вообще не пойму какой-то тут может быть ASAP: на твоих компиляторах есть OpenMP? — ну замечательно, просто бери и используй — зачем тащить в C++ ISO?

EP>>Поддержка нужна, и она прекрасно реализуется library-only. Microsoft PPL, Intel TBB — тому подтверждение.

X>в отношении С++ и многопоточности — слова типа "хорошо"/"отлично"/"прекрасно" — вообще не соответствуют действительности. в С++ с многопоточностью полная жопа.
X>посмотри на такие компилируемые ЯП как haskell/Go/Rust — в них да, какое-то из этих слов может использоваться.

я конкретно говорю про сравнение openmp vs library-only

EP>>Вот например:

EP>>1. В OpenMP Proposal они предлагают paralleltask, который по функциональности сильно пересекается с std::async. Но, почему-то их язык не устраивает — новый keyword подавай.
X>цель проста: упростить реализаторам жизнь.

Реализаторы спокойно могут использовать openmp внутри реализации N3554

EP>>2. Предложенный ими "parallel for" — имеет свои семантические ограничения, ты не можешь любой for заменить на parallel for. Эти ограничения должны быть описаны в стандарте, захламляя core language.

EP>>В то время как library-only решение может забетонировать эти ограничения в API:
EP>>
EP>>parallel_for_each( irange(0,100), [&](i) a[i]=i*2 );
EP>>or
EP>>parallel_transform( irange(0,100), a, [](i) i*2 );
EP>>

X>это же можно реализовать в Cilk+ или OpenMP. достаточно лишь научить их принимать пользовательское функторы/предикаты.

Openmp с функторами это же вообще жесть и цирк с конями.
но речь не о них.

Пример выше показывает, что при использовании irange — интерфейс реинфосит использование инкремента одним только синтаксисом. В то время как в OpenMP семантику возможных инкрементов нужно дополнительно описывать, причём в core langauge.

EP>>Да, кстати, что делать например с parallel reduce, parallel transform/map? тоже вводить openmp'шные костыли?

X>нет же, строка выше.

Поясни, желательно с небольшими примерами кода
Re[8]: Что нам C++14 готовит...
От: Мишень-сан  
Дата: 11.04.13 08:02
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, niXman, Вы писали:


X>>иначе С++ получается самым неподходящим ЯП для разработки многопоточных программ.


KP>Господа, проявите терпение, Rust почти готов


Ждём-с. Идеи в основе просто пальчики оближешь — movable owned values, non-nullable по умолчанию, type inference...
Хотя конечно с некоторыми вещами типа явного self для функций-членов класса и чрезмерной мании сокращать идентификаторы я бы поспорил.
Re[9]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 11.04.13 08:08
Оценка:
Здравствуйте, Мишень-сан, Вы писали:

МС>Ждём-с. Идеи в основе просто пальчики оближешь — movable owned values, non-nullable по умолчанию, type inference...

радует то, что они компилятор строят на основе LLVM, а не как Go, самопальный =)

МС>Хотя конечно с некоторыми вещами типа явного self для функций-членов класса и чрезмерной мании сокращать идентификаторы я бы поспорил.

да, self в последней редакции языка меня тоже расстроил %)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[10]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 11.04.13 11:36
Оценка:
так а что, 'static if' в 2014 таки ждать не стОит?!
пишу тут кодец и думаю, будь доступен сабж — кода бы получилось в разы меньше, и он бы писался и читался в разы проще.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[11]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 11.04.13 16:51
Оценка:
Здравствуйте, niXman, Вы писали:

X>так а что, 'static if' в 2014 таки ждать не стОит?!

X>пишу тут кодец и думаю, будь доступен сабж — кода бы получилось в разы меньше, и он бы писался и читался в разы проще.

уже походу не будет static if.
Re[12]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 11.04.13 16:54
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>уже походу не будет static if.

как из этого документа ты это понял?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[13]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 11.04.13 17:02
Оценка:
Здравствуйте, niXman, Вы писали:

X>как из этого документа ты это понял?

понял.
я поначалу подумал, что это ссылка на пропосал

а откуда ты взял эту ссылку? где-то вообще обсуждался этот документ? есть ли решение?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[14]: Что нам C++14 готовит...
От: Evgeny.Panasyuk Россия  
Дата: 11.04.13 17:47
Оценка:
Здравствуйте, niXman, Вы писали:

X>а откуда ты взял эту ссылку? где-то вообще обсуждался этот документ? есть ли решение?


взял отсюда.
Re[14]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 11.04.13 17:48
Оценка:
прочитал отговорку описанную в документе и улыбнулся =)))
аргументы не принимать 'static if' приводятся на реально нелепых примерах %)
template<typename T, typename A>
class dynarray {
   T* start_;
   T* finish_;
   static if (!is_empty<A>::value) {
      A alloc_;
   }
};

// Although may seem like an elegant alternative, the impact 
// on the class’s implementation is far less so.
// For example, how would we write a constructor?
template<typename T, typename A>
dynarray<T, A>::dynarray(size_t n, T value, const A& alloc)
   :start_(alloc.allocate(n * sizeof(T))
   ,finish_(start + n)
{
   static if (!is_empty<A>::value) {
      alloc = alloc_;
   }
}

// Every access to the allocator member must be guarded by a new static if.
// Again, this use of static if is viral.
// A viable alternative to the use of static if or more traditional means of
// implementing the empty base optimization is to use a tuple. The tuple template
// will eliminate all of the overhead of empty classes.
// The use of static if might also be used to reorder data structures for tighter
// alignment, but this is a potentially dangerous idea that could lead to bugs that
// are exceptionally difficult to diagnose and fix.
// Being a new and relatively simple-to-use new feature, static_if would 
// undoubtedly be used by many who have no need for the relatively small 
// incremental improvement in performance offered. The library writers for which such
// techniques really are important, already have the tools and skills needed.

ну зачем тут статик иф?!
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[15]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 11.04.13 18:06
Оценка:
ну или такой пример.
// The static if feature is also available inside class scope. A number of possible
// applications have been presented. Below is an example of a metafunction for
// computing factorials.

template <unsigned long n>
struct factorial {
   static if (n <= 1) {
      enum : unsigned long { value = 1 };
   } else {
      enum : unsigned long { value = factorial<n - 1>::value * n };
   }
};

// This seems like a reasonable idea, but the motivating example simply moves
// the complexity from one style of idiomatic programming to another and does
// so in a way that requires a new language feature. A better solution would be
// to use constexpr functions. A significant negative consequence of that feature
// is increased confusion about how to write integer metaprograms.

ну реально же, зачем кому-то может понадобится написать такое, когда в стандарте есть constexpr?!
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[15]: Что нам C++14 готовит...
От: Ku-ku  
Дата: 11.04.13 22:57
Оценка:
Здравствуйте, niXman, Вы писали:

X>прочитал отговорку описанную в документе и улыбнулся =)))

X>аргументы не принимать 'static if' приводятся на реально нелепых примерах %)

Обрати внимание, какие веские контраргументы господин Страуструп умеет приводить, когда дело касается его предложений
Re[16]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 12.04.13 06:11
Оценка:
Здравствуйте, Ku-ku, Вы писали:

KK>Обрати внимание, какие веские контраргументы господин Страуструп умеет приводить, когда дело касается его предложений

да он троллит =)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re: Что нам C++14 готовит...
От: CoolCmd Россия  
Дата: 19.04.13 16:43
Оценка:
а почему не хотят добавить else для for? с другим названием конечно.
простите, я убил небо
Re[2]: Что нам C++14 готовит...
От: Ops Россия  
Дата: 19.04.13 17:13
Оценка:
Здравствуйте, CoolCmd, Вы писали:

CC>а почему не хотят добавить else для for? с другим названием конечно.


Это как?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[4]: Что нам C++14 готовит...
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 19.04.13 19:49
Оценка:
Здравствуйте, CoolCmd, Вы писали:

CC>Здравствуйте, Ops, Вы писали:


Ops>>Это как?

CC>так. и для while тоже.

Тогда, имхо, было бы логично добавить две ветки — одна выполняется, если был break, другая — если не был. Опциональная третья ветка — если цикл выполнился 0 раз.
Маньяк Робокряк колесит по городу
Re[2]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 20.04.13 05:33
Оценка:
Здравствуйте, CoolCmd, Вы писали:

CC>а почему не хотят добавить else для for? с другим названием конечно.

почему не хотят? вроде уже предложили.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[4]: Что нам C++14 готовит...
От: alex_public  
Дата: 20.04.13 16:09
Оценка:
Здравствуйте, CoolCmd, Вы писали:

CC>Здравствуйте, Ops, Вы писали:


Ops>>Это как?

CC>так. и для while тоже.

Кстати да, частенько бывает ситуация узнать после цикла как он завершился... Интересное решение.
Re[5]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 21.04.13 15:00
Оценка:
а тем временем, разработчики gcc интересуются "Macro for C++14 support":
http://gcc.gnu.org/ml/gcc/2013-04/msg00194.html

I'm starting to implement some new library features voted into C++14
at the Bristol meeting and am wondering what feature check to use.

Will there be a macro like _GXX_EXPERIMENTAL_CXX1Y__ to correspond to
-std=c++1y?

Alternatively we could set the value of __cplusplus to 201400L but I'm
not sure that's strictly allowed.

пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[6]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 22.04.13 12:26
Оценка:
в списке рассылки boost сообщили о том, что boost::optional&lt;&gt; принят в С++14.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[7]: Что нам C++14 готовит...
От: alex_public  
Дата: 23.04.13 19:45
Оценка:
Здравствуйте, niXman, Вы писали:

X>в списке рассылки boost сообщили о том, что boost::optional&lt;&gt; принят в С++14.


О, отлично! А то в этом смысле даже классическая техника из старенького C с нулевыми указателями имела преимущество над C++. Ну естественно если не использовать Boost или свой подобный велосипед.
Re[10]: Что нам C++14 готовит...
От: abrarov Россия http://asio-samples.blogspot.com/
Дата: 29.04.13 12:19
Оценка:
Здравствуйте, MTD, Вы писали:

A>>зато header-only.

MTD>Это минус.

А "Optional separate compilation" не пробовали?
Programs must be written for people to read, and only incidentally for machines to execute
Re[2]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 24.09.13 15:37
Оценка:
Здравствуйте, The Passenger, Вы писали:

TP>C# и жабу уже вроде изобрели

зачем?
TP>зачем все эти жалкие потуги
вот и мне не понятно, см. выше %)
TP>когда половина программеров 98х не знает и наполовину?
наверное потому, что есть вторая половина?

TP>И почему расширение стандартной библиотеки называют фичами языка ?

а хз.

TP>вот например — auto или новый for — это вроде как фича

TP>а бинды функторы и потоки — это вроде как расширения библиотеки, какого хрена они делают в стандарте.
неотъемлемая часть стандарта?

TP>по мне так плюсы используют люди, которые хотят иметь уверенность как это работает под капотом вплоть до ассемблерных инструкций,

TP>а когда пошли эти высокоуровневые навороты — то проще уж на жабу перейти и не мучаться.
"на жабу" и "не мучаться" — что-то не так %)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[3]: Что нам C++14 готовит...
От: niXman Ниоткуда https://github.com/niXman
Дата: 25.09.13 14:31
Оценка:
а вот и оно:
http://gcc.gnu.org/ml/libstdc++/2013-09/msg00189.html
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[2]: Что нам C++14 готовит...
От: MasterZiv СССР  
Дата: 26.09.13 13:37
Оценка:
Здравствуйте, The Passenger,
по-моему вы просто сели не в тот поезд...
Re[3]: Что нам C++14 готовит...
От: The Passenger Голландия  
Дата: 26.09.13 16:15
Оценка:
Здравствуйте, jazzer, Вы писали:

J>А кто сказал, что мы в С++ не понимаем, как работают лямбды "под капотом вплоть до ассемблерных инструкций"?


и каков процент таких программистов на ++ ?
Весь мир — Кремль, а люди в нем — агенты
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.