Интересная ветка на boost.devel
От: Pavel Chikulaev Россия  
Дата: 13.04.06 17:36
Оценка: 33 (6)
На boost.devel mailing list несколько дней назад появилось очень интересное обсуждение на английском о С++0х.
Report from Berlin C++ Standards Committee meeting

Кому интересно сюда:
http://thread.gmane.org/gmane.comp.lib.boost.devel/140542/focus=140542
или через NNTP
news://news.gmane.org/gmane.comp.lib.boost.devel

ЗЫ Что-то у нас тут не бывает таких дисскусий
Re: Интересная ветка на boost.devel
От: Lorenzo_LAMAS  
Дата: 14.04.06 06:52
Оценка:
PC>ЗЫ Что-то у нас тут не бывает таких дисскусий

Возможно потому, что на работе все заняты более "приземленными" вещами ?
Кстати, по поводу КонцептГЦЦ — работает ли в нем новый вид раздельной компиляции шаблонов, к котором говорилось в предложениях от этой группы? (у меня вот руки пока не дошли попробовать)
Of course, the code must be complete enough to compile and link.
Re: Интересная ветка на boost.devel
От: Константин Л. Россия  
Дата: 14.04.06 09:02
Оценка:
Здравствуйте, Pavel Chikulaev, Вы писали:

PC>На boost.devel mailing list несколько дней назад появилось очень интересное обсуждение на английском о С++0х.

PC>Report from Berlin C++ Standards Committee meeting

PC>Кому интересно сюда:

PC>http://thread.gmane.org/gmane.comp.lib.boost.devel/140542/focus=140542
PC>или через NNTP
PC>news://news.gmane.org/gmane.comp.lib.boost.devel

PC>ЗЫ Что-то у нас тут не бывает таких дисскусий


Потому, что все код пишут)
Estuve en Granada y me acorde' de ti
Re[2]: Интересная ветка на boost.devel
От: night beast СССР  
Дата: 14.04.06 10:33
Оценка:
Здравствуйте, Константин Л., Вы писали:

PC>>ЗЫ Что-то у нас тут не бывает таких дисскусий


КЛ>Потому, что все код пишут)


посмотреть бы на него
вот на буст можно посмотреть.
Re[3]: Интересная ветка на boost.devel
От: Константин Л. Россия  
Дата: 14.04.06 10:36
Оценка: +1
Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, Константин Л., Вы писали:


PC>>>ЗЫ Что-то у нас тут не бывает таких дисскусий


КЛ>>Потому, что все код пишут)


NB>посмотреть бы на него

NB>вот на буст можно посмотреть.

без комментариев
Estuve en Granada y me acorde' de ti
Re[2]: Интересная ветка на boost.devel
От: alexeiz  
Дата: 16.04.06 07:20
Оценка:
Здравствуйте, Lorenzo_LAMAS, Вы писали:

PC>>ЗЫ Что-то у нас тут не бывает таких дисскусий


L_L>Возможно потому, что на работе все заняты более "приземленными" вещами ?

L_L>Кстати, по поводу КонцептГЦЦ — работает ли в нем новый вид раздельной компиляции шаблонов, к котором говорилось в предложениях от этой группы? (у меня вот руки пока не дошли попробовать)

А по подробнее можно? Что за новый вид раздельной компиляции шаблонов? Где про это написано?
Re: Интересная ветка на boost.devel
От: kwas Россия  
Дата: 16.04.06 21:34
Оценка: 59 (9) +1
Здравствуйте, Pavel Chikulaev, Вы писали:

PC>На boost.devel mailing list несколько дней назад появилось очень интересное обсуждение на английском о С++0х.

PC>Report from Berlin C++ Standards Committee meeting

PC>ЗЫ Что-то у нас тут не бывает таких дисскусий


Ты бы помимо ссылок вкратце рассказал, о чем там речь идет, глядишь и здесь бы дискуссия завязалась
А речь идет об очень интересных вещах:







Обсудим?
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Re[2]: Интересная ветка на boost.devel
От: alexeiz  
Дата: 16.04.06 22:18
Оценка:
Здравствуйте, kwas, Вы писали:

K>

Действительно два: n1958, n1968. Ни один из proposal'ов мне не нравится. В n1968 синтакс такой:
<> ( parameter-declaration-clause )
    local-var-clauseopt exception-specificationopt compound-statement

