Герб Саттер написал пост по итогам июньской встречи комитета и рассказал немного по поводу будущих улучшений инициализации в C++0x.
Лично мне всегда не хватало простой инициализации векторов. Чтобы по-быстрому забить вектор тестовыми значениями и проверить что-нибудь. Сейчас заполнение вектора выглядит так:
// Initialize by hand today
vector<string> v;
v.push_back( "xyzzy" );
v.push_back( "plugh" );
v.push_back( "abracadabra" );
map'а вот так:
// Initialize by hand today
map<string,string> phonebook;
phonebook[ "Bjarne Stroustrup (cell)" ] = "+1 (212) 555-1212";
phonebook[ "Tom Petty (home)" ] = "+1 (858) 555-9734";
phonebook[ "Amy Winehouse (agent)" ] = "+44 20 74851424";
А в C++0x можно будет делать так
// Can use initializer list in C++0x
vector<string> v = { "xyzzy", "plugh", "abracadabra" };
map<string,string> phonebook =
{ { "Bjarne Stroustrup (cell)", "+1 (212) 555-1212" },
{ "Tom Petty (home)", "+1 (858) 555-9734" },
{ "Amy Winehouse (agent)", "+44 99 74855424" } };
Полный драфт C++0x обещают в сентябре. После его выхода в C++0x будут вноситься уточнения, будут делаться багфиксы, ничего нового уже не добавится.
Atom feed
25 коммент.:
хм, вроде ничего не поменялось с последнего драфта...
Рекомендую посмотреть на boost.assign. http://www.boost.org/doc/libs/1_35_0/libs/assign/doc/index.html#intro дает наглядное представление. Кажется, это то, что тебе хотелось.
Но ведь кроме отражения новых фич в стандарте (по сути просто документе, своде правил, описывающим каким язык _должен_ быть), надо дождаться и реализации этого в компиляторах - так что ждать ИМХО осталось заметно больше, чем до осени.
>надо дождаться и реализации этого в >компиляторах - так что ждать ИМХО >осталось заметно больше, чем до осени.
ИМХО нет, в gcc уже частично реализовано C++0x, а платформы где не работает gcc, по-моему не существует.
> в gcc уже частично реализовано C++0x
В gcc реализовано самое элементарное, а самого вкусного, типа анонимных функций, и в помине нет.
>> ИМХО нет, в gcc уже частично реализовано C++0x, а платформы где не работает gcc, по-моему не существует
извините, но сами используйте это говно :(
2Алёна:относительно инициализации векторов (да и вообще контейнеров), ее действительно очень не хватает. Страуструп как то рассказывал про sequence constructor в своем интервью
How could we eliminate the repeated call of push_back()? We could allow a vector to take an initializer list as its argument. That would require the definition of a constructor taking such an initializer list. For example:
template<Value_type T> class vector {
// ...
vector(const T*, const T*); // sequence constructor
// ...
};
vector<double> v = { 1.2, 2.3, 3.4 };
2Анонимный:
извините, но сами используйте это говно :(
напрасно вы так батенька. Сами то им пользовались? хоть раз? для разработки реальных проектов, а не написания тестовых примеров.
конкретно вектора и сейчас можно удобно инициализировать:
int vtmp[] = { 1, 2, 3, 4 };
std::vector<int> v(vtmp, vtmp+sizeof(vtmp)/sizeof(vtmp[0]));
а также упомянутый выше boost::assign.
хотя было бы интересней иметь такую функциональность без дополнительных библиотек.
> самого вкусного, типа анонимных функций, и в помине нет.
Приехали. А нафига в плюсах нужны анонимные функции???
2Андрей Светлов:
Рекомендую посмотреть на boost.assign. http://www.boost.org/doc/libs/1_35_0/libs/assign/doc/index.html#intro дает наглядное представление. Кажется, это то, что тебе хотелось.
Это, всё, конечно, хорошо. Но получается, чтобы прогнать жалкий тестик, придется подключать boost. Мне будет лень :-)
2LG.BALUKATION:
надо дождаться и реализации этого в компиляторах - так что ждать ИМХО осталось заметно больше, чем до осени.
Уже потихоньку все реализовывается. Не только в gcc, я думаю...
Анонимный:
В gcc реализовано самое элементарное, а самого вкусного, типа анонимных функций, и в помине нет.
Вот здесь написано, что "Lambda expressions and closures" under development.
2Yuriy Volkov:
2Анонимный:
извините, но сами используйте это говно :(
напрасно вы так батенька. Сами то им пользовались? хоть раз? для разработки реальных проектов, а не написания тестовых примеров.
Предлагаю не развивать эту увлекательную дискуссию :-)
2Denis Dzyubenko:
конкретно вектора и сейчас можно удобно инициализировать:
int vtmp[] = { 1, 2, 3, 4 };
std::vector<int> v(vtmp, vtmp+sizeof(vtmp)/sizeof(vtmp[0]));
Угу, Саттер у себя тоже приводит аналогичный пример. Но все же это неудобно, имхо. Будет лучше :-).
2Анонимный:
> самого вкусного, типа анонимных функций, и в помине нет.
Приехали. А нафига в плюсах нужны анонимные функции???
I think this will make STL algorithms an order of magnitude more usable, and it will be a great boon to concurrent code.
Это отсюда, есть примеры.
Эх, не тем они занимаются...
syntactic sugar
а мне вот интересно,
проблемы со скоростью компиляции,
в C++0x наконец решат?
т.е. откажутся от этих include,
и разбора одного и того же текста сотни раз,
или просто добавят требования на поддержку precompiled headers?
оно конечно дело удобное. но для тестов и строчку несколько раз скопипастить не проблема. а в рабочем коде такое наполнение контейнеров дело весьма редкое и подозрительное.
2Анонимный:
а мне вот интересно,
проблемы со скоростью компиляции,
в C++0x наконец решат?
Насколько я понимаю, это скорее к разработчикам компиляторов вопрос, нежели к разработчика стандарта языка.
2Алена: ну подключать буст это не такое уж и тяжелое дело. Я как раз для тестов/прототипов активно использую буст, который правда потом народ выкидывает (зачем-то) и вставляя свой код делает уже production code ;-)
P.S. ну bcp никто не отменял...
Это, всё, конечно, хорошо. Но получается, чтобы прогнать жалкий тестик, придется подключать boost. Мне будет лень :-)
Алена, а почему лень? Лень разбираться и читать документацию? Но ее нужно будет прочитать и когда в компиляторе появиться поддержка таких конструкций, чтобы понять как этим пользоваться.
Лень создавать маленький плюсатый кусок кода? Опять же его нужно будет создавать. Правильный ответ - у меня нет буста. Я прав? Или есть какая-то объективная причина не подключать буст.
2darkangel:
Алена, а почему лень? Лень разбираться и читать документацию?
Допустим, мне нужно прогнать небольшой тест на векторе. Вектор нужно предзаполнить. Я могу
1. Скачать буст, слинковать проект с ним, разобраться как работает нужная мне фича, настроить сборку так, чтобы в релизе никакого буста не было, ибо больше он нигде не используется.
2. Забить нужные мне значения через push_back'и.
Я выбираю второй вариант. :-)
Если тестов будет много и мне это надоест... Ну что же, выберу первый. Тут дело не в том, что это очень сложно, не в сложности вообще дело. Существует большое количество мелких неудобств. Не ставить же на каждое такое неудобство библиотеку, которая это неудобство решает. Чем их будет меньше, тем лучше.
Но ее нужно будет прочитать и когда в компиляторе появиться поддержка таких конструкций, чтобы понять как этим пользоваться.
Да в принципе по посту Саттера понятно как этим можно будет пользоваться. Тут всё интуитивно понятно.
Правильный ответ - у меня нет буста. Я прав? Или есть какая-то объективная причина не подключать буст.
Сейчас у меня на рабочей машине буста нет, ага.
У меня скорее нет объективных причин подключать буст. :-)
Допустим, мне нужно прогнать небольшой тест на векторе. Вектор нужно предзаполнить. Я могу
1. ----
2. ----
Выбор понятен. Просто когда мне нужно забить энное количество таких констант я все же выбираю буст по причине того что он хоть не замусоривает взгляд push_back-ами. А когда дело касается мапов так вообще супер.
В вашем ответе проскочила очень интересная вещь
чтобы в релизе никакого буста не было, ибо больше он нигде не используется.
Эта фраза, в различных ее изложения с сохранением смысла, обостряет мое внимание. И потому вопрос: А что плохого в том, чтобы воспользоваться библиотекой, которая была необходима для реализации какой-то маленькой и нужной функциональности, но больше она нигде не используется? Почему нужно выкидывать ее из релиза?
2darkangel:
А что плохого в том, чтобы воспользоваться библиотекой, которая была необходима для реализации какой-то маленькой и нужной функциональности, но больше она нигде не используется? Почему нужно выкидывать ее из релиза?
Вообще ее не только из релиза придется выкидывать. А как-то хитро отключать. Чтобы этот код не попал в репозиторий, чтобы остальным разрабочикам, которым эта маленькая библиотека совершенно не нужна, не пришлось ее ставить.
Если в компании настроена процедура автосборки, всё становится еще веселее.
Ну и на размере результирующего экзешника это отразится. Но тут уже надо внимательно смотреть, возможно, это копейки.
Вообще ее не только из релиза придется выкидывать. А как-то хитро отключать. Чтобы этот код не попал в репозиторий, чтобы остальным разрабочикам, которым эта маленькая библиотека совершенно не нужна, не пришлось ее ставить.
Ага. Значит проблема таки не в том чтоб заюзать нужную библиотеку, а в том чтоб не доставить гемороя своим коллегам. Правильно? Если бы подключение нужной либы было таковым, что не влияло бы на других участников проекта, то вы бы ею воспользовались. Верно?
Если в компании настроена процедура автосборки, всё становится еще веселее.
Вообщето автосборка для того и предназначенна чтобы все трудности сборки были минимизированны. Во всяком случае у нас она избавляет программиста от проблем, а не добавляет их, позволяя ему воспользоваться нужной ему библиотекой и не создав трудностей другим участникам.
Ну и на размере результирующего экзешника это отразится. Но тут уже надо внимательно смотреть, возможно, это копейки.
Ну сейчас это не сильно актуально... Хотя я, например, ACE выкинул не только по причине ее архаичности, а еще и потому что это монолит немаленького размера. Был бы хорошо модуляризировам можно было бы и воспользоваться нужной частью.
2darkangel:
Ага. Значит проблема таки не в том чтоб заюзать нужную библиотеку, а в том чтоб не доставить гемороя своим коллегам. Правильно? Если бы подключение нужной либы было таковым, что не влияло бы на других участников проекта, то вы бы ею воспользовались. Верно?
Нет, проблема в том, что из-за заюзания библиотеки у меня появляется много новых мелких проблем, которые я не хочу решать. Проблемы у меня, проблемы у коллег, возможные проблемы с автосборкой, еще чего-нибудь может всплыть по дороге. Оно того не стоит просто. Коллеги, кстати, скорее всего ничего ставить не будут, а пошлют меня и будут правы :-)
Вообщето автосборка для того и предназначенна чтобы все трудности сборки были минимизированны
Хм, для меня автосборка - это прежде всего возможность удостовериться, что никто билд своим коммитом не сломал.
Во всяком случае у нас она избавляет программиста от проблем, а не добавляет их, позволяя ему воспользоваться нужной ему библиотекой и не создав трудностей другим участникам.
Добавление новой библиотеки в процедуру автосборки - это все же какой-никакой процесс, который займет некоторое время.
2Алена: большая часть небольших библиотек из буста является headers-only, так что их можно добавить прямо в исходники с помощью утилиты bcp, и просто добавить лишьний флаг препроцессора, так что никакой донастройки системы автосборки не понадобится
Нет, проблема в том, что из-за заюзания библиотеки у меня
появляется много новых мелких проблем, которые я не хочу решать.
Проблемы у меня, проблемы у коллег, возможные проблемы с автосборкой, еще чего-нибудь может всплыть по дороге.
А можна их озвучить? Какие конкретно проблемы возможны при нормально организованной билдовой системе?
Коллеги, кстати, скорее всего ничего ставить не будут, а пошлют меня и будут правы :-)
При нормальной организации работы коллеги ставить ничего и не должны. "Оно" все должно делать прозрачно. К тому же чья-то лень и нежелание не может руководить моими решениями.
P.S.
Объясняю причину моих домоганий :). На моей практике подключиение сторонней разработки в проект всегда наталкивалось на очень сильное сопротивление со стороны менеджмента, а потом и разработчиков у которых вечно что-то падало и именно в той библиотеке. Вот мне и интересно выяснить круг тех проблем, которые мешают плюсатым разработчикам делать то, что на других языках само собой разумеющееся.
2darkangel:
А можна их озвучить? Какие конкретно проблемы возможны при нормально организованной билдовой системе?
Ну не то, чтобы проблемы... Допустим, речь идет о библиотеке, которая хедеры и либы, а не только хедеры, как Alex Ott написал.
Надо эту библиотеку залить в систему автосборки. Придется на это отвлекаться.
При нормальной организации работы коллеги ставить ничего и не должны. "Оно" все должно делать прозрачно.
Хм, ну это только если необходимую либу в репозиторий заливать. А так для локальной сборки либа понадобится, ее надо будет качать-ставить всем.
К тому же чья-то лень и нежелание не может руководить моими решениями.
Да не, ну при чем здесь лень... Если каждый будет в проекте творить, что вздумается, даже если из самых лучших побуждений, то проект не пойми во что превратится.
Отправить комментарий