Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > Чего Вам не хватает в стандарте Си++

Автор: borisbn 13.4.2011, 09:01

Здравствуйте ! Предлагаю в этой теме собирать предложения/пожелания к стандарту Си++. Отдаю себе отчёт, что это никак не повлияет на комитет ISO, но просто интересно, чего людям не хватает. Принимаются любые пожелания - изменение языка, дополнения стандартных функций, изменение работы имеющихся компиляторов... Начнём. 1. Возможность задавать параметры по-умолчанию не только в конце списка аргументов, но и в начале/середине. При этом вызов будет выглядеть следующим образом: Код // Описание void foo( int a, int b, int x = 0, int y ); // вызов foo( 3, 42, , 20 ); 2. В std::string добавить функции преобразования числа в строки и обратно. Типа такого Код class string { ... static string num( int val, int length = 0, char fill = '0', int base = 10 ); static string num( double val, int length = 0, int precision, char fill = '0' ); int toInt( bool * ok = 0 ); double toDouble( bool * ok = 0 ); }; и т.п. Объясню: почти наверняка у каждого есть скелет в шкафу свои обёртки над stringstream или sprintf... Почему бы не сделать это централизовано... 3. Позаимствовать у До-диеза unescape строки (не знаю, как это правильно называется), чтобы не нужно было вставлять в строку бэкслэши. Типа такого Код path = @"\\host\path\to\file"; или так path = @"\\host\path\to\file" "\n"; // @ действует только до закрывающей кавычки

Автор: bems 13.4.2011, 09:15

Там уже есть модульность?

Автор: TIT 13.4.2011, 09:22

