Появилась первая подборка нововведений планируемых к включению в C++14.
Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет
Здравствуйте, 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
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Abyx, Вы писали:
A>>а что в ASIO не продумано?
KP>ASIO — это не более чем часть BOOST.
нет, ASIO это не часть буста.
KP>ACE, как было верно подмечено выше, это полноценный фрэймворк, который по ряду функций превосходит BOOST. Так, к примеру, при работе с ACE у тебя сразу решены такие мелочи как логирование, TLS (этот вопрос вроде отпал с C++11), межпроцессное взаимодействие (в виде TAO, т.е. CORBA),
а если мне этого всего не надо?
KP>пул потоков
пул потоков пишется в 2 строчки кода, для этого библиотека не нужна
Здравствуйте, Cyberax, Вы писали:
C>В основном, там библиотечные изменения (вполне разумные — полиморфные аллокаторы рулят). Языковых почти нет.
Надо же. 13 лет кормили пользователей stl говном и вдруг прозрели. Полагаю в следующей итерации прийдут к контейнеру как к некопируемому объекту с виртуальными функциями аллокации. Т.е. к старому доброму ООП.
C# и жабу уже вроде изобрели, зачем все эти жалкие потуги, когда половина программеров 98х не знает и наполовину?
И почему расширение стандартной библиотеки называют фичами языка ?
вот например — auto или новый for — это вроде как фича
а бинды функторы и потоки — это вроде как расширения библиотеки, какого хрена они делают в стандарте.
по мне так плюсы используют люди, которые хотят иметь уверенность как это работает под капотом вплоть до ассемблерных инструкций,
а когда пошли эти высокоуровневые навороты — то проще уж на жабу перейти и не мучаться.
15.10.2013 15:19, slava_phirsov пишет:
> Собеседуя (ну и просто беседуя) программеров на C++ (вт.ч. с профильным > образованием, сертификатами и прочими понтами), приходилось массово > сталкиваться с людьми, не понимающими, как целое число хранится в > памяти, не знающими, что такое двоичная система счисления, не > понимающими, что тип строки "foo" — не std::string, ну ит.д.
Почему-то после вопросов о пересечении двух отрезков оное меня не
удивляет. Ты просто не то спрашивал, надо было про сортировки и гномиков.
Здравствуйте, kaa.python, Вы писали:
KP>Я, может быть, несколько старомоден, но мне ACE несравненно больше чем boost.asio нравится
неповоротливый монстр. фреймворк, одним словом.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, denisko, Вы писали:
D>>OpenMP тоже лишнее. X>это еще почему? оО
А нафига оно нужно на уровне языка? Мое мнение -- если что-то включается в язык C++, то в идеале программист должен представлять во что это скомпильнется с точностью до инструкции (пока не берем оптимизированный код, но и его надо уметь читать. В случае с OpenMP это практически невозможно, т.к. она классический черный ящик, который делает под капотом кучу небесплатной работы, и который со временем развивается. Та поддержка ее, которая есть сейчас имхо оптимальна, да и читать прагмы гораздо легче, чем очередной вариант for'a.
Здравствуйте, 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 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, 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() в С++).
Здравствуйте, The Passenger, Вы писали:
TP>по мне так плюсы используют люди, которые хотят иметь уверенность как это работает под капотом вплоть до ассемблерных инструкций, TP>а когда пошли эти высокоуровневые навороты — то проще уж на жабу перейти и не мучаться.
А кто сказал, что мы в С++ не понимаем, как работают лямбды "под капотом вплоть до ассемблерных инструкций"?
Здравствуйте, jazzer, Вы писали:
J>А кто сказал, что мы в С++ не понимаем, как работают лямбды "под капотом вплоть до ассемблерных инструкций"?
Собеседуя (ну и просто беседуя) программеров на C++ (вт.ч. с профильным образованием, сертификатами и прочими понтами), приходилось массово сталкиваться с людьми, не понимающими, как целое число хранится в памяти, не знающими, что такое двоичная система счисления, не понимающими, что тип строки "foo" — не std::string, ну ит.д. Так что, боюсь, что число людей понимающих как работают лямбды "под капотом вплоть до ассемблерных инструкций" исчезающе мало (скоро будет мало и число людей, вообще знающих, что такое "ассемблерные инструкции").
Но с The Passenger согласен — язык и так уже раздут до предела всякими свистульками и бубенчиками, которые большинству кодеров либо не знакомы, либо знакомы, но не нужны, либо нужны, но можно обойтись и без них (как-то ж обходились с 98-го). А комитет всё продолжает и продолжает — видать, теплое местечко, уходить неохота. Боюсь, что кончится это все так же, как с POSIX.
Люди! Люди, смотрите, я сошел с ума! Люди! Возлюбите друг друга! (вы чувствуете, какой бред?)
KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет
Это вроде как старая приплюснутая традиция -- стандарты таки парами выходят
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Abyx, Вы писали:
A>и еще конструктор/деструктор переименовать в this и ~this A>эх, мечты, мечты...
Вот что на самом деле было бы круто, так это возможность иметь именованные конструкторы.
Что бы конструктор можно было выьирать не только перегрузкой, но и явным именем.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Abyx, Вы писали:
A>а что в ASIO не продумано?
ASIO — это не более чем часть BOOST. ACE, как было верно подмечено выше, это полноценный фрэймворк, который по ряду функций превосходит BOOST. Так, к примеру, при работе с ACE у тебя сразу решены такие мелочи как логирование, TLS (этот вопрос вроде отпал с C++11), межпроцессное взаимодействие (в виде TAO, т.е. CORBA), пул потоков, нормальный Proactor (тут не могу утверждать на все сто, но год-два назад ASIO лишь эмулировал Proactor на синхронном I/O).
Здравствуйте, 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
Здравствуйте, 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; } // никакой избыточности
Такое нужно при использовании автоматически сгенерированного кода,
в частности макросов типа
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А зачем языку с lambda, higher-order functions, с библиотекой уровня STL, костыли типа OpenMP?
возможно ты не в курсе, но сейчас параллельные алгоритмы в GCC реализованы при помощи OMP.
зачем?/почему? — ну я право хз, как еще объяснить...чтоб упростить достижение цели.
EP>Уж лучше N3554 или C++ AMP.
лучше. когда стандартизуют, вот тогда оно будет лучше. а пока что, OMP, замечательный стандартизованный инструмент, поддерживаемый всеми топовыми компиляторами.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, denisko, Вы писали:
D>>Здравствуйте, Abyx, Вы писали:
A>>>и еще бы хорошо иметь decltype(return) для получения возвращаемого типа функции как в D D>>В каких ситуациях используется? вообще в ++11 уже есть такая порнография
A>decltype(return) используется внутри функции, чтобы убрать избыточность,
естество, имхо
A>Такое нужно при использовании автоматически сгенерированного кода, A>в частности макросов типа A>
Здравствуйте, Nikita.Trophimov, Вы писали:
A>>и еще конструктор/деструктор переименовать в this и ~this
NT>Зачем?
А почему нет, собственно? Какое преимущество у констуктора/деструктора, называющегося точно как класс?
Имя в любом случае прибито гвоздями: Если класс называется Т, то и конструктор обязан называться Т, а деструктор — ~T. Это ровно то же самое, что this, за исключением того, что ты можешь при переименовании класса тебе не нужно будет лезть и переименовывать конструкторы и деструктор.
Единственный довод за старое имя, который я вижу — это явный вызов деструктора через ptr->~T(), но и тут тоже ~this нормально сработал бы, разве что не так наглядно (с другой стороны, сейчас есть возможность совершить ошибку, вписав не тот деструктор, а, например, деструктор базового класса, который, если не виртуальный, не сделает всего, что нам нужно — с ~this это будет невозможно — деструктор будет определяться по типу ptr).
Ну и можно сделать эту фичу дополнением и разрешать и то, и другое, так что старый код от этого ломаться не будет, а новый только выиграет.
Еще довод: сейчас при использовании макросов всюду надо передавать имя класса, а так не надо будет, можно будет просто иметь макрос с телом класса, который сгенерит все, что надо, пользуясь class-agnostic-именами типа this.
Здравствуйте, 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> {};
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Nikita.Trophimov, Вы писали:
A>>>и еще конструктор/деструктор переименовать в this и ~this
NT>>Зачем?
J>А почему нет, собственно?
В C++ и так уже полно мест, где одно и тоже ключевое слово означает совсем разное: и static, и template, и typename. Когда ты уже 20 лет наблюдаешь развитие языка, то подобное ре-использование ключевых слов вроде и не добавляет сложности. Но вот многих, кто только начинает изучать язык, это всё сильно запутывает, и самое неприятное то, что до того как они во всём разберуться, они уже успевают понаписать достаточно кода, который потом приходится поддерживать.
Может и стоит сделать независящие от имени типа конструкторы и деструкторы, но уж точно не как this/~this. __ctor и __dtor для такого подойдут гораздо лучше.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, The Passenger, Вы писали:
TP>>по мне так плюсы используют люди, которые хотят иметь уверенность как это работает под капотом вплоть до ассемблерных инструкций, TP>>а когда пошли эти высокоуровневые навороты — то проще уж на жабу перейти и не мучаться.
J>А кто сказал, что мы в С++ не понимаем, как работают лямбды "под капотом вплоть до ассемблерных инструкций"?
Я даже больше скажу, часто плюсовики настолько суровы, что знают и как эти йихние явы работают под капотом вплоть до ассемблерных инструкций
Здравствуйте, kaa.python, Вы писали:
KP>Появилась первая подборка нововведений планируемых к включению в C++14. KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет
В основном, там библиотечные изменения (вполне разумные — полиморфные аллокаторы рулят). Языковых почти нет.
KP>Появилась первая подборка нововведений планируемых к включению в C++14. KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет
Мне бы очень хотелось вот такого:
void foo(int n = 0, int k = 1, int m = 2);
foo(1,/*возможности пропускать аргумент по умолчанию*/,3);
И вот такого:
//foo.hstruct foo {
struct doo {
};
};
//another.h
// - форвардной декларации вложенных классовstruct foo::doo;
//для этогоclass some {
friend struct foo::doo; //теперь doo из foo друг класса some
}
Здравствуйте, denisko, Вы писали:
D>А нафига оно нужно на уровне языка? Мое мнение -- если что-то включается в язык C++, то в идеале программист должен представлять во что это скомпильнется с точностью до инструкции (пока не берем оптимизированный код, но и его надо уметь читать. В случае с OpenMP это практически невозможно, т.к. она классический черный ящик, который делает под капотом кучу небесплатной работы, и который со временем развивается. Та поддержка ее, которая есть сейчас имхо оптимальна, да и читать прагмы гораздо легче, чем очередной вариант for'a.
а я хотел бы, чтоб у плюсов был пайтоновский синтаксис
так и с OMP и с Cilk+(который войдет в gcc-4.9.x). они упрощают достижение цели.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, 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
эх, мечты, мечты...
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Abyx, Вы писали:
A>>а что в ASIO не продумано? X>не искаропки =)
зато header-only.
#include <asio.hpp>
и готово
Здравствуйте, Erop, Вы писали:
E>Вот что на самом деле было бы круто, так это возможность иметь именованные конструкторы. E>Что бы конструктор можно было выьирать не только перегрузкой, но и явным именем.
для этого есть теги
разница между
Foo(Tag);
FooTag();
не велика,
те же самые символы, только в другом порядке
Здравствуйте, Abyx, Вы писали:
A>нет, ASIO это не часть буста.
А что это?
A>а если мне этого всего не надо?
В более-менее крупных проектах, необходимость во всем этом добре рано или поздно появляется. Но, ACE никто для мелких проектов и не будет использовать в силу его размера.
A>пул потоков пишется в 2 строчки кода, для этого библиотека не нужна
Здравствуйте, kaa.python, Вы писали:
A>>нет, ASIO это не часть буста. KP>А что это?
просто библиотека, у которой есть отдельный вариант который входит в буст http://think-async.com/
KP>В более-менее крупных проектах, необходимость во всем этом добре рано или поздно появляется. Но, ACE никто для мелких проектов и не будет использовать в силу его размера.
в крупных проектах уже есть свои(другие) логгеры и т.п.
Здравствуйте, niXman, Вы писали:
X>свою фразу я приводил для того, чтоб показать что OMP отлично справляется со своей задачей, и что нереально сильно экономит и время и нервы.
С какой именно задачей? С задачей реализации высокоуровневых параллельных алгоритмов? Ну и замечательно — пусть и используется внутри реализации.
EP>>Но тащить его в ISO C++ это как-то уже слишком: добавлять в язык новые keyword'ы, для того что прекрасно реализуется библиотекой — это не C++ way X>Cilk+ точно войдет в gcc-4.9.x. и того, gcc и Intel будут поддерживать это расширение. а это, основные компиляторы для всех ОСей кроме масдайки. так что, думается мне, оно получит признание среди множества разработчиков.
Ну и пусть получает признание
Чтобы ты предпочёл увидеть в стандарте: высокоуровневую библиотеку по типу TBB, PPL, N3554 или низкоуровневое расширение языка по типу OpenMP? И почему?
Здравствуйте, niXman, Вы писали:
X>Cilk+ точно войдет в gcc-4.9.x. и того, gcc и Intel будут поддерживать это расширение. а это, основные компиляторы для всех ОСей кроме масдайки. так что, думается мне, оно получит признание среди множества разработчиков.
И еще Mac OS X и FreeBSD, где основной компилятор Clang. Сдается мне, что это расширение получит признание в основном у Linux разработчиков.
Здравствуйте, Erop, Вы писали:
A>>и еще конструктор/деструктор переименовать в this и ~this A>>эх, мечты, мечты...
Имхо это было бы неплохо
E>Вот что на самом деле было бы круто, так это возможность иметь именованные конструкторы. E>Что бы конструктор можно было выьирать не только перегрузкой, но и явным именем.
Здравствуйте, Marty, Вы писали:
M>Статические методы чем не устраивают?
Возвращаемым значением...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, 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>
Как насчет прав доступа? Вложенный класс ведь может быть объявлен приватным...
Здравствуйте, kaa.python, Вы писали:
KP>Появилась первая подборка нововведений планируемых к включению в C++14. KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет
Здравствуйте, 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>Я правильно понимаю
Здравствуйте, kaa.python, Вы писали:
KP>Появилась первая подборка нововведений планируемых к включению в C++14. KP>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет
Лучше бы модули сделали нормальные. Пока что по моим впечатлениям в язык пихают кучу непонятной порнографии. Один свап оператор чего стоит...
Здравствуйте, Мишень-сан, Вы писали:
МС>Лучше бы модули сделали нормальные. Пока что по моим впечатлениям в язык пихают кучу непонятной порнографии. Один свап оператор чего стоит...
Как быть с обратной совместимостью? С тоннами legacy кода?
Здравствуйте, flаt, Вы писали:
F>Здравствуйте, Мишень-сан, Вы писали:
МС>>Лучше бы модули сделали нормальные. Пока что по моим впечатлениям в язык пихают кучу непонятной порнографии. Один свап оператор чего стоит... F>Как быть с обратной совместимостью? С тоннами legacy кода?
F>Вряд ли кто рискнёт вручную или через http://code.google.com/p/include-what-you-use переконвертировать гигантскую кучу кода библиотек.
Здравствуйте, Мишень-сан, Вы писали:
МС>Лучше бы модули сделали нормальные. Пока что по моим впечатлениям в язык пихают кучу непонятной порнографии. Один свап оператор чего стоит...
Здравствуйте, Мишень-сан, Вы писали:
KP>>Вообще, с C++ интересно получается, то чуть ли не самый мало изменяемый язык из активно использующихся, то каак понесет МС>Лучше бы модули сделали нормальные. Пока что по моим впечатлениям в язык пихают кучу непонятной порнографии. Один свап оператор чего стоит...
Делают в рамках разработки LLVM: http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf
Здравствуйте, Abyx, Вы писали:
A>>>>>зато header-only. MTD>>>>Это минус. A>>>это почему? MTD>>Сильно увеличивает время компиляции. A>сильно это насколько? A>а с PCH?
PCH, при сборке проектов с разными параметрами, нужны разные. При такой ситуации, когда PCH генерируется один раз при сборке всего проекта, если какой-то заголовок используется только один раз — то выигрыша не получается (для этого заголовка).
Аналогичная ситуация с Unity Builds — основной выигрыш происходит тогда, когда заголовок используется многократно.
Вот например, попробуй подключить Boost.Spirit, и скомпилируй "на холодную".
Да, и PCH и Unity Builds, реально помогают сократить время build'ов (на одном из проектов было 4x), но не являются панацеей против долгой сборки проектов.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>PCH, при сборке проектов с разными параметрами, нужны разные. При такой ситуации, когда PCH генерируется один раз при сборке всего проекта, если какой-то заголовок используется только один раз — то выигрыша не получается (для этого заголовка).
Почему же не получается? PCH же можно собрать один раз, а при последующих компиляциях использовать готовый — вполне себе выигрыш.
N>>//another.h
N>>// - форвардной декларации вложенных классов
N>>struct foo::doo;
N>>
J>Как насчет прав доступа? Вложенный класс ведь может быть объявлен приватным...
Гм.. а они не и нарушаются. Дружба она ж в обратную сторону действует.
Т.е. суть в том что бы doo из foo получил доступ к закрытым полям/методам some.
Но вот к сожалению синтаксис объявления такой дружбы в языке не предусмотрен.
Здравствуйте, rusted, Вы писали:
EP>>PCH, при сборке проектов с разными параметрами, нужны разные. При такой ситуации, когда PCH генерируется один раз при сборке всего проекта, если какой-то заголовок используется только один раз — то выигрыша не получается (для этого заголовка). R>Почему же не получается? PCH же можно собрать один раз, а при последующих компиляциях использовать готовый — вполне себе выигрыш.
Выделенное это исходные данные. При описанной ситуации — выигрыша не получается.
Если же, например, сборка всего лишь одна, один компилятором, параметры define-ы всегда одни и те же (ну или например всего два набора) — то да, тут PCH вполне решают.
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
};
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Кстати, если swap реализован как 3 assignment'а (не важно — move или copy) — то получается три swap'а это 9 assignment (N-1)*3. EP>А если делать нормальный cycle/rotate по получается 5 assignment (N+1).
Думаю, если это будет встроенным оператором, то оптимизатор справится. В простых случаях это будет сделано вообще без присваиваний, просто регистры начнут соответствовать другим переменным.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, 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 крайне редко используется в случаях, где возможно просто "переосмысление" что чему соответствует.
Здравствуйте, Кодт, Вы писали:
J>>Ну и можно сделать эту фичу дополнением и разрешать и то, и другое, так что старый код от этого ломаться не будет, а новый только выиграет. К>Вот только не надо this. Это дурацкая экономия на спичках, перегрузка смысла ключевого слова.
Согласен, this перегружать не надо. Я думаю ноги у this растут из D:
class AbraCadAbRa
{
this()
{}
~this()
{}
}
К>Чем микрософтовские стандарто-совместимые __ctor и __dtor не приглянулись?
имхо, имя должно быть одно, что то типа self_type (но более лаконичное, + нужно постараться поломать как можно меньше кода новым keyword'ом), и желательно, чтобы его можно было использовать как имя типа, например при CRTP:
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, 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 не принципиален.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Мишень-сан, Вы писали:
МС>>Лучше бы модули сделали нормальные.
EP>Daveed Vandervoorde: "Modules in C++"
Спасибо за видео, я пока только читал предложение Дэвида.
Поэтому и высказался, что лучше бы его добавили в TR.
Стрим мьютексы туда попали.
OpenMP туда попал.
А нормальная система модулей никому, похоже, не нужна. Ок, продолжаем жить при Header Hell.
Здравствуйте, Мишень-сан, Вы писали:
МС>Поэтому и высказался, что лучше бы его добавили в TR. МС>OpenMP туда попал.
Куда это OpenMP попал?
Я так понял это только proposal, и то там весь proposal это "а давай-те как-нибудь заюзаем OpenMP" без конкретики.
Надеюсь что никакое OpenMP в язык не пролезет.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Я так понял это только proposal, и то там весь proposal это "а давай-те как-нибудь заюзаем OpenMP" без конкретики. EP>Надеюсь что никакое OpenMP в язык не пролезет.
зря надеешься =)
OpenMP стандартизован и развивается. нет причин не включать его в стандарт С++.
но признаюсь, тот способ которым OpenMP реализуется, ниразу не соответствует идеологии С++. но, с другой стороны, если так мыслить, то и Cilk+ там не нужен.
в общем поглядим... но определенно, нужна какая-то поддержка многопоточности/синхронизации на уровне языка. иначе С++ получается самым сложным ЯП для разработки многопоточных программ.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>иначе С++ получается самым сложным ЯП для разработки многопоточных программ.
иначе С++ получается самым неподходящим ЯП для разработки многопоточных программ.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, 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'шные костыли?
Здравствуйте, 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>
это же можно реализовать в Cilk+ или OpenMP. достаточно лишь научить их принимать пользовательское функторы/предикаты.
EP>Да, кстати, что делать например с parallel reduce, parallel transform/map? тоже вводить openmp'шные костыли?
нет же, строка выше.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, 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>>
X>это же можно реализовать в Cilk+ или OpenMP. достаточно лишь научить их принимать пользовательское функторы/предикаты.
Openmp с функторами это же вообще жесть и цирк с конями.
но речь не о них.
Пример выше показывает, что при использовании irange — интерфейс реинфосит использование инкремента одним только синтаксисом. В то время как в OpenMP семантику возможных инкрементов нужно дополнительно описывать, причём в core langauge.
EP>>Да, кстати, что делать например с parallel reduce, parallel transform/map? тоже вводить openmp'шные костыли? X>нет же, строка выше.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, niXman, Вы писали:
X>>иначе С++ получается самым неподходящим ЯП для разработки многопоточных программ.
KP>Господа, проявите терпение, Rust почти готов
Ждём-с. Идеи в основе просто пальчики оближешь — movable owned values, non-nullable по умолчанию, type inference...
Хотя конечно с некоторыми вещами типа явного self для функций-членов класса и чрезмерной мании сокращать идентификаторы я бы поспорил.
Здравствуйте, Мишень-сан, Вы писали:
МС>Ждём-с. Идеи в основе просто пальчики оближешь — movable owned values, non-nullable по умолчанию, type inference...
радует то, что они компилятор строят на основе LLVM, а не как Go, самопальный =)
МС>Хотя конечно с некоторыми вещами типа явного self для функций-членов класса и чрезмерной мании сокращать идентификаторы я бы поспорил.
да, self в последней редакции языка меня тоже расстроил %)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
так а что, 'static if' в 2014 таки ждать не стОит?!
пишу тут кодец и думаю, будь доступен сабж — кода бы получилось в разы меньше, и он бы писался и читался в разы проще.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>так а что, 'static if' в 2014 таки ждать не стОит?! X>пишу тут кодец и думаю, будь доступен сабж — кода бы получилось в разы меньше, и он бы писался и читался в разы проще.
прочитал отговорку описанную в документе и улыбнулся =)))
аргументы не принимать '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 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
// 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 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>прочитал отговорку описанную в документе и улыбнулся =))) X>аргументы не принимать 'static if' приводятся на реально нелепых примерах %)
Обрати внимание, какие веские контраргументы господин Страуструп умеет приводить, когда дело касается его предложений
Здравствуйте, Ku-ku, Вы писали:
KK>Обрати внимание, какие веские контраргументы господин Страуструп умеет приводить, когда дело касается его предложений
да он троллит =)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, CoolCmd, Вы писали:
CC>Здравствуйте, Ops, Вы писали:
Ops>>Это как? CC>так. и для while тоже.
Тогда, имхо, было бы логично добавить две ветки — одна выполняется, если был break, другая — если не был. Опциональная третья ветка — если цикл выполнился 0 раз.
Здравствуйте, niXman, Вы писали:
X>в списке рассылки boost сообщили о том, что boost::optional<> принят в С++14.
О, отлично! А то в этом смысле даже классическая техника из старенького C с нулевыми указателями имела преимущество над C++. Ну естественно если не использовать Boost или свой подобный велосипед.
Здравствуйте, The Passenger, Вы писали:
TP>C# и жабу уже вроде изобрели
зачем? TP>зачем все эти жалкие потуги
вот и мне не понятно, см. выше %) TP>когда половина программеров 98х не знает и наполовину?
наверное потому, что есть вторая половина?
TP>И почему расширение стандартной библиотеки называют фичами языка ?
а хз.
TP>вот например — auto или новый for — это вроде как фича TP>а бинды функторы и потоки — это вроде как расширения библиотеки, какого хрена они делают в стандарте.
неотъемлемая часть стандарта?
TP>по мне так плюсы используют люди, которые хотят иметь уверенность как это работает под капотом вплоть до ассемблерных инструкций, TP>а когда пошли эти высокоуровневые навороты — то проще уж на жабу перейти и не мучаться.
"на жабу" и "не мучаться" — что-то не так %)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)