пример:
<>(int x) {return x + 1;}

В n1958 немного другой, но похожий:
ret_type(type1 value1, type2 value2, ...) { statements }

пример:
int (int x) {return x + 1;}

Ни один из них даже и близко не приближается по краткости и понятности к lambda из C# 3.0:
x => x + 1


Основная проблема этих proposal'ов в том, что они описывают только lambda functions, а на lambda expressions им наплевать.
Re[2]: Интересная ветка на boost.devel
От: remark Россия http://www.1024cores.net/
Дата: 16.04.06 23:07
Оценка: 3 (1)
Здравствуйте, kwas, Вы писали:

K>Здравствуйте, Pavel Chikulaev, Вы писали:


PC>>На boost.devel mailing list несколько дней назад появилось очень интересное обсуждение на английском о С++0х.

PC>>Report from Berlin C++ Standards Committee meeting

PC>>ЗЫ Что-то у нас тут не бывает таких дисскусий


K>Ты бы помимо ссылок вкратце рассказал, о чем там речь идет, глядишь и здесь бы дискуссия завязалась


Да, читать там было действительно лень и времени не было

K>А речь идет об очень интересных вещах:


K>

По поводу try_lexical_cast<>:
Мой личный опыт говорит, что обычно в таких случаях удобно и достаточно два вида функции:
T lexical_cast<T>(U value); // throw (bad_lexical_cast)

и
T lexical_cast<T>(U value, T defaultValue); // throw ()


Первая — обычный lexical_cast, вторая в случае ошибки возвращает defaultValue. По моему опыту в 90% случаях в случае ошибки надо присвоить именно значение по умолчанию.
Функция возвращающая bool более гибкая, но менее удобная. Вместо:

std::string s; // = "abc"
int i = 0;
if (!try_lexical_cast(s, i))
  i = -1;


Пишем:

std::string s; // = "abc"
int i = lexical_cast<int>(s, -1);


Более сложное поведение в конце концов можно будет реализовать через тот же try/catch.

За то, что это не было сделано сразу в boost'е, огромный не респект создателям.


По поводу string_to<T>/string_from<T>.
Я лично так уже сделал
Только я это назвал number_cast — т.к. конвертит или число в строку, либо строку в число. И в ней я реализовал то, о чём написал выше — не кидающую версию со значением по умолчанию.

Так же я в ней реализовал автовывод возвращаемого типа. Т.е. пишем просто:
int i = number_cast(s); // вместо int i = lexical_cast<int>(s);
std::string s = number_cast(i); // вместо std::string s = lexical_cast<std::string>(i);


Я пока сам не понял, стрёмная это фича или нет. Пока ни разу не нарывался на неприятности. Но удобно.






K>

Было бы прикольно.
Потому что oci — это п#$ец...
Сделали бы ещё что-то типа DLinq — вообще зашибенско было бы. Т.е. что бы можно было описывать схему БД в виде метаинформации. И это бы сразу позволяло отлавливать ошибки в запросах во время компиляции. И одновременно бы являлось описанием сущностей.

Примерно так:
std::vector<Person> persons = select<All>.from<Person>.where<equal<Person::Name, "XXX">, less<Person::Age, 50> >.order_by<asc<Person::N> >;

std::vector<tuple<string, int> > name_and_age;
select<Person::Name, Person::Age>.from<Person>.into(name_and_age);


Вот она мощь с++! Любой императивный язык тут всосёт. DLinq — это всё таки расширение на уровне языка.


Только вот одна проблема. Нативные интерфейсы различных БД обычно имеют много особенностей, без которых нельзя. Как их запихнуть в один интерфейс?







K>

Тут много не скажу. Меня пока вполне устраивают статические ассёрты, прототипы, документация, юнит-тесты и т.д.
В конце концов концепт можно и сейчас в коде описать. Всё равно концепт опишет только которую часть интерфейса, а самые тонкие и интересные моменты не сможет. Но наверное с поддержкой языка будет всё-таки удобнее и приятнее.
Но имхо сейчас есть более важные вещи, чем концепты (потоки, сокеты, forwarding аргументов).







K>

Чем больше возможностей — тем сложней — выбирать же придётся! ):
Лучше бы сделали lock-free структуры. Имхо.







K>