Не совсем к стандарту языка, скорее к IDE предложение. Добавить возможность временного кода, который исполняется только на debug-компиляции. Например, вам для отладки нужно записывать отладочный лог в базу данных, чего не нужно будет делать в релизе. Код int main() {     int i = 42;     debug     {         fopen(file);         fwrite(file, time(now);         fclose(file);     }     return i; } В dubug-компиляции выполняет весь код выше, а в релизе компилятор должен игнорировать конструкцию debug{}.

Автор: bems 13.4.2011, 09:23

TIT, а чем условная компиляция не подходит?

Автор: borisbn 13.4.2011, 09:31

Цитата(bems @  13.4.2011,  09:15 ) Там уже есть модульность? а что это ? можно с примером, чтоб понятней было ? TIT, а чем это "вкуснее", чем Код int main() {     int i = 42;     #ifdef _DEBUG         fopen(file);         fwrite(file, time(now);         fclose(file);     #endif     return i; }

Автор: bems 13.4.2011, 09:32

Цитата(borisbn @  13.4.2011,  09:01 ) void foo( int a, int b, int x = 0, int y ); ну и что делать компилятору если он видит foo(1, 2, 3); Тройка уходит в х (и возникает ошибка "недостаточно параметров") или у? И почему? Добавлено через 1 минуту и 14 секунд Цитата(borisbn @  13.4.2011,  09:31 ) а что это ? можно с примером, чтоб понятней было ?  нечто менее убогое чем директива #include препроцессора. Например вроде юнитов Паскаля

Автор: Severyanin 13.4.2011, 09:34

Предлагаю сделать стандартными контейнеры QT и часть типов -- QString, QVariant. Как вспомню еще - дополню)

Автор: borisbn 13.4.2011, 09:36

Цитата(bems @  13.4.2011,  09:32 ) ну и что делать компилятору если он видит foo(1, 2, 3);Тройка уходит в х (и возникает ошибка "недостаточно параметров") или у? И почему? не... вызов должен быть такой Код foo(1, 2, , 3); а твой вариант должен выдавать ашипку Цитата(bems @  13.4.2011,  09:32 ) нечто менее убогое чем директива #include препроцессора. Например вроде юнитов Паскаля есть нечто подобное в ActiveX (type-library и т.п.), но в итоге всё сводится к генерации h-ников и тем же #include'ам в общем нету.

Автор: bems 13.4.2011, 09:41

Цитата(borisbn @  13.4.2011,  09:36 ) вызов должен быть такой окей. Не вижу в таком варианте много пользы, но пусть будет Цитата(borisbn @  13.4.2011,  09:36 ) есть нечто подобное в ActiveX не-не, активикс и не плюсоспецифичен Цитата(borisbn @  13.4.2011,  09:36 ) в общем нету ну вроде есть неймспейсы, если каждый хидер заворачиватьл в свой неймспейс то вроде получается нечто подобное. Но я так, только что-то слышал

Автор: borisbn 13.4.2011, 10:30

Цитата(bems @  13.4.2011,  09:41 ) окей. Не вижу в таком варианте много пользы, но пусть будет для заключительных параметров это сделано и, в общем-то, удобно Код void replaceString( string where, string before, string after, bool caseSens = false, bool replaceAll = true ); вызов: replaceString( "A quick brown fox jumps over a lazy dog", "a", "the" ); // Гыыы, получится lthezy dog. пусть это будет новая порода :) а если нужно, например, указать диапазон [min;max], и в большинстве случаев min=0... Сейчас приходится либо менять их местами (полный бред) Код void setDiap( int max, int min = 0 ); либо не использовать параметр по-умолчанию Код void setDiap( int min, int max ); а хотелось бы так Код void setDiap( int min = 0, int max ); вызов setDiap( , 100 );

Автор: xvr 13.4.2011, 11:24

Хотелось бы модульность и управляемые квалификаторы доступа, хотя бы на уровне наборов классов. Пример - есть некая сущность, которая управляется набором классов. Есть некий класс, представляющий эту сущность (он и использует для работы вышеупомянутый набор классов). Хотелось бы сделать у каждого класса из этого набора интерфейсы, доступные для других классов этого же набора, но не доступные снаружи. Этакий friend, но не на все потроха класса, а лишь на явно заданную часть методов. Это можно сделать и в текущем С++, но это будет либо громоздко, либо накладно, либо недостаточно избирательно

Автор: borisbn 13.4.2011, 12:34

xvr, не совсем понял, абстрактые интерфейсы ? Можешь привести примерчик, как бы это выглядело ?

Автор: cutwater 13.4.2011, 12:46

borisbn,  Цитата(borisbn @  13.4.2011,  08:01 ) 1. Возможность задавать параметры по-умолчанию не только в конце списка аргументов, но и в начале/середине. При этом вызов будет выглядеть следующим образом: Выглядит как-то криво чессслово. Уж тогда лучше как в python к примеру Код def foo(a, b, c=5, *args, **kwargs):     pass foo(1, 2, 7, x1=10, x2=12)

Автор: azesmcar 13.4.2011, 13:57

1. побольше возможностей для compile-time проверок. Например ключевое слово override как в C# значительно бы помогло при работе с виртуальными функциями. Также неплохо было бы иметь что-то вроде sealed. Еще неплохо было бы иметь compile-time спецификацию исключений вместо того недоразумения, что есть сейчас. 2. параллельные алгоритмы 3. эффективная реализация thread-safe контейнеров 4. thread-pool 5. нормальный и не тормозной аналог sprintf-а. 6. добавить в стандарт библиотеку работы с сетью (возможно asio) 7. сериализация и отражения пока это, потом еще дополню. ...естественно я это пишу с учетом наличия нового стандарта.

Автор: xvr 13.4.2011, 17:19

Цитата(borisbn @ 13.4.2011,  12:34) xvr, не совсем понял, абстрактые интерфейсы ? Можешь привести примерчик, как бы это выглядело ? Пример (прямо из текущего проекта). Есть некоторый модуль, который занимается чтением объектных файлов (в ELF формате), извлечением из них кода (отдельно для каждой секции кода ELF файла) и некоторой символьной информации, и складывает это все в некоторый поток (в самопальную базу данных). Корень всего модуля - класс File. Ему дают имя ELF файла, он его читает и делает набор экземпляров классов Section. Один экземпляр Section описывает 1 секцию кода. Он содержит собственно образ кода, таблицу релокаций и таблицу символов (это еще один класс - Symbols). Очевидно, что у всех этих классов есть 2 набора интерфейсов - для чтения и разбора исходного ELF файла и для доступа к результатам разбора. Второй набор интерфейсов является public интерфейсом всего модуля, а первый набор (чтение ELF файла) нужен только для начального чтения файла (он весь покрывается единственным public методом File::open() ) Проблема как раз в 1м наборе интерфейсов. Он должен быть public для всех классов, входящих в модуль (File, Section, Symbols) и private для внешнего мира. Вот этого и не хватает

Автор: bsa 13.4.2011, 17:39

Цитата(borisbn @  13.4.2011,  10:30 ) void setDiap( int max, int min = 0  В данном случае лучше делать через перегрузку: Код void setDiap(int min, int max); void setDiap(int max) {    setDiap(0, max); }

Автор: mabrarov 13.4.2011, 17:57

Цитата(azesmcar @ 13.4.2011,  13:57) 2. параллельные алгоритмы 3. эффективная реализация thread-safe контейнеров 4. thread-pool 5. нормальный и не тормозной аналог sprintf-а. 6. добавить в стандарт библиотеку работы с сетью (возможно asio) Вот этого как раз и не надо в стандарт. Это реализуется и должно реализовываться сторонними библиотеками (есть же Boost). Вообще, комитет по стандартизации C++ хоть и жутко "тормозит", но, слава богу, ведет себя "по-взрослому" - не пытаясь сваять из C++ Java - "вот вам вместо языка (и, местами, вашей ОС) целая платформа". Иначе C++, стандарты которого итак неважно поддерживаются в mobile/embedded-мире, так и останется расколотым на Modern C++ Design и то, что используют Google/Mozilla/etc. А так, в свете rvalue reference и clang, надежда еще живет

Автор: Alekseyl92 13.4.2011, 18:24

Цитата(borisbn @  13.4.2011,  09:01 ) При этом вызов будет выглядеть следующим образом: Да ну, а потом запятые считать? Лучше как в C#: Код foo(1, id=2, text="test"); Не хватает свойств (привет C#). Они делают код красивым и безопасным (данные в private, а доступ, как к паблик).

Автор: azesmcar 13.4.2011, 19:40

Цитата(mabrarov @  13.4.2011,  17:57 ) Вот этого как раз и не надо в стандарт. Это реализуется и должно реализовываться сторонними библиотеками (есть же Boost). С тем же успехом реализуются и умные указатели, и STL и очень многое другое. Следуя твоей логике отказываемся от STL и пишем свои велосипеды, так-как пользоваться сторонними библиотеками не каждый может себе позволить. Я перечислил базовые средства, необходимые для построения современных приложений. Цитата(mabrarov @  13.4.2011,  17:57 ) есть же Boost Который используется далеко не в каждом проекте.

Автор: mabrarov 13.4.2011, 20:04

Цитата(azesmcar @ 13.4.2011,  19:40) С тем же успехом реализуются и умные указатели, и STL и очень многое другое. Следуя твоей логике отказываемся от STL и пишем свои велосипеды, так-как пользоваться сторонними библиотеками не каждый может себе позволить. Я перечислил базовые средства, необходимые для построения современных приложений. Контейнеры и указатели - достаточно обобщенные классы, чтобы быть, что называется, "из коробки". А вот тот же Boost.Asio "уходит корнями" в ОС (которой может и не быть) гораздо дальше. Стандартная библиотека C++ потому и называется стандартной, что должна предоставлять только обобщенные и "мелкие" кирпичики для дальнейшей разработки - с учетом многообразия всех тех сред, где C++ применяется и планирует применяться. Попытки засунуть в нее то, что хорошо иметь как сменный объектив у фотокамеры, приведут к превращению библиотеки в "платформу".  Пример, как говорится, "у всех на виду" - J2SE, J2EE, J2ME (+ куча профилей), Android, GAE и т.п. Насколько я знаком с мнением Страуструпа по этому поводу (вопрос по поводу Embedded C++) - он выступает за единую гибкую стандартную библиотеку + произвольное множество сторонних библиотек для конкретных целей/платформ. Лично мне хватает тех же Boost-вских потоков и Boost.Asio.

Автор: azesmcar 13.4.2011, 20:36

Цитата(mabrarov @  13.4.2011,  20:04 ) Контейнеры и указатели - достаточно обобщенные классы, чтобы быть, что называется, "из коробки". А параллельные алгоритмы это что-то специфичное? Цитата(mabrarov @  13.4.2011,  20:04 ) А вот тот же Boost.Asio "уходит корнями" в ОС (которой может и не быть) гораздо дальше. Без сетевых технологий сегодня обходиться редкая программа. Язык, библиотека которой не имеет стандартной библиотеки с поддержкой примитивных средств коммуникации - сильно усложняет жизнь программиста. Тоже самое можно сказать о поддержке базы данных. По сути сегодня, что написать более менее нужную программу на C++ программисту приходиться собирать конструктор из разнообразных библиотек (и некоторых весьма сомнительных), что приводит к усложнению поддержки кода. Лично мне это не по душе. Цитата(mabrarov @  13.4.2011,  20:04 ) Стандартная библиотека C++ потому и называется стандартной, что должна предоставлять только обобщенные и "мелкие" кирпичики для дальнейшей разработки - с учетом многообразия всех тех сред, где C++ применяется и планирует применяться С каких пор слово "стандартная" приобрела такой смысл? Все перечисленное является кирпичиками, необходимыми для построения современных приложений. Половина вышеперечисленного есть в буст, другая половина в TBB. Цитата(mabrarov @  13.4.2011,  20:04 ) Лично мне хватает тех же Boost-вских потоков и Boost.Asio.  а мне - нет

Автор: borisbn 13.4.2011, 22:21

xvr, понял. некий закрытый клуб "только для членов" (в хорошем смысле этого слова)  Цитата(bsa @  13.4.2011,  17:39 ) В данном случае лучше делать через перегрузку: не пойму чем лучше... то, что можно сделать - понятно, но то, что лучше... ведь я не предлагаю отменить перегрузку, а всего лишь дать возможность делать и так, и так... Цитата(mabrarov @  13.4.2011,  20:04 ) Лично мне хватает тех же Boost-вских потоков их же вроде ввели в C++0x. нет ? Цитата(azesmcar @  13.4.2011,  20:36 ) По сути сегодня, что написать более менее нужную программу на C++ программисту приходиться собирать конструктор из разнообразных библиотек поддерживаю в том плане, что у мнооооооогих программистов есть такой каталог типа common или shared или tools или utils, где собраны если не небоскрёбы, то как минимум приличные 9-ти этажки из тех самых "кирпичиков", предоставляемых стандартом, и у многих эти здания похожи как те новостройки из "С лёгким паром". Так почему бы это не объединить в библиотеку, которую назвать стандартной ? По сути тот же boost - это и есть объединение всего того, что наваяли программисты за много лет. Ведь говоря, что "нам достаточно кирпичиков, из них можно построить всё, что хочешь" можно и от STL отказаться...

Автор: azesmcar 14.4.2011, 08:02

Цитата(borisbn @  13.4.2011,  22:21 ) Так почему бы это не объединить в библиотеку, которую назвать стандартной ? Тут дело не столько в названии, сколько в гарантии стабильности (или по крайней мере backward compatability) интерфейса этой библиотеки. Цитата(borisbn @  13.4.2011,  22:21 ) их же вроде ввели в C++0x. нет ? Ввели, и не только их. Кстати, потоки тоже уходят корнями в ОС.

Автор: mimik 14.4.2011, 10:13

http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D1%81%D0%B2%D0%B0%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5#.D0.9F.D0.B0.D1.80.D0.B0.D0.BB.D0.BB.D0.B5.D0.BB.D1.8C.D0.BD.D0.BE.D0.B5_.D0.BF.D1.80.D0.B8.D1.81.D0.B2.D0.B0.D0.B8.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5 Код a, b = 1, 11

Автор: ИванМ 14.4.2011, 10:18

На счет параметров по умолчанию в середине функции идея хорошая. Хотелось бы улучшить делегирование. Например, в стиле Builder'а который я не люблю, но вещь там есть хорошаю, которая называется __closure. Либо реализовать стандартный механизм сигналов/слотов. Либо что-то сделать в стиле delegate из c#. Добавить lexical_cast или как предлагал borisbn функции преобразования внутри класса string. Возможность определять функции внутри любого блока кода.

Автор: mimik 14.4.2011, 10:21

ИванМ, http://ru.wikipedia.org/wiki/C%2B%2B0x#.D0.9B.D1.8F.D0.BC.D0.B1.D0.B4.D0.B0-.D1.84.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D0.B8_.D0.B8_.D0.B2.D1.8B.D1.80.D0.B0.D0.B6.D0.B5.D0.BD.D0.B8.D1.8F это?

Автор: ИванМ 14.4.2011, 10:53

mimik, лямбда-фунции можно определить один раз внутри блока кода и потом использовать несколько раз? Если можно, то, в принципе, то, только как-то сложно. Обычный синтаксис не помешал бы.

Автор: azesmcar 14.4.2011, 10:56

Цитата(ИванМ @  14.4.2011,  10:53 ) mimik, лямбда-фунции можно определить один раз внутри блока кода и потом использовать несколько раз? Если можно, то, в принципе, то, только как-то сложно. Обычный синтаксис не помешал бы.  конечно можно. Код #include <iostream> #include <functional> int main() {    std::function<void()> f = [](){ std::cout << "Yes!" << std::endl; };    f();    f();    f(); } Добавлено через 54 секунды попроще Код auto f = [](){ std::cout << "Yes!" << std::endl; };

Автор: ИванМ 14.4.2011, 11:00

azesmcar, тогда один пункт пожеланий убираю.

Автор: alexvs11 14.4.2011, 11:22

#pragma once сделать стандартом Добавлено через 14 минут и 20 секунд да, кстати ключевое слово interface по аналогии с жабой и COM

Автор: mabrarov 14.4.2011, 12:11

Цитата(azesmcar @ 13.4.2011,  20:36) Все перечисленное является кирпичиками, необходимыми для построения современных приложений. Половина вышеперечисленного есть в буст, другая половина в TBB. Вы сами же и ответили на вопрос, почему это не надо вносить в стандартную библиотеку C++ - потому что это уже хорошо реализовано сторонними библиотеками. Все просто. Это обычный баланс (и уже поэтому, здесь можно дискутировать бесконечно): или "у нас все с собой (но, возможно, ваше сюда не встраивается и, вообще, мы из-за наших инструментов такое сделать не сможем)"; или "у нас только минимум инструментов (дайте-ка нам еще пару лет только на подготовку подходящего набора-инструментария)". Я не против того, что уже внесено в C++0x, например, потоки (особенно в части требований к компиляторам). Но, как в известной сказке, если в дом полезут все (потащат все, что кому-то может и действительно нужно, но не обязтельно нужно всем и всегда), то дом треснет и развалится (на анклавы-платформы). Цитата(borisbn @ 13.4.2011,  22:21) поддерживаю в том плане, что у мнооооооогих программистов есть такой каталог типа common или shared или tools или utils, где собраны если не небоскрёбы, то как минимум приличные 9-ти этажки из тех самых "кирпичиков", предоставляемых стандартом, и у многих эти здания похожи как те новостройки из "С лёгким паром". Так почему бы это не объединить в библиотеку, которую назвать стандартной ? По сути тот же boost - это и есть объединение всего того, что наваяли программисты за много лет. Ведь говоря, что "нам достаточно кирпичиков, из них можно построить всё, что хочешь" можно и от STL отказаться... Неужели кто-то всерьез полагает, что серьезное поизводство ПО на базе C++ возможно без какого-то дополнительного набора библиотек (или даже framework-ов), пусть даже и довольно стабильно переходящего из проекта в проект? Для меня это, как минимум, Boost C++ Libraries. Наверное, тема "На каких платформах (аппаратные платформы, ОС) Вы бы хотели видеть (Вам нужны) полноценные/современные компиляторы C++, полностью (без багов!) и эффективно поддерживающие хотя бы стандарт C++ 2003 года?" была бы менее противоречивой (для меня). Это так, отступление от темы нашего вопроса, отчасти связанное с ним.

Автор: azesmcar 14.4.2011, 12:22

Цитата(mabrarov @  14.4.2011,  12:11 ) Вы сами же и ответили на вопрос, почему это не надо вносить в стандартную библиотеку C++ - потому что это уже хорошо реализовано сторонними библиотеками.   где это? не надо вносить, потому-что это можно сделать построив лего из всевозможных библиотек, половина из которых имеет работают довольно сомнительно? Цитата(mabrarov @  14.4.2011,  12:11 ) Неужели кто-то всерьез полагает, что серьезное поизводство ПО на базе C++ возможно без какого-то дополнительного набора библиотек (или даже framework-ов), пусть даже и довольно стабильно переходящего из проекта в проект?   если этот фреймворк будет частью стандарта - то да, естественно можно. На .NET люди же как-то пишут. Цитата(mabrarov @  14.4.2011,  12:11 ) если в дом полезут все (потащат все, что кому-то может и действительно нужно, но не обязтельно нужно всем и всегда), то дом треснет и развалится (на анклавы-платформы). это далеко не все, я к примеру не предлагал включать в стандарт библиотеку для работы с протоколом x.501, а вот минимальные средства для разработки этого протокола все таки должны быть включены. Я не вижу чем сокеты хуже потоков, мьютексов или тех же файлов. Например в одной довольно серьезной компании, в которой я работал, использование какой либо внешней библиотеки было вообще запрещено. В моей теперешней компании на многих проектах буст также запрещен. В последний раз смена версии буста остановила мою работу на сутки (и не только мою), а смена версии Qt уже продолжается на протяжении месяцев. Удовольствия от всего этого как Вы понимаете мало. Мне гораздо приятнее знать, что кто-то долго сидел, думал и заботился о работе 2-х гигабайтов кода, написанного 7 лет назад и при смене версии библиотеки/компилятора нам не придется сидеть и искать где и в какой функции добавили новый аргумент.

Автор: mabrarov 14.4.2011, 12:36

Цитата(azesmcar @ 14.4.2011,  12:22) На .NET люди же как-то пишут. .NET Framework. Ну да, именно как-то. Т.е. вполне нормально, пока дело не доходит до распространения или, упаси боже, переноса на др. платформу. Впрочем, тут проблемы есть у всех. Просто кто-то может (имеет время, силы и "скиллы") потратить на их решение больше (тех же ресурсов), а кто-то меньше. Вот только не надо того "сахара" и обилия "из коробки", что есть в .NET. Кому нужно, как в .NET, те на нем и пишут (не в упрек Вам, data-race.com я видел - хороший ресурс). Как я и писал - баланс противоречив и дискутировать дальше не вижу смысла

Автор: azesmcar 14.4.2011, 12:54

Цитата(mabrarov @  14.4.2011,  12:36 ) Кому нужно, как в .NET, те на нем и пишут Так в том то и дело, что очень многие так и поступают и именно из за наличия сахара из коробки. Если мне надо написать программу под windows (без планов переноса под *nix) то я долго думать надо выбором платформы и языка не стану, хотя C++ как язык мне нравиться. Цитата(mabrarov @  14.4.2011,  12:36 ) Как я и писал - баланс противоречив и дискутировать дальше не вижу смысла     Ну, ничего от нашей дискуссии все равно не измениться, стандарт то уже приняли

Автор: mabrarov 14.4.2011, 13:01

Цитата(azesmcar @ 14.4.2011,  12:22) Например в одной довольно серьезной компании, в которой я работал, использование какой либо внешней библиотеки было вообще запрещено. В моей теперешней компании на многих проектах буст также запрещен.  Бывает. Все, наверное, читали "JSF C++ Coding standards" - там и STL (фактически) под запретом. Требования разные бывают, а подобрать правильный инструмент иногда становится настоящим искусством (которым, к сожалению, могут заниматься некомпетентые личности). Цитата(azesmcar @ 14.4.2011,  12:22) В последний раз смена версии буста остановила мою работу на сутки (и не только мою) Serialization? (по этому поводу и без меня ответов хватает) Все пользователи Boost (если читали то место в документации Boost) знают, что Boost не дает никаких гарантий касаемо ABI и даже совместимости на уровне исходных кодов (за исключением разве что устоявшихся библиотек) - это в общем случае, если обратное не указано явно. Цитата(azesmcar @ 14.4.2011,  12:22) а смена версии Qt уже продолжается на протяжении месяцев. Удовольствия от всего этого как Вы понимаете мало.  Ну Qt-то как раз даже в плане ABI много чего гарантирует при определенных условиях - надо это учитывать при разработке. Хотите 100%-ной ABI совместимости - пишите C-like внешние интерфейсы или используйте COM (лучше, пожалуй, XPCOM). Зачем "плакаться", если "всех предупреждали". Когда, порой, слышишь "мне в C++ не хватает того-то и того-то как там-то и там-то", то предложение использовать это самое "там-то и там-то" (Java, C#, Python) оказывается очень даже уместным и вполне принимается вопрошающим. Потому что не зря существуют другие языки программирования и иногда стоит объективно оценивать нежелание их использовать, замечая в нем обычную, человеческую инертность. Добавлено через 10 минут и 51 секунду Цитата(azesmcar @ 14.4.2011,  12:54) Так в том то и дело, что очень многие так и поступают и именно из за наличия сахара из коробки. Если мне надо написать программу под windows (без планов переноса под *nix) то я долго думать надо выбором платформы и языка не стану, хотя C++ как язык мне нравиться. Обогнали    Я, кстати, свои деньги за Java получаю уже года 2, "хотя C++ как язык мне нравиться" - ну ооочень.

Автор: azesmcar 14.4.2011, 13:16

Цитата(mabrarov @  14.4.2011,  13:01 ) Хотите 100%-ной ABI совместимости - пишите C-like внешние интерфейсы или используйте COM (лучше, пожалуй, XPCOM).  Ну и на кой фиг так извращаться? Цитата(mabrarov @  14.4.2011,  13:01 ) Зачем "плакаться", если "всех предупреждали". А кто плачется? что есть - то есть, я как раз говорю о том, что "всех предупреждали". Со стандартной библиотекой/фреймворком многих проблем удастся избежать. Цитата(mabrarov @  14.4.2011,  13:01 ) Когда, порой, слышишь "мне в C++ не хватает того-то и того-то как там-то и там-то", то предложение использовать это самое "там-то и там-то" (Java, C#, Python) оказывается очень даже уместным и вполне принимается вопрошающим. Потому что не зря существуют другие языки программирования и иногда стоит объективно оценивать нежелание их использовать, замечая в нем обычную, человеческую инертность. т.е. по Вашему нам надо ничего не хотеть, ни к чему не стремиться и сидеть довольствоваться тем, что у нас есть?

Автор: Леопольд 19.4.2011, 13:30

Цитата(azesmcar @  14.4.2011,  12:54 ) Ну, ничего от нашей дискуссии все равно не измениться, стандарт то уже приняли Правда? Поделись, пожалуйста, ссылочкой на новость! Нашёл что примут примерно в следующем году, но текущий драфт последний. Значительных изменений не будет. Ура, товарищи!

Автор: borisbn 19.4.2011, 13:48

Цитата(Леопольд @  19.4.2011,  13:30 ) Ну, ничего от нашей дискуссии все равно не измениться, стандарт то уже приняли Правда? Поделись, пожалуйста, ссылочкой на новость! http://forum.try-catch.ru/index.php?topic=426.0

Автор: bsa 19.4.2011, 22:55

Цитата(ИванМ @  14.4.2011,  10:18 ) Хотелось бы улучшить делегирование. Например, в стиле Builder'а который я не люблю, но вещь там есть хорошаю, которая называется __closure. Либо реализовать стандартный механизм сигналов/слотов. Либо что-то сделать в стиле delegate из c#. Тоже считаю, что возможность создания указателя на метод класса с привязкой к конкретному объекту была бы очень полезна. Есть подозрение, что std::function (копия boost::function, если не ошибаюсь) имеет значительный оверхэд (new/delete) против простого указателя (пусть даже двойного размера). Тем более, что в этом случае решалась бы проблема с виртуальными функциями и прочей фигней - на машинном уровне это выглядело бы как два указателя, один на объект, а второй на функцию (причем, так как на момент создания указателя объект известен, можно сразу подставить нужный вариант виртуального метода). В принципе, сокеты можно включить в стандарт на тех же правах, что и потоки. Ведь бывают системы, где нет потоков, бывают, где нет сети... Но тупо включать asio я не считаю разумным. Для начала следует сделать серьезный его рефакторинг. В частности, переименовать io_service в task_manager (ну или что-то в этом духе).

Автор: mes 20.4.2011, 21:07

Цитата(bsa @  19.4.2011,  21:55 )  Есть подозрение, что std::function (копия boost::function, если не ошибаюсь) имеет значительный оверхэд (new/delete) против простого указателя (пусть даже двойного размера).  имеет в случае хранения функционального объекта.. а без оверхеда тут никак, ибо размер объекта не известен.. А при хранении функций и методов никакого оверхеда нет.. Добавлено через 2 минуты и 20 секунд Цитата(bsa @  19.4.2011,  21:55 ) . Тем более, что в этом случае решалась бы проблема с виртуальными функциями о какой именно проблеме идет речь ? чем она в случае s std::function не решена ? Добавлено через 8 минут и 54 секунды Цитата(bsa @  19.4.2011,  21:55 ) возможность создания указателя на метод класса с привязкой к конкретному объекту была бы очень полезна а стоит ли эта лишняя сущность, того чтоб отказываться от более мощного и удобного инструмента bind ?

Автор: bsa 20.4.2011, 21:18

Цитата(mes @  20.4.2011,  21:07 )  А при хранении функций и методов никакого оверхеда нет.. Точно нет? Даже при связывании метода с объектом? Просто синтаксис связывания метода с объектом не особо удобен... Имхо, значительно красивее было бы что-то вроде: Код auto func = &object->method;

Автор: mes 20.4.2011, 21:23

Цитата(bsa @  20.4.2011,  20:18 )  Даже при связывании метода с объектом?  результат bind`a - функциональный объект .. его естественно приходится хранить в куче..

Автор: boostcoder 20.4.2011, 21:40

Цитата(bsa @  19.4.2011,  22:55 ) переименовать io_service в task_manager    какой же он task_manager ? откуда такие выводы? Цитата(bsa @  20.4.2011,  21:18 ) Просто синтаксис связывания метода с объектом не особо удобен например?

Автор: alexvs11 20.4.2011, 21:43

Цитата(boostcoder @  20.4.2011,  21:40 ) например? ну до ++0x вообще монструозно .* и ->* кого угодно введут в ступор

Автор: boostcoder 20.4.2011, 21:46

Цитата(alexvs11 @  20.4.2011,  21:43 )  .* и ->* кого угодно введут в ступор все логично. есть адрес объекта, и есть адрес метода. чтоб произвести вызов метода, нужно знать И адрес объекта. не понимаю, что тут не логично.. Добавлено @ 21:46 Цитата(alexvs11 @  20.4.2011,  21:43 ) до ++0x а в с++0х разве что-то изменилось?

Автор: alexvs11 20.4.2011, 21:52

раньше был mem_fun, но как и все из stl монструозно, теперь уже упомянутый std::function Код #include <functional> #include <iostream> struct X {       int foo(int a) {return a;} }; int main() {    std::function<int (X*, int)> f;    f = &X::foo;      // pointer to member    X x;    std::cout << f(&x, 5); // call X::foo() for x with 5 }

Автор: mes 20.4.2011, 21:54

Цитата(bsa @  20.4.2011,  20:18 ) Просто синтаксис связывания метода Цитата(boostcoder @  20.4.2011,  20:40 ) например? насколько я понял, речь об этом : Код std::function<..> f = std::bind(A::mtd, that);

Автор: alexvs11 20.4.2011, 21:56

bind тоже в стандарте вижу

Автор: mes 20.4.2011, 22:01

Цитата(alexvs11 @  20.4.2011,  20:56 ) bind тоже в стандарте вижу  речь не о наличии binda, a о неудобстве синтаксиса связывания, особенно при наличии нескольких аргументов. .

Автор: bsa 20.4.2011, 22:09

Цитата(boostcoder @  20.4.2011,  21:40 ) какой же он task_manager ? откуда такие выводы? Не нравится task_manager придумай что-то другое. Но по мне, класс, отвечающий за управление и выполнение задач, следует называть ну никак не io_service. Так как обслуживание операций ввода/вывода это одна из выполняемых операций. Причем, у него НЕТ НИ ОДНОГО метода, для работы с вводом/выводом. Имхо, ему больше подходит название именно task_manager, ну или job_manager, но никак не io_service. Добавлено через 3 минуты и 3 секунды Цитата(mes @ 20.4.2011,  21:23) Цитата(bsa @  20.4.2011,  20:18 )  Даже при связывании метода с объектом?  результат bind`a - функциональный объект .. его естественно приходится хранить в куче.. Ну вот. Зачем вместо хранения просто двух указателей необходимо выделять и освобождать память? Имхо, указатель на метод связанный с объектом, намного полезней простого указателя на метод.

Автор: boostcoder 20.4.2011, 22:25

Цитата(alexvs11 @  20.4.2011,  21:52 )    std::function<int (X*, int)> f;    f = &X::foo;      // pointer to member    X x;    std::cout << f(&x, 5); // call X::foo() for x with 5 хотите сказать, что это понятней/логичней? Цитата(mes @  20.4.2011,  21:54 ) насколько я понял, речь об этом : std::function<..> f = std::bind(A::mtd, that); ну дык... вообще простоты захотелось? - тогда с++ однозначно вам не подходит   Цитата(bsa @  20.4.2011,  22:09 ) по мне, класс, отвечающий за управление и выполнение задач каких задач?   Цитата(bsa @  20.4.2011,  22:09 ) у него НЕТ НИ ОДНОГО метода, для работы с вводом/выводом потому он и сервис_для_ввода-вывода! Цитата(bsa @  20.4.2011,  22:09 ) Имхо, ему больше подходит название именно task_manager, ну или job_manager, но никак не io_service. простите, но Вы плохо понимаете архитектуру и устройство asio. потому как то, для чего используется io_service - никак не задачи. а если учесть тот факт, что в asio все является сервисами(сокеты, файловый ввод-вывод, COM-порты, и т.д..), то непонятно, почему io_service не должен называться сервисом?  Добавлено через 50 секунд Цитата(bsa @  20.4.2011,  22:09 ) Зачем вместо хранения просто двух указателей необходимо выделять и освобождать память? это же очевидно - чтоб не плодить сущности ;)

Автор: mes 20.4.2011, 22:45

Цитата(bsa @  20.4.2011,  21:09 ) Имхо, указатель на метод связанный с объектом, намного полезней простого указателя на метод.  т.е. Вы предлагаете std:function выделить место под случай, когда заполняться он будет связкой указатель+метод, и добавить наряду с bind еще один связыватель, допустим, closure..  так ?

Автор: bsa 20.4.2011, 23:08

mes, нет. я предлагаю сделать отдельный тип "указатель на метод объекта". А не пытаться его связать с std::function и пр. Т.е. это требует изменение самого языка. Цитата(boostcoder @  20.4.2011,  22:25 ) простите, но Вы плохо понимаете архитектуру и устройство asio. потому как то, для чего используется io_service - никак не задачи. Давай рассмотрим интерфейс этого класса: Цитата dispatch Request the io_service to invoke the given handler. io_service Constructor. poll Run the io_service object's event processing loop to execute ready handlers. poll_one Run the io_service object's event processing loop to execute one ready handler. post Request the io_service to invoke the given handler and return immediately. reset Reset the io_service in preparation for a subsequent run() invocation. run Run the io_service object's event processing loop. run_one Run the io_service object's event processing loop to execute at most one handler. stop Stop the io_service object's event processing loop. wrap Create a new handler that automatically dispatches the wrapped handler on the io_service. ~io_service Desctructor Если не обращать внимание на приставку "io_" в названии класса, то пропадает всякая связь с вводом/выводом. Понятно, что изначально этот класс  задумывался именно для обслуживания ввода/вывода. Но сейчас круг его применения значительно расширился. У него есть штатные операции постановки любых задач в очередь на выполнение. У него есть возможность параллельного выполнения задач в нескольких потоках. А теперь представим, что мне ввод/вывод не нужен, а нужен подобных диспетчер задач? Если бы я не знал, что он находится в asio, я бы ни за что не догадался.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)