Не скажу по поводу локальных функций. Но скажу, что с поддержкой языка будет значительно круче. Я бы даже сказал, что сейчас Lambda плохо пригодна для реального использования (за исключением прострейших случаев).

Но сам факт, что Lambda-функции смогли сделать без поддержки языка, в виде библиотеки, поразителен. Java в стороне нервно курит







K>

Сделали б хоть что-нибудь для начала
Я имею в виду, хоть какой-то networking.

Вообще я за "one-line services" везде где только можно. Мне кажется, что по возможности библиотеки должны предоставлять именно "one-line" синтаксис. Особенно для common tasks.

Вот это меня убивает:

CString s;
s.Format("%d", code);
throw Except(s);


В принципе вот это похоже на то, что меня убивает:

std::ifstream is( "http://www.example.com/file.zip" );
std::ofstream os( "file.zip" );
os << is.rdbuf();


Если сами не сделают, придётся самому сразу обёртку сделать. В конце концов нам не привыкать

А кстати, кто-нить в курсе, в asio кроме сокетов есть поддержка и http и ftp?
Вот это будет круто!


K>Обсудим?

Конечно

1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Интересная ветка на boost.devel
От: remark Россия http://www.1024cores.net/
Дата: 16.04.06 23:13
Оценка: 3 (1) +1
Здравствуйте, alexeiz, Вы писали:

A>Ни один из них даже и близко не приближается по краткости и понятности к lambda из C# 3.0:

A>
A>x => x + 1
A>



Ну это ты можешь просто взять текущую boost.lambda:

_1 + 1





1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Интересная ветка на boost.devel
От: _DAle_ Беларусь  
Дата: 16.04.06 23:36
Оценка:
Здравствуйте, remark, Вы писали:

R>По поводу try_lexical_cast<>:

R>Мой личный опыт говорит, что обычно в таких случаях удобно и достаточно два вида функции:
R>
R>T lexical_cast<T>(U value); // throw (bad_lexical_cast)
R>

R>и
R>
R>T lexical_cast<T>(U value, T defaultValue); // throw ()
R>


R>Первая — обычный lexical_cast, вторая в случае ошибки возвращает defaultValue. По моему опыту в 90% случаях в случае ошибки надо присвоить именно значение по умолчанию.

R>Функция возвращающая bool более гибкая, но менее удобная. Вместо:

R>
R>std::string s; // = "abc"
R>int i = 0;
R>if (!try_lexical_cast(s, i))
R>  i = -1;
R>


R>Пишем:


R>
R>std::string s; // = "abc"
R>int i = lexical_cast<int>(s, -1);
R>


Как-то мне все же больше нравится try_lexical_cast вариант. Во всяком случае, не видно никаких потенциальных ошибок, которые могут возникнуть, если в приведенном тобой примере строка s будет равна "-1". Тогда будет непонятно, произошла ошибка или нет. Получается, что в случаях, когда подходящего значения по-умолчанию не существует, мы не получим такой формы без исключений. Но в принципе, можно ведь и оба этих варианта добавить.

R>Более сложное поведение в конце концов можно будет реализовать через тот же try/catch.


R>За то, что это не было сделано сразу в boost'е, огромный не респект создателям.
Re[4]: Интересная ветка на boost.devel
От: alexeiz  
Дата: 17.04.06 06:30
Оценка:
Здравствуйте, remark, Вы писали:

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


A>>Ни один из них даже и близко не приближается по краткости и понятности к lambda из C# 3.0:

A>>
A>>x => x + 1
A>>

R>Ну это ты можешь просто взять текущую boost.lambda:
R>
R>_1 + 1
R>

Если lambda будет в языке, то boost.lambda уже ничего не светит. Оправдать использование boost.lambda будет очень и очень сложно.
Re[3]: Интересная ветка на boost.devel
От: Anton V. Kolotaev  
Дата: 17.04.06 07:03
Оценка:
Здравствуйте, remark, Вы писали:


K>>

R>Тут много не скажу. Меня пока вполне устраивают статические ассёрты, прототипы, документация, юнит-тесты и т.д.

R>В конце концов концепт можно и сейчас в коде описать. Всё равно концепт опишет только которую часть интерфейса, а самые тонкие и интересные моменты не сможет. Но наверное с поддержкой языка будет всё-таки удобнее и приятнее.
R>Но имхо сейчас есть более важные вещи, чем концепты (потоки, сокеты, forwarding аргументов).

Не забываем про перегрузку по концептам
... << RSDN@Home 1.2.0 alpha rev. 648>>
Re[2]: Интересная ветка на boost.devel
От: Cyberax Марс  
Дата: 17.04.06 07:45
Оценка:
kwas wrote:
> *boost::lexical_cast:* вспомнили некоторое количество проблем
> (производительность, обработка ошибок), как и то, что разработчики
> boost по этому поводу либо отмалчиваются, либо ссылаются на
> "неприкосновенность" красивого интерфейса. Для ускорения работы
> было предложено сделать специализации, использующие strtol и
> strtod. Проблема обработки ошибок состоит в том, что не всегда
> удобно оборачивать lexical_cast в try/catch, иногда хочется
> простого if (successfulCast) {}. В качестве решения было
> предложено сделать try_lexical_cast<>, возвращающий bool, a
> lexical_cast<> сделать его оберткой, кидающей исключение, если
> try_lexical_cast вернет false.
Еще было предложение сделать, чтобы lexical_cast возвращал boost::optional.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[3]: Интересная ветка на boost.devel
От: kwas Россия  
Дата: 17.04.06 07:53
Оценка:
Здравствуйте, remark, Вы писали:

R>По поводу string_to<T>/string_from<T>.

R>Я лично так уже сделал
R>Только я это назвал number_cast — т.к. конвертит или число в строку, либо строку в число. И в ней я реализовал то, о чём написал выше — не кидающую версию со значением по умолчанию.

R>Так же я в ней реализовал автовывод возвращаемого типа. Т.е. пишем просто:

R>
R>int i = number_cast(s); // вместо int i = lexical_cast<int>(s);
R>std::string s = number_cast(i); // вместо std::string s = lexical_cast<std::string>(i);
R>


R>Я пока сам не понял, стрёмная это фича или нет. Пока ни разу не нарывался на неприятности. Но удобно.


Правильным путем идете, товарищ — Proposal на эту тему.

K>>

R>Примерно так:

R>
R>std::vector<Person> persons = select<All>.from<Person>.where<equal<Person::Name, "XXX">, less<Person::Age, 50> >.order_by<asc<Person::N> >;

R>std::vector<tuple<string, int> > name_and_age;
R>select<Person::Name, Person::Age>.from<Person>.into(name_and_age);
R>


Ну, тут возникает сразу несколько "what ifs" А что, если соответствие между классом Person и структурой таблицы неоднозначное?
И как вообще будет устанавливаться соответствие между классом Person и соответствующей таблицей?

R>Только вот одна проблема. Нативные интерфейсы различных БД обычно имеют много особенностей, без которых нельзя. Как их запихнуть в один интерфейс?


Если под нативным интерфейсом понимается сишный, то запихать эти особенности можно в connection string, ИМХО.

K>>

R>Тут много не скажу. Меня пока вполне устраивают статические ассёрты, прототипы, документация, юнит-тесты и т.д.

R>В конце концов концепт можно и сейчас в коде описать. Всё равно концепт опишет только которую часть интерфейса, а самые тонкие и интересные моменты не сможет. Но наверное с поддержкой языка будет всё-таки удобнее и приятнее.
R>Но имхо сейчас есть более важные вещи, чем концепты (потоки, сокеты, forwarding аргументов).

Разработчики утверждают, что concepts помогут избавиться от кучи разных костылей (aka traits) + сделать удобочитаемыми сообщения об ошибках + ... +. В общем, лично мне часто не хватало описания концепта, именно как ограничения на параметры шаблона. Вон boost их описывает, но через одно место. А так — doxygen'ом прогнал — и сразу понятно, каким интерфейсом должен обладать параметр шаблона.

K>>
R>Чем больше возможностей — тем сложней — выбирать же придётся! ):

Да нет, речь шла о банальном оверхеде, когда лишний класс можно заменить добавлением одной функции к уже существующему.

R>Лучше бы сделали lock-free структуры. Имхо.


Может быть следующим этапом?

На самом деле, мне не нравится интерфейс этих потоков. Мне больше импонирует идиома task/executor, как она реализована, например, в zthread или в java.util.concurrent в Java 5.

K>>

R>Вообще я за "one-line services" везде где только можно. Мне кажется, что по возможности библиотеки должны предоставлять именно "one-line" синтаксис. Особенно для common tasks.


А вот я бы не был столь категоричен... One-line services хороши тогда, когда они реализуются не за счет гибкости, расширяемости и т.д. Так что лучше пусть не будет one-line, но зато в 10 строк я смогу уложить практически любую задачу, чем для common tasks будет one-line, а что-то более сложное будет укладываться строк в 100.

R>Если сами не сделают, придётся самому сразу обёртку сделать. В конце концов нам не привыкать


Именно что

R>А кстати, кто-нить в курсе, в asio кроме сокетов есть поддержка и http и ftp?


Скорее всего нет. Потому что кроме http и ftp, есть еще https, ftps, sftp, ssh, smtp, pop3, imap и еще много разных других умных слов В обшем, вы поняли

If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Re[2]: Интересная ветка на boost.devel
От: achmed Удмуртия https://www.linkedin.com/in/nail-achmedzhanov-9907188/
Дата: 17.04.06 08:18
Оценка:
Здравствуйте, kwas, Вы писали:

K>
...
K>Обсудим?

Не прошло и 3 года .. В свое время решил заюзать lexical_cast(нужно было парсить довольно большие файлы),
в итоге пришлось дописывать частичные спецификации с использованием strto*, потому как аналогичная программа
на perl работала в дестки раз быстрее.
Re[3]: Интересная ветка на boost.devel
От: Lorenzo_LAMAS  
Дата: 17.04.06 08:28
Оценка:
Здравствуйте, alexeiz, Вы писали:

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


PC>>>ЗЫ Что-то у нас тут не бывает таких дисскусий


L_L>>Возможно потому, что на работе все заняты более "приземленными" вещами ?

L_L>>Кстати, по поводу КонцептГЦЦ — работает ли в нем новый вид раздельной компиляции шаблонов, к котором говорилось в предложениях от этой группы? (у меня вот руки пока не дошли попробовать)

A>А по подробнее можно? Что за новый вид раздельной компиляции шаблонов? Где про это написано?


А вот там по ссылке посмотри, там есть два пдфа, в одном сам пропозал, а в другом — описание реализации. И есть раздел, в котором говорится о раздельной компиляции. Сдается мне, это только перспективы и они еще такого не сделали.

http://www.osl.iu.edu/~dgregor/ConceptGCC/papers/n1848.pdf
Of course, the code must be complete enough to compile and link.
Re[4]: Интересная ветка на boost.devel
От: alexeiz  
Дата: 17.04.06 09:40
Оценка:
Здравствуйте, Lorenzo_LAMAS, Вы писали:

L_L>А вот там по ссылке посмотри, там есть два пдфа, в одном сам пропозал, а в другом — описание реализации. И есть раздел, в котором говорится о раздельной компиляции. Сдается мне, это только перспективы и они еще такого не сделали.


L_L>http://www.osl.iu.edu/~dgregor/ConceptGCC/papers/n1848.pdf


Основная идея заключена, как мне кажется, в отсутствии специализаций. Однако, возможность специализации является одной из главных особенностей поддержки generic кода в C++. Отними её, и шаблоны превратятся в generic'и из C# или Java.
Re[2]: Интересная ветка на boost.devel
От: pigeon Великобритания
Дата: 11.05.06 08:46
Оценка:
Здравствуйте, kwas, Вы писали:

K>Ты бы помимо ссылок вкратце рассказал, о чем там речь идет, глядишь и здесь бы дискуссия завязалась

K>А речь идет об очень интересных вещах:
[...]
K>Обсудим?

All of TR1 except special functions has been voted into C++0x, the next
standard.


Прошу прощения за непонятливость, но что это за special functions, посмотрел состав TR1
здесь, он ниже и не понял что из нежеперечисленного
есть special functions.


... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Premature optimization is the root of all evil in programming. Donald Knuth
Re[3]: Интересная ветка на boost.devel
От: night beast СССР  
Дата: 11.05.06 09:00
Оценка: 2 (1)
Здравствуйте, pigeon, Вы писали:

P>

P> All of TR1 except special functions has been voted into C++0x, the next
P>standard.


P>Прошу прощения за непонятливость, но что это за special functions, посмотрел состав TR1

P>здесь, он ниже и не понял что из нежеперечисленного
P>есть special functions.

P>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.