Google code style
От: Аноним  
Дата: 01.04.12 19:23
Оценка:
Прочитал тут Google Code Style. Обратил внимание на пункт Streams, где говорится "Use streams only for logging" и "Do not use streams, except where required by a logging interface. Use printf-like routines instead".

Я, конечно, понимаю, что многие вещи в C++ — дело вкуса, но, на мой взгляд, не в данном случае. Почему? Ну, например, хотя бы поэтому:


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

А что Вы думаете по этому поводу?
Re: Google code style
От: Ops Россия  
Дата: 01.04.12 19:32
Оценка: +3
Здравствуйте, Аноним, Вы писали:

А>А что Вы думаете по этому поводу?


Google code style вообще очень спорная штука, лично мне не нравится там многое. К счастью, кроме самого гугла, его мало кто использует.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re: Google code style
От: ntp  
Дата: 01.04.12 19:35
Оценка:
Здравствуйте, Аноним, Вы писали:

А>А что Вы думаете по этому поводу?

Всё так, только забыли главное упомянуть: неудобство форматирования вывода. Во всех языках имеется возможность удобного вывода в том или ином виде, от обычных printf-подобных и их расширений (ява, шарп) до here-doc & K°.

ЗЫ: ещё камень в потоки, хотя это уже не относится к stream vs printf: стандартные потоки завязаны исключительно на текстовой вывод, и средствами C++ вроде бы нельзя работать с бинарными файлами. Или неформатированный ввод/вывод может?
Re: Google code style
От: _DAle_ Беларусь  
Дата: 01.04.12 19:35
Оценка: +2
Здравствуйте, Аноним, Вы писали:

А>Прочитал тут Google Code Style. Обратил внимание на пункт Streams, где говорится "Use streams only for logging" и "Do not use streams, except where required by a logging interface. Use printf-like routines instead".

...
А>А что Вы думаете по этому поводу?

Думаю, что у них были какие-то свои причины на это. Вообще, нет особого смысла обсуждать чьи-то конкретные стандарты кодирования, не зная причин появления тех или иных правил.
Re[2]: Google code style
От: YourLastSong  
Дата: 01.04.12 19:40
Оценка:
_DA>Думаю, что у них были какие-то свои причины на это. Вообще, нет особого смысла обсуждать чьи-то конкретные стандарты кодирования, не зная причин появления тех или иных правил.

Они объясняют это так:

Streams make it difficult to do functionality like pread(). Some formatting (particularly the common format string idiom %.*s) is difficult if not impossible to do efficiently using streams without using printf-like hacks. Streams do not support operator reordering (the %1s directive), which is helpful for internationalization


Но разве этого достаточно, чтобы говорить, что потоки C++ стоит использовать разве что для логов?
Re: Google code style
От: Pzz Россия https://github.com/alexpevzner
Дата: 01.04.12 19:49
Оценка: +6 -2
Здравствуйте, Аноним, Вы писали:

А>
  • Интуитивно-понятны (не надо вспоминать, что означает тот или иной спецификатор в строке форматирования)

    Эта интуитивная понятность кончается, когда хочется вписать результат форматирования в поле определенной ширины, или вывести число с определенной точностью — то, что в printf'е как раз делается просто и естественно.
  • Re[2]: Google code style
    От: YourLastSong  
    Дата: 01.04.12 19:55
    Оценка:
    Pzz>Эта интуитивная понятность кончается, когда хочется вписать результат форматирования в поле определенной ширины, или вывести число с определенной точностью — то, что в printf'е как раз делается просто и естественно.

    Не совсем понял, честно говоря.

    std::setw и std::setprecision менее понятны? Они ведь как раз описывают то, что собирается делать человек, а не используют одни лишь числа.

    Я не хочу спорить — сразу же сказал, что это дело вкуса, просто интересно.
    Re[3]: Google code style
    От: __kot3 США  
    Дата: 01.04.12 19:58
    Оценка:
    Здравствуйте, YourLastSong, Вы писали:

    YLS>std::setw и std::setprecision менее понятны? Они ведь как раз описывают то, что собирается делать человек, а не используют одни лишь числа.


    Меня такие модификаторы бесят тем, что в случае, если область существования потока несколько больше, чем текущий блок, ты никогда заранее не знаешь, в каком состоянии он находится и что ожидать на выходе.
    Re[2]: Google code style
    От: zaufi Земля  
    Дата: 01.04.12 23:05
    Оценка:
    Здравствуйте, ntp, Вы писали:

    ntp>Здравствуйте, Аноним, Вы писали:


    А>>А что Вы думаете по этому поводу?

    ntp>Всё так, только забыли главное упомянуть: неудобство форматирования вывода. Во всех языках имеется возможность удобного вывода в том или ином виде, от обычных printf-подобных и их расширений (ява, шарп) до here-doc & K°.

    в чем именно неудобство? в том, что приходится "прерывать" строковые литералы конструкциями вида "..." << variable << "..." ??
    вообще говоря это дело вкуса (и меня лично не напрягает, и местами даже не плохо выглядит -- все зависит от того как отформатировать исходник...).
    кроме того, возможность использовать манипуляторы (в т.ч. свои собственные... или даже: в особенности собственные) может сильно упростить жизнь.

    кроме того, имеется вполне себе навороченная библа boost::format. а для тех кто перешел на С++11 raw string literals + variadic templates помогут сделать более простую (lightweight) замену этой библе...

    ntp>ЗЫ: ещё камень в потоки, хотя это уже не относится к stream vs printf: стандартные потоки завязаны исключительно на текстовой вывод, и средствами C++ вроде бы нельзя работать с бинарными файлами. Или неформатированный ввод/вывод может?


    может
    Re[4]: Google code style
    От: zaufi Земля  
    Дата: 01.04.12 23:08
    Оценка: +1
    Здравствуйте, __kot3, Вы писали:

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


    YLS>>std::setw и std::setprecision менее понятны? Они ведь как раз описывают то, что собирается делать человек, а не используют одни лишь числа.


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


    нужно просто писать собственные перегрузки для operator<< адекватно.
    ну и временами помогает http://www.boost.org/doc/libs/1_40_0/libs/io/doc/ios_state.html
    Re[3]: «Прерывать» строковые литералы
    От: Qbit86 Кипр
    Дата: 02.04.12 04:45
    Оценка: 7 (3) +7
    Здравствуйте, zaufi, Вы писали:

    Z>в чем именно неудобство? в том, что приходится "прерывать" строковые литералы конструкциями вида "..." << variable << "..." ??

    Z>вообще говоря это дело вкуса (и меня лично не напрягает, и местами даже не плохо выглядит -- все зависит от того как отформатировать исходник...).

    Форматная строка может быть единицей локализации (или просто строковым ресурсом). Ты легко можешь заменить литерал «"Could not open file {0} in directory {1}."» на вызов «GetOpenErrorMessageFormat()». А если это у тебя куски типа «... << "Could not open file " << filename << " in directory " << directory << "."»?
    Глаза у меня добрые, но рубашка — смирительная!
    Re: Google code style
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 06:19
    Оценка: +1
    Здравствуйте, Аноним, Вы писали:

    А>Прочитал тут Google Code Style. Обратил внимание на пункт Streams, где говорится "Use streams only for logging" и "Do not use streams, except where required by a logging interface. Use printf-like routines instead".


    Удивительно, что никто из обсуждавших пока что не обратил внимание на то, что вообще-то одно другому не противоречит. Видимо, потому, что Гугл противопоставляет эти два варианта.
    Но никто не запрещает сделать что-то вроде

    cerr << format("Error in %s: %s", module, errormessage) << endl;


    причём реализация, если хорошо сделана, обойдётся без выделения места под строку.

    Мне это кажется более разумным, чем stdio (о котором почему-то подумали все, кто тут отметился и говорил про printf-like), хотя бы потому, что в stdio нет стандартного варианта сделать не связанный с файлом поток. GNU libc знает fopencookie(); BSD системы знают funopen(); MSVC CRT вообще не предоставляет никакого аналога для этой функциональности, как и большинство проприетарных Unix-систем. C++ <iostream> позволяет делать потоки, не связанные с внешним файлом, штатными средствами, а с произвольным коллбэками — лёгкой доработкой, но без хака основ.

    А>
  • Потоки C++ можно удобно использовать с классами путём перегрузки операторов
    А>
  • Сами потоки также представляют собой объекты и отлично вписываются в объектно-ориентированную структуру языка
    А>
  • Интуитивно-понятны (не надо вспоминать, что означает тот или иной спецификатор в строке форматирования)

    Вот-вот, Вы говорите о штатном управлении потоком, но привязали к потокам целиком. Лично мне давно проще вспомнить значение какого-нибудь %20.8f — хотя бы потому, что он универсален для C, Python, Perl и ещё кучи языков, и даже в Erlang похожий стиль (только ~ вместо % и в конце другой символ вместо f). А вот межъязыкового аналога <iostream> нет и, похоже, не будет. Зато возиться с FILE* в C++ мне кажется порочным, при наличии собственного механизма, адекватного языку и, следовательно, более удобного по сумме всех использований. В случае RAII этот FILE* придётся оборачивать спец-классом, потоки C++ такого не требуют.
  • The God is real, unless declared integer.
    Re[2]: Google code style
    От: __kot2  
    Дата: 02.04.12 07:07
    Оценка: 1 (1) :)))
    Здравствуйте, netch80, Вы писали:
    N>Удивительно, что никто из обсуждавших пока что не обратил внимание на то, что вообще-то одно другому не противоречит. Видимо, потому, что Гугл противопоставляет эти два варианта.
    N>Но никто не запрещает сделать что-то вроде
    N>
    N>cerr << format("Error in %s: %s", module, errormessage) << endl;
    N>

    есть стандартные вещи из С, переосмысленные в С++. они были изменены по двум причинам — (1) они стали надежнее, (2) они стали проще.
    printf был переосмыслен из-за того, что при неправильном формате/пропуске параметра или, еще интереснее, изменении его типа где-то там наверху, printf начинал делать очень поганые вещи. и они совсем не стоили того, чтобы выводить что-то на экран. в С printf был введен также из-за отсутствия перегрузки ф-ий, чтобы не делать отдельно print_str, print_int и т.д. кроме printf эллипсис по сути вообще нигде не используется!

    потоки решили эти проблемы безопасным, простым и расширяемым способом. если кто-то до сих пор продолжает использовать printf вместо потоков, он не понимает философии С++ и ему вообще писать на нем не следует. а тем более делать какие-то там стандарты С++ кода
    Re[3]: Google code style
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 07:15
    Оценка: 2 (2) +2
    Здравствуйте, __kot2, Вы писали:

    __>есть стандартные вещи из С, переосмысленные в С++. они были изменены по двум причинам — (1) они стали надежнее, (2) они стали проще.

    __>printf был переосмыслен из-за того, что при неправильном формате/пропуске параметра или, еще интереснее, изменении его типа где-то там наверху, printf начинал делать очень поганые вещи. и они совсем не стоили того, чтобы выводить что-то на экран. в С printf был введен также из-за отсутствия перегрузки ф-ий, чтобы не делать отдельно print_str, print_int и т.д. кроме printf эллипсис по сути вообще нигде не используется!

    __>потоки решили эти проблемы безопасным, простым и расширяемым способом. если кто-то до сих пор продолжает использовать printf вместо потоков, он не понимает философии С++ и ему вообще писать на нем не следует. а тем более делать какие-то там стандарты С++ кода


    (намеренно не срезал квотинг. он весь показателен)

    Понятно. Есть два мнения: одно Ваше, другое неправильное.

    А Вы никогда не задумывались, почему потокового интерфейса в таком стиле, как в C++, больше нигде нет?
    Почему ещё более "безопасный, простой и расширяемый" C#, например, использует printf-like интерфейсы (разницу между %d и {0} я тут не считаю существенной)?
    Почему весь из себя объектный Python использует два стиля форматирования, один весь как в printf, другой похож на тот, что в C#, и — о ужас! — там тоже есть проблемы с возможной неадекватностью параметров формату, которые не выявляются влёгкую на компиляции? И почему, раз "проблемы решены безопасным, простым и расширяемым образом", что-то не видно штатного аналога стиля C++, хотя его сделать — раз плюнуть?

    Может, Вам стоит задуматься о том, что это не весь окружающий мир шагает не в ногу, а это Вы с iostream шагаете не в ногу?
    The God is real, unless declared integer.
    Re[4]: Google code style
    От: __kot2  
    Дата: 02.04.12 07:20
    Оценка:
    Здравствуйте, netch80, Вы писали:
    N>А Вы никогда не задумывались, почему потокового интерфейса в таком стиле, как в C++, больше нигде нет?
    вот есть я. я не задумывался никогда почему такого, как я больше нет нигде

    N>Почему ещё более "безопасный, простой и расширяемый" C#, например, использует printf-like интерфейсы (разницу между %d и {0} я тут не считаю существенной)?

    вот есть бомж Вася. он собирает бутылки

    N>Почему весь из себя объектный Python использует два стиля форматирования, один весь как в printf, другой похож на тот, что в C#, и — о ужас! — там тоже есть проблемы с возможной неадекватностью параметров формату, которые не

    выявляются влёгкую на компиляции? И почему, раз "проблемы решены безопасным, простым и расширяемым образом", что-то не видно штатного аналога стиля C++, хотя его сделать — раз плюнуть?
    вот есть баба Валя жена бомжа Васи, она тоже собирает бутылки

    N>Может, Вам стоит задуматься о том, что это не весь окружающий мир шагает не в ногу, а это Вы с iostream шагаете не в ногу?

    может и мне стоить бросить это программирование и идти собирать бутылки?
    Re[5]: Google code style
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 07:25
    Оценка:
    Здравствуйте, __kot2, Вы писали:

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

    N>>А Вы никогда не задумывались, почему потокового интерфейса в таком стиле, как в C++, больше нигде нет?
    __>вот есть я. я не задумывался никогда почему такого, как я больше нет нигде

    N>>Почему ещё более "безопасный, простой и расширяемый" C#, например, использует printf-like интерфейсы (разницу между %d и {0} я тут не считаю существенной)?

    __>вот есть бомж Вася. он собирает бутылки

    Интересно бы увидеть обоснование сравнения разработчиков одного из трёх основных языков программирования современного мира с бомжом, собирающим бутылки.
    Наверняка у Вас есть существенные аргументы для этого. Например, особенности процедуры собирания бутылок, или статистические характеристики урожая бутылок этого года.

    N>>Может, Вам стоит задуматься о том, что это не весь окружающий мир шагает не в ногу, а это Вы с iostream шагаете не в ногу?

    __>может и мне стоить бросить это программирование и идти собирать бутылки?

    Хм... Даже не знаю, что сказать. Попробуйте. Может, лет через 10 этого занятия сможете изобрести что-то сравнимое с C# по популярности...
    The God is real, unless declared integer.
    Re[4]: Google code style
    От: __kot2  
    Дата: 02.04.12 07:27
    Оценка: :)
    ну а если серьезно, то

    Здравствуйте, netch80, Вы писали:
    N>А Вы никогда не задумывались, почему потокового интерфейса в таком стиле, как в C++, больше нигде нет?
    а как их реализовать средствами языка в C# и в Python? уже как сделали, так сделали
    Re[6]: Google code style
    От: __kot2  
    Дата: 02.04.12 07:31
    Оценка: -1 :)
    Здравствуйте, netch80, Вы писали:
    N>Хм... Даже не знаю, что сказать. Попробуйте. Может, лет через 10 этого занятия сможете изобрести что-то сравнимое с C# по популярности...
    это аргумент из серии "миллионы зоофилов не могут ошибаться"?
    только не надо сейчас бычиться на меня про бутылки и зоофилов. C# хороший язык со своей нишей. но для своей аудитории. посмотрите на наименование контейнеров, например — сразу видно, что их разрабатывал человек не для, там, алгоритмов каких-то продвинутых, а для тех, кто 2 недельный курс программирования в ПТУ закончил. аналогично с перегрузкой операторов.
    Я сделал с нуля два проекта на C# и еще в одном участвовал, это прекрасный язык, если вам нужно что-то с базой данных и интерфейсом быстренько сделать. но это не значит, что это идеальный язык, где все прямо так безупречно
    Re[7]: Контейнеры
    От: Qbit86 Кипр
    Дата: 02.04.12 07:40
    Оценка: 2 (1) +1
    Здравствуйте, __kot2, Вы писали:

    __>посмотрите на наименование контейнеров, например — сразу видно, что их разрабатывал человек не для, там, алгоритмов каких-то продвинутых, а для тех, кто 2 недельный курс программирования в ПТУ закончил.


    Lol'd :) Хуже, чем в C++, коллекции мало где называются :)

    list'ом называется не абстрактный тип данных cписок, а структура данных односвязный список.
    vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.
    Хэш-таблица в стандарте называется unordered_map.

    Facepalm.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[8]: Контейнеры
    От: night beast СССР  
    Дата: 02.04.12 07:44
    Оценка: :)
    Здравствуйте, Qbit86, Вы писали:

    Q>Lol'd Хуже, чем в C++, коллекции мало где называются


    Q>list'ом называется не абстрактный тип данных cписок, а структура данных односвязный список.


    это точная информация?
    Re[8]: Контейнеры
    От: __kot2  
    Дата: 02.04.12 07:48
    Оценка:
    Здравствуйте, Qbit86, Вы писали:
    Q>Здравствуйте, __kot2, Вы писали:
    __>>посмотрите на наименование контейнеров, например — сразу видно, что их разрабатывал человек не для, там, алгоритмов каких-то продвинутых, а для тех, кто 2 недельный курс программирования в ПТУ закончил.
    Q>Lol'd Хуже, чем в C++, коллекции мало где называются
    Q>list'ом называется не абстрактный тип данных cписок, а структура данных односвязный список.
    это то же самое, что написать: у моего знакомого руки не из жопы торчат, а из плеч, во прикол-то какой!
    а что вы ожидали от понятия "список"?

    Q>vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.

    правильно было назвать его dynamic_array, но это слишком длинно для базового типа. точно из тех же соображений int, а не integer и float, а не floating_point

    Q>Хэш-таблица в стандарте называется unordered_map.

    у хэш-таблицы может быть миллион реализаций и все нужны

    Q>Facepalm.

    а русские слова кончились?
    Re[5]: Бомж Вася
    От: Qbit86 Кипр
    Дата: 02.04.12 07:50
    Оценка:
    Здравствуйте, __kot2, Вы писали:

    __>вот есть я. я не задумывался никогда почему такого, как я больше нет нигде :)

    __>вот есть бомж Вася. он собирает бутылки
    __>вот есть баба Валя жена бомжа Васи, она тоже собирает бутылки
    __>может и мне стоить бросить это программирование и идти собирать бутылки?

    А вот разработчики Boost.Format таки решили уподобиться бомжу Васе, и сделать более или менее безопасную реализацию форматных срок. Взамен слабоюзабельным потокам.

    (Интересно, а кто-то всерьёз регулярно проверяет std::cout.bad(), или, по старой традиции забивает на подобные мелочи?).
    Глаза у меня добрые, но рубашка — смирительная!
    Re[9]: Контейнеры
    От: Qbit86 Кипр
    Дата: 02.04.12 08:00
    Оценка: +1 -1 :)
    Здравствуйте, __kot2, Вы писали:

    __>а что вы ожидали от понятия "список"?


    Близости к бытовому понятию списка. Скажем, список покупок. Вполне может быть нумерованным. Есть абстракция List, есть реализации ArrayList (индексируемый список), есть LinkedList (однонаправленный список), SortedList, etc. С соответствующими асимптотиками поддерживаемых операций, и т.п.

    Q>>vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.

    __>правильно было назвать его dynamic_array, но это слишком длинно для базового типа. точно из тех же соображений int, а не integer и float, а не floating_point

    Т.е. dynamic_array слишком длинно, поэтому решили сократить до vector? Facepalm.

    Q>>Хэш-таблица в стандарте называется unordered_map.

    __>у хэш-таблицы может быть миллион реализаций и все нужны

    И наоборот, хэш-таблицы — это способ реализации (структуры данных) абстрактного типа ассоциативный массив. Есть абстракция Map, есть реализации HashMap, SortedMap (или даже уточнения типа RBTreeMap), etc.

    Q>>Facepalm.

    __>а русские слова кончились?

    Рукалицо.
    Глаза у меня добрые, но рубашка — смирительная!
    Re: Google code style
    От: MasterZiv СССР  
    Дата: 02.04.12 08:01
    Оценка: 2 (2) +2
    > * Сами потоки также представляют собой объекты и отлично вписываются в
    > объектно-ориентированную структуру языка

    Какого ? С++ ? Он не объектно-ориентированный. Он гибридный.

    > * Интуитивно-понятны (не надо вспоминать, что означает тот или иной

    > спецификатор в строке форматирования)

    Это если тебе надо что-то очень простое вывести, тебе хватит << .
    А потом тебе придётся вспоминать такие же форматтеры из потоковой библиотеки.

    > * Безопасны (хотя некоторые компиляторы и выдают ошибки / предупреждения на

    > попытку некорректного использования функций семейства printf, это лишь
    > исключения из правила — стандарт этого, разумеется, не обязывает)


    Безопасность -- на самом деле единственный плюс потоковой библиотеки.
    Но безопасно можно писать и на stdio.

    > А что Вы думаете по этому поводу?


    В общем, потоки -- отстой. Красивая игрушка, плохо пригодная для
    нормального промышленного применения.

    Хорошо подходит для тестовых или учебных целей -- вывел и не надо
    думать о типе аргумента. как бы ввод-вывод, встроенный в язык
    (как в паскал`е).
    Posted via RSDN NNTP Server 2.1 beta
    Re[2]: Google code style
    От: MasterZiv СССР  
    Дата: 02.04.12 08:05
    Оценка: +2 -1
    > Всё так, только забыли главное упомянуть: неудобство форматирования вывода. Во
    > всех языках имеется возможность удобного вывода в том или ином виде, от обычных
    > printf-подобных и их расширений (ява, шарп) до here-doc & K°.

    Кстати, те же джависты таки добавили в последней версии форматный вывод.
    6 кажется версий пыжились и тужились, но таки добавили.

    Кстати, на счёт форматного ввода-вывода. В первом языке программирования
    (fortran) всегда был очень сильный форматный ввод-вывод. Описание его
    занимает порядка трети всего языка. Так что форматный ввод-вывод можно
    сказать must в программировании.


    > ЗЫ: ещё камень в потоки, хотя это уже не относится к stream vs printf:

    > стандартные потоки завязаны исключительно на текстовой вывод, и средствами C++
    > вроде бы нельзя работать с бинарными файлами. Или неформатированный ввод/вывод
    > может?

    Можно.
    Posted via RSDN NNTP Server 2.1 beta
    Re[6]: Бомж Вася
    От: __kot2  
    Дата: 02.04.12 08:07
    Оценка: +1
    Здравствуйте, Qbit86, Вы писали:
    Q>А вот разработчики Boost.Format таки решили уподобиться бомжу Васе, и сделать более или менее безопасную реализацию форматных срок. Взамен слабоюзабельным потокам.
    а разработчики гугла советуют использовать эту безопасную альтернативу или эллипсис проканает?

    лично я тоже не фанат потоков. если нужно написать свое логгирование или сериализация меня вполне устраивает просто переопределенные ф-ии типа log(int, float, string) и т.д.
    другое дело что я против переменного числа аргументов в printf. это как ездить в машине с неработающими тормозами и тормозить только ручником — так делать можно, но советовать это как стиль вождения??? сейчас не 19ый век, надо избавляться от таких решений.

    Q>(Интересно, а кто-то всерьёз регулярно проверяет std::cout.bad(), или, по старой традиции забивает на подобные мелочи?).

    проверки зависят от требований к проекту. в таких проектов, где вывод в cout был критически важен, я еще не участвовал
    Re[10]: Контейнеры
    От: __kot2  
    Дата: 02.04.12 08:13
    Оценка: -1
    Здравствуйте, Qbit86, Вы писали:
    Q>Близости к бытовому понятию списка. Скажем, список покупок. Вполне может быть нумерованным. Есть абстракция List, есть реализации ArrayList (индексируемый список), есть LinkedList (однонаправленный список), SortedList, etc. С соответствующими асимптотиками поддерживаемых операций, и т.п.
    да, для определенной аудитории д-но нужно чтобы список был похож на список покупок. те же, кто книжки читал по алгоритмам знают, что за списком закреплена определенная структура с определенными операциями

    Q>>>vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.

    __>>правильно было назвать его dynamic_array, но это слишком длинно для базового типа. точно из тех же соображений int, а не integer и float, а не floating_point
    Q>Т.е. dynamic_array слишком длинно, поэтому решили сократить до vector? Facepalm.
    вектор тоже подходит. есть, например, функан. там вектора вообще почти все бесконечномерны. никто не мешает использовать его как массив фиксированной длинны + они сделали его авторасширяемым

    Q>>>Хэш-таблица в стандарте называется unordered_map.

    __>>у хэш-таблицы может быть миллион реализаций и все нужны
    Q>И наоборот, хэш-таблицы — это способ реализации (структуры данных) абстрактного типа ассоциативный массив. Есть абстракция Map, есть реализации HashMap, SortedMap (или даже уточнения типа RBTreeMap), etc.
    откройте книжку по алгоритмам. самое главное чем отличаются хэш-таблицы это можно ли из них удалять элементы, ожидаемое время поиска, вставки и т.д. это главное. и реализации у них принципиально разные.

    Q>>>Facepalm.

    __>>а русские слова кончились?
    Q>Рукалицо.
    ну и причем тут рукалицо?
    Re[5]: Google code style
    От: Erop Россия  
    Дата: 02.04.12 08:13
    Оценка:
    Здравствуйте, __kot2, Вы писали:

    __>может и мне стоить бросить это программирование и идти собирать бутылки?

    Если судить по этому топику, то очень даже может быть
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[11]: Контейнеры
    От: Qbit86 Кипр
    Дата: 02.04.12 08:24
    Оценка:
    Здравствуйте, __kot2, Вы писали:

    __>да, для определенной аудитории д-но нужно чтобы список был похож на список покупок. те же, кто книжки читал по алгоритмам знают, что за списком закреплена определенная структура с определенными операциями


    Ну вот Кормен—Лейзерсон—Ривест — это подходящая книжка по алгоритмам? Там то, что в C++ называется std::list, называется singly linked list.

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


    Мне интересно, ну хоть где-то в природе используется std::vector как часть какого-нибудь API, работающего с каким-нибудь векторным пространством? Графические библиотеки, библиотеки вычислительной алгебры, цифровой обработки изображений, 3D-моделирования, ну хоть где-нибудь?
    Глаза у меня добрые, но рубашка — смирительная!
    Re: Google code style
    От: Erop Россия  
    Дата: 02.04.12 08:24
    Оценка:
    Здравствуйте, Аноним, Вы писали:

    А>Из минусов могу вспомнить лишь,..


    А>А что Вы думаете по этому поводу?


    Ну, например, часто не так уж и просто предсказать какой именно ваиант operator << выберется в том или ином месте...
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[12]: Контейнеры
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 08:27
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Мне интересно, ну хоть где-то в природе используется std::vector как часть какого-нибудь API, работающего с каким-нибудь векторным пространством? Графические библиотеки, библиотеки вычислительной алгебры, цифровой обработки изображений, 3D-моделирования, ну хоть где-нибудь?


    Где-то тут же на RSDN с полгода назад видел комментарий, что в STL надо мысленно менять названия vector и array местами, тогда оно будет соответствовать привычному пониманию.
    The God is real, unless declared integer.
    Re[7]: Бомж Вася
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 08:30
    Оценка:
    Здравствуйте, __kot2, Вы писали:

    __>лично я тоже не фанат потоков. если нужно написать свое логгирование или сериализация меня вполне устраивает просто переопределенные ф-ии типа log(int, float, string) и т.д.

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

    Я-то думал, что Вы против возможного рассогласования формата и типа данных, а Вы, оказывается, против переменного числа аргументов.
    The God is real, unless declared integer.
    Re[5]: Google code style
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 08:31
    Оценка:
    Здравствуйте, __kot2, Вы писали:

    N>>А Вы никогда не задумывались, почему потокового интерфейса в таком стиле, как в C++, больше нигде нет?

    __>а как их реализовать средствами языка в C# и в Python? уже как сделали, так сделали

    1) при чём тут язык? эта реализация в библиотеке.
    2) да точно так же как в C++. если бы было нужно и полезно, давно бы сделали. у питона средства для этого не хуже чем C++, и даже гибче. но раз нет — значит, не настолько нужно
    The God is real, unless declared integer.
    Re[9]: Контейнеры
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 08:35
    Оценка: 1 (1) :)
    Здравствуйте, __kot2, Вы писали:

    Q>>list'ом называется не абстрактный тип данных cписок, а структура данных односвязный список.

    __>это то же самое, что написать: у моего знакомого руки не из жопы торчат, а из плеч, во прикол-то какой!
    __>а что вы ожидали от понятия "список"?

    список, к сведению, может быть, например, двусвязным. это значительно полезнее, когда хотя бы иногда возникают ситуации типа "надо посмотреть на предыдущий элемент" или "надо выкинуть элемент из списка, имея только указатель на этот элемент и на какую-то условную голову списка".

    а в случае STL это ситуация, когда одна рука из плеча растёт, а вторая таки из зада, и то может отсутствовать.

    Q>>vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.

    __>правильно было назвать его dynamic_array, но это слишком длинно для базового типа. точно из тех же соображений int, а не integer и float, а не floating_point

    правильно было его назвать просто array.

    Q>>Хэш-таблица в стандарте называется unordered_map.

    __>у хэш-таблицы может быть миллион реализаций и все нужны

    и какая из этого миллиона реализаций может быть названа, к примеру, ordered map?
    The God is real, unless declared integer.
    Re[7]: Бомж Вася
    От: Qbit86 Кипр
    Дата: 02.04.12 08:37
    Оценка:
    Здравствуйте, __kot2, Вы писали:

    __>а разработчики гугла советуют использовать эту безопасную альтернативу или эллипсис проканает?


    Я не знаю. Этот стайл гайд я читал очень давно. Они там, вроде, даже исключения не используют, так что мне с ними не по пути.

    __>лично я тоже не фанат потоков.


    То-то и оно. (С C# на C++ очень тяжело возвращаться.) Printf не использую из-за небезопасности, Boost.Format — из-за нежелания собирать его под целевую платформу. Так что продолжаю грызть кактус и использую потоки.

    __>если нужно написать свое логгирование или сериализация меня вполне устраивает просто переопределенные ф-ии типа log(int, float, string) и т.д.


    Хм... Log всегда выводит строку. Другое дело, как её форматировать. Обычно это не просто число, а более сложный комментарий, описывающий контекст возникновения ошибки.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[8]: Переменное число аргументов
    От: Qbit86 Кипр
    Дата: 02.04.12 08:54
    Оценка:
    Здравствуйте, netch80, Вы писали:

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


    N>Я-то думал, что Вы против возможного рассогласования формата и типа данных, а Вы, оказывается, против переменного числа аргументов.


    Вот, например, переменное число аргументов в C# — это по сути синтаксический сахар для одного аргумента, коллекции с переменным количеством элементов. Т.е. быть против переменного числа параметров — примерно как быть против многоэлементных коллекций. (В C#, конечно, форматирование строк безопаснее, чем в Си.)

    Использование такой функциональности вполне имеет смысл. Скажем, мы делаем
    var messageFormat = Resources.GetUserFormat();
    var message = String.Format(messageFormat, userName, userId, date, time);

    А конкретная форматная строка может выбираться в зависимости от каких-то настроек, и содержать все, не все, переупорядоченные или даже продублированные параметры (скажем, "{1} (0x{1:X})" для вывода идентификатора и его 16-ричного представления).
    Глаза у меня добрые, но рубашка — смирительная!
    Re[6]: Google code style
    От: __kot2  
    Дата: 02.04.12 08:59
    Оценка:
    Здравствуйте, netch80, Вы писали:
    N>>>А Вы никогда не задумывались, почему потокового интерфейса в таком стиле, как в C++, больше нигде нет?
    __>>а как их реализовать средствами языка в C# и в Python? уже как сделали, так сделали
    N>1) при чём тут язык? эта реализация в библиотеке.
    ниче не понял. вот вездеход. он ездит везде. вот Лада Калина. она нигде не ездит. я говорю — раздатка нужна для того, чтобы везде проехать. без раздатки вы не уедете. на Калину не устанавливается раздатка вообще ни в каком варианте. у C# или в Python нельзя реализовать вывод текста в стиле cout << "A" << 10 << endl, так же, как раздатку не вкорячишь в Калину, хоть ты что делай. ограничения конструкции.

    Здравствуйте, netch80, Вы писали:
    N>список, к сведению, может быть, например, двусвязным. это значительно полезнее, когда хотя бы иногда возникают ситуации типа "надо посмотреть на предыдущий элемент" или "надо выкинуть элемент из списка, имея только указатель на этот элемент и на какую-то условную голову списка".
    по дефолту список односвязный так как это минимальная структура такого рода. и алгоритмы для списков в основном ориентируются на односвязность. двусвязность это уже фича списка — оптимизация за счет увеличения использования памяти. поэтому списком называют именно односвязный список, а двусвязный список обычно называют полностью.

    Здравствуйте, netch80, Вы писали:
    N>правильно было его назвать просто array.
    нет. array обычно размещается на стеке и размер его фиксирован

    Q>>>Хэш-таблица в стандарте называется unordered_map.

    N>и какая из этого миллиона реализаций может быть названа, к примеру, ordered map?
    обычно реализуется через дерево. коих тоже множество разных реализаций в зависимости от того, что нужно. какая из них в stl — не знаю, не интересовался. может быть и нету.
    Re[7]: Array
    От: Qbit86 Кипр
    Дата: 02.04.12 09:12
    Оценка:
    Здравствуйте, __kot2, Вы писали:

    __>ниче не понял. вот вездеход. он ездит везде. вот Лада Калина. она нигде не ездит. я говорю — раздатка нужна для того, чтобы везде проехать. без раздатки вы не уедете. на Калину не устанавливается раздатка вообще ни в каком варианте. у C# или в Python нельзя реализовать вывод текста в стиле cout << "A" << 10 << endl, так же, как раздатку не вкорячишь в Калину, хоть ты что делай. ограничения конструкции.


    Можешь сформулировать, в чём именно заключаются «ограничения конструкции» этих языков, что не позволяют реализовать? Отсутствие вывода в стиле C++ в других языках и библиотеках имеет место из-за того, что вывод в стиле потоков C++ — он как Неуловимый Джо.

    N>>правильно было его назвать просто array.

    __>нет. array обычно размещается на стеке и размер его фиксирован

    «array обычно размещается на стеке» — это «обычно» только для C++. Структуры данных в упомянутых тобой книжках по алгоритмам никогда не привязаны к особенностям конкретных языков.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[10]: Контейнеры
    От: night beast СССР  
    Дата: 02.04.12 09:13
    Оценка: +3
    Здравствуйте, netch80, Вы писали:

    Q>>>list'ом называется не абстрактный тип данных cписок, а структура данных односвязный список.

    __>>это то же самое, что написать: у моего знакомого руки не из жопы торчат, а из плеч, во прикол-то какой!
    __>>а что вы ожидали от понятия "список"?

    N>список, к сведению, может быть, например, двусвязным. это значительно полезнее, когда хотя бы иногда возникают ситуации типа "надо посмотреть на предыдущий элемент" или "надо выкинуть элемент из списка, имея только указатель на этот элемент и на какую-то условную голову списка".


    ну, как-бы, список из стандартной библиотеки, двусвязный и есть.
    так что суть претензий не совсем понятна.
    Re[11]: Контейнеры
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 09:23
    Оценка:
    Здравствуйте, night beast, Вы писали:

    N>>список, к сведению, может быть, например, двусвязным. это значительно полезнее, когда хотя бы иногда возникают ситуации типа "надо посмотреть на предыдущий элемент" или "надо выкинуть элемент из списка, имея только указатель на этот элемент и на какую-то условную голову списка".


    NB>ну, как-бы, список из стандартной библиотеки, двусвязный и есть.

    NB>так что суть претензий не совсем понятна.

    А коллега из одного из предыдущих постингов сказал, что односвязный. Кому верить?
    Я сам с STL слишком давно возился и уже забыл.
    The God is real, unless declared integer.
    Re[12]: Контейнеры
    От: Qbit86 Кипр
    Дата: 02.04.12 09:25
    Оценка: :))
    Здравствуйте, netch80, Вы писали:

    NB>>ну, как-бы, список из стандартной библиотеки, двусвязный и есть.

    NB>>так что суть претензий не совсем понятна.

    N>А коллега из одного из предыдущих постингов сказал, что односвязный. Кому верить?

    N>Я сам с STL слишком давно возился и уже забыл.

    Не, я не настаиваю, пусть будет двусвязный, не суть. (Но про std::map помню, что в основе студийной реализации — красно-чёрное дерево.)
    Глаза у меня добрые, но рубашка — смирительная!
    Re[12]: Контейнеры
    От: night beast СССР  
    Дата: 02.04.12 09:26
    Оценка:
    Здравствуйте, netch80, Вы писали:

    NB>>ну, как-бы, список из стандартной библиотеки, двусвязный и есть.

    NB>>так что суть претензий не совсем понятна.

    N>А коллега из одного из предыдущих постингов сказал, что односвязный. Кому верить?


    стандарту

    1 A list is a kind of sequence that supports bidirectional iterators and allows constant time insert and erase operations anywhere within the sequence, with storage management handled automatically. Unlike vectors (23.2.4) and deques (23.2.1), fast random access to listelements is not supported, butmany algorithms only needsequential access anyway.


    N>Я сам с STL слишком давно возился и уже забыл.


    коллега с шарпа переходит, у него ломка
    Re[11]: Контейнеры
    От: Masterkent  
    Дата: 02.04.12 09:26
    Оценка: 1 (1)
    night beast:

    NB>ну, как-бы, список из стандартной библиотеки, двусвязный и есть.

    NB>так что суть претензий не совсем понятна.

    +1, std::list — это никакой не singly linked list. Роль singly linked list в стандартной библиотеке отводится шаблону std::forward_list (С++11).
    Re[3]: Google code style
    От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
    Дата: 02.04.12 09:36
    Оценка: +2
    Здравствуйте, __kot2, Вы писали:

    N>>
    N>>cerr << format("Error in %s: %s", module, errormessage) << endl;
    N>>

    А если тут нужно диалог на экран вывести, то cerr совсем не нужен.

    __>есть стандартные вещи из С, переосмысленные в С++. они были изменены по двум причинам — (1) они стали надежнее, (2) они стали проще.

    __>printf был переосмыслен из-за того, что при неправильном формате/пропуске параметра или, еще интереснее, изменении его типа где-то там наверху, printf начинал делать очень поганые вещи. и они совсем не стоили того, чтобы выводить что-то на экран. в С printf был введен также из-за отсутствия перегрузки ф-ий, чтобы не делать отдельно print_str, print_int и т.д. кроме printf эллипсис по сути вообще нигде не используется!

    С printf единственная проблема — небезопасная передача параметров и отсутствие контроля типов.
    Вот сделали бы что-то типа

    std::string  printf( const std::string &format , const std::vector<Variant> &args );
    std::wstring printf( const std::wstring &format, const std::vector<Variant> &args );

    и было бы счастье.

    __>потоки решили эти проблемы безопасным, простым и расширяемым способом. если кто-то до сих пор продолжает использовать printf вместо потоков, он не понимает философии С++ и ему вообще писать на нем не следует. а тем более делать какие-то там стандарты С++ кода


    Потоки не нужны
    Маньяк Робокряк колесит по городу
    Re[13]: STL
    От: Qbit86 Кипр
    Дата: 02.04.12 09:36
    Оценка:
    Здравствуйте, night beast, Вы писали:

    NB>коллега с шарпа переходит, у него ломка ;)


    Да я с шарпа возвращаюсь, редкоиспользуемые части STL забыл. (Но сам STL по сравнению с Linq, конечно, ад. То, что придумывает Александреску по части ranges vs. iterators конечно, чуть лучше, но, увы, на данный момент в природе не встречается.)
    Глаза у меня добрые, но рубашка — смирительная!
    Re[12]: Контейнеры
    От: SleepyDrago Украина  
    Дата: 02.04.12 09:44
    Оценка:
    Здравствуйте, Masterkent, Вы писали:

    M>night beast:


    NB>>ну, как-бы, список из стандартной библиотеки, двусвязный и есть.

    NB>>так что суть претензий не совсем понятна.

    M>+1, std::list — это никакой не singly linked list. Роль singly linked list в стандартной библиотеке отводится шаблону std::forward_list (С++11).


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

    по теме флейма у меня к руколицым любителям принтф вопросец. Вот вы пишете программу, которая работает с геометрией. Для простоты точками заданными структуркой. Как вы будете в лог выводить эти самые точки ? И так все N тыщ раз рукалицо 2 раза: 1й раз для координаты x и второй раз для y...
    Re[14]: STL
    От: night beast СССР  
    Дата: 02.04.12 09:44
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    NB>>коллега с шарпа переходит, у него ломка


    Q>Да я с шарпа возвращаюсь, редкоиспользуемые части STL забыл. (Но сам STL по сравнению с Linq, конечно, ад. То, что придумывает Александреску по части ranges vs. iterators конечно, чуть лучше, но, увы, на данный момент в природе не встречается.)


    хз. меня после sql линк как-то не впечатлил.
    дело привычки, в общем.
    Re[12]: Контейнеры
    От: __kot2  
    Дата: 02.04.12 09:44
    Оценка:
    Здравствуйте, netch80, Вы писали:
    N>А коллега из одного из предыдущих постингов сказал, что односвязный. Кому верить?
    я забыл что std::list двусвязный я этим никогда в явном виде не пользовался
    Re[7]: Google code style
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 09:46
    Оценка: 6 (1)
    Здравствуйте, __kot2, Вы писали:

    N>>>>А Вы никогда не задумывались, почему потокового интерфейса в таком стиле, как в C++, больше нигде нет?

    __>>>а как их реализовать средствами языка в C# и в Python? уже как сделали, так сделали
    N>>1) при чём тут язык? эта реализация в библиотеке.
    __>ниче не понял. вот вездеход. он ездит везде. вот Лада Калина. она нигде не ездит. я говорю — раздатка нужна для того, чтобы везде проехать. без раздатки вы не уедете. на Калину не устанавливается раздатка вообще ни в каком варианте. у C# или в Python нельзя реализовать вывод текста в стиле cout << "A" << 10 << endl, так же, как раздатку не вкорячишь в Калину, хоть ты что делай. ограничения конструкции.

    И кто же мне это, интересно, запретит сделать такое на Python?

    #!/usr/bin/env python
    import sys
    
    class OStream:
        rf = None
    
        def __init__(self, file):
            self.rf = file
    
        def __lshift__(self, value):
            if isinstance(value, int):
                self.rf.write("%d" % value)
                return self
            elif isinstance(value, str):
                self.rf.write(value)
                return self
            else:
                raise UnsupportedException("I'm too lazy to show real overloading in small example")
    
    if __name__ == '__main__':
        cout = OStream(sys.stdout)
        cout << "Hello " << 333 << " world!\n"


    Запускаю:

    $ python cout.py
    Hello 333 world!

    Ну признайтесь, что Вы его просто не знаете, и зачем писали чушь — неизвестно.

    N>>список, к сведению, может быть, например, двусвязным. это значительно полезнее, когда хотя бы иногда возникают ситуации типа "надо посмотреть на предыдущий элемент" или "надо выкинуть элемент из списка, имея только указатель на этот элемент и на какую-то условную голову списка".

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

    Я не знаю, в каких это краях у Вас такое "обычно". В моих прежних краях, например, значительно "обычнее" список вот такого рода. Или здесь двусвязный список — это просто LIST, а односвязный — SLIST. (Хотя я по умолчанию сразу беру TAILQ, она удобнее, а затем уже можно урезать, если очень жёсткие требования по памяти.) Наоборот, односвязный список — это там нетипичная вещь.

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

    N>>правильно было его назвать просто array.
    __>нет. array обычно размещается на стеке и размер его фиксирован

    Фиксированный размер массива на стеке отменён в C99, то есть 12 лет назад.

    Q>>>>Хэш-таблица в стандарте называется unordered_map.

    N>>и какая из этого миллиона реализаций может быть названа, к примеру, ordered map?
    __>обычно реализуется через дерево. коих тоже множество разных реализаций в зависимости от того, что нужно. какая из них в stl — не знаю, не интересовался. может быть и нету.

    Да, я вынужден признать, что это заблуждение — что хэш-таблица может быть реализована через дерево — слишком распространено. Впрочем, именно тут могли сыграть роль лингвистические принципы — что важнее то, что это map, а unordered (хэш) или ordered (дерево) уже вторично.
    The God is real, unless declared integer.
    Re[8]: Google code style
    От: __kot2  
    Дата: 02.04.12 09:51
    Оценка:
    Здравствуйте, netch80, Вы писали:
    N>Ну признайтесь, что Вы его просто не знаете, и зачем писали чушь — неизвестно.
    я у питона только описание читал. как дочитал до места, что там автоматическое управление памятью, закрыл и забыл про него. это очередное баловство, а не язык.

    N>Фиксированный размер массива на стеке отменён в C99, то есть 12 лет назад.

    в смысле неизменяемый
    Re[4]: Google code style
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 09:52
    Оценка:
    Здравствуйте, Marty, Вы писали:

    N>>>
    N>>>cerr << format("Error in %s: %s", module, errormessage) << endl;
    N>>>

    M>А если тут нужно диалог на экран вывести, то cerr совсем не нужен.

    Ну это уже вопрос того, как получить реальное форматирование. Может, проще сделать ostringstream,
    вывести в него и уже строку показать в диалоге, чем вызывать format() с выходом строки и уже строку писать в поток. Что-то я подозреваю, что в стиле C++ будет предпочтён "функтор", который дальше применяется к потоку.
    В boost, насколько я понял документацию, оно где-то так.

    M>С printf единственная проблема — небезопасная передача параметров и отсутствие контроля типов.

    M>Вот сделали бы что-то типа

    M>
    M>std::string  printf( const std::string &format , const std::vector<Variant> &args );
    M>std::wstring printf( const std::wstring &format, const std::vector<Variant> &args );
    M>

    M>и было бы счастье.

    А набивать этот vector аргументами насколько удобно?
    The God is real, unless declared integer.
    Re[9]: Google code style
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 09:54
    Оценка:
    Здравствуйте, __kot2, Вы писали:

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

    N>>Ну признайтесь, что Вы его просто не знаете, и зачем писали чушь — неизвестно.
    __>я у питона только описание читал. как дочитал до места, что там автоматическое управление памятью, закрыл и забыл про него. это очередное баловство, а не язык.

    Вау. И C# баловство, и Java баловство? Да Вы, батенька, эстет.

    N>>Фиксированный размер массива на стеке отменён в C99, то есть 12 лет назад.

    __>в смысле неизменяемый

    Ну предположим. И какой сверхглубокий смысл устанавливать неизменяемость размера массива как неотъемлемую характеристику его понятия?
    The God is real, unless declared integer.
    Re[13]: Контейнеры
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 09:56
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>по теме флейма у меня к руколицым любителям принтф вопросец. Вот вы пишете программу, которая работает с геометрией. Для простоты точками заданными структуркой. Как вы будете в лог выводить эти самые точки ? И так все N тыщ раз рукалицо 2 раза: 1й раз для координаты x и второй раз для y...


    Честно говоря, не понял проблему.
    Вопрос в том, куда попадает лог, или в выборе конкретных чисел в каком-нибудь %10.4f для их показа?
    Или в том, что кому-то религия запрещает вызвать printf в цикле?
    The God is real, unless declared integer.
    Re[10]: Google code style
    От: __kot2  
    Дата: 02.04.12 09:59
    Оценка:
    Здравствуйте, netch80, Вы писали:
    __>>Здравствуйте, netch80, Вы писали:
    N>>>Ну признайтесь, что Вы его просто не знаете, и зачем писали чушь — неизвестно.
    __>>я у питона только описание читал. как дочитал до места, что там автоматическое управление памятью, закрыл и забыл про него. это очередное баловство, а не язык.
    N>Вау. И C# баловство, и Java баловство? Да Вы, батенька, эстет.
    точно с той точки зрения что и iPad — баловство. очень узкая область применения. хотя иногда очень современно и быстро что-то можно сделать.

    N>>>Фиксированный размер массива на стеке отменён в C99, то есть 12 лет назад.

    __>>в смысле неизменяемый
    N>Ну предположим. И какой сверхглубокий смысл устанавливать неизменяемость размера массива как неотъемлемую характеристику его понятия?
    значит, у него нет операции добавления элемента и всего гемора, что с этим связано — переноса данных, выбор шага увеличения, отложенная инициализация и т.д.
    Re[13]: Контейнеры
    От: Erop Россия  
    Дата: 02.04.12 10:01
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>по теме флейма у меня к руколицым любителям принтф вопросец. Вот вы пишете программу, которая работает с геометрией. Для простоты точками заданными структуркой. Как вы будете в лог выводить эти самые точки ? И так все N тыщ раз рукалицо 2 раза: 1й раз для координаты x и второй раз для y...


    Ну так, например:
    // Это где-то в библе
    #define TO_STR( data ) ToStr( data ).c_str()
    
    //  ToStr -- определены для разных нужных типов.
    
    //  Теперь там, где определена эта точка, я определяю ещё и ToStr, после чего  могу писать так как-то:
    
    printf( "vector: (%s -> %s)", TO_STR(point1), TO_STR(point2) );
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[13]: Форматные строки
    От: Qbit86 Кипр
    Дата: 02.04.12 10:03
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>шаблон был изначально под именем slist как расширение, так что кому надо могли пользоваться.


    Вопрос не про list, slist, forward_list, а про смешное утверждение, что де в других языках контейнеры названы для ПТУ-шников, а в C++ всё «чотко и ровно».

    SD>по теме флейма у меня к руколицым любителям принтф вопросец.


    Если это ко мне, то к любителям printf не отношусь: http://www.rsdn.ru/forum/cpp/4685018.1.aspx
    Автор: Qbit86
    Дата: 02.04.12
    . Некоторые в треде путают любителей printf и любителей нормального вывода через форматные строки.

    SD>Как вы будете в лог выводить эти самые точки ?


    В нормальном API это выглядит так:
    Console.WriteLine(GetPointFormatString(), point); // Где GetFormatString() это «Current point: {0}.» или «Текущая точка: {0}.».

    А в C++ как динамически менять выводимое сообщение и его структуру (скажем, вывести точку дважды при каких-то настройках в логе)?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[14]: Контейнеры
    От: SleepyDrago Украина  
    Дата: 02.04.12 10:04
    Оценка:
    Здравствуйте, netch80, Вы писали:

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


    SD>>по теме флейма у меня к руколицым любителям принтф вопросец. Вот вы пишете программу, которая работает с геометрией. Для простоты точками заданными структуркой. Как вы будете в лог выводить эти самые точки ? И так все N тыщ раз рукалицо 2 раза: 1й раз для координаты x и второй раз для y...


    N>Честно говоря, не понял проблему.

    N>Вопрос в том, куда попадает лог, или в выборе конкретных чисел в каком-нибудь %10.4f для их показа?
    N>Или в том, что кому-то религия запрещает вызвать printf в цикле?

    то есть вы в выборе между
    logstream("at:" << point);


    и

    >вызвать printf в цикле


    добровольно выбираете 2е зная что это нужно каждые 50 строк ? Я чесслово не смог бы лучше за вас описать насколько это эпик.
    А геометрия она бывает не только из чисел. Вот например 2d грань это 2 точки и направление
    Re[14]: Форматные строки
    От: SleepyDrago Украина  
    Дата: 02.04.12 10:07
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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

    ...
    SD>>Как вы будете в лог выводить эти самые точки ?

    Q>В нормальном API это выглядит так:

    Q>
    Q>Console.WriteLine(GetPointFormatString(), point); // Где GetFormatString() это «Current point: {0}.» или «Текущая точка: {0}.».
    Q>

    Q>А в C++ как динамически менять выводимое сообщение и его структуру (скажем, вывести точку дважды при каких-то настройках в логе)?

    Стоп стоп стоп я популярно объяснил что пойнт консольке не знаком? Или надо еще раз. Читайте медленно — поинт это структура из программы.
    Re[15]: STL
    От: Qbit86 Кипр
    Дата: 02.04.12 10:08
    Оценка:
    Здравствуйте, night beast, Вы писали:

    NB>хз. меня после sql линк как-то не впечатлил.

    NB>дело привычки, в общем.

    Linq — это не только SQL-like запросы (можешь SQL-like синтаксис вообще не использовать, просто применять ФВП). Это унифицированный доступ к разным сущностям. Скажем, к потоку событий (т.е. push-, а не pull-модель), с его фильтрацией, отображением, свёрткой. etc.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[5]: Google code style
    От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
    Дата: 02.04.12 10:08
    Оценка: +1
    Здравствуйте, netch80, Вы писали:

    N>Ну это уже вопрос того, как получить реальное форматирование. Может, проще сделать ostringstream,

    N>вывести в него и уже строку показать в диалоге, чем вызывать format() с выходом строки и уже строку писать в поток. Что-то я подозреваю, что в стиле C++ будет предпочтён "функтор", который дальше применяется к потоку.
    N>В boost, насколько я понял документацию, оно где-то так.

    А зачем нужен поток, когда мне нужен просто результат работы format? При том, что форматную строку я беру из ресурсов, и в зависимости от языка, фразы могут быть построены так, что аргументы могут быть поменяны местами в форматной строке?

    M>>С printf единственная проблема — небезопасная передача параметров и отсутствие контроля типов.

    M>>Вот сделали бы что-то типа

    N>А набивать этот vector аргументами насколько удобно?


    Ну, я себе сделал, примерно так выглядит:

    my_format("Error: %1 in line %2, pos %3", my_arg( err_msg ) % lineNo % posNo );


    Язык мог бы помочь, если бы элипсис преобразовывался к какому-то более-менее типизированному хранилищу.
    Как нибудь так:
    class arg_array;
    std::string printf( char *fmt, const arg_array &args);
    class arg_array
    {
     ellipsis std::string printf( char *fmt, const arg_array &args);
     ellipsis arg_array() // ctor
      {
       //...
      }
       //...
    };
    Маньяк Робокряк колесит по городу
    Re[6]: Google code style
    От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
    Дата: 02.04.12 10:15
    Оценка:
    Здравствуйте, Marty, Вы писали:

    M>Язык мог бы помочь, если бы элипсис преобразовывался к какому-то более-менее типизированному хранилищу.

    M>Как нибудь так:
    M>
    M>class arg_array;
    M>std::string printf( char *fmt, const arg_array &args);
    M>class arg_array
    M>{
    M> ellipsis std::string printf( char *fmt, const arg_array &args);
    M> ellipsis arg_array() // ctor
    M>  {
    M>   //...
    M>  }
    M>   //...
    M>};
    M>


    Уточню немного.
    В вышеприведенной фантазии ключевое слово ellipsis указывает, в первом случае, что правило применяется к указанной функции. И, если компилятор встречает вызов print c подходящими параметрами (до const arg_array &args) то может трактовать список параметров как переменный, и подыскивает конструктор с ellipsis (ну или без), и для каждой ',' подыскивает в классе некий '& operator push_op()'.
    Маньяк Робокряк колесит по городу
    Re[11]: Google code style
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 10:15
    Оценка: +1
    Здравствуйте, __kot2, Вы писали:

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

    N>>Вау. И C# баловство, и Java баловство? Да Вы, батенька, эстет.
    __>точно с той точки зрения что и iPad — баловство. очень узкая область применения. хотя иногда очень современно и быстро что-то можно сделать.

    Завидую Вам — потому, что не знаете, что эта "очень узкая область применения" сейчас преобладает во всей области так называемого "внутреннего ПО" (по Спольски), которая в свою очередь занимает, по разным оценкам, от 70 до 90 процентов всех усилий программистов. Как в анекдоте — "бросить всё и уехать в этот Урюпинск".

    N>>>>Фиксированный размер массива на стеке отменён в C99, то есть 12 лет назад.

    __>>>в смысле неизменяемый
    N>>Ну предположим. И какой сверхглубокий смысл устанавливать неизменяемость размера массива как неотъемлемую характеристику его понятия?
    __>значит, у него нет операции добавления элемента и всего гемора, что с этим связано — переноса данных, выбор шага увеличения, отложенная инициализация и т.д.

    Я вообще-то не о том. С тем, что даже в C++/C#/Java/etc. иногда полезно вводить понятие массива неизменяемого размера, я заранее согласен. Вопрос в том, почему только такой реализации позволять гордо нести имя "массив", а для изменяемого размера требовать что-то иное?
    The God is real, unless declared integer.
    Re[16]: STL
    От: night beast СССР  
    Дата: 02.04.12 10:17
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    NB>>хз. меня после sql линк как-то не впечатлил.

    NB>>дело привычки, в общем.

    Q>Linq — это не только SQL-like запросы (можешь SQL-like синтаксис вообще не использовать, просто применять ФВП). Это унифицированный доступ к разным сущностям. Скажем, к потоку событий (т.е. push-, а не pull-модель), с его фильтрацией, отображением, свёрткой. etc.


    возможно.
    однако заметь, я не рассказываю какое линк г*но, потому что синтаксис условий on убог, или потому что нет группировки по нескольким полям...
    Re[12]: Google code style
    От: night beast СССР  
    Дата: 02.04.12 10:22
    Оценка: +3
    Здравствуйте, netch80, Вы писали:

    N>Я вообще-то не о том. С тем, что даже в C++/C#/Java/etc. иногда полезно вводить понятие массива неизменяемого размера, я заранее согласен. Вопрос в том, почему только такой реализации позволять гордо нести имя "массив", а для изменяемого размера требовать что-то иное?


    о. терминологический спор, это так увлекательно
    давайте обсудим шарповский List.
    Re[15]: Контейнеры
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.04.12 10:23
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    N>>Честно говоря, не понял проблему.

    N>>Вопрос в том, куда попадает лог, или в выборе конкретных чисел в каком-нибудь %10.4f для их показа?
    N>>Или в том, что кому-то религия запрещает вызвать printf в цикле?

    SD>то есть вы в выборе между

    SD>
    SD>logstream("at:" << point);
    SD>


    SD>и


    >>вызвать printf в цикле


    SD>добровольно выбираете 2е зная что это нужно каждые 50 строк ? Я чесслово не смог бы лучше за вас описать насколько это эпик.


    Вы не объяснили сколь-нибудь внятно, чего именно хотите, а теперь рассказываете про эпик на основании своих домыслов о том, как бы я решал эту задачу. Вам действительно интересны такие игры? Или проще было бы просто ответить на вопросы, а затем уже слушать ответы собеседника?

    SD>А геометрия она бывает не только из чисел. Вот например 2d грань это 2 точки и направление


    Охотно верю. То есть, если я правильно Вас понял, вся суть ситуации в том, что объект знает, как именно его выводить в конкретном случае, и Вы не хотите расшифровывать внутреннее содержимое потому что 1) это куча громоздкой писанины, 2) это нарушение инкапсуляции. Я правильно понял?
    The God is real, unless declared integer.
    Re[12]: Google code style
    От: __kot2  
    Дата: 02.04.12 10:25
    Оценка: +1 :)
    Здравствуйте, netch80, Вы писали:
    N>Завидую Вам — потому, что не знаете, что эта "очень узкая область применения" сейчас преобладает во всей области так называемого "внутреннего ПО" (по Спольски), которая в свою очередь занимает, по разным оценкам, от 70 до 90 процентов всех усилий программистов. Как в анекдоте — "бросить всё и уехать в этот Урюпинск".
    автоматизация работы предприятия? скучно. я не для этого программистом хотел в детстве стать
    Re[16]: Контейнеры
    От: SleepyDrago Украина  
    Дата: 02.04.12 10:41
    Оценка:
    Здравствуйте, netch80, Вы писали:

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

    ...

    N>Вы не объяснили сколь-нибудь внятно, чего именно хотите, а теперь рассказываете про эпик на основании своих домыслов о том, как бы я решал эту задачу. Вам действительно интересны такие игры? Или проще было бы просто ответить на вопросы, а затем уже слушать ответы собеседника?


    SD>>А геометрия она бывает не только из чисел. Вот например 2d грань это 2 точки и направление


    N>Охотно верю. То есть, если я правильно Вас понял, вся суть ситуации в том, что объект знает, как именно его выводить в конкретном случае, и Вы не хотите расшифровывать внутреннее содержимое потому что 1) это куча громоздкой писанины, 2) это нарушение инкапсуляции. Я правильно понял?


    да на 1). Самая популярная описка это спутать ось координат точки в выражении .

    про 2 я вас не понял. Для простоты не нужна там инкапсуляция.

    На счет локализации да там будет идеален вариант "текст {идентификатор1} текст {идентификатор2} текст". Но такие программы редко нуждаются в локализации. Так что локализация не нужна.
    Re[15]: Форматные строки
    От: Qbit86 Кипр
    Дата: 02.04.12 11:01
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    Q>>В нормальном API это выглядит так:

    Q>>
    Q>>Console.WriteLine(GetPointFormatString(), point); // Где GetFormatString() это «Current point: {0}.» или «Текущая точка: {0}.».
    Q>>

    Q>>А в C++ как динамически менять выводимое сообщение и его структуру (скажем, вывести точку дважды при каких-то настройках в логе)?

    SD>Стоп стоп стоп я популярно объяснил что пойнт консольке не знаком? Или надо еще раз. Читайте медленно — поинт это структура из программы.


    Что значит «консольке не знаком»? В C++ по умолчанию знаком, что ли? Или таки требует реализацию каких-то методов (типа оператор вывода)?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[15]: Неоднозначность
    От: Qbit86 Кипр
    Дата: 02.04.12 11:44
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>logstream("at:" << point);


    Такой код перестанет компилироваться, как только разработчики структуры Point добавят свой собственный вывод в поток (обнаруживаемый через ADL) — будет неоднозначность. Или, скажем, такой оператор уже есть, просто неподходящий, а нам нужно своё форматирование.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[3]: Google code style
    От: MasterZiv СССР  
    Дата: 02.04.12 12:05
    Оценка: 1 (1) +2
    если
    > кто-то до сих пор продолжает использовать printf вместо потоков, он не понимает
    > философии С++ и ему вообще писать на нем не следует. а тем более делать какие-то
    > там стандарты С++ кода

    Ага, засунь свою философию знаешь куда ?

    С++ уже был нормальным языком лет десять, прежде чем эту потоковую библиотечку
    изобрели, вместе с шаблонами.
    Posted via RSDN NNTP Server 2.1 beta
    Re[4]: Google code style
    От: __kot2  
    Дата: 02.04.12 12:21
    Оценка: :)
    Здравствуйте, MasterZiv, Вы писали:
    MZ>Ага, засунь свою философию знаешь куда ?
    да ты я вижу крут, чувачок.

    MZ>С++ уже был нормальным языком лет десять, прежде чем эту потоковую библиотечку

    MZ>изобрели, вместе с шаблонами.
    только вот я покруче тебя буду. я писал на С++ с тех пор когда еще stl не стандартизовали.
    он тогда все равно был, но не стандартизован. вместо <iostream> писали <iostream.h>, не было namespace std, все было в глобальном и мелочи были типа не ios_base::in, а ios::in
    stl появился почти сразу с С++, как только туда шаблоны добавили
    Re[17]: STL
    От: koodeer  
    Дата: 02.04.12 12:27
    Оценка: 1 (1) :)
    Здравствуйте, night beast, Вы писали:

    NB>однако заметь, я не рассказываю какое линк г*но, потому что синтаксис условий on убог, или потому что нет группировки по нескольким полям...


    Группировка по нескольким полям:

    group x by new { x.Field1, x.Field2}

    Не?

    Насчёт синтаксиса on. Сдаётся мне, вы пытаетесь использовать linq ненадлежащим образом. Сколько встречал опытных разработчиков баз данных, практически все пытаются переводить sql-запросы тупо один в один на linq-запросы. Но это неправильно! Это разные технологии.
    Аналогично, например, программеры пытаются перенести свой опыт ООП из таких языков, как C++,C#,Java на JavaScript: плюются на дурацкое, с их точки зрения, прототипное ООП. Оно не дурацкое, оно другое!

    Может, всё же стоит освоить linq?
    Вот, например, кратенько-кратенько: http://www.linqpad.net/WhyLINQBeatsSQL.aspx Полагаю, некоторые предубеждения по прочтении развеются сами.
    Вообще, для понимания LINQ рекомендую книги Албахари.
    Re[15]: Форматные строки
    От: koodeer  
    Дата: 02.04.12 12:40
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

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


    Q>>В нормальном API это выглядит так:

    Q>>
    Q>>Console.WriteLine(GetPointFormatString(), point); // Где GetFormatString() это «Current point: {0}.» или «Текущая точка: {0}.».
    Q>>


    SD>Стоп стоп стоп я популярно объяснил что пойнт консольке не знаком? Или надо еще раз. Читайте медленно — поинт это структура из программы.


    В данном случае автоматически вызовется метод ToString. Если он не переопределён, то по умолчанию выведется что-то вроде:

    MyNamespace.MyClass+Point


    Стоит отметить, что перегрузка метода ToString — практически обязательное условие при написании нового класса/структуры. Таким образом, консольке point знаком в любом случае.
    Re[16]: ICustomFormatter
    От: Qbit86 Кипр
    Дата: 02.04.12 12:43
    Оценка:
    Здравствуйте, koodeer, Вы писали:

    K>Стоит отметить, что перегрузка метода ToString — практически обязательное условие при написании нового класса/структуры. Таким образом, консольке point знаком в любом случае.


    Он, может, и знаком, но, возможно, делает не то, что нужно в конкретном синтетическом примере.

    Однако функции форматирования содержат перегрузки, принимающие IFormatProvider. Достаточно его реализовать (вместе с ICustomFormatter'ом) требуемым образом.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[5]: Google code style
    От: MasterZiv СССР  
    Дата: 02.04.12 13:12
    Оценка:
    > MZ>Ага, засунь свою философию знаешь куда ?
    > да ты я вижу крут, чувачок.

    Да, в общем, не дурак.

    Ты извини уж, резковато получилось, но вот чего в С++ нет и никогда не было,
    так это философии. Единственная его философия -- это компромис между
    производительностью и типобезопасностью и другими безопасностями.

    > MZ>С++ уже был нормальным языком лет десять, прежде чем эту потоковую библиотечку

    > MZ>изобрели, вместе с шаблонами.
    > только вот я покруче тебя буду. я писал на С++ с тех пор когда еще stl не
    > стандартизовали.

    Да я тоже писал.
    Вообще-то с ... эээ ... с 1990-го где-то...
    Posted via RSDN NNTP Server 2.1 beta
    Re[16]: Неоднозначность
    От: SleepyDrago Украина  
    Дата: 02.04.12 13:17
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    ...

    Q>
    SD>logstream("at:" << point);


    Q>Такой код перестанет компилироваться, как только разработчики структуры Point добавят свой собственный вывод в поток (обнаруживаемый через ADL) — будет неоднозначность. Или, скажем, такой оператор уже есть, просто неподходящий, а нам нужно своё форматирование.


    поскольку диспетчеризуем по 2м аргументам то необязательно быть автором структуры чтобы в наш лог она выводилась однозначно. Проблемы только у тех кто гвоздями прибивает в коде единственно правильный поток

    ps и принтэфы в цикле и print_point'ы все я успел повидать.
    Re[17]: Неоднозначность
    От: Qbit86 Кипр
    Дата: 02.04.12 13:26
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    Q>>
    SD>logstream("at:" << point);


    Q>>Такой код перестанет компилироваться, как только разработчики структуры Point добавят свой собственный вывод в поток (обнаруживаемый через ADL) — будет неоднозначность. Или, скажем, такой оператор уже есть, просто неподходящий, а нам нужно своё форматирование.


    SD>поскольку диспетчеризуем по 2м аргументам то необязательно быть автором структуры чтобы в наш лог она выводилась однозначно. Проблемы только у тех кто гвоздями прибивает в коде единственно правильный поток :beer:


    Т.е. ты выводишь не в std::ostream, а в свой поток конкретного типа? Что такое logstream?

    SD>ps и принтэфы в цикле и print_point'ы все я успел повидать.


    В соседней ветке я описал, как это будет выглядеть в C#. Без обёрток типа print_point. Грубо говоря, аналогом плюсового оператора вывода будет реализация одного метода в ICustomFormatter.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[18]: STL
    От: night beast СССР  
    Дата: 02.04.12 14:30
    Оценка: +1
    Здравствуйте, koodeer, Вы писали:

    NB>>однако заметь, я не рассказываю какое линк г*но, потому что синтаксис условий on убог, или потому что нет группировки по нескольким полям...


    K>Группировка по нескольким полям:


    K>
    K>group x by new { x.Field1, x.Field2 }
    K>

    K>Не?

    возможно.

    K>Насчёт синтаксиса on. Сдаётся мне, вы пытаетесь использовать linq ненадлежащим образом. Сколько встречал опытных разработчиков баз данных, практически все пытаются переводить sql-запросы тупо один в один на linq-запросы. Но это неправильно! Это разные технологии.


    ага. это фича. знакомо.

    K>Аналогично, например, программеры пытаются перенести свой опыт ООП из таких языков, как C++,C#,Java на JavaScript: плюются на дурацкое, с их точки зрения, прототипное ООП. Оно не дурацкое, оно другое!


    то же можно сказать про stl, не?

    K>Может, всё же стоит освоить linq?

    K>Вот, например, кратенько-кратенько: http://www.linqpad.net/WhyLINQBeatsSQL.aspx Полагаю, некоторые предубеждения по прочтении развеются сами.

    обычная агитка, ничего интересного.
    веселье начинается когда начинаешь переносить рабочие запросы в шарп.

    K>Вообще, для понимания LINQ рекомендую книги Албахари.
    Re[7]: Google code style
    От: GreyMan  
    Дата: 02.04.12 15:46
    Оценка:
    Здравствуйте, Marty, Вы писали:

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


    M>>Язык мог бы помочь, если бы элипсис преобразовывался к какому-то более-менее типизированному хранилищу.

    std::initializer_list вместе с собственным лисапедом?
    struct Var
    {
        Var(const char a);
        Var(const int a);
        Var(const float a);
        Var(const double a);
        Var(const char* a);
        Var(const string&a);
    };
    void printm(const string s,const initializer_list<var>&list);
    
    ...
    
    printm("Format string",{'a',1,2.3."aa"});
    Re: Google code style
    От: alex_public  
    Дата: 02.04.12 17:50
    Оценка:
    Хы, одному мне кажется что потоки и контейнеры C++ тут обсуждают больше всего C# люди, которые уже "забыли всё" (или вообще не знали)? )))
    Re[2]: Google code style
    От: Qbit86 Кипр
    Дата: 02.04.12 18:13
    Оценка: 3 (1) :))
    Здравствуйте, alex_public, Вы писали:

    _>Хы, одному мне кажется что потоки и контейнеры C++ тут обсуждают больше всего C# люди, которые уже "забыли всё" (или вообще не знали)? )))


    Не больше, чем люди, которые кроме C++ ничего во внешнем мире не видели, и сравнивать могут лишь с Си.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[6]: Google code style
    От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
    Дата: 02.04.12 18:16
    Оценка:
    Здравствуйте, MasterZiv, Вы писали:

    >> MZ>Ага, засунь свою философию знаешь куда ?

    >> да ты я вижу крут, чувачок.

    MZ>Да, в общем, не дурак.


    ЭЭЭ, не ссорьтесь, горячие парни. Я на паскале начинал писать программы в 93 (до того на асме как-то), крутые чуваки уже тогда говорили, как крут C++. В 95-96 и сам стал пописывать на нем. Но вы оба гораздо круче, я это знаю, так как постоянно читал посты и одного, и другого. Не вежливо хамить оппонентам, уж вы бы должны знать это.
    Маньяк Робокряк колесит по городу
    Re[8]: Google code style
    От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
    Дата: 02.04.12 18:22
    Оценка:
    Здравствуйте, GreyMan, Вы писали:


    M>>>Язык мог бы помочь, если бы элипсис преобразовывался к какому-то более-менее типизированному хранилищу.

    GM>std::initializer_list вместе с собственным лисапедом?

    1) std::initializer_list это какой стандарт языка?
    2) с разными типами как быть?
    3) ну у меня примерно так и сейчас, живу и без поддержки языка. Но с поддержкой сахара больше, а нажатий по кнопкам меньше.
    Маньяк Робокряк колесит по городу
    Re[3]: Google code style
    От: alex_public  
    Дата: 02.04.12 19:28
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Не больше, чем люди, которые кроме C++ ничего во внешнем мире не видели, и сравнивать могут лишь с Си.


    Ииии? ) Чем знание другого языка может помочь не разбирающимся в тонкостях C++, но желающим поговорить о них? )))
    Re[4]: Google code style
    От: Qbit86 Кипр
    Дата: 02.04.12 19:32
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ииии? ) Чем знание другого языка может помочь не разбирающимся в тонкостях C++, но желающим поговорить о них? )))


    Это ты меня так троллишь, что ли? Поставь ещё больше закрывающих скобок тогда, для верности.

    Какие тонкости ты имеешь в виду, говори конкретнее.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[18]: Неоднозначность
    От: SleepyDrago Украина  
    Дата: 02.04.12 19:42
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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

    ...
    Q>Т.е. ты выводишь не в std::ostream, а в свой поток конкретного типа? Что такое logstream?

    любая вещь которая понимает вывод в себя как поток. Например макро аля COMPANYPREFIX_LOGSTREAM_LOGLEVEL только короче. На нынешней работе мы выводим в класс строки и ее кушает лог.

    SD>>ps и принтэфы в цикле и print_point'ы все я успел повидать.


    Q>В соседней ветке я описал, как это будет выглядеть в C#. Без обёрток типа print_point. Грубо говоря, аналогом плюсового оператора вывода будет ...

    тоже самое. Если учесть что манипуляторы я тоже не люблю и не реализую для потоков то по сути тоже самое — 1 операция на класс снаружи от него.
    Re[7]: Google code style
    От: MasterZiv СССР  
    Дата: 02.04.12 19:46
    Оценка:
    > постоянно читал посты и одного, и другого. Не вежливо хамить оппонентам, уж вы
    > бы должны знать это.

    Я не хамиль. Просто фигура речи такой ...
    Posted via RSDN NNTP Server 2.1 beta
    Re[19]: Неоднозначность
    От: Qbit86 Кипр
    Дата: 02.04.12 20:02
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>любая вещь которая понимает вывод в себя как поток. Например макро аля COMPANYPREFIX_LOGSTREAM_LOGLEVEL только короче. На нынешней работе мы выводим в класс строки :super: и ее кушает лог.


    Т.е. это может развернуться во что-то типа
    std::ostringstream out;
    ...
    out << "at:" << point;

    ?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[5]: Google code style
    От: alex_public  
    Дата: 02.04.12 20:10
    Оценка: +2
    Здравствуйте, Qbit86, Вы писали:

    Q>Это ты меня так троллишь, что ли? Поставь ещё больше закрывающих скобок тогда, для верности.


    Q>Какие тонкости ты имеешь в виду, говори конкретнее.


    В теме вообще то обсуждаются потоки C++. Потом разговор почему то (тоже не по теме вообще то) перешёл на STL... Ну перешёл и ладно. Но я не пойму зачем STL обсуждают люди не знающие её (list односвязный список?) и откуда тут вообще взялся linq?

    По теме. В C++ есть:

    — удобное, небезопасное — printf
    — неудобное, безопасное — cout<<
    — удобное, безопасное — boost::format

    Кому чего не хватает? )))

    P.S. Если запрет Гугла на исключения я понимаю (это существенное архитектурное решение), то запрет на io потоки не особо. Т.е. я бы скорее понял запрет на printf, как на опасное. А запрет на потоки... Ну оно не особо удобное, так и не будут просто пользоваться сами.

    P.P.S. Использую printf для отладки и т.п.
    Re[3]: Google code style
    От: night beast СССР  
    Дата: 02.04.12 20:23
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    _>>Хы, одному мне кажется что потоки и контейнеры C++ тут обсуждают больше всего C# люди, которые уже "забыли всё" (или вообще не знали)? )))


    Q>Не больше, чем люди, которые кроме C++ ничего во внешнем мире не видели, и сравнивать могут лишь с Си.


    ваша главаная проблема в том, что вы действительно так думаете
    с возрастом это проходит, обычно.
    Re[6]: Тонкости C++
    От: Qbit86 Кипр
    Дата: 02.04.12 20:29
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Потом разговор почему то (тоже не по теме вообще то) перешёл на STL...


    Не почему-то, а потому что упомянули именования стандартных коллекций/контейнеров. Которые в C++ весьма смешные, да.

    _>Но я не пойму зачем STL обсуждают люди не знающие её (list односвязный список?)


    STL я знаю. В обсуждаемом контексте названий было не суть важно точное соотношение doubly-/singly-linked list и std::list/std::forward_list, поэтому ни я, ни собеседник (по его же словам, могу найти ссылку) не придали большого внимания точности соотнесения этих структур данных и контейнеров C++. Важнее было фигурирование в названии АТД (list; map; array) vs. СД (singly-, doubly-linked list; tree (ordered), hash (unordered) map; std::array, std::vector).

    Но ты почему-то решил докопаться к второстепенной детали. Так это и были твои «тонкости C++»? Нет, правда, библиотечные контейнеры — это для тебя тонкость языка?

    _>и откуда тут вообще взялся linq?


    В сравнении работы с коллекциями в C# и в C++. Linq — он вообще про последовательности и коллекции, а не про базы данных, как думают «.NET-казуалы». Ущербность интерфейса стандартных коллекций и алгоритмов в C++ понятна и вполне уважаемым людям вроде Александреску.

    _>По теме. В C++ есть:


    _>- удобное, небезопасное — printf

    _>- неудобное, безопасное — cout<<
    _>- удобное, безопасное — boost::format

    _>Кому чего не хватает? )))


    На этот комментарий я вполне ответил в треде: не хватает нормального форматирования как в .NET или на худой конец Boost.Format (потому что не хочется заморачиваться сборкой и линковкой под iOS), приходится использовать потоки и их ущербные манипуляторы. За использование printf вроде никто не ратует (кроме гугловского стайл гайда).
    Глаза у меня добрые, но рубашка — смирительная!
    Re[3]: Google code style
    От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
    Дата: 02.04.12 20:41
    Оценка: :))) :)
    Здравствуйте, Qbit86, Вы писали:

    _>>Хы, одному мне кажется что потоки и контейнеры C++ тут обсуждают больше всего C# люди, которые уже "забыли всё" (или вообще не знали)? )))


    Q>Не больше, чем люди, которые кроме C++ ничего во внешнем мире не видели, и сравнивать могут лишь с Си.


    Что-то видел, что-то нет. C++ довольно сложен и многословен. Но после всех его минусов — auto уже есть в последнем стандарте, остался только форматный вывод. Будет типобезопасный форматный вывод в printf — хм, Nemerle (да и все остальное) не нужен.
    Маньяк Робокряк колесит по городу
    Re[8]: Google code style
    От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
    Дата: 02.04.12 20:58
    Оценка: :)
    Здравствуйте, MasterZiv, Вы писали:

    MZ>Я не хамиль. Просто фигура речи такой ...

    хамиль — нехамль, я просто абарот между вами немного убавиль. уважаемыи, хорошие луди сорятся, мне жалко, да, панимаишь?
    Маньяк Робокряк колесит по городу
    Re[9]: Google code style
    От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
    Дата: 02.04.12 21:03
    Оценка:
    Здравствуйте, Marty, Вы писали:

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

    ну не убавиль, но папробоваль убавить. зачем харашим лудям сорится, им дружбанить надо, да?
    Маньяк Робокряк колесит по городу
    Re[9]: Google code style
    От: GreyMan  
    Дата: 02.04.12 21:22
    Оценка:
    Здравствуйте, Marty, Вы писали:

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

    M>1) std::initializer_list это какой стандарт языка?
    C++11.
    M>2) с разными типами как быть?
    Шаблонный конструктор с привлечением же шаблонной магии для промежуточного типа (Который Var в примере)?
    Или в списке конструкторов конструктор, принимающий абстрактный класс ToString? Кому надо, пусть наследуется от него. Как в C# и сделано, например.
    Re[19]: Неоднозначность
    От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
    Дата: 02.04.12 21:55
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    Q>>В соседней ветке я описал, как это будет выглядеть в C#. Без обёрток типа print_point. Грубо говоря, аналогом плюсового оператора вывода будет ...

    SD>тоже самое. Если учесть что манипуляторы я тоже не люблю и не реализую для потоков то по сути тоже самое — 1 операция на класс снаружи от него.

    Читал тут немного в параллельной ветке про потоки вывода.
    Сделал вывод — амно-амном эти C++ потоки в/выв (это вывод по прочтении веток форума, 100-500 лет назад и сам допер) .
    Оператор << немного годится для использования в классах, которые делают вид, что они потоки ввода-вывода. При случае использовать можно. А почему-бы и нет? Перегрузка оператора '<<' для любого класса никого обычно не травмирует. Надо бы стандарт Цпп допилить до внятного использования элипсисов при возможности, и тогда будет (ща)счастье всем.
    Маньяк Робокряк колесит по городу
    Re[9]: Контейнеры, комментарий Страуструпа
    От: B0FEE664  
    Дата: 02.04.12 22:00
    Оценка: 3 (1)
    Здравствуйте, __kot2, Вы писали:

    Q>>vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.

    __>правильно было назвать его dynamic_array, но это слишком длинно для базового типа. точно из тех же соображений int, а не integer и float, а не floating_point

    Кто-нибудь может сказать, что valarray следовало бы назвать vector(вектор), поскольку он является традиционным математическим вектором, а vector следовало бы назвать array(массив), однако терминология развивалась иначе. valarray — это вектор, оптимизированный для численных расчётов, а vector — это гибкий контейнер разработанный для хранения объектов различного типа и манипулирования с ними, массив же — это низкоуровневый встроенный тип.

    Бьерн Страуструп
    "Язык программирования С++"
    третье издание
    Издательство "Бином" Москва
    Издательство "Невский диалект" Санкт-Петербург
    г. 1999
    стр. 760
    И каждый день — без права на ошибку...
    Re[6]: Google code style
    От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
    Дата: 02.04.12 22:00
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>По теме. В C++ есть:


    _>- удобное, небезопасное — printf

    _>- неудобное, безопасное — cout<<
    _>- удобное, безопасное — boost::format

    _>Кому чего не хватает? )))


    Мне бы
    _>удобное, безопасное — printf
    можно сделать?
    Маньяк Робокряк колесит по городу
    Re[7]: Тонкости C++
    От: alex_public  
    Дата: 02.04.12 22:07
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Не почему-то, а потому что упомянули именования стандартных коллекций/контейнеров. Которые в C++ весьма смешные, да.


    А какое это имеет отношение к потокам то? )))

    Что касается имён... То для людей проходивших университетские курсы они по идее не должны быть смешными, т.к. идут с довольно старых времён. Ну а для самоучек у которых list ассоциируется со списком покупок это возможно странным кажется.

    Q>Но ты почему-то решил докопаться к второстепенной детали. Так это и были твои «тонкости C++»? Нет, правда, библиотечные контейнеры — это для тебя тонкость языка?


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

    Q>В сравнении работы с коллекциями в C# и в C++. Linq — он вообще про последовательности и коллекции, а не про базы данных, как думают «.NET-казуалы». Ущербность интерфейса стандартных коллекций и алгоритмов в C++ понятна и вполне уважаемым людям вроде Александреску.


    Мне нравятся идеи Александреску в языке D. А вот в C++ его иногда заносит слишком далеко. Всё же изначально шаблоны — это не полноценный язык для метапрограммирования. )))

    Q>На этот комментарий я вполне ответил в треде: не хватает нормального форматирования как в .NET или на худой конец Boost.Format (потому что не хочется заморачиваться сборкой и линковкой под iOS), приходится использовать потоки и их ущербные манипуляторы. За использование printf вроде никто не ратует (кроме гугловского стайл гайда).


    А что там страшного с Boost'ом на iOS? Я под iOS не собирал, а вот под OS X собирал (в gcc 4.6) — ни малейших проблем не видел. Там что-то принципиально другое?

    Ну и наконец главное... Boost::Format — это библиотечка в заголовках! Её не надо собирать и линковать вообще))) Так вы точно знаете нюансы C++? )))
    Re[8]: Тонкости C++
    От: Qbit86 Кипр
    Дата: 02.04.12 22:48
    Оценка: 3 (1) -1 :))
    Здравствуйте, alex_public, Вы писали:

    Q>>Не почему-то, а потому что упомянули именования стандартных коллекций/контейнеров. Которые в C++ весьма смешные, да.

    _>А какое это имеет отношение к потокам то? )))

    Это вопрос не ко мне, это к тому, кто первым упомянул про названия коллекций. И да, смайликов больше, больше надо!

    _>Что касается имён... То для людей проходивших университетские курсы они по идее не должны быть смешными, т.к. идут с довольно старых времён. Ну а для самоучек у которых list ассоциируется со списком покупок это возможно странным кажется.


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

    Q>>Но ты почему-то решил докопаться к второстепенной детали. Так это и были твои «тонкости C++»? Нет, правда, библиотечные контейнеры — это для тебя тонкость языка?

    _>Это часть стандарта языка, так что конечно. И кстати одно или двух связный список — довольно важный нюанс в смысле быстродействия...

    В смысле быстродействия, но абсолютно несущественный в контексте первого упоминания. Твои наивные попытки самоутвердиться, пытаясь обличить в неведении незнакомых тебе людей, выглядят глупо и смешно. Поцепляйся ещё к пунктуации, я иногда вводные слова не обосабливаю.

    _>Мне нравятся идеи Александреску в языке D. А вот в C++ его иногда заносит слишком далеко. Всё же изначально шаблоны — это не полноценный язык для метапрограммирования. )))


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

    _>А что там страшного с Boost'ом на iOS? Я под iOS не собирал, а вот под OS X собирал (в gcc 4.6) — ни малейших проблем не видел. Там что-то принципиально другое?


    Не уверен, что тебе удастся убедить бустовский сборщик с полпинка, что в качестве компилятора надо использовать LLVM, а не GCC, а таргетом будет iOS, а не MacOS.

    _>Ну и наконец главное... Boost::Format — это библиотечка в заголовках! Её не надо собирать и линковать вообще)))


    Это прекрасно. Давно не освежал в памяти набор не headers only библиотек, вот, ты подбросил повод.

    _>Так вы точно знаете нюансы C++? )))


    Вот срезал так срезал :)
    Глаза у меня добрые, но рубашка — смирительная!
    Re[9]: Тонкости C++
    От: alex_public  
    Дата: 03.04.12 01:22
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Толсто же. Про университетские курсы мне говорит махровый гуманитарий, который слабо представляет себе, что за сущность такая — вектор.


    И что это за сущность? )))

    Q>В смысле быстродействия, но абсолютно несущественный в контексте первого упоминания. Твои наивные попытки самоутвердиться, пытаясь обличить в неведении незнакомых тебе людей, выглядят глупо и смешно. Поцепляйся ещё к пунктуации, я иногда вводные слова не обосабливаю.


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

    Ладно хотя бы одно ещё... Но обе вещи сразу — это перебор уже. )))

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


    О, вот это уже интересно. Так вы считаете STL убогой? ) Какой бы другой библиотекой вы предпочли заменить её?

    Q>Не уверен, что тебе удастся убедить бустовский сборщик с полпинка, что в качестве компилятора надо использовать LLVM, а не GCC, а таргетом будет iOS, а не MacOS.

    Ммм, сам не пробовал, поэтому не знаю. Но глянув в гугле первую же ссылку: http://www.danielsefton.com/2012/03/building-boost-1-49-with-clang-ios-5-1-and-xcode-4-3/ — вроде всё автоматом собирается.
    Re: Google code style
    От: мыщъх США http://nezumi-lab.org
    Дата: 03.04.12 03:43
    Оценка:
    Здравствуйте, Аноним, Вы писали:

    А>Прочитал тут Google Code Style.

    ...
    А>А что Вы думаете по этому поводу?
    почитал Google Code Style про питона. даже воспользовался гугловским чекером. чекер обругал матом стандартные питоновские библиотеки и до моего кода даже не добрался как выдохся и упал замертно. не, ну все правильно. у ms vc на /W4 тоже ругается на свои же библиотеки. бывает...

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

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

    ладно, читаю эту лабуду дальше. "Exceptions are allowed but must be used carefully". блин, какой капиан это писал? это вообще о чем? это вообще к психологу. какое слово тут лишнее. правильно. исключения. потому что этот совет справедлив практически для всех языковых возможностей. сильно поменяется смысл если исключения заменить на комментарии, например?


    Avoid global variables -- пацаны жгут напалпом. пион уже постарался и в _каждой_ функции, изменяющей значение глобальной переменной, ее необходимо явно описывать как global, в противном случае сработает copy-on-write и все изменения окажутся сугубо локальными. именно благодаря этой фиче глобальных переменных на питоне можно не бояться. это вам не си. кстати, наличие 'global' в пионе создает конфликтную ситуацию. чего рекомендуется избегать -- объектов с глобальной видимостью или объектов, которые можно глобально модифицировать? каковы границы этой глобальности? если в пределах модуля, то всякая функция с точки зрения питона это переменная. у него же динамическая типизация.

    Nested/local/inner classes and functions are fine. -- это уже не напалп, а горилка настоенная на ацетоне. вот, цитирую:

    Pros: Allows definition of utility classes and functions that are only used inside of a very limited scope. Very ADT-y.

    Cons: Instances of nested or local classes cannot be pickled.

    Decision: They are fine.

    упомянить closures стоило хотя бы для приличия. scope это не повод вилами махать. или тогда вообще ничего не объяснять, а просто сказать They are fine, потому как если мне позарез нужно их замариновать, то это совсем не айс.


    вообще, гайдлайны главным образом пишут для унификации и единообразия. плюс еще немного полезных советов в стиле "если вы не можете писать код не более чем с тремя вложениями -- вам вообще лучше не писать". гайдлайны для ядра линуха очень хороший пример правильных гайдлайнов. да, местами они _очень_ спорны, но по крайней мере они направлены против бардака. а у гугла что? "исключения использовать допустимо, но только с головой. вложенные функции это тоже нормально". а если у меня будет 200 уровней вложенности это как? нормально? нет, увы. отступы мы делаем 4 пробелами. макс. длина строки 80 символов (по гайдлайном). определение функции def_имя(): т.е. минимум 8 символов. плюс 4 на отступ. осталось решить задачку -- какой уровень вложенности считается допустимым. я фигею дорогая редакция.
    americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
    Re[10]: Вектор
    От: Qbit86 Кипр
    Дата: 03.04.12 04:55
    Оценка: +1 :))
    Здравствуйте, alex_public, Вы писали:

    Q>>Толсто же. Про университетские курсы мне говорит махровый гуманитарий, который слабо представляет себе, что за сущность такая — вектор.

    _>И что это за сущность? )))

    Не, точно гуманитарий. (А судя по смайликам, ещё и малолетний.) Мой комментарий выше про векторное пространство так и не понял. Вот, например, в WPF есть класс Vector, его экземпляры, по сути, элементы пространства, присоединённого к аффинному пространству Point'ов.

    В твоих, э... «университетских курсах» про подобное не рассказывали?

    _>Не, тут дело не в самоутверждение.


    И кого ты хочешь обмануть?

    _>Просто раздражает когда люди:

    _>- ...пишут не зная предмет.

    Вот, например, ты. Не знаешь, что двусвязный список в неплюсовых API (например, в Jave и .NET) называются LinkedList (а List'ом называются вполне индексируемые коллекции), и продолжаешь нести чушь про самоучек и «университетские курсы».

    _>- пишут вообще не по теме, отвлекаясь на всякие сомнительные языки


    Это раздел КСВ.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[7]: Google code style
    От: Niemand Австралия  
    Дата: 03.04.12 05:18
    Оценка: :)
    Здравствуйте, Marty, Вы писали:

    MZ>>Да, в общем, не дурак.


    M>ЭЭЭ, не ссорьтесь, горячие парни.


    хорошо, вам, плюсовикам. всегда есть о чем поболтать
    If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
    Re[10]: Контейнеры, комментарий Страуструпа
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 03.04.12 05:21
    Оценка: 2 (2) +2
    Здравствуйте, B0FEE664, Вы писали:

    BFE>Кто-нибудь может сказать, что valarray следовало бы назвать vector(вектор), поскольку он является традиционным математическим вектором, а vector следовало бы назвать array(массив), однако терминология развивалась иначе. valarray — это вектор, оптимизированный для численных расчётов, а vector — это гибкий контейнер разработанный для хранения объектов различного типа и манипулирования с ними, массив же — это низкоуровневый встроенный тип.


    Красиво сказано, как будто слушаешь наших политиков и их объяснения, что же на самом деле улучшилось

    BFE> Бьерн Страуструп

    BFE>"Язык программирования С++"
    The God is real, unless declared integer.
    Re[17]: Контейнеры
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 03.04.12 05:30
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    N>>Вы не объяснили сколь-нибудь внятно, чего именно хотите, а теперь рассказываете про эпик на основании своих домыслов о том, как бы я решал эту задачу. Вам действительно интересны такие игры? Или проще было бы просто ответить на вопросы, а затем уже слушать ответы собеседника?

    SD>>>А геометрия она бывает не только из чисел. Вот например 2d грань это 2 точки и направление
    N>>Охотно верю. То есть, если я правильно Вас понял, вся суть ситуации в том, что объект знает, как именно его выводить в конкретном случае, и Вы не хотите расшифровывать внутреннее содержимое потому что 1) это куча громоздкой писанины, 2) это нарушение инкапсуляции. Я правильно понял?
    SD>да на 1). Самая популярная описка это спутать ось координат точки в выражении .

    OK, понятно. Отвечаю на такое: я категорически не против использования потоков для такого применения, более того, даже "за". Впрочем, тут есть пара подводных камней. Например, надо решить, как именно выбирать метод представления в конкретном потоке — где-то двоичная сериализация, где-то легкоразбираемая текстовая (типа JSON), где-то печать для лога... конкретный метод решения сильно разнится по обстоятельствам.

    SD>про 2 я вас не понял. Для простоты не нужна там инкапсуляция.


    Не знаю, что называется простотой в данном случае, но она тут получается совершенно естественна.

    SD>На счет локализации да там будет идеален вариант "текст {идентификатор1} текст {идентификатор2} текст". Но такие программы редко нуждаются в локализации. Так что локализация не нужна.


    Для отладочной печати — да, согласен (хотя и тут бывают исключения)
    The God is real, unless declared integer.
    Re[13]: Google code style
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 03.04.12 05:32
    Оценка:
    Здравствуйте, __kot2, Вы писали:

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

    N>>Завидую Вам — потому, что не знаете, что эта "очень узкая область применения" сейчас преобладает во всей области так называемого "внутреннего ПО" (по Спольски), которая в свою очередь занимает, по разным оценкам, от 70 до 90 процентов всех усилий программистов. Как в анекдоте — "бросить всё и уехать в этот Урюпинск".
    __>автоматизация работы предприятия? скучно. я не для этого программистом хотел в детстве стать

    Я думаю, все, кто хотели стать программистами *в детстве*, хотели не для учёта старых простыней
    но даже в таких областях можно придумать много нового.
    The God is real, unless declared integer.
    Re[14]: STL
    От: FR  
    Дата: 03.04.12 06:26
    Оценка: 1 (1)
    Здравствуйте, Qbit86, Вы писали:

    NB>>коллега с шарпа переходит, у него ломка


    Q>Да я с шарпа возвращаюсь, редкоиспользуемые части STL забыл. (Но сам STL по сравнению с Linq, конечно, ад. То, что придумывает Александреску по части ranges vs. iterators конечно, чуть лучше, но, увы, на данный момент в природе не встречается.)


    В бусте встречаются, например http://www.boost.org/doc/libs/1_49_0/libs/range/doc/html/range/reference/adaptors/introduction.html
    вполне близко к F# (с его |> и т. п.) или C# linq.
    Re[14]: Форматные строки
    От: FR  
    Дата: 03.04.12 06:30
    Оценка: 1 (1)
    Здравствуйте, Qbit86, Вы писали:

    SD>>шаблон был изначально под именем slist как расширение, так что кому надо могли пользоваться.


    Q>Вопрос не про list, slist, forward_list, а про смешное утверждение, что де в других языках контейнеры названы для ПТУ-шников, а в C++ всё «чотко и ровно».


    Везде плохо.
    Re[6]: Google code style
    От: Centaur Россия  
    Дата: 03.04.12 07:47
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>По теме. В C++ есть:


    _>- удобное, небезопасное — printf

    _>- неудобное, безопасное — cout<<
    _>- удобное, безопасное — boost::format

    Помимо осей «удобное—неудобное» и «безопасное—небезопасное» есть ещё оси «быстрое—тормозное» и «доступное—геморное».

    А вообще, я давно говорил, что в операции вывода кроме Значения и Потока участвует ещё третья сущность — Форматер. printf и boost::format упрощают/усложняют Форматер до Форматной строки (неполный embedded DSL), iostreams прячут его в состояние Потока и воздействуют на него Манипуляторами. А надо бы его на поверхность вынести и вкусный синтаксис придумать.
    Re: Google code style
    От: maykie Россия  
    Дата: 03.04.12 08:56
    Оценка: 6 (5) +6
    Здравствуйте, Аноним, Вы писали:

    Ненавижу потоки.

    
    #include <iostream>
    
    int main()
    {
        int flags = 0x16;
        std::cout << std::setw(15) << std::hex << flags << "\n";
        ...
        int money = 100;
        std::cout << money << "\n";
    }

    Вопрос:
    Что выведет последняя строка? Правильный ответ: не известно.

    Всё зависит от .... Если там ничего нет, то выведется 64.

    Причем отнюдь не шириной в 15 символов. Ну и с чего это hex более значим чем setw? IMNSHO ввод-вывод не должен иметь такой невнятный state где половина модификаторов сохраняются, а половина нет.

    С++ потоки имеют все минусы глобальных переменных без глобальных переменных.

    Ещё один повод для ненависти:
    cout/cin тормозные и их надо десинхронизровать с stdin/stdout иначе скорость ввода/вывода будет хуже чем в питоне(http://stackoverflow.com/questions/9371238/why-is-reading-lines-from-stdin-much-slower-in-c-than-python/9371717#comment12310955_9371717). Только не надо рассказывать сказки про то, что синхронизация с stdin/stdout это деталь реализации, и в теории всё может не тупить. На практике тупит.

    И про костыли вида `std::cout << (std::stringstream() << "foo" << std::setw(8) << "bar").rdbuf() << std::endl;` не надо говорить. И про copyfmt тоже не надо. И про flags. И про Boost.IO_State_Savers. В нормальном I/O такие костыли нафиг не нужны.
    И то, что надо тренировать память запоминая что hex это дескать флаг, а width это дескать манипулятор и поэтому первый сохраняется, а второй нет, тоже не надо говорить.
    Re[11]: Вектор
    От: alex_public  
    Дата: 03.04.12 09:30
    Оценка: 1 (1)
    Здравствуйте, Qbit86, Вы писали:

    Q>Не, точно гуманитарий. (А судя по смайликам, ещё и малолетний.) Мой комментарий выше про векторное пространство так и не понял. Вот, например, в WPF есть класс Vector, его экземпляры, по сути, элементы пространства, присоединённого к аффинному пространству Point'ов.


    Так я так и не увидел обещанного негуманитарного определения вектора. )))

    Хыхы, снова .Net выполз. Без него не получается математическое определение? )))

    Q>Вот, например, ты. Не знаешь, что двусвязный список в неплюсовых API (например, в Jave и .NET) называются LinkedList (а List'ом называются вполне индексируемые коллекции), и продолжаешь нести чушь про самоучек и «университетские курсы».


    И снова .Net и Java. Без них никак не получается говорить про C++? )

    Кстати, hint: посмотреть даты создания STL, Java, .Net.

    Q>Это раздел КСВ.


    О, уже... А изначально C++ был. Вот к чему приводят все эти уходы от темы, как я и говорил.
    Re[2]: Google code style
    От: alex_public  
    Дата: 03.04.12 09:34
    Оценка:
    Здравствуйте, мыщъх, Вы писали:

    М>вообще, гайдлайны главным образом пишут для унификации и единообразия. плюс еще немного полезных советов в стиле "если вы не можете писать код не более чем с тремя вложениями -- вам вообще лучше не писать".


    С питоновскими гайдлайнами Гугла понятно. А у C++ варианта как дела? )
    Re[12]: Вектор
    От: Qbit86 Кипр
    Дата: 03.04.12 09:47
    Оценка: :)
    Здравствуйте, alex_public, Вы писали:

    _>Так я так и не увидел обещанного негуманитарного определения вектора. )))


    Обещанного? Никто не обещал восполнять твои пробелы в образовании.

    _>Хыхы, снова .Net выполз. Без него не получается математическое определение? )))


    Ты не улавливаешь связи в последовательных предложениях. Упоминание класса вектора в одном из .NET API служило примером, а не определением вектора в алгебре (который элемент векторного пространства).

    В качестве твоей первой книги по линейной алгебре советую Кострикина.

    _>И снова .Net и Java. :))) Без них никак не получается говорить про C++? )


    Нельзя продуктивно говорить о чём бы то ни было, не пытаясь расширить контекст и проводить сравнения с существующими образцами.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[3]: Google code style
    От: Ops Россия  
    Дата: 03.04.12 10:08
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Здравствуйте, мыщъх, Вы писали:


    М>>вообще, гайдлайны главным образом пишут для унификации и единообразия. плюс еще немного полезных советов в стиле "если вы не можете писать код не более чем с тремя вложениями -- вам вообще лучше не писать".


    _>С питоновскими гайдлайнами Гугла понятно. А у C++ варианта как дела? )


    А C++ там практически урезан до C с классами (а новый стандарт вообще явно запрещен, разве что смарт-поинтеры можно), зато чОтко регламентировано, где сколько пробелов ставить и дофига КЭПитанства.
    Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
    Re: Google code style
    От: zakharov75 Великобритания  
    Дата: 03.04.12 10:20
    Оценка: -1
    Здравствуйте, Аноним, Вы писали:

    А>Прочитал тут Google Code Style. Обратил внимание на пункт Streams, где говорится "Use streams only for logging" и "Do not use streams, except where required by a logging interface. Use printf-like routines instead".


    А>Я, конечно, понимаю, что многие вещи в C++ — дело вкуса, но, на мой взгляд, не в данном случае. Почему? Ну, например, хотя бы поэтому:


    А>

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


    А>А что Вы думаете по этому поводу?


    C++ streams are much slower than C-style printf-like functions. My guess is more than 10 times slower.
    Re[18]: Контейнеры
    От: SleepyDrago Украина  
    Дата: 03.04.12 10:29
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>... Впрочем, тут есть пара подводных камней. Например, надо решить, как именно выбирать метод представления в конкретном потоке — где-то двоичная сериализация, где-то легкоразбираемая текстовая (типа JSON), где-то печать для лога... конкретный метод решения сильно разнится по обстоятельствам.


    как я уже писал операция вывода имеет 2 аргумента и тип потока не прибит гвоздями к std. Хотя я не видел особого профита от потоков в бинарном/json виде так как там нет свободной структуры куда можно добавить еще что-то по настроению.
    Re[11]: Google code style
    От: Mamut Швеция http://dmitriid.com
    Дата: 03.04.12 10:59
    Оценка:
    N>>>>Ну признайтесь, что Вы его просто не знаете, и зачем писали чушь — неизвестно.
    __>>>я у питона только описание читал. как дочитал до места, что там автоматическое управление памятью, закрыл и забыл про него. это очередное баловство, а не язык.
    N>>Вау. И C# баловство, и Java баловство? Да Вы, батенька, эстет.
    __>точно с той точки зрения что и iPad — баловство. очень узкая область применения. хотя иногда очень современно и быстро что-то можно сделать.

    Хм. И Erlang тоже баловство?


    dmitriid.comGitHubLinkedIn
    Re[14]: Форматные строки
    От: VoidEx  
    Дата: 03.04.12 11:45
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>В нормальном API это выглядит так:

    Q>
    Q>Console.WriteLine(GetPointFormatString(), point); // Где GetFormatString() это «Current point: {0}.» или «Текущая точка: {0}.».
    Q>

    Q>А в C++ как динамически менять выводимое сообщение и его структуру (скажем, вывести точку дважды при каких-то настройках в логе)?

    В нормальном API преобразование в строку не должно быть намертво пришито к типу данных.
    Re[12]: Google code style
    От: Privalov  
    Дата: 03.04.12 11:48
    Оценка: +1 :))
    Здравствуйте, Mamut, Вы писали:

    M>Хм. И Erlang тоже баловство?


    Баловство все, что не Фортран IV.
    Re[15]: Форматные строки
    От: Qbit86 Кипр
    Дата: 03.04.12 11:53
    Оценка:
    Здравствуйте, VoidEx, Вы писали:

    VE>В нормальном API преобразование в строку не должно быть намертво пришито к типу данных.


    А что, где-то пришито?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[16]: Форматные строки
    От: VoidEx  
    Дата: 03.04.12 11:57
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    VE>>В нормальном API преобразование в строку не должно быть намертво пришито к типу данных.


    Q>А что, где-то пришито?


    object.ToString
    Re[17]: Formatting Types
    От: Qbit86 Кипр
    Дата: 03.04.12 12:14
    Оценка:
    Здравствуйте, VoidEx, Вы писали:

    Q>>А что, где-то пришито?


    VE>object.ToString


    Это всего лишь способ вывода по умолчанию, который используется в случае, если в методы форматирования не передаётся своя реализация IFormatProvider/ICustomFormatter. See also: Formatting Types
    Глаза у меня добрые, но рубашка — смирительная!
    Re[18]: Formatting Types
    От: VoidEx  
    Дата: 03.04.12 12:16
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    Q>>>А что, где-то пришито?


    VE>>object.ToString


    Q>Это всего лишь способ вывода по умолчанию, который используется в случае, если в методы форматирования не передаётся своя реализация IFormatProvider/ICustomFormatter. See also: Formatting Types


    Снимаю все обвинения!
    Re[10]: Контейнеры, комментарий Страуструпа
    От: Erop Россия  
    Дата: 03.04.12 18:40
    Оценка:
    Здравствуйте, B0FEE664, Вы писали:

    BFE>

    BFE>Кто-нибудь может сказать, что valarray следовало бы назвать vector(вектор), поскольку он является традиционным математическим вектором, а vector следовало бы назвать array(массив), однако терминология развивалась иначе. valarray — это вектор, оптимизированный для численных расчётов, а vector — это гибкий контейнер разработанный для хранения объектов различного типа и манипулирования с ними, массив же — это низкоуровневый встроенный тип.

    BFE> Бьерн Страуструп

    IMHO, это только доказывает, что "терминология развивалась" неудачно...
    Ну вообще весь STL делали люди со значительным вывихом мозга. Так что чего там было ждать-то прямых решений?
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[13]: Вектор
    От: alex_public  
    Дата: 03.04.12 19:13
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Обещанного? Никто не обещал восполнять твои пробелы в образовании.


    Ага, как я и думал. В начале много громких слов, а когда переходим к конкретике, то пшик.

    Q>Ты не улавливаешь связи в последовательных предложениях. Упоминание класса вектора в одном из .NET API служило примером, а не определением вектора в алгебре (который элемент векторного пространства).


    Угу, и в OpenGL тоже есть свои вектора. Только какое это имеет отношение к универсальным контейнерам C++?

    _>>И снова .Net и Java. Без них никак не получается говорить про C++? )

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

    Ооо, ну хорошо. Тогда давайте разберём что же подразумевается под понятием "список" в языках Лисп, Пролог, Хаскель. Ну это для начала. )))
    Re[14]: Вектор
    От: Ops Россия  
    Дата: 03.04.12 21:35
    Оценка: +1
    Здравствуйте, alex_public, Вы писали:

    _>Ооо, ну хорошо. Тогда давайте разберём что же подразумевается под понятием "список" в языках Лисп, Пролог, Хаскель. Ну это для начала. )))


    Для начала лучше вспомнить, что называли списком, например, Дейкстра или Вирт. Неожиданно оказывается, что это 1 или 2-связный интрузивный список, а никак не список покупок.
    Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
    Re[15]: Контейнеры
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 04.04.12 03:35
    Оценка: +1 :)
    Здравствуйте, SleepyDrago, Вы писали:

    SD>добровольно выбираете 2е зная что это нужно каждые 50 строк ? Я чесслово не смог бы лучше за вас описать насколько это эпик.

    SD>А геометрия она бывает не только из чисел. Вот например 2d грань это 2 точки и направление
    Не очень понятно ваше желание выводить точки исключительно в поток. А если вам потребуется их не логгировать, а, скажем, в TextBox записывать?
    Безотносительно к наличию в языке потоков достаточно реализовать метод .toString(), который решит все проблемы форматирования точки раз и навсегда.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[11]: Люди со значительным вывихом мозга
    От: Qbit86 Кипр
    Дата: 04.04.12 04:42
    Оценка: +1 :)
    Здравствуйте, Erop, Вы писали:

    E>IMHO, это только доказывает, что "терминология развивалась" неудачно... :xz:

    E>Ну вообще весь STL делали люди со значительным вывихом мозга. Так что чего там было ждать-то прямых решений? ;)

    Не скажи. Его делали очень умные люди, в первую очередь, Алекс Степанов. В его книжке «Начала программирования» (которая скорее, не про программирование, а про алгебру, кмк) на довольно глубоком уровне расписаны концепции итераторов.

    В то время как API коллекций в .NET, кажется, изначально развивалось как бог на душу положит, по-рабоче-крестьянски. Значительно позже появились правильные решения, дженерики, Linq, Rx, выведенные «учОными», а не «инженерАми».

    И вот тем не менее, в первом случае появилось малоюзабельное нечто, на что нельзя смотреть без содрогания после работы с более гуманными API.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[16]: Контейнеры
    От: Qbit86 Кипр
    Дата: 04.04.12 04:47
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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


    Предполагается, что в этом случае ты выведешь в строковый поток, а оттуда получишь строку и запихнёшь в TextBox.

    Но я по-прежнему не могу понять, чем вызов MyNamespace::operator <<(cout, point) принципиально лучше упомянутого вызова MyNamespace::print_point(point). Автор что-то недоговаривает.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[14]: Вектор
    От: Qbit86 Кипр
    Дата: 04.04.12 04:53
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ага, как я и думал. В начале много громких слов, а когда переходим к конкретике, то пшик.


    Я дважды озвучил определение вектора, ты этого так и не понял. Вот тебе и «пшик».

    _>Угу, и в OpenGL тоже есть свои вектора.


    Да-да, я как раз хотел в качестве ещё одного примера упомянуть векторы из OpenGL, ты меня опередил.

    _>Только какое это имеет отношение к универсальным контейнерам C++?


    Наоборот, какое отношение имеют универсальные контейнеры C++ к тому, что принято называть векторами?

    _>Ооо, ну хорошо. Тогда давайте разберём что же подразумевается под понятием "список" в языках Лисп, Пролог, Хаскель. Ну это для начала. )))


    В Лиспе и Хаскеле под списком понимается отнюдь не двусвязный список с возможностью быстрой вставки в середину. Так-то.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[17]: Контейнеры
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 04.04.12 04:58
    Оценка:
    Здравствуйте, Qbit86, Вы писали:
    Q>Предполагается, что в этом случае ты выведешь в строковый поток, а оттуда получишь строку и запихнёшь в TextBox.
    Ну вот это мне кажется не лучшим способом разделения абстракций. То есть предположение, что "всё можно в поток", при этом "некоторые потоки можно превратить в строку" кажется мне более нелепым, чем предположение, что "всё можно превратить в строку", при этом "строку можно и в поток".
    Идеология плюсов явно отстала от времени. Потоки в плюсах в себе скрывают собственно Stream, Writer, и Formatter. То есть с точки зрения теории кристалла, они в лучшем случае могли бы подходить для сериализации, где вопросов форматирования и кодировок просто не встаёт. Но для неё они тоже плохо пригодны, т.к. зачем-то подразумевают текстовость представления.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[18]: Streams
    От: Qbit86 Кипр
    Дата: 04.04.12 05:08
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Ну вот это мне кажется не лучшим способом разделения абстракций. То есть предположение, что "всё можно в поток", при этом "некоторые потоки можно превратить в строку" кажется мне более нелепым, чем предположение, что "всё можно превратить в строку", при этом "строку можно и в поток".

    S>Идеология плюсов явно отстала от времени. Потоки в плюсах в себе скрывают собственно Stream, Writer, и Formatter. То есть с точки зрения теории кристалла, они в лучшем случае могли бы подходить для сериализации, где вопросов форматирования и кодировок просто не встаёт. Но для неё они тоже плохо пригодны, т.к. зачем-то подразумевают текстовость представления.

    Да вот я как раз примерно то же самое хотел при случае упомянуть. В .NET получение строкового представления объекта рассматривается в рамках более общего понятия «форматирование», куда входит ещё и парсинг, локали/культуры, etc. А «сериализация» — сама по себе, отдельные механизмы и подходы. «Потоки» (стримы) тоже есть, представляют из себя отдельную абстракцию (в том числе декораторы и адаптеры потоков). А в плюсах всё это попытались запихнуть в единое понятие «поток», с его модификаторами (манипуляторами), флагами, специфической обработкой ошибок, изменяемым состоянием, etc.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[18]: Контейнеры
    От: FR  
    Дата: 04.04.12 05:19
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    Q>>Предполагается, что в этом случае ты выведешь в строковый поток, а оттуда получишь строку и запихнёшь в TextBox.

    S>Ну вот это мне кажется не лучшим способом разделения абстракций. То есть предположение, что "всё можно в поток", при этом "некоторые потоки можно превратить в строку" кажется мне более нелепым, чем предположение, что "всё можно превратить в строку", при этом "строку можно и в поток".

    Ничего ни мешает TextBox'у быть потоком.
    Например в wxWidgets все контролы (для которых это имеет смысл) поддерживают operator<<.

    S>Идеология плюсов явно отстала от времени. Потоки в плюсах в себе скрывают собственно Stream, Writer, и Formatter. То есть с точки зрения теории кристалла, они в лучшем случае могли бы подходить для сериализации, где вопросов форматирования и кодировок просто не встаёт. Но для неё они тоже плохо пригодны, т.к. зачем-то подразумевают текстовость представления.


    Фигня, большой разницы между строкой и строковым потоком нет. Для некоторых применений удобно одно, для других другое.
    Re[19]: Streams
    От: FR  
    Дата: 04.04.12 05:27
    Оценка: +2
    Здравствуйте, Qbit86, Вы писали:

    Q>Да вот я как раз примерно то же самое хотел при случае упомянуть. В .NET получение строкового представления объекта рассматривается в рамках более общего понятия «форматирование», куда входит ещё и парсинг, локали/культуры, etc. А «сериализация» — сама по себе, отдельные механизмы и подходы. «Потоки» (стримы) тоже есть, представляют из себя отдельную абстракцию (в том числе декораторы и адаптеры потоков). А в плюсах всё это попытались запихнуть в единое понятие «поток», с его модификаторами (манипуляторами), флагами, специфической обработкой ошибок, изменяемым состоянием, etc.


    Согласен с тем что реализация паршивая. Но сама идея вывода в поток ничем ни хуже идеи вывода в строку.
    Re[19]: Контейнеры
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 04.04.12 05:30
    Оценка:
    Здравствуйте, FR, Вы писали:

    FR>Фигня, большой разницы между строкой и строковым потоком нет. Для некоторых применений удобно одно, для других другое.

    Ну, с моей точки зрения, разница — огромна. Одно дело иммутабельная строка, другое дело — строковый поток.
    Да, с идеологической точки зрения StringBuilder и TextWriter — примерно одно и то же.
    Тем не менее, все остальные аспекты, запиханные в плюсовые потоки, там точно лишние.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[12]: Чтобы вывихнуть мозги, их надо иметь ;)
    От: Erop Россия  
    Дата: 04.04.12 06:09
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    Q>Не скажи. Его делали очень умные люди, в первую очередь, Алекс Степанов.

    Дык у глупых-то отуда вывих мозга возьмётся?..

    Q>В его книжке «Начала программирования» (которая скорее, не про программирование, а про алгебру, кмк) на довольно глубоком уровне расписаны концепции итераторов.

    Беда тут ровно одна -- для программирования 99% кода это всё вляется переусложнением и вообще не надо

    Он, как бы, пытался угадать, какие сложные задачи классно поддержать в языке. От чего-то затеял разделять данные и алгоритмы (этакое ати-ООП), и в основу положил жёстко заданные последовательности.
    А на практике оказалось нужным уметь работать с наборами, а не с последовательностями (типа SQL зарулил степановский STL), и отказ от ООП тоже пошёл по другому пути...

    А С++ остался со всей этой не особо нужной алгеброй....

    Q>И вот тем не менее, в первом случае появилось малоюзабельное нечто, на что нельзя смотреть без содрогания после работы с более гуманными API.


    Дык вот о том и речь...
    Но у них был систематический просчёт и фейл закономерен. Если хочешь получить что-то юзабельное -- надо идти ОТ ЗАДАЧ, а не от математических красот...

    Правда я не думаю, что Степанов хотел юзабельное. IMHO, он хотел не юзабельности, а славы
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[16]: Контейнеры
    От: SleepyDrago Украина  
    Дата: 04.04.12 09:33
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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


    SD>>добровольно выбираете 2е зная что это нужно каждые 50 строк ? Я чесслово не смог бы лучше за вас описать насколько это эпик.

    SD>>А геометрия она бывает не только из чисел. Вот например 2d грань это 2 точки и направление
    S>Не очень понятно ваше желание выводить точки исключительно в поток. А если вам потребуется их не логгировать, а, скажем, в TextBox записывать?
    S>Безотносительно к наличию в языке потоков достаточно реализовать метод .toString(), который решит все проблемы форматирования точки раз и навсегда.
    мне тут выше 3 раза напоминали что форматировать надо уметь по разному. Так что метод внутри класса это не удобно.
    На практике я не настаиваю на вывод в поток так как у нас строка выглядит и ведет себя как поток так что мне не важно
    Re: Google code style
    От: minorlogic Украина  
    Дата: 04.04.12 10:04
    Оценка:
    Здравствуйте, <Аноним>, Вы писали:

    А>А что Вы думаете по этому поводу?


    Согласен что пунк неоднозначный.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
    Ищу работу, 3D, SLAM, computer graphics/vision.
    Re[2]: Google code style
    От: minorlogic Украина  
    Дата: 04.04.12 10:08
    Оценка:
    Здравствуйте, Pzz, Вы писали:

    Pzz>Эта интуитивная понятность кончается, когда хочется вписать результат форматирования в поле определенной ширины, или вывести число с определенной точностью — то, что в printf'е как раз делается просто и естественно.


    Вопрос привычки
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
    Ищу работу, 3D, SLAM, computer graphics/vision.
    Re[11]: Контейнеры, комментарий Страуструпа
    От: B0FEE664  
    Дата: 04.04.12 11:21
    Оценка:
    Здравствуйте, Erop, Вы писали:

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


    BFE>>

    BFE>>Кто-нибудь может сказать, что valarray следовало бы назвать vector(вектор), поскольку он является традиционным математическим вектором, а vector следовало бы назвать array(массив), однако терминология развивалась иначе. valarray — это вектор, оптимизированный для численных расчётов, а vector — это гибкий контейнер разработанный для хранения объектов различного типа и манипулирования с ними, массив же — это низкоуровневый встроенный тип.

    BFE>> Бьерн Страуструп

    E>IMHO, это только доказывает, что "терминология развивалась" неудачно...

    Я думаю, что если посмотреть английский вариант, то станет понятнее, почему vector это не array, который int array[32];

    Впрочем, исторические причины очень сильны в C++.
    И каждый день — без права на ошибку...
    Re[12]: Контейнеры, комментарий Страуструпа
    От: Qbit86 Кипр
    Дата: 04.04.12 11:37
    Оценка:
    Здравствуйте, B0FEE664, Вы писали:

    BFE>Я думаю, что если посмотреть английский вариант, то станет понятнее, почему vector это не array, который int array[32];


    Я не очень понял про «array, который int array[32];», и почему это не помешало ввести std::array<int, 32>.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[13]: Контейнеры, комментарий Страуструпа
    От: B0FEE664  
    Дата: 04.04.12 11:49
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    BFE>>Я думаю, что если посмотреть английский вариант, то станет понятнее, почему vector это не array, который int array[32];

    Q>Я не очень понял про «array, который int array[32];», и почему это не помешало ввести std::array<int, 32>.

    Признаю, пожалуй это я "погорячился".
    И каждый день — без права на ошибку...
    Re[12]: Контейнеры, комментарий Страуструпа
    От: Erop Россия  
    Дата: 04.04.12 12:35
    Оценка: :)
    Здравствуйте, B0FEE664, Вы писали:

    E>>IMHO, это только доказывает, что "терминология развивалась" неудачно...

    BFE>Я думаю, что если посмотреть английский вариант, то станет понятнее, почему vector это не array, который int array[32];
    IMHO, он таков потому, что так захотелось г-ну Степанову

    BFE>Впрочем, исторические причины очень сильны в C++.

    Интересно, рад ли Степанов, когда его так обызывают?

    Я так думаю, что беда рийдёт откуда не ждали. Вот засунут дотнет в винапи, и появится оттуда доступ к коллекциям и прочим разным линкам, тут-то к STL и прийдёт одна северная лиса знакомиться
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re: Google code style
    От: quwy  
    Дата: 04.04.12 13:31
    Оценка:
    Не понимаю, а почему на RSDN не обсуждаются конвенции/нотации, принятые в урюпинской шаражке по внедрению пиратской 1С? Какая разница?
    Re[15]: Вектор
    От: alex_public  
    Дата: 04.04.12 14:03
    Оценка:
    Здравствуйте, Ops, Вы писали:

    Ops>Для начала лучше вспомнить, что называли списком, например, Дейкстра или Вирт. Неожиданно оказывается, что это 1 или 2-связный интрузивный список, а никак не список покупок.


    Я как раз к этому и вел с самого начала. )))
    Re[15]: Вектор
    От: alex_public  
    Дата: 04.04.12 14:08
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Я дважды озвучил определение вектора, ты этого так и не понял. Вот тебе и «пшик».


    Аааа, это всё что смог сказать по этой теме? ))) Я то надеялся что не всё так запущено и просто до сих пор мнёшься с ответом. Мда, печальная картина.

    Q>Наоборот, какое отношение имеют универсальные контейнеры C++ к тому, что принято называть векторами?


    Ну как бы в этой теме мы обсуждаем C++. Поэтому вполне логичен мой вопрос, а не обратный к нему.

    Q>В Лиспе и Хаскеле под списком понимается отнюдь не двусвязный список с возможностью быстрой вставки в середину. Так-то.


    Двусвязный или односвязнный — это детали реализации. Их важно знать при использование, но они не влияют на внешний интерфейс.

    В данном случае ключевым параметром является возможность доступа по индексу. Как у "списка покупок". Так вот как у нас с этим у тех структур, которые изначально называли списками в мире программирования?
    Re[13]: Чтобы вывихнуть мозги, их надо иметь ;)
    От: alex_public  
    Дата: 04.04.12 14:16
    Оценка:
    Здравствуйте, Erop, Вы писали:

    E>Он, как бы, пытался угадать, какие сложные задачи классно поддержать в языке. От чего-то затеял разделять данные и алгоритмы (этакое ати-ООП), и в основу положил жёстко заданные последовательности.

    E>А на практике оказалось нужным уметь работать с наборами, а не с последовательностями (типа SQL зарулил степановский STL), и отказ от ООП тоже пошёл по другому пути...

    E>А С++ остался со всей этой не особо нужной алгеброй....


    Я вижу немного другое. Он пошёл в сторону функциональных принципов. И кстати как раз сейчас эти принципы переживают новый расцвет. А с учётом появления лямбд в языке всё становится совсем интересно.

    Но если писать код в строго императивном стиле, то тогда некоторые подходы STL конечно сомнительны.

    E>Дык вот о том и речь...

    E>Но у них был систематический просчёт и фейл закономерен. Если хочешь получить что-то юзабельное -- надо идти ОТ ЗАДАЧ, а не от математических красот...

    А где фейл то? ) Библиотека стала частью стандарта языка. Всем бы такой фейл. )))

    Кстати, сейчас с Бустом происходит тоже самое частями.
    Re[13]: Контейнеры, комментарий Страуструпа
    От: alex_public  
    Дата: 04.04.12 14:20
    Оценка:
    Здравствуйте, Erop, Вы писали:

    E>Я так думаю, что беда рийдёт откуда не ждали. Вот засунут дотнет в винапи, и появится оттуда доступ к коллекциям и прочим разным линкам, тут-то к STL и прийдёт одна северная лиса знакомиться


    Это которое через COM будет? )
    Re[16]: std::first_rank_tensor
    От: Qbit86 Кипр
    Дата: 04.04.12 14:27
    Оценка: -1 :))
    Здравствуйте, alex_public, Вы писали:

    Q>>Я дважды озвучил определение вектора, ты этого так и не понял. Вот тебе и «пшик».

    _>Аааа, это всё что смог сказать по этой теме?

    По этой теме я сказал достаточно. Умному достаточно.

    _>))) Я то надеялся что не всё так запущено и просто до сих пор мнёшься с ответом. Мда, печальная картина.


    Конечно, печальная. Ты смотришь, как баран на новые ворота, на понятие «векторное пространство», и оно тебе ни о чём не говорит.

    Q>>Наоборот, какое отношение имеют универсальные контейнеры C++ к тому, что принято называть векторами?

    _>Ну как бы в этой теме мы обсуждаем C++. Поэтому вполне логичен мой вопрос, а не обратный к нему.

    Ну и почему индексируемый динамический контейнер в C++ называется «вектор», а не, скажем, «тензор первого ранга»?

    _>В данном случае ключевым параметром является возможность доступа по индексу. Как у "списка покупок". ;) Так вот как у нас с этим у тех структур, которые изначально называли списками в мире программирования?


    Вот, например, что по этому поводу думает Википедия: «На практике линейные списки обычно реализуются при помощи массивов и связных списков... В зависимости от реализации может быть возможен произвольный доступ к элементам списка.»

    Оттуда же то, о чём говоришь ты: «Иногда термин «список» неформально используется также как синоним понятия «связный список».» Заметь, «иногда», а не обычно или изначально. Классическая книга по алгоритмам Кормена и других это подтверждает. Вирта под рукой нет.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[17]: std::first_rank_tensor
    От: Ops Россия  
    Дата: 04.04.12 14:47
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Вот, например, что по этому поводу думает Википедия: «На практике линейные списки обычно реализуются при помощи массивов и связных списков... В зависимости от реализации может быть возможен произвольный доступ к элементам списка.»


    Q>Оттуда же то, о чём говоришь ты: «Иногда термин «список» неформально используется также как синоним понятия «связный список».» Заметь, «иногда», а не обычно или изначально. Классическая книга по алгоритмам Кормена и других это подтверждает. Вирта под рукой нет.


    А про вектор википедия говорит, что в программировании это одномерный массив.
    Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
    Re[14]: Чтобы вывихнуть мозги, их надо иметь ;)
    От: Erop Россия  
    Дата: 04.04.12 15:01
    Оценка: 3 (2)
    Здравствуйте, alex_public, Вы писали:

    _>Я вижу немного другое. Он пошёл в сторону функциональных принципов. И кстати как раз сейчас эти принципы переживают новый расцвет. А с учётом появления лямбд в языке всё становится совсем интересно.


    Да не особо-то оно интересно, без GC...
    А с GC -- это не совсем С++

    Ну и вообще, криво всё это получилось и сложно...

    _>А где фейл то? ) Библиотека стала частью стандарта языка. Всем бы такой фейл. )))

    Ну она убога. И нуждается в костылях, см. буст

    _>Кстати, сейчас с Бустом происходит тоже самое частями.

    Вот-вот. На чистом STL вообще жить нельзя, пришлось притащить ещё кое-чего из буста + десятьлет пилить компиляторы на тему скорости компиляциии шаблонов + добавить в язык кучу всякой фигни, вроде лямбд, которые всё равно получились не до конца юзабельными, и auto, чтобы как-то заткнуть проблемы STL...

    В принципе это сейчас модно. Вот гуглы компилятор JS залудили, комитет STL пытается выпрямить, рихтуя сам C++...

    Но в целом это всё очень сложные решения. Ясно, что есть унаследованный код, совместимость и всё такое, но считать этот путь хоть сколько-нибудь удобным, хорошим и оправданным?
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[14]: Контейнеры, комментарий Страуструпа
    От: Erop Россия  
    Дата: 04.04.12 15:02
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Это которое через COM будет? )

    В смысле "через COM"?
    Прикрутят поддержку в компилятор прозрачную и всё...
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[17]: std::first_rank_tensor
    От: night beast СССР  
    Дата: 04.04.12 15:07
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Оттуда же то, о чём говоришь ты: «Иногда термин «список» неформально используется также как синоним понятия «связный список».» Заметь, «иногда», а не обычно или изначально. Классическая книга по алгоритмам Кормена и других это подтверждает. Вирта под рукой нет.


    А можно подробнее, что конкретно подтверждает Классическая книга по алгоритмам Кормена?
    Re[18]: std::first_rank_tensor
    От: Qbit86 Кипр
    Дата: 04.04.12 15:09
    Оценка:
    Здравствуйте, Ops, Вы писали:

    Ops>А про вектор википедия говорит, что в программировании это одномерный массив.


    ...И в качестве примера приводит std::vector в C++. То есть да, со времён форсинга этого термина путём набравшего популярность C++ вектор неизбежно стал ассоциироваться с одномерным массивом. В Джаве даже, по-моему, тоже что-то такое есть. А если бы его таки назвали std::first_rank_tensor, то alex_public мне сейчас доказывал бы, что это рационально и естественно, и всегда так было.

    И даже если «в программировании» оно и до C++ так было, это ещё не значит, что это название естественное и здравое.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[18]: Связный список
    От: Qbit86 Кипр
    Дата: 04.04.12 15:11
    Оценка:
    Здравствуйте, night beast, Вы писали:

    NB>А можно подробнее, что конкретно подтверждает Классическая книга по алгоритмам Кормена?


    Использует термин «связный список», а не «список».
    Глаза у меня добрые, но рубашка — смирительная!
    Re[17]: std::first_rank_tensor
    От: alex_public  
    Дата: 04.04.12 15:19
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Ну и почему индексируемый динамический контейнер в C++ называется «вектор», а не, скажем, «тензор первого ранга»?


    Потому что тензор обладает определёнными свойствами при преобразовании системы координат. В отличие от например произвольной матрицы. Если мы определим для контейнера соответствующие преобразования (что будет довольно странно ), то можно и назвать тензором. А так, одномерный контейнер — вектор, двухмерный — матрица (а не тензор 2-го ранга ). Кстати, матрицы есть в Бусте.

    Q>Вот, например, что по этому поводу думает Википедия: «На практике линейные списки обычно реализуются при помощи массивов и связных списков... В зависимости от реализации может быть возможен произвольный доступ к элементам списка.»


    Хы, так я могу вообще к любому списку организовать функцию доступа по индексу. Итерируемся нужное количество раз и возвращаем результат. Только как бы зачем нам тогда список? )

    Q>Оттуда же то, о чём говоришь ты: «Иногда термин «список» неформально используется также как синоним понятия «связный список».» Заметь, «иногда», а не обычно или изначально. Классическая книга по алгоритмам Кормена и других это подтверждает. Вирта под рукой нет.


    Особенно забавно становится если щёлкнуть в твоей ссылке из вики на английский вариант статьи.
    Re[15]: Контейнеры, комментарий Страуструпа
    От: alex_public  
    Дата: 04.04.12 15:22
    Оценка:
    Здравствуйте, Erop, Вы писали:

    _>>Это которое через COM будет? )

    E>В смысле "через COM"?
    E>Прикрутят поддержку в компилятор прозрачную и всё...

    Эээ, не слышал про такие планы. Где можно про это посмотреть?

    Хотя всё равно вряд ли буду использовать — всё же кроссплатформенность и всё такое... Но самое по себе в любом случае интересно.
    Re[16]: WinRT
    От: Qbit86 Кипр
    Дата: 04.04.12 15:28
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    E>>...Вот засунут дотнет в винапи, и появится оттуда доступ к коллекциям и прочим разным линкам...

    _>Эээ, не слышал про такие планы. Где можно про это посмотреть?

    Вероятно, имелось в виду WinRT.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[19]: Связный список
    От: night beast СССР  
    Дата: 04.04.12 15:39
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    NB>>А можно подробнее, что конкретно подтверждает Классическая книга по алгоритмам Кормена?


    Q>Использует термин «связный список», а не «список».


    Это, конечно, аргумент.
    А если в исходниках посмотреть?
    Re[18]: std::first_rank_tensor
    От: Qbit86 Кипр
    Дата: 04.04.12 15:43
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Потому что тензор обладает определёнными свойствами при преобразовании системы координат.


    Верно! Так и у алгебраического вектора есть ожидаемые свойства. Скажем, я могу сложить два вектора. Или посчитать длину, в предположении, что на векторном пространстве ведена (как правило, евклидова норма), etc. А уменьшить арность не могу, соответственно, не нужно рантайм-проверок числа компонент. И сортировать по возрастанию координаты вектора (при отождествлении с R^n) операция малоосмысленная. Etc, etc, etc.

    Q>>В зависимости от реализации может быть возможен произвольный доступ к элементам списка.»

    _>Хы, так я могу вообще к любому списку организовать функцию доступа по индексу. Итерируемся нужное количество раз и возвращаем результат. Только как бы зачем нам тогда список? )

    У списка, реализованного через массив, будет константный доступ и линейная вставка; у списка, реализованного как связный список — наоборот.

    _>Особенно забавно становится если щёлкнуть в твоей ссылке из вики на английский вариант статьи. :)))


    Ну да. Оказывается, статья об обсуждаемой структуре данных называется «linked list», а не просто «list».
    Глаза у меня добрые, но рубашка — смирительная!
    Re[19]: std::first_rank_tensor
    От: Ops Россия  
    Дата: 04.04.12 15:50
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Ops>>А про вектор википедия говорит, что в программировании это одномерный массив.


    Q>...И в качестве примера приводит std::vector в C++. То есть да, со времён форсинга этого термина путём набравшего популярность C++ вектор неизбежно стал ассоциироваться с одномерным массивом. В Джаве даже, по-моему, тоже что-то такое есть. А если бы его таки назвали std::first_rank_tensor, то alex_public мне сейчас доказывал бы, что это рационально и естественно, и всегда так было.


    Так что, оставляем википедию как аргумент в этом споре, или на помоечку? А то диссонанс какой-то

    Q>И даже если «в программировании» оно и до C++ так было, это ещё не значит, что это название естественное и здравое.


    Да просто исторически так сложилось, а потом поперли новые языки со своими трактованиями терминов, и это неправильно, иначе бы этот спор на пустом месте не возник.
    Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
    Re[20]: std::first_rank_tensor
    От: Qbit86 Кипр
    Дата: 04.04.12 15:57
    Оценка: +1
    Здравствуйте, Ops, Вы писали:

    Ops>Так что, оставляем википедию как аргумент в этом споре, или на помоечку? А то диссонанс какой-то :shuffle:


    Википедия во фразе «Вектор в программировании — одномерный массив. Vector (C++) — это шаблон из стандартной библиотеки C++, реализующий динамический массив (контейнер std::vector в C++)» отражает текущее состояние дел постфактум, а не естественность такой терминологии. Странная логика — говорить, что «вектор» как динамически расширяемый массив — нормально, потому что вот, например, так сделано в C++. В то время как логичность этого в C++ как раз и оспаривается.

    Ops>Да просто исторически так сложилось, а потом поперли новые языки со своими трактованиями терминов, и это неправильно, иначе бы этот спор на пустом месте не возник.


    Да, я тоже считаю, что не нужно было C++ поддерживать левую трактовку устоявшегося на тот момент в математике (в течение многих десятилетий) термина.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[13]: Контейнеры, комментарий Страуструпа
    От: night beast СССР  
    Дата: 04.04.12 16:06
    Оценка:
    Здравствуйте, Erop, Вы писали:

    E>Я так думаю, что беда рийдёт откуда не ждали. Вот засунут дотнет в винапи, и появится оттуда доступ к коллекциям и прочим разным линкам, тут-то к STL и прийдёт одна северная лиса знакомиться


    ага, вместе с унихами и всяким ембедед.
    Re[21]: std::first_rank_tensor
    От: Ops Россия  
    Дата: 04.04.12 16:18
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

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


    Ops>>Так что, оставляем википедию как аргумент в этом споре, или на помоечку? А то диссонанс какой-то


    Q>Википедия во фразе «Вектор в программировании — одномерный массив. Vector (C++) — это шаблон из стандартной библиотеки C++, реализующий динамический массив (контейнер std::vector в C++)» отражает текущее состояние дел постфактум, а не естественность такой терминологии. Странная логика — говорить, что «вектор» как динамически расширяемый массив — нормально, потому что вот, например, так сделано в C++. В то время как логичность этого в C++ как раз и оспаривается.


    Оспаривать надо было когда стандарт обсуждали, если это так принципиально. Сейчас или принимать как есть, или писать в спортлото/на форумы/президенту.

    Ops>>Да просто исторически так сложилось, а потом поперли новые языки со своими трактованиями терминов, и это неправильно, иначе бы этот спор на пустом месте не возник.


    Q>Да, я тоже считаю, что не нужно было C++ поддерживать левую трактовку устоявшегося на тот момент в математике (в течение многих десятилетий) термина.


    Вообще-то я про списки, ну да ладно, смысла спорить я не вижу.
    Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
    Re[16]: Контейнеры, комментарий Страуструпа
    От: Erop Россия  
    Дата: 04.04.12 16:42
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Эээ, не слышал про такие планы. Где можно про это посмотреть?

    Ну от http://blogs.msdn.com/b/rusaraford/archive/2012/03/30/10289527.aspx через http://msdn.microsoft.com/en-us/library/windows/apps/hh441569(v=vs.110).aspx и до упора...

    MS вроде как обещали плюшек тем, кто отзовётся на их "Welcome Back to C++ (Modern C++)"...
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[14]: Контейнеры, комментарий Страуструпа
    От: Erop Россия  
    Дата: 04.04.12 16:43
    Оценка:
    Здравствуйте, night beast, Вы писали:

    NB>ага, вместе с унихами и всяким ембедед.

    Запортят.
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[15]: Контейнеры, комментарий Страуструпа
    От: night beast СССР  
    Дата: 04.04.12 17:25
    Оценка:
    Здравствуйте, Erop, Вы писали:

    NB>>ага, вместе с унихами и всяким ембедед.

    E>Запортят.

    кто? микрософт? вряд ли.
    а посторонним не дадут.
    Re[3]: Google code style
    От: Трололоша  
    Дата: 04.04.12 17:43
    Оценка: +1
    Здравствуйте, YourLastSong, Вы писали:

    YLS>Но разве этого достаточно, чтобы говорить, что потоки C++ стоит использовать разве что для логов?

    Честно говоря этого достаточно чтоб их и для логов не использовать тоже.
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[3]: Google code style
    От: Трололоша  
    Дата: 04.04.12 17:43
    Оценка:
    Здравствуйте, __kot2, Вы писали:

    __>если кто-то до сих пор продолжает использовать printf вместо потоков, он не понимает философии С++ и ему вообще писать на нем не следует. а тем более делать какие-то там стандарты С++ кода


    С появлением variadic templates printf-like функциональность легко и просто делается в typesafe виде.
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[5]: Google code style
    От: Трололоша  
    Дата: 04.04.12 17:43
    Оценка:
    Здравствуйте, __kot2, Вы писали:

    N>>Может, Вам стоит задуматься о том, что это не весь окружающий мир шагает не в ногу, а это Вы с iostream шагаете не в ногу?

    __>может и мне стоить бросить это программирование и идти собирать бутылки?
    Хм. Интересная мысль
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[8]: Контейнеры
    От: Трололоша  
    Дата: 04.04.12 17:43
    Оценка: +1
    Здравствуйте, Qbit86, Вы писали:

    Q>list'ом называется не абстрактный тип данных cписок, а структура данных односвязный список.

    Двунаправленный.

    Q>vector'ом называется не кортеж фиксированного числа элементов с операциями типа евклидова длина или скалярное произведение, а динамически расширяемый массив.

    Это и в самом деле непонятно почему так назвали.
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[13]: Контейнеры
    От: Трололоша  
    Дата: 04.04.12 17:43
    Оценка: +1
    Здравствуйте, Qbit86, Вы писали:

    Q>Но про std::map помню, что в основе студийной реализации — красно-чёрное дерево.

    Самое прикольное что по стандарту там может быть как RB так и AVL или ещё какой нить вариант дерева. Лишь бы удовлетворял требованиям.
    Т.е. реализация стандартом не фиксирована.
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[16]: Контейнеры, комментарий Страуструпа
    От: Erop Россия  
    Дата: 04.04.12 17:56
    Оценка:
    Здравствуйте, night beast, Вы писали:

    E>>Запортят.

    NB>а посторонним не дадут.
    Интересно, как?
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[17]: Контейнеры, комментарий Страуструпа
    От: night beast СССР  
    Дата: 04.04.12 18:02
    Оценка:
    Здравствуйте, Erop, Вы писали:

    E>>>Запортят.

    NB>>а посторонним не дадут.
    E>Интересно, как?

    я за нетом не слежу, но нет же в моно WPF?
    ну да поживем, увидим. пока рано о чем-то говорить.
    Re[18]: Контейнеры, комментарий Страуструпа
    От: Erop Россия  
    Дата: 04.04.12 18:07
    Оценка:
    Здравствуйте, night beast, Вы писали:

    NB>я за нетом не слежу, но нет же в моно WPF?

    Ну 4.5 нет они же когда-нибудь, да поддержат?

    NB>ну да поживем, увидим. пока рано о чем-то говорить.

    Ну да.
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[20]: std::first_rank_tensor
    От: Erop Россия  
    Дата: 04.04.12 18:11
    Оценка:
    Здравствуйте, Ops, Вы писали:

    Q>>И даже если «в программировании» оно и до C++ так было, это ещё не значит, что это название естественное и здравое.


    Ops>Да просто исторически так сложилось, а потом поперли новые языки со своими трактованиями терминов, и это неправильно, иначе бы этот спор на пустом месте не возник.


    Не-не-не. Исторически оно сложилось, как ARRAY[1..5[ OF...
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[19]: std::first_rank_tensor
    От: alex_public  
    Дата: 04.04.12 18:47
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Верно! Так и у алгебраического вектора есть ожидаемые свойства. Скажем, я могу сложить два вектора. Или посчитать длину, в предположении, что на векторном пространстве ведена (как правило, евклидова норма), etc. А уменьшить арность не могу, соответственно, не нужно рантайм-проверок числа компонент. И сортировать по возрастанию координаты вектора (при отождествлении с R^n) операция малоосмысленная. Etc, etc, etc.


    А причём тут алгебраический вектор? Вы бы ещё геометрическую интерпритацию вектора привлекли...

    Вектором значений часто называют произвольный кортеж элементов. И кстати не только в программирование. Например математические понятия вектор-столбец или вектор-строка очень близки по смыслу к массивам программистским.

    Ну и напоследок, раз уж мы докатились до википедии: http://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%BA%D1%82%D0%BE%D1%80_(%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0)#.D0.92.D0.B5.D0.BA.D1.82.D0.BE.D1.80_.D0.BA.D0.B0.D0.BA_.D0.BF.D0.BE.D1.81.D0.BB.D0.B5.D0.B4.D0.BE.D0.B2.D0.B0.D1.82.D0.B5.D0.BB.D1.8C.D0.BD.D0.BE.D1.81.D1.82.D1.8C
    Re[17]: WinRT
    От: alex_public  
    Дата: 04.04.12 18:49
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Вероятно, имелось в виду WinRT.


    Так оно же вроде через COM. Или я что-то путаю? Я сам не копался ещё в win8 и VS11, но читал что winrt реализовано через COM.
    Re[17]: Контейнеры, комментарий Страуструпа
    От: alex_public  
    Дата: 04.04.12 18:58
    Оценка:
    Здравствуйте, Erop, Вы писали:

    E>Ну от http://blogs.msdn.com/b/rusaraford/archive/2012/03/30/10289527.aspx через http://msdn.microsoft.com/en-us/library/windows/apps/hh441569(v=vs.110).aspx и до упора...


    Ну так а там разве не COM? Хотя реализации не видно, но HRESULT как бы намекает... )

    E>MS вроде как обещали плюшек тем, кто отзовётся на их "Welcome Back to C++ (Modern C++)<br />
    <span class='lineQuote level1'>E&gt;</span>
    "...


    Это совсем другое дело... Там не про winrt а про модный современный C++. Это очень правильно. )
    Re[18]: Контейнеры, комментарий Страуструпа
    От: Erop Россия  
    Дата: 04.04.12 19:07
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ну так а там разве не COM? Хотя реализации не видно, но HRESULT как бы намекает... )


    Если мы про winrt, то там есть array байт, например, который без всякого сома обходится...

    Ну да фиг бы с ними всеми, я же говорил не про нынешнее положение дел, а про то, что если оно и дальше пойдёт, как идёт, MS сделают на С++ такую же удобную и продвинутую среду для разработки приложений, как из дотнета сделали. Ну чисто чтобы заманить разрабов на метро своё, или на какое-нибудь ещё шметро, которое они потом тоже замутят.

    АРI системы они объектным уже сделали, сделают то, что должно быть быстрым в нём шаблонным, и привет. Просто сам по себе WinRT или какой-нибудь WinRT++ вдруг будет давать программисту готовые строчки, коллекции, ввод/вывод и т. д.
    И всё это будет бесшовно интегрированно в С++. Ну и все призадумаются, точно ли им нужен STL при таком раскладе
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[19]: Контейнеры, комментарий Страуструпа
    От: alex_public  
    Дата: 04.04.12 21:41
    Оценка:
    Здравствуйте, Erop, Вы писали:

    E>Если мы про winrt, то там есть array байт, например, который без всякого сома обходится...


    Ну я же говорю, что сам не смотрел, но читал где-то, что все обращения к winrt идут через com. А если это так (надо бы всё же взглянуть на доки), то тут уже совсем другая ситуация. Если для каких-то сложных функций ОС это приемлемо, то для контейнеров языка (а тем более такого как C++) это уже ненормально.

    E>Ну да фиг бы с ними всеми, я же говорил не про нынешнее положение дел, а про то, что если оно и дальше пойдёт, как идёт, MS сделают на С++ такую же удобную и продвинутую среду для разработки приложений, как из дотнета сделали. Ну чисто чтобы заманить разрабов на метро своё, или на какое-нибудь ещё шметро, которое они потом тоже замутят.


    Ну собственно к 2000-му году они уже были явными лидерами по средствам разработки для C++. Потом немного запустили это дело, увлёкшись дотнетом, а сейчас пытаются вернуться. Только не знаю получится ли. С одной стороны у них для этого все потенциальные ресурсы есть. А с другой они всегда делали средства специфичные для своей платформы, а в последние годы (и в том числе благодаря ослаблению MS тут) многие программисты успешно перешли на кроссплатформенные инструменты и заманить их обратно будет очень проблематично. Надо будет или предоставить что-то наголову выше всей индустрии (сомнительно) или перейти к кроссплатформенным инструментам (не помню у них такого ни разу)...

    E>АРI системы они объектным уже сделали, сделают то, что должно быть быстрым в нём шаблонным, и привет. Просто сам по себе WinRT или какой-нибудь WinRT++ вдруг будет давать программисту готовые строчки, коллекции, ввод/вывод и т. д.

    E>И всё это будет бесшовно интегрированно в С++. Ну и все призадумаются, точно ли им нужен STL при таком раскладе

    Мммм а можно пример на котором видно что коллекции из .Net заметно удобнее STL? )
    Re: Google code style
    От: trophim Россия  
    Дата: 04.04.12 21:54
    Оценка:
    Нас спасет http://www.fastformat.org/
    P.S. И, да, он таки быстрее буста. И безопасное форматирование есть. Песня. 8-)
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
    Let it be! — Давайте есть пчелу!
    Re[20]: Контейнеры, комментарий Страуструпа
    От: Erop Россия  
    Дата: 04.04.12 21:56
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ну я же говорю, что сам не смотрел, но читал где-то, что все обращения к winrt идут через com. А если это так (надо бы всё же взглянуть на доки), то тут уже совсем другая ситуация. Если для каких-то сложных функций ОС это приемлемо, то для контейнеров языка (а тем более такого как C++) это уже ненормально.



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

    _>или перейти к кроссплатформенным инструментам (не помню у них такого ни разу)...

    Если метро + их апстор взлетят, то все тихо и мирно вернуться на винду и всё. В смысле все разрабы, ну просто большинству будет ничего не надо больше.

    E>>И всё это будет бесшовно интегрированно в С++. Ну и все призадумаются, точно ли им нужен STL при таком раскладе


    _>Мммм а можно пример на котором видно что коллекции из .Net заметно удобнее STL? )


    Ну конкретно .Net контейнеры в С++ неудобны, потому, что им нужен GC. Или, наоборот, удобны...
    Но, например, std::string -- малоюзабелен. Если появится удобная и стандартная, хотя бы на винде С++ строка, то это будет концом std::basic_string. Та же фигня с потоками, ну и далее по списку
    Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
    Re[17]: Контейнеры
    От: Трололоша  
    Дата: 04.04.12 23:39
    Оценка: :)
    Здравствуйте, Qbit86, Вы писали:

    Q>Предполагается, что в этом случае ты выведешь в строковый поток, а оттуда получишь строку и запихнёшь в TextBox.

    А зубную щётку надо засунуть в задницу, а потом вынуть и начать чистить зубы?
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[4]: Google code style
    От: Трололоша  
    Дата: 04.04.12 23:39
    Оценка:
    Здравствуйте, Marty, Вы писали:

    M>С printf единственная проблема — небезопасная передача параметров и отсутствие контроля типов.

    M>Вот сделали бы что-то типа

    M>
    M>std::string  printf( const std::string &format , const std::vector<Variant> &args );
    M>std::wstring printf( const std::wstring &format, const std::vector<Variant> &args );
    M>

    M>и было бы счастье.

    Уже давно лёхким движением руки пишется цаца наподобие такой:

    template <class... Args> string Format (const char* mask, const Args&... args) ...

    Которой плевать на то, что число параметров не совпадает с форматной строкой, которой плевать что в %s передаётся double (выведет как будто было написано %f) или в %i передаётся std::wstring (выведет заглушку про invalid type).
    Единственное к чему уязвима, это если в %s передать char* который указывает на мусор. Впрочем можно просто запретить принимать тип char* — тогда просто не соберётся если передать его.
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[8]: Google code style
    От: Трололоша  
    Дата: 04.04.12 23:39
    Оценка:
    Здравствуйте, GreyMan, Вы писали:

    M>>>Язык мог бы помочь, если бы элипсис преобразовывался к какому-то более-менее типизированному хранилищу.

    GM>std::initializer_list вместе с собственным лисапедом?

    Нафига геморроиться, есть жеж нормальные variadic templates
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[7]: Google code style
    От: Трололоша  
    Дата: 04.04.12 23:39
    Оценка:
    Здравствуйте, Marty, Вы писали:

    M>Мне бы

    _>>удобное, безопасное — printf
    M>можно сделать?

    В С++0х лехко
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[4]: Google code style
    От: Трололоша  
    Дата: 04.04.12 23:39
    Оценка:
    Здравствуйте, Marty, Вы писали:

    M>Будет типобезопасный форматный вывод в printf — хм, Nemerle (да и все остальное) не нужен.

    Уже реализуем без проблем.
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[21]: Контейнеры, комментарий Страуструпа
    От: alex_public  
    Дата: 05.04.12 00:02
    Оценка:
    Здравствуйте, Erop, Вы писали:

    E>Ну так контейнеры же нужны и для самого API. Ну там массив чего-нибудь вернуть, например...


    Ааа, понял. Но только тогда это формально говоря не будет иметь отношения к winrt. Это просто будет ещё одна стандартная библиотека C++ в поставке VC, интерфейс у которой будет совпадать с .Net'им.

    Было бы интересно посмотреть на такое. Правда я пока нигде не слышал конкретно про такие планы MS...

    E>Если метро + их апстор взлетят, то все тихо и мирно вернуться на винду и всё. В смысле все разрабы, ну просто большинству будет ничего не надо больше.


    Вот как раз может не взлететь потому что требует несовместимости. Т.е. у нас сейчас условно говоря есть win7 отлично работающая, osx и зоопарк линуксов. И есть много достаточно развитых инструментов для работы на них всех сразу. Если win8 будет требовать уникальный код (а в варианте под metro так и выходит), то не факт что многие захотят переходить на неё и писать под неё софт. А сама по себе win8 может выигрывать у той же win7 только на планшетах, причём там она конкурирует не с osx и linux, а с android и iOS, у которых свои особенности в разработке.

    В общем когда Балмер сказал что win8 — это их самый рискованный шаг, то я думал что это для красоты сказано. Но увидив её в действие уже готов согласиться... )

    E>Ну конкретно .Net контейнеры в С++ неудобны, потому, что им нужен GC. Или, наоборот, удобны...


    Что-то я запутался в ваших оценках удобных контейнеров. ))) В начале сказали что вот появятся они в C++ и тут конец STL. А теперь и они неудобны...

    E>Но, например, std::string -- малоюзабелен. Если появится удобная и стандартная, хотя бы на винде С++ строка, то это будет концом std::basic_string. Та же фигня с потоками, ну и далее по списку


    Хы, строки это отдельная тема. Одна из самых больных для C++. ))) Собственно для строк многое из функциональности контейнеров вообще лишнее. Лично я предпочитаю использовать класс строк из обычно используемого фрейморка. Они там с кучей полезных именно строковых (а не контейнерных) функций и при этом прозрачно совместимы с std::string/std::wstring.
    Re[2]: Google code style
    От: Трололоша  
    Дата: 05.04.12 00:47
    Оценка: +1
    Здравствуйте, trophim, Вы писали:

    T>Нас спасет http://www.fastformat.org/

    T>P.S. И, да, он таки быстрее буста. И безопасное форматирование есть. Песня. 8-)

    Какой нереальный трындец.
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[18]: std::first_rank_tensor
    От: _d_m_  
    Дата: 05.04.12 03:00
    Оценка: 1 (1)
    Здравствуйте, Ops, Вы писали:

    Ops>А про вектор википедия говорит, что в программировании это одномерный массив.


    Ну такие же ландухи приплюснутые там и написали.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
    Re[18]: Контейнеры
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 05.04.12 05:51
    Оценка:
    Здравствуйте, Трололоша, Вы писали:

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


    Q>>Предполагается, что в этом случае ты выведешь в строковый поток, а оттуда получишь строку и запихнёшь в TextBox.

    Т>А зубную щётку надо засунуть в задницу, а потом вынуть и начать чистить зубы?

    Тебе по любому, чтобы передать строку в TextBox, надо её полностью сформировать.
    Так что твоя троллевая аналогия некорректна.
    The God is real, unless declared integer.
    Re[20]: Коллекции .NET и контейнеры STL
    От: Qbit86 Кипр
    Дата: 05.04.12 07:14
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Мммм а можно пример на котором видно что коллекции из .Net заметно удобнее STL? )


    Да в принципе любая задача на ФВП по работе с последовательностями — фильтрация, проекция, свёртка, группировка, сортировка. Напиши, например, на алгоритмах STL решение задачи:

    «В файле Numbers.txt содержатся строки, каждая из которых — последовательность целых чисел, разделённых запятыми.
    Для всех строк, в которых более двух чисел, перексорить содержащиеся в них числа.
    Вывести на экран отсортированную по убыванию последовательность результатов.»

    Пример исходных данных:
    19937,62,134
    42
    58,59,13373
    648,649
    3,14,15,92,6
    2,7,1828,1828

    Желательно бы без лямбд из C++11, т.к. не везде ещё поддерживаются.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[19]: Контейнеры
    От: Трололоша  
    Дата: 05.04.12 14:00
    Оценка: +1
    Здравствуйте, netch80, Вы писали:

    N>Так что твоя троллевая аналогия некорректна.

    Вполне корретна. Для формирования готовой зубной щётки достаточно держать её в руке, а не в заднице.
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[3]: Google code style
    От: avpavlov  
    Дата: 05.04.12 15:01
    Оценка:
    MZ>Кстати, те же джависты таки добавили в последней версии форматный вывод.
    MZ>6 кажется версий пыжились и тужились, но таки добавили.

    MessageFormat в Яве был всегда — ну ладно, как минимум с 1.3, которой 100 лет в обед. Он не являлся полным аналогом printf, потому что был заточен под многоязычную локализацию. В некоторых применениях он более удобен, чем printf.

    А вот уже 1.5 (которая тоже не вчера вышла) добавили полный аналог printf.
    Re[19]: std::first_rank_tensor
    От: Ops Россия  
    Дата: 05.04.12 15:20
    Оценка: +2
    Здравствуйте, _d_m_, Вы писали:

    Ops>>А про вектор википедия говорит, что в программировании это одномерный массив.


    ___>Ну такие же ландухи приплюснутые там и написали.


    Я вот не пойму, как можно аргументировать что-то статьей из википедии, и сразу же писать, что в википедии туфта?
    Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
    Re[21]: std::first_rank_tensor
    От: Ops Россия  
    Дата: 05.04.12 15:21
    Оценка:
    Здравствуйте, Erop, Вы писали:

    E>Не-не-не. Исторически оно сложилось, как ARRAY[1..5[ OF...


    Это про списки было, возможно, неверно сформулировал.
    Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
    Re[21]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 06.04.12 03:50
    Оценка: 2 (2)
    Здравствуйте, Qbit86, Вы писали:

    Q>Да в принципе любая задача на ФВП по работе с последовательностями — фильтрация, проекция, свёртка, группировка, сортировка.


    Что-то как-то сомнительно пока. Ну посмотрим сейчас.

    Q>Напиши, например, на алгоритмах STL решение задачи:

    Q>«В файле Numbers.txt содержатся строки, каждая из которых — последовательность целых чисел, разделённых запятыми.
    Q>Для всех строк, в которых более двух чисел, перексорить содержащиеся в них числа.
    Q>Вывести на экран отсортированную по убыванию последовательность результатов.»
    Q>Пример исходных данных:
    Q>19937,62,134
    Q>42
    Q>58,59,13373
    Q>648,649
    Q>3,14,15,92,6
    Q>2,7,1828,1828

    Хм, и что тут страшного появляется от использования std? Вроде как раз в несколько строк решение:

    #include <set>
    #include <numeric>
    #include <fstream>
    #include <iostream>
    #include <exception>
    #include <boost/tokenizer.hpp>
    #include <boost/lexical_cast.hpp>
    using namespace std;
    using boost::tokenizer; using boost::char_separator; using boost::lexical_cast;
    
    int main()
    {
        try{
            ifstream file("Numbers.txt");
            if(!file.is_open()) throw invalid_argument("Invalid filename 'Numbers.txt'");
            string row;
            set<int> result;
            while(getline(file, row)){
                tokenizer<char_separator<char>> numbers(row, char_separator<char>(","));
                result.insert(accumulate(numbers.begin(), numbers.end(), 0, [](int a, const string& n){return a^lexical_cast<int>(n);}));
            }
            for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;
        }catch(exception& e){
            cout<<"Error: "<<e.what()<<endl;
        }
        return 0;
    }


    Теперь давай вариант того же на .Net, посмотрим в чём преимущество. И кстати будет ещё интересно сравнить по быстродействию. Вот появится твой вариант, я его скомпилирую и натравлю оба на какой-нибудь приличный файлик (скажем 100 строк по 10000 случайных цифр). Посмотрим какие цифры по времени исполнения будут.

    Q>Желательно бы без лямбд из C++11, т.к. не везде ещё поддерживаются.


    Это где они сейчас не поддерживаются? У нас проекты компилируются сразу под windows (msvc), linux (gcc), osx (gcc). И нигде проблем нет с лямбдами (мы их уже используем). Вот range for в msvc до сих пор нет — это расстраивает, т.к. из-за этого не можем использовать такую приятную плюшку (вот прямо в коде выше она бы тоже пригодилась).
    Re[22]: Коллекции .NET и контейнеры STL
    От: Qbit86 Кипр
    Дата: 06.04.12 04:29
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Хм, и что тут страшного появляется от использования std?


    В предложенном решении не только контейнеры STL.

    _>Хм, и что тут страшного появляется от использования std?


    В отсутствии декларативности, наглядности, единообразия. Вроде как было упомянуто, что Степанов стремился к «функциональности» своей библиотеки — где она в предложенном решении проявляется?

    _>Вроде как раз в несколько строк решение:


    _>
    #include <set>
    _>#include <numeric>
    _>#include <fstream>
    _>#include <iostream>
    _>#include <exception>
    _>#include <boost/tokenizer.hpp>
    _>#include <boost/lexical_cast.hpp>
    _>using namespace std;
    _>using boost::tokenizer; using boost::char_separator; using boost::lexical_cast;
    
    _>int main()
    _>{
    _>    try{
    _>        ifstream file("Numbers.txt");
    _>        if(!file.is_open()) throw invalid_argument("Invalid filename 'Numbers.txt'");
    _>        string row;
    _>        set<int> result;
    _>        while(getline(file, row)){
    _>            tokenizer<char_separator<char>> numbers(row, char_separator<char>(","));
    _>            result.insert(accumulate(numbers.begin(), numbers.end(), 0, [](int a, const string& n){return a^lexical_cast<int>(n);}));
    _>        }
    _>        for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;
    _>    }catch(exception& e){
    _>        cout<<"Error: "<<e.what()<<endl;
    _>    }
    _>    return 0;
    _>}


    Не вижу фильтрации по количеству чисел в строке: «Для всех строк, в которых более двух чисел...»

    _>Теперь давай вариант того же на .Net, посмотрим в чём преимущество.


    File.ReadAllLines("Numbers.txt")
        .Select(line => line.Split(','))
        .Where(numbers => numbers.Length > 2)
        .Select(numbers => numbers.Aggregate(0, (total, number) => total ^ Int32.Parse(number)))
        .OrderByDescending(result => result)
        .ForEach(Console.WriteLine);


    Q>>Желательно бы без лямбд из C++11, т.к. не везде ещё поддерживаются.

    _>Это где они сейчас не поддерживаются? У нас проекты компилируются сразу под windows (msvc), linux (gcc), osx (gcc).

    В Clang 3.0 в предпоследней версии XCode (и в последней, судя по документации, тоже). И в поставляемом с XCode древним GCC. А под iOS 4.3 вообще печаль, C++11 использовать можно (хоть и без лямбд), а библиотеку из нового стандарта нельзя. Т.е. rvalue references вроде есть, но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[23]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 06.04.12 11:23
    Оценка:
    >Здравствуйте, Qbit86, Вы писали:

    Q>В предложенном решении не только контейнеры STL.


    Это про Boost что ли? ) Ну он там только для красоты. ))) Например если заменить boost::lexical_cast на atoi то ничего принципиально не изменится. Просто не охота была с C-ми функциями мешать. И с остальным тоже самое.

    Q>В отсутствии декларативности, наглядности, единообразия.


    Это всё общие слова. Надо смотреть конкретный код. Вот сейчас и посмотрим...

    Q>Вроде как было упомянуто, что Степанов стремился к «функциональности» своей библиотеки — где она в предложенном решении проявляется?


    Вообще то это был пример не на функциональность, а на предложенное сравнение с .Net. Однако некоторые характерные для фунцкионального стиля элементы проскочили и здесь. А именно использование accumulate.

    Q>Не вижу фильтрации по количеству чисел в строке: «Для всех строк, в которых более двух чисел...»


    Аааа, я как-то упустил что там строгое неравенство в тексте. ОК, добавил строчку реализующую это в коде ниже.

    Q>
    Q>File.ReadAllLines("Numbers.txt")
    Q>    .Select(line => line.Split(','))
    Q>    .Where(numbers => numbers.Length > 2)
    Q>    .Select(numbers => numbers.Aggregate(0, (total, number) => total ^ Int32.Parse(number)))
    Q>    .OrderByDescending(result => result)
    Q>    .ForEach(Console.WriteLine);
    Q>


    1. Эммм, а где программа то целиком? Где каркас, обработка ошибок, импорт? Как я это запускать буду для теста? Я по памяти не знаю что там должно быть в импорте, что бы оно заработало.

    Можно предоставить код полноценный программы, а не этот огрызок? Я тут уже 100мб файлик случайных чисел заготовил для теста.

    2. Хгм, так вот это и есть наглядность? Напоминает SQL в чистом виде. Для определённых целей конечно может быть очень удобно. Я даже знаю пару C++ библиотек для работы с базами данных, которые по такому же принципу работает. Но SQL в качестве универсальных контейеров языка, на все случаи жизни? Нее...

    3. Eсли убрать весь лишний код, как в примере выше, то вариант на stl выглядит схожим по размеру (добавил тут строку, которую упустил в первом варианте) и простоте:

    ifstream file("Numbers.txt");
    multiset<int> result;
    string row;
    while(getline(file, row)){
        if(count(row.cbegin(), row.cend(), ',')<2) continue;
        tokenizer<char_separator<char>> numbers(row, char_separator<char>(","));
        result.insert(accumulate(numbers.begin(), numbers.end(), 0, [](int a, const string& n){return lexical_cast<int>(n);}));
    }
    for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;


    Но при этом он абсолютно другой по принципам работы — очень интересно какое же будет соотношение по быстродействию...

    Q>В Clang 3.0 в предпоследней версии XCode (и в последней, судя по документации, тоже). И в поставляемом с XCode древним GCC. А под iOS 4.3 вообще печаль, C++11 использовать можно (хоть и без лямбд), а библиотеку из нового стандарта нельзя. Т.е. rvalue references вроде есть, но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.


    Хгм, на osx мы просто используем свой gcc, а не из xcode. Могу предположить что и на iOS можно что-то подобное сделать, правда утверждать не будут, т.к. не пробовал.
    Re[24]: Коллекции .NET и контейнеры STL
    От: Qbit86 Кипр
    Дата: 06.04.12 12:05
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Можно предоставить код полноценный программы, а не этот огрызок? Я тут уже 100мб файлик случайных чисел заготовил для теста. ;)


    К цивилизации я вернусь не раньше понедельника, так что придётся подождать.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[23]: Коллекции .NET и контейнеры STL
    От: Трололоша  
    Дата: 06.04.12 19:25
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.

    А самому их написать никак что ли?
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[24]: Коллекции .NET и контейнеры STL
    От: MxMsk Португалия  
    Дата: 06.04.12 20:54
    Оценка:
    Здравствуйте, Трололоша, Вы писали:

    Q>>но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.

    Т>А самому их написать никак что ли?
    Господа, ну это нечестно. Алекса просили на stl, он туда boost впихнул. Тут спрашивают про состав библиотеки, так в ответ "самому написать". Вы как-то уж придерживайтесь предмета что-ли. Иначе можно и про производительность ДотНет-а утверждать "могу свой рантайм наваять, будет всех рвать"
    Re[25]: Коллекции .NET и контейнеры STL
    От: Трололоша  
    Дата: 06.04.12 21:12
    Оценка:
    Здравствуйте, MxMsk, Вы писали:

    Q>>>но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.

    Т>>А самому их написать никак что ли?
    MM>Господа, ну это нечестно. Алекса просили на stl, он туда boost впихнул. Тут спрашивают про состав библиотеки, так в ответ "самому написать".

    Ты в курсе что делают std::forward и std::move и как они устроены?
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[25]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 07.04.12 04:56
    Оценка: 1 (1)
    Здравствуйте, Qbit86, Вы писали:

    Q>К цивилизации я вернусь не раньше понедельника, так что придётся подождать.


    А я даже сумел справиться сам. Правда пришлось разок погуглить на тему вставки всяких там using System.Linq;

    Так что я смог уже всё протестировать и результаты меня если честно, сильно удивили!

    Начну по порядку. Значит тестировались куски кода выше (а потом и ещё кое-что). Оптимиация у обоих компиляторов включена. Тестировалось на файле состоящем из 1000 строк по 10 000 случайных int'ов.

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

    Меня это результат сильно удивил. Я подумал что недооценил способность MS создавать оптимальный код и т.п... И так бы это удивление и осталось, если бы я не решил ради шутки проверить ещё один вариант. А именно, я написал код решающий задачу в лоб. Т.е. скорее в стиле C решение (хотя там всё равно был итоговый контейнер set<int>), без всяких красивостей (но и без какой-то спец. оптимизации). И вот этот код "неожиданно" показал быстродействие в 5 раз превышающее те два кода выше! Это было как раз похоже на то, что я ожидал, но только не от того кода...

    И вот на этом месте моё удивление скорость работы .Net совсем прошло и заменилось удивлением по поводу некоторых элементов C++. ))) Есествено что я решил немного иследовать вопрос, посмотрев чуть подробнее на причины. И так весь код выше можно разделись на "загрузку из файла" (занимает приблизительно 1/4 времени) и "обработку данных".

    Загрузка данных ускорилась в 10 (!) раз, в результате замены while(getline()) на одиночный fread. В принципе конечно так и должно быть... Но в свете данного факта запрет гугла на потоки, обсуждаемый в этой теме, не кажется таким уж и странным...

    Код обработки данных становится быстрее приблизительно в 5 раз, если заменить 3 строчки красивого кода внутри цикла (в изначальном решение) на 7 строчек решения той же задачи в лоб, без всяких итераторов, лямбд, аккумуляторов. В принципе это тоже достаточно очевидно, т.к. решение в лоб позволяет произвести все манипуляции в один проход по данным, а не в несколько, как это происходит у красивого решения. Но всё же я несколько разочарован, что все эти красивости в стиле Boost'а "стоят так дорого", что откидывают производительность до уровня дотнетовской. Хотя... В большинстве случаев сейчас скорость разработки софта важнее скорости самого софта, так что подобные решения очень нужны и хорошо что у C++ оно есть по полной.
    Re[25]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 07.04.12 05:05
    Оценка:
    Здравствуйте, MxMsk, Вы писали:

    MM>Господа, ну это нечестно. Алекса просили на stl, он туда boost впихнул. Тут спрашивают про состав библиотеки, так в ответ "самому написать". Вы как-то уж придерживайтесь предмета что-ли. Иначе можно и про производительность ДотНет-а утверждать "могу свой рантайм наваять, будет всех рвать"


    Бррр, что там от Буста то было? Замена C-ных функций типа atoi их более красивым внешне аналогом? ) Даа, это конечно очень важно. )))

    Это не говоря уже о том, что оно всё в h файлах, так что доступно где угодно по сути.
    Re[26]: Коллекции .NET и контейнеры STL
    От: Ночной Смотрящий Россия  
    Дата: 07.04.12 22:11
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>А я даже сумел справиться сам. Правда пришлось разок погуглить на тему вставки всяких там using System.Linq;


    Можно было просто поставить Решарпер, и ничего гуглить не понадобилось бы.

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


    Так уперлось все в вывод в консоль

    _>Меня это результат сильно удивил. Я подумал что недооценил способность MS создавать оптимальный код и т.п.


    Ну у тебя и основания для выводов. No comments.

    _>Загрузка данных ускорилась в 10 (!) раз, в результате замены while(getline()) на одиночный fread.


    Что значит одиночный? Все сразу в память? В фреймворке есть более гуманный способ — BufferedStream.
    Re[20]: std::first_rank_tensor
    От: _d_m_  
    Дата: 08.04.12 01:21
    Оценка:
    Здравствуйте, Ops, Вы писали:

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


    Ops>>>А про вектор википедия говорит, что в программировании это одномерный массив.


    ___>>Ну такие же ландухи приплюснутые там и написали.


    Ops>Я вот не пойму, как можно аргументировать что-то статьей из википедии, и сразу же писать, что в википедии туфта?


    Я вот тоже не понял — и что ж я такого аргументировал статьей из педивикии?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
    Re[11]: Вектор
    От: Хвост  
    Дата: 08.04.12 01:32
    Оценка: +1
    Здравствуйте, Qbit86, Вы писали:


    Q>Не, точно гуманитарий. (А судя по смайликам, ещё и малолетний.) Мой комментарий выше про векторное пространство так и не понял. Вот, например, в WPF есть класс Vector, его экземпляры, по сути, элементы пространства, присоединённого к аффинному пространству Point'ов.


    вектором испокон веков называется одномерный массив, википедия в помощь:
    начинаем отсюда: http://en.wikipedia.org/wiki/Array_data_structure

    Arrays are analogous to the mathematical concepts of vectors, matrices, and tensors. Indeed, arrays with one or two indices are often called vectors or matrices, respectively.


    отсюда выражения "векторные инструкции", "векторный процессор" итд итп. Так что название vector для динамического одномерного массива считаю более чем адекватным.
    People write code, programming languages don't.
    Re[27]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 08.04.12 09:20
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

    НС>Можно было просто поставить Решарпер, и ничего гуглить не понадобилось бы.


    Зачем мне его ставить ради маленького теста с форума? )

    НС>Так уперлось все в вывод в консоль


    Эмм, там вывод в консоль микроскопический же по сравнению со входными данными.

    И вообще, логика то у вас хоть немного присутствует? ) Откуда тогда могло бы взяться ускорение кода в 5 раз при одинаковом выводе?

    НС>Ну у тебя и основания для выводов. No comments.


    Всегда хочется получить одновременно и красивый высокоуровневый код и не потерять в быстродействие. Как мы сейчас увидeли, .Net и STL (если использовать в лоб) обеспечивают красоту и краткость, но ценой огромного (в 5 раз по сравнению с тупым циклом, написаным за 1 минуту) падения быстродействия.

    Кстати, получить высокоуровневый код не потеряв быстродействия с STL всё же можно, если подключить Boost. В смысле подключив для основных операций, а не в качестве украшательства (замены C функций), как в первом моём примере.

    Вот такой код:
    stringstream buf;
    buf<<ifstream("Numbers.txt").rdbuf();
    
    multiset<int> result;
    vector<int> row;
    auto calc=[&](...){if(row.size()>2) result.insert(accumulate(row.begin(), row.end(), 0, [](int a, int n){return a^n;})); row.clear();};
    parse(buf.str().begin(), buf.str().end(), (*(int_[ph::push_back(ph::ref(row), _1)] % ',' >> -eol)[calc]));
    for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;

    даёт увеличение быстродействия кода обработки в 5 раз (соответственно весь код становиться быстрее где-то в 3 раза) по сравнению с моим изначальным примером на STL и по сравнению с кодом .Net (хотя там я не знаю какая пропорция по времени у загрузки и обработки данных). Причём здесь остались наши тормознутые потоки C++. Если же их заменить на обычные C функции:

    FILE* file=fopen("Numbers.txt", "rb");
    fseek(file, 0, SEEK_END);
    int size=ftell(file);
    fseek(file, 0, SEEK_SET);
    unique_ptr<char[]> buf(new char[size]);
    fread(buf.get(), 1, size, file);
    fclose(file);
    
    multiset<int> result;
    vector<int> row;
    auto calc=[&](...){if(row.size()>2) result.insert(accumulate(row.begin(), row.end(), 0, [](int a, int n){return a^n;})); row.clear();};
    parse(buf.get(), buf.get()+size, (*(int_[ph::push_back(ph::ref(row), _1)] % ',' >> -eol)[calc]));
    for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;

    То загрузка файла ускоряется раз в 10 и соответственно получаем в итоге то самое преимущество в 5 раз. Причём код реализующий логику является у нас тут весьма кратким и выскоуровневым и может быть легко модифицирован (в отличие от моего быстрого кода написанного в виде цикла) для любых более сложных случаев. И при этом у нас преимущество в быстродействие в 500%.

    Конечно быстродействие важно далеко не всегда и чаще важнее скорость разработки. Поэтому то .Net и существует. Но как мы видим, синтаксический сахар и быстродействие всё же можно совмещать...

    НС>Что значит одиночный? Все сразу в память? В фреймворке есть более гуманный способ — BufferedStream.


    Ну да, сразу. Это как раз быстро. Кстати, интересно а .Net ReadAllLines как внутри реализован. С чтением по запросу или же сразу грузит в память? )
    Re[28]: Коллекции .NET и контейнеры STL
    От: Ночной Смотрящий Россия  
    Дата: 08.04.12 12:44
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    НС>>Можно было просто поставить Решарпер, и ничего гуглить не понадобилось бы.


    _>Зачем мне его ставить ради маленького теста с форума? )


    Ну посмотришь заодно, каким инструментарием люди пользуются

    НС>>Так уперлось все в вывод в консоль


    _>Эмм, там вывод в консоль микроскопический же по сравнению со входными данными.


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

    НС>>Ну у тебя и основания для выводов. No comments.


    _>Всегда хочется получить одновременно и красивый высокоуровневый код и не потерять в быстродействие.


    Не, я про то что если МС, то априори некачественный код.

    _> Как мы сейчас увидeли, .Net и STL (если использовать в лоб) обеспечивают красоту и краткость, но ценой огромного (в 5 раз по сравнению с тупым циклом, написаным за 1 минуту) падения быстродействия.


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

    _>Конечно быстродействие важно далеко не всегда и чаще важнее скорость разработки. Поэтому то .Net и существует.


    На дотнете тоже можно точно так же решить все в лоб. Той же, или даже чуть меньшей ценой.

    _>Ну да, сразу. Это как раз быстро.


    Ну так это изменение требований и сравнение уже некорректно.

    _> Кстати, интересно а .Net ReadAllLines как внутри реализован.


    using (StreamReader sr = new StreamReader(path, encoding))
      while ((line = sr.ReadLine()) != null)
        lines.Add(line);
    Re[29]: Коллекции .NET и контейнеры STL
    От: MxMsk Португалия  
    Дата: 08.04.12 14:53
    Оценка: 1 (1)
    Здравствуйте, Ночной Смотрящий, Вы писали:

    _>>Ну да, сразу. Это как раз быстро.

    НС>Ну так это изменение требований и сравнение уже некорректно.
    Так это типично для подобных "споров". Об этом когда-то шикарно написал
    Автор: adontz
    Дата: 19.03.09
    adontz.
    Re[29]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 08.04.12 16:11
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

    НС>Ну посмотришь заодно, каким инструментарием люди пользуются


    Мне Нетбинса хватает для всего. )

    Кстати, вот тут http://www.rsdn.ru/forum/tools/4678338.aspx
    Автор: BabloZlo
    Дата: 28.03.12
    я заводил темку по подобным вопросам. )

    НС>Консоль, по крайней мере в винде, штука очень тормозная. Буквально недавно лечил — вывод пары строчек в консоль оказался по времени сопоставим с временем обработки удаленного вызова.


    В данном тесте данные специально так подобраны, что бы эти времена были несопоставимы между собой. Если бы использовали в файле данных строки по 2-3 числа, то реально влияло бы. А у нас по 10 000 чисел строки...

    НС>Не, я про то что если МС, то априори некачественный код.


    Я писал не про это, а про .Net. В том смысле что сделать на нём такое проблематично. Т.е. если бы у MS это вышло (как я на секунду подумал), то это было бы типа героическим свершением. Но как и ожидалось, чудес не бывает. )))

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


    Бррр) Я закомментировал код вывода в консоль во всех вариантах и прогнал их тестом снова — изменение во времени выполнения порядка 2-3%. Можешь сам проверить. )

    Так что давай вот как раз на этом конкретном примере и покажешь всё. ) Хотя я в целом и так догадываюсь — данный синтаксический сахар должен иметь последствий в виде создания промежуточных коллекций.

    НС>На дотнете тоже можно точно так же решить все в лоб. Той же, или даже чуть меньшей ценой.


    ОК, ну покажи на данном примере. Только пожалуйста пришли код сразу с разделом импорта, а то мне потом разбираться ещё...

    НС>Ну так это изменение требований и сравнение уже некорректно.


    Не понял, какое изменение требований? У нас стоит задача: есть исходный файл с числами и требуется вывести в консоль какие-то результаты. Какие ещё требования и где они изменялись?

    _>> Кстати, интересно а .Net ReadAllLines как внутри реализован.

    НС>
    НС>using (StreamReader sr = new StreamReader(path, encoding))
    НС>  while ((line = sr.ReadLine()) != null)
    НС>    lines.Add(line);
    НС>

    Ага, т.е. загружает всё в память сразу, но построчно. Понятно. )
    Re[30]: Коллекции .NET и контейнеры STL
    От: Ночной Смотрящий Россия  
    Дата: 09.04.12 17:13
    Оценка: 1 (1)
    Здравствуйте, alex_public, Вы писали:

    _>Так что давай вот как раз на этом конкретном примере и покажешь всё. )


    Выкладывай свой тестовый файл.

    _> Хотя я в целом и так догадываюсь — данный синтаксический сахар должен иметь последствий в виде создания промежуточных коллекций.


    Предположение неверное. В дотнетном коде вообще, за исключением ReadAllLines, никаких коллекций не создается. И ReadAllLines это игрушечный метод, специально для демок.

    НС>>Ну так это изменение требований и сравнение уже некорректно.


    _>Не понял, какое изменение требований?


    Файл может быть неприемлемо большим, чтобы его целиком в оперативку тащить.

    _>Ага, т.е. загружает всё в память сразу, но построчно. Понятно. )


    Я ж говорю, игрушечный метод. Достаточно переписать так:
    using (StreamReader sr = new StreamReader(path, encoding))
      while ((line = sr.ReadLine()) != null)
        yield return line;


    И все станет существенно интереснее.
    Re[31]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 09.04.12 18:46
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

    НС>Выкладывай свой тестовый файл.


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

    Значит у нас файл состоит из 1000 строк. Каждая строка это 10000 чисел разделённых запятой. Каждое число — это случайный 32 битный int (т.е. -2147483648 до 2147483647).

    НС>Предположение неверное. В дотнетном коде вообще, за исключением ReadAllLines, никаких коллекций не создается. И ReadAllLines это игрушечный метод, специально для демок.


    Ммм, а как тогда реализована команда split? И кстати ещё одна коллекция по любому должна создаваться — итоговая, т.к. по ней сортировка идёт. Но она есть и в C++ коде.

    _>>Не понял, какое изменение требований?

    НС>Файл может быть неприемлемо большим, чтобы его целиком в оперативку тащить.

    Ааа, ну да, но у нас же тут конкретный тестовый пример, а не работа вообще. Так что я подобрал набор данных вполне укладывающийся в начальные требование. И при этом достаточно большой что бы засекать время.

    НС>Я ж говорю, игрушечный метод. Достаточно переписать так:

    НС>
    НС>using (StreamReader sr = new StreamReader(path, encoding))
    НС>  while ((line = sr.ReadLine()) != null)
    НС>    yield return line;
    НС>

    Кстати это будет аналогом кода из моего примера на C++ с потоками. ) Там как раз читается по запросу по строке. И при этом хочу заметить что оно заметно медленнее варианта с загрузкой файла целиком. Хотя там ещё сами потоки тормознутые, поэтому из этого никаких выводов делать нельзя. )))

    НС>И все станет существенно интереснее.


    Ну посмотрим) Вообще говоря в C++ коде (который медленный вариант) загрузка занимала только 1/4 времени (и вообще эта пропорция существенно зависит от дисковой подсистемы компьютера). Не знаю как с этим в том .Net коде, но если предположить что так же, то сосредотачиваться надо на оптимизации совсем другого места.
    Re[12]: Вектор
    От: Qbit86 Кипр
    Дата: 09.04.12 20:49
    Оценка:
    Здравствуйте, Хвост, Вы писали:

    Х>вектором испокон веков называется одномерный массив, википедия в помощь:


    Ну да, испокон веков вектор — структура данных «массив», а хитрозадые математики уже оттуда свистнули словечко.

    Х>отсюда выражения "векторные инструкции", "векторный процессор" итд итп.


    Векторные инструкции и векторный процессор — они немного о другом. Примерно как векторная запись сокращает нотацию по сравнению с покомпонентной для описания алгебраических операций. О том, чтобы рассматривать структуры данных динамических и несогласованных в компайл-тайме размеров и как контейнеры общего назначения для произвольных пользовательских типов, речи нет в контексте термина «векторный процессор».

    Х>Так что название vector для динамического одномерного массива считаю более чем адекватным.


    Это только если мозги травмированы сиплюсплюсом. Куда лучше, если они поражены математикой, имхо.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[24]: Move semantics
    От: Qbit86 Кипр
    Дата: 09.04.12 21:00
    Оценка:
    Здравствуйте, Трололоша, Вы писали:

    Q>>но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.

    Т>А самому их написать никак что ли?

    Их-то я напишу, а остальную часть STL кто на их использование переведёт?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[8]: Google code style
    От: о_О
    Дата: 09.04.12 21:14
    Оценка:
    N>хорошо, вам, плюсовикам. всегда есть о чем поболтать

    вступай и компелируй1
    Re[24]: Fluent syntax, query syntax
    От: Qbit86 Кипр
    Дата: 09.04.12 22:19
    Оценка: -1 :)
    Здравствуйте, alex_public, Вы писали:

    Q>>Вроде как было упомянуто, что Степанов стремился к «функциональности» своей библиотеки — где она в предложенном решении проявляется?

    _>Вообще то это был пример не на функциональность, а на предложенное сравнение с .Net.

    Да нет, как раз хотелось
    Автор: Qbit86
    Дата: 05.04.12
    увидеть идиоматичные примеры использования стандартных ФВП: свёртки (редукции, аггрегации, катаморфизма), проекции, фильтрации. Всю эту неуклюжесть при работе с итераторами и падение эффективности из-за энергичного создания промежуточных коллекций при работе с алгоритмами STL (малоюзабельность которых нашла своё подтверждение в твоём примере).

    _>Я по памяти не знаю что там должно быть в импорте, что бы оно заработало.


    Тут бы ты на моём месте обязательно придрался к знанию стандартной библиотеки.

    _>2. Хгм, так вот это и есть наглядность?


    Да, она, родимая.

    _>Напоминает SQL в чистом виде.


    Это был fluent syntax. Оно бы действительно напоминало SQL, если бы я использовал query syntax:
    var results = from line in File.ReadAllLines("Numbers.txt")
                  select line.Split(',') into numbers
                  where numbers.Length > 2
                  select numbers.Aggregate(0, (total, number) => total ^ Int32.Parse(number)) into result
                  orderby result descending select result;
    foreach (var result in results)
        Console.WriteLine(result);


    _>Но SQL в качестве универсальных контейеров языка, на все случаи жизни? Нее...


    Ты выше упоминал про списки в Lisp и Haskell. Очевидно, это был пустой звон, и ты не представляешь, как происходит в них работа со списками; иначе ты бы никогда не сказал процитированного. Я бы на твоём месте не разбрасывался остроумными уколами типа «Чем знание другого языка может помочь не разбирающимся в тонкостях C++, но желающим поговорить о них?»

    _>3. Eсли убрать весь лишний код, как в примере выше, то вариант на stl выглядит схожим по размеру (добавил тут строку, которую упустил в первом варианте) и простоте:

    _>ifstream file("Numbers.txt");
    _>multiset<int> result;
    _>string row;
    _>while(getline(file, row)){
    _>    if(count(row.cbegin(), row.cend(), ',')<2) continue;
    _>    tokenizer<char_separator<char>> numbers(row, char_separator<char>(","));
    _>    result.insert(accumulate(numbers.begin(), numbers.end(), 0, [](int a, const string& n){return lexical_cast<int>(n);}));
    _>}
    _>for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;


    Дело не только в количестве строк или лексем, дело в скорости и простоте восприятия. Декларативность vs. кондовая императивность.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[28]: Красота и краткость
    От: Qbit86 Кипр
    Дата: 09.04.12 22:39
    Оценка: :)
    Здравствуйте, alex_public, Вы писали:

    _>Всегда хочется получить одновременно и красивый высокоуровневый код и не потерять в быстродействие. Как мы сейчас увидeли, .Net и STL (если использовать в лоб) обеспечивают красоту и краткость, но ценой огромного (в 5 раз по сравнению с тупым циклом, написаным за 1 минуту) падения быстродействия.


    Лолшто? 0_о Красота и краткость в продемонстрированном низкоуровневом (sic!) императивном подходе??? Нет, это не может быть сказано всерьёз.

    Имхо, хаскельщик, знающий C++, поймёт приведённый код на неизвестном ему шарпе гораздо быстрее, чем на известных ему плюсах. (Сможет понять, что код делает, вплоть до обратной формулировки исходной задачи.)

    Отбрасывая нерелевантные обсуждения про скорость чтения из файла, etc, возвращаюсь к исходному вопросу: «Мммм а можно пример на котором видно что коллекции из .Net заметно удобнее STL?» Резюмирую ответ: практически любой случай, где код нужно не только писать, но и читать.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[25]: Fluent syntax, query syntax
    От: alex_public  
    Дата: 10.04.12 05:11
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Тут бы ты на моём месте обязательно придрался к знанию стандартной библиотеки.


    Эээм, а я разве где-то писал что знаком с linq? Я только краем глаза видел всякие обзоры по ней, но в руках никогда не держал. Собственно по этому я и попросил показать мне пример — вдруг оно действительно так красиво и эффективно. Оказалось что нет.

    Q>Это был fluent syntax. Оно бы действительно напоминало SQL, если бы я использовал query syntax:


    И тот и другой вариант — типичный sql с мелкими синтаксическими различиями.

    Q>Ты выше упоминал про списки в Lisp и Haskell. Очевидно, это был пустой звон, и ты не представляешь, как происходит в них работа со списками; иначе ты бы никогда не сказал процитированного. Я бы на твоём месте не разбрасывался остроумными уколами типа «Чем знание другого языка может помочь не разбирающимся в тонкостях C++, но желающим поговорить о них?»


    http://www.rsdn.ru/forum/decl/4695418.aspx
    Автор: vdimas
    Дата: 10.04.12
    да, да, я ничего не знаю про списки. ))) Зато мы уже выяснили что адепты .Net не знают почему в компьютерном мире под словом list подразумевается вполне конкретная сущность и это вовсе не нумерованный "список покупок".

    Q>Дело не только в количестве строк или лексем, дело в скорости и простоте восприятия. Декларативность vs. кондовая императивность.


    1. Не надо путать функциональности и декларативность. Большинство современных языков поддерживающих функциональный стиль являются при этом полностью императивными. C++ как раз такой.

    2. А что, декларативность с каких-то пор стала самоцелью? ) Если императивный код короче, яснее и при этом ещё и работает на 500% быстрее, то зачем нам нужна тогда такая декларативность? Из принципа? )))

    И кстати состояние индустрии, в которой подавляющее преимущество составляют императивные языки, это хорошо демонстрирует...

    А жаль. Например Пролог — это практически мой любимый язык. Только ни для каких практичных целей мы его ни разу применить не смогли.
    Re[29]: Красота и краткость
    От: alex_public  
    Дата: 10.04.12 05:26
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Лолшто? 0_о Красота и краткость в продемонстрированном низкоуровневом (sic!) императивном подходе??? Нет, это не может быть сказано всерьёз.


    А кто сказал что подход будет не императивным? ) И с каких пор императивный подход — это плохо? )))

    На счёт низкоуровневости. Таким было только моё решение с циклом в лоб (я его тут даже не показывал), которое я написал за минуту для сравнения скорости. Вариант с stl практически аналогичен linq по смыслу происходящего. А вот вариант с использованием Boost является более высокоуровневым чем с linq, т.к гораздо более расширяем, но там логика работы уже совсем другая.

    Q>Имхо, хаскельщик, знающий C++, поймёт приведённый код на неизвестном ему шарпе гораздо быстрее, чем на известных ему плюсах. (Сможет понять, что код делает, вплоть до обратной формулировки исходной задачи.)


    Хыхы, что бы понять код linq надо знать не хаскель или c#, а всего лишь sql. )

    Q>Отбрасывая нерелевантные обсуждения про скорость чтения из файла, etc,


    Ооо, начинаются традиционные виляния. Как только обнаружилось что используемый синтаксический сахар требует падения производительности в 5 раз, то сразу все вопросы сравнения быстродействия стали "нерелевантными". И кстати чтение из файла занимает небольшое время теста, так что данные цифры показывают именно реальную скорость работы алгоритма.

    Q>возвращаюсь к исходному вопросу: «Мммм а можно пример на котором видно что коллекции из .Net заметно удобнее STL?» Резюмирую ответ: практически любой случай, где код нужно не только писать, но и читать.


    Для задач хорошо ложащихся на sql так и есть (конечно если вас вообще не волнуют вопросы быстродействия, что довольно часто бывает), но не более того.
    Re[30]: Красота и краткость
    От: Qbit86 Кипр
    Дата: 10.04.12 06:08
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Вариант с stl практически аналогичен linq по смыслу происходящего.


    :)

    _>Вариант с stl практически аналогичен linq по смыслу происходящего.


    Собственно, там не было алгоритмов STL, что и хотелось бы увидеть. Это понятно почему, всеми этими муторными error prone парами итераторов действительно невозможно без содрогания и без потери эффективности пользоваться.

    _>А вот вариант с использованием Boost является более высокоуровневым чем с linq, т.к гораздо более расширяем, но там логика работы уже совсем другая.


    Это который же? :)

    _>Для задач хорошо ложащихся на sql так и есть (конечно если вас вообще не волнуют вопросы быстродействия, что довольно часто бывает), но не более того.

    _>...
    _>Хыхы, что бы понять код linq надо знать не хаскель или c#, а всего лишь sql. )

    К моему огромному сожалению, авторы Linq назвали старые добрые свёртку, проекцию и фильтрацию не как fold, map и filter, а как Aggregate, Select и Where. Сделано это было в угоду полчищам «птушников», ничего декларативного кроме SQL не видевших. Собственно, так их назвали, чтобы была лучше видна связь между сахаром SQL-like query-синтаксиса и нижележащими вызовами.

    Это, как мы видим, породило у казуалов стойкую ассоциацию Linq'а с SQL, реляционными базами, etc. Кто хоть раз работал со списками на Хаскеле или Окамле, без труда узнали бы в сигнатурах Linq-методов привычные с детства операции над последовательностями.

    Q>>Отбрасывая нерелевантные обсуждения про скорость чтения из файла, etc,

    _>Ооо, начинаются традиционные виляния.

    Виляния начались как раз у тебя. Как оказалось, что один statement на C# 4.0 в плане выразительности как небо и земля в сравнении с C++, так и начались стандартные заносы в сторону скорости, тактов, мегабайтов, etc.

    _>Как только обнаружилось что используемый синтаксический сахар требует падения производительности в 5 раз, то сразу все вопросы сравнения быстродействия стали "нерелевантными".


    Ну-ну, расскажи, как Linq приводит к падению производительности по сравнению с рукописными циклами над контейнерами. Ты его устройство хоть примерно представляешь?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[26]: Fluent syntax, query syntax
    От: Qbit86 Кипр
    Дата: 10.04.12 06:28
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>И тот и другой вариант — типичный sql с мелкими синтаксическими различиями.


    Ну да, ФВП в Хаскель, ML'и и Лисп со своими списками тоже типичный SQL :)

    Q>>Ты выше упоминал про списки в Lisp и Haskell. Очевидно, это был пустой звон, и ты не представляешь, как происходит в них работа со списками; иначе ты бы никогда не сказал процитированного. Я бы на твоём месте не разбрасывался остроумными уколами типа «Чем знание другого языка может помочь не разбирающимся в тонкостях C++, но желающим поговорить о них?»


    _>http://www.rsdn.ru/forum/decl/4695418.aspx
    Автор: vdimas
    Дата: 10.04.12
    да, да, я ничего не знаю про списки. )))


    Не вижу, как комментарий vdimas'а по ссылке связан с твоими утверждениями про SQL.

    _>Большинство современных языков поддерживающих функциональный стиль являются при этом полностью императивными. C++ как раз такой.


    Исходно речь шла про контейнеры и коллекции. (А точнее, так как сами по себе они по сути мало отличаются, про алгоритмы работы с ними — <algorithms> и Linq соответственно.) Вот и получается, что C++ весь из себя такой функциональный, а его стандартной библиотекой в функциональном стиле пользоваться невозможно (хоть и заявлено, что она тоже вся из себя функциональная.)

    _>Если императивный код короче, яснее и при этом ещё и работает на 500% быстрее, то зачем нам нужна тогда такая декларативность? Из принципа? )))


    Ну, «короче, яснее и на 500% быстрее» — это явно не про C++.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[27]: Fixed
    От: Qbit86 Кипр
    Дата: 10.04.12 06:31
    Оценка:
    Q>А точнее... про алгоритмы работы с ними — <algorithms> и Linq соответственно.

    О боже, надо быстрее исправить, пока не началось!
    * Fixed: <algorithm>
    Глаза у меня добрые, но рубашка — смирительная!
    Re[31]: Красота и краткость
    От: alex_public  
    Дата: 10.04.12 07:00
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Собственно, там не было алгоритмов STL, что и хотелось бы увидеть. Это понятно почему, всеми этими муторными error prone парами итераторов действительно невозможно без содрогания и без потери эффективности пользоваться.


    A count и accumulate тогда что же? Куда больше то двух алгоритмов на такую простую задачу? ) Можно было ещё и все циклы на алгоритм foreach с лямбдой заменить. Но на мой личный вкус for проще выглядит. А когда сможем использовать нормальный range for на всех компиляторах вообще вопросов не будет. Т.е. если под gcc я бы уже написал for(auto i: result) cout<<i<<endl; и т.д.

    _>>А вот вариант с использованием Boost является более высокоуровневым чем с linq, т.к гораздо более расширяем, но там логика работы уже совсем другая.

    Q>Это который же?

    Который через boost работает:
    multiset<int> result;
    vector<int> row;
    auto calc=[&](...){if(row.size()>2) result.insert(accumulate(row.begin(), row.end(), 0, [](int a, int n){return a^n;})); row.clear();};
    parse(buf.get(), buf.get()+size, (*(int_[ph::push_back(ph::ref(row), _1)] % ',' >> -eol)[calc]));

    Кстати calc в отдельной переменной только для упрощения — можно было так же засунуть в ту одну строку. Но тогда слишком громоздкая строка была бы (как у того примера на Linq), надо было переносить её и т.д...

    Так вот этот вариант легко модифицируется на такие случаи, которые в linq получится впихнуть только с дикими изращениями, если вообще возможно. И при этом он в 5 раз быстрее варианта на linq.

    Q>К моему огромному сожалению, авторы Linq назвали старые добрые свёртку, проекцию и фильтрацию не как fold, map и filter, а как Aggregate, Select и Where. Сделано это было в угоду полчищам «птушников», ничего декларативного кроме SQL не видевших. Собственно, так их назвали, чтобы была лучше видна связь между сахаром SQL-like query-синтаксиса и нижележащими вызовами.


    Ха, они как раз сделали что бы было "декларативно". Т.к. sql — это декларативный язык во многом. А вот map, filter и т.п. — это классические термины из функционального стиля. Который вовсе не подразумевает декларативность. Так что если нравится декларативность, то имена самое оно. )))

    Q>>>Отбрасывая нерелевантные обсуждения про скорость чтения из файла, etc,

    _>>Ооо, начинаются традиционные виляния.

    Q>Виляния начались как раз у тебя. Как оказалось, что один statement на C# 4.0 в плане выразительности как небо и земля в сравнении с C++, так и начались стандартные заносы в сторону скорости, тактов, мегабайтов, etc.


    На мой вкус slq стиль не является выразительнее. И кстати сейчас в мире намечается тенденция ухода от повсеместного использования sql баз. Как раз в числе и потому что у их аналогов возможно более удобное обращение (ООП например) и большая скорость.

    Q>Ну-ну, расскажи, как Linq приводит к падению производительности по сравнению с рукописными циклами над контейнерами. Ты его устройство хоть примерно представляешь?


    Какая мне разница как он устроен внутри, если я вижу конкретные цифры на тесте?
    Re[27]: Fluent syntax, query syntax
    От: alex_public  
    Дата: 10.04.12 07:13
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Ну да, ФВП в Хаскель, ML'и и Лисп со своими списками тоже типичный SQL 

    Мы можем устроить встроенные SQL и в них, если очень надо. Можно и в C++ кстати. Например здесь http://www.ultimatepp.org/www$uppweb$overview$en-us.html была похожая реализация (см. внизу страницы). SQL — это же просто DSL. А linq — это реализация для C#.

    _>>http://www.rsdn.ru/forum/decl/4695418.aspx
    Автор: vdimas
    Дата: 10.04.12
    да, да, я ничего не знаю про списки. )))

    Q>Не вижу, как комментарий vdimas'а по ссылке связан с твоими утверждениями про SQL.
    Ошибся в ссылке. Имелось в виду первое сообщение в той темке.

    Q>Исходно речь шла про контейнеры и коллекции. (А точнее, так как сами по себе они по сути мало отличаются, про алгоритмы работы с ними — <algorithms> и Linq соответственно.) Вот и получается, что C++ весь из себя такой функциональный, а его стандартной библиотекой в функциональном стиле пользоваться невозможно (хоть и заявлено, что она тоже вся из себя функциональная.)


    Где получается то? Как раз stl вся из себя такая фунциональная (что многим и не нравится — многим роднее ООП стиль) и нормально ею все, кто хочет, пользуются.

    Q>Ну, «короче, яснее и на 500% быстрее» — это явно не про C++.


    Если подключить Boost, то как раз именно так и получается. На примерах из этой области. В других областях возможно будут другие цифры. Например не 500%, а всего 200% или 1000%.
    Re[32]: Красота и краткость
    От: Qbit86 Кипр
    Дата: 10.04.12 07:31
    Оценка: :)
    Здравствуйте, alex_public, Вы писали:

    _>>>А вот вариант с использованием Boost является более высокоуровневым чем с linq, т.к гораздо более расширяем, но там логика работы уже совсем другая.

    Q>>Это который же? :)
    _>Который через boost работает:
    multiset<int> result;
    _>vector<int> row;
    _>auto calc=[&](...){if(row.size()>2) result.insert(accumulate(row.begin(), row.end(), 0, [](int a, int n){return a^n;})); row.clear();};
    _>parse(buf.get(), buf.get()+size, (*(int_[ph::push_back(ph::ref(row), _1)] % ',' >> -eol)[calc]));



    Лопни мои глаза...

    _>Кстати calc в отдельной переменной только для упрощения — можно было так же засунуть в ту одну строку.


    Ты так и не понял. Дело не в конкатенации строк и натужном тулении операторов к скобкам. Плюсовый код содержит тупо больше мусорных лексем и посторонних сущностей, не имеющих прямого отношения к задаче. Даже зная C++ и условия задачи, я затрудняюсь разобрать приведённый код.

    Я не понимаю, как ты не понимаешь?

    _>Так вот этот вариант легко модифицируется на такие случаи, которые в linq получится впихнуть только с дикими изращениями, если вообще возможно.


    Я, пожалуй, буду в одностороннем порядке сворачивать дискуссию. Такой оголтелого отрыва от реальности у собеседников я не встречал уже давно.

    _>На мой вкус slq стиль не является выразительнее. И кстати сейчас в мире намечается тенденция ухода от повсеместного использования sql баз.


    Поэтому я и не использовал в исходном примере query syntax. Обошёлся идиоматичными для ФЯП (или языков с поддержкой функ. стиля) методами.

    Q>>Ну-ну, расскажи, как Linq приводит к падению производительности по сравнению с рукописными циклами над контейнерами. Ты его устройство хоть примерно представляешь?

    _>Какая мне разница как он устроен внутри, если я вижу конкретные цифры на тесте?

    Но ты же утверждаешь, что причиной какого-то там падения служит именно Linq?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[28]: Write-only style
    От: Qbit86 Кипр
    Дата: 10.04.12 07:43
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ошибся в ссылке. Имелось в виду первое сообщение в той темке.


    Там в исходном сообщении рассказано, какой alex_public молодец, и сколько языков он выучил. В том числе, кстати, указаны C#, Lisp и Haskell. Да.

    _>Как раз stl вся из себя такая фунциональная (что многим и не нравится — многим роднее ООП стиль) и нормально ею все, кто хочет, пользуются.


    Никто не хочет, я смотрю. Проще на if'ах и циклах накидать по-быстрому. Write-only style.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[33]: Красота и краткость
    От: alex_public  
    Дата: 10.04.12 08:19
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Ты так и не понял. Дело не в конкатенации строк и натужном тулении операторов к скобкам. Плюсовый код содержит тупо больше мусорных лексем и посторонних сущностей, не имеющих прямого отношения к задаче. Даже зная C++ и условия задачи, я затрудняюсь разобрать приведённый код.


    Это код конечно выглядит сложнее и linq и stl варианта. Исключительно потому, что он решает более общую задачу. И при этом без потери скорости!

    _>>Так вот этот вариант легко модифицируется на такие случаи, которые в linq получится впихнуть только с дикими изращениями, если вообще возможно.

    Q>Я, пожалуй, буду в одностороннем порядке сворачивать дискуссию. Такой оголтелого отрыва от реальности у собеседников я не встречал уже давно.

    Ха, ну давай пример раз не веришь.

    Значит в твоём изначальном примере у нас была фильтрация на количество чисел в строке. Типа учитываем строку только если в ней больше 2 чисел. Да, это отлично ложится на sql синтаксис. А теперь уберём это условие и поставим новое, поинтереснее:

    в xor должны попадать только числа или находящиеся на позиции не большей чем длинна предыдущей строки или стоящие после числа меньше их. Т.е. для того же примера
    19937,62
    42
    58,59,13373
    648,649
    14, 3, 15,92,6
    2,7,1828,1828
    выкидываются 62 и 6.

    Интересно чего будет стоить что бы модифицировать тот пример на linq под это условие? Код же на boost'е выше можно подправить под это условие парой букв.

    _>>Какая мне разница как он устроен внутри, если я вижу конкретные цифры на тесте?

    Q>Но ты же утверждаешь, что причиной какого-то там падения служит именно Linq?

    А там есть что-то ещё? С загрузкой файла мы уже разобрались — она занимает мало времени.
    Re[32]: Красота и краткость
    От: _d_m_  
    Дата: 10.04.12 10:44
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>На мой вкус slq стиль не является выразительнее. И кстати сейчас в мире намечается тенденция ухода от повсеместного использования sql баз. Как раз в числе и потому что у их аналогов возможно более удобное обращение (ООП например) и большая скорость.


    Ну-ну... хватит фантазий.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
    Re[25]: Move semantics
    От: Трололоша  
    Дата: 10.04.12 17:53
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>>>но std::forward, std::move и прочей поддержки со стороны библиотеки — нет.

    Т>>А самому их написать никак что ли?

    Q>Их-то я напишу, а остальную часть STL кто на их использование переведёт?

    а, ты про использование move operator/constructor в принципе

    Мне проще — у меня в проекте STL запрещён, используется собственный framework с STL-compatible контейнерами. Там всё работает с move как только проект переехал на C++0х компилятор.
    ... << RSDN@Home>>
    Да, йа зелёный тролль!
    Re[33]: Красота и краткость
    От: alex_public  
    Дата: 10.04.12 18:46
    Оценка:
    Здравствуйте, _d_m_, Вы писали:

    ___>Ну-ну... хватит фантазий.


    Слова Redis, MongoDB и т.п. знакомы? Там ещё несколько десятков таких. И они сейчас уверенно выходят на сцену. Причём как раз в тех областях где раньше безраздельно царили всякие разновидности slq баз.
    Re[32]: Коллекции .NET и контейнеры STL
    От: Ночной Смотрящий Россия  
    Дата: 10.04.12 22:14
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Нафига выкладывать 100мб файл случайных чисел? Я написал его генератор ровно в две строки, запустил разок и всё.


    Выложи генератор.

    _>Значит у нас файл состоит из 1000 строк. Каждая строка это 10000 чисел разделённых запятой. Каждое число — это случайный 32 битный int (т.е. -2147483648 до 2147483647).


    Ну хотя бы так.

    _>Ммм, а как тогда реализована команда split?


    Какая такая команда split? Ты про System.String.Split() что ли? Вот один из вариантов:
      Скрытый текст
            // This function will not keep the Empty String 
            private String[] InternalSplitOmitEmptyEntries(Int32[] sepList, Int32[] lengthList, Int32 numReplaces, int count) {
                Contract.Requires(numReplaces >= 0); 
                Contract.Requires(count >= 2, "Count>=2");
    
                // Allocate array to hold items. This array may not be
                // filled completely in this function, we will create a 
                // new array and copy string references to that new array.
     
                int maxItems = (numReplaces < count) ? (numReplaces+1): count ; 
                String[] splitStrings = new String[maxItems];
     
                int currIndex = 0;
                int arrIndex = 0;
    
                for(int i=0; i< numReplaces && currIndex < Length; i++) { 
                    if( sepList[i]-currIndex > 0) {
                        splitStrings[arrIndex++] = Substring(currIndex, sepList[i]-currIndex ); 
                    } 
                    currIndex=sepList[i] + ((lengthList == null) ? 1 : lengthList[i]);
                    if( arrIndex == count -1 )  { 
                        // If all the remaining entries at the end are empty, skip them
                        while( i < numReplaces - 1 && currIndex == sepList[++i]) {
                            currIndex += ((lengthList == null) ? 1 : lengthList[i]);
                        } 
                        break;
                    } 
                } 
    
                // we must have at least one slot left to fill in the last string. 
                Contract.Assert( arrIndex < maxItems, "arrIndex < maxItems");
    
                //Handle the last string at the end of the array if there is one.
                if (currIndex< Length) { 
                    splitStrings[arrIndex++] = Substring(currIndex);
                } 
     
                String[] stringArray = splitStrings;
                if( arrIndex!= maxItems) { 
                    stringArray = new String[arrIndex];
                    for( int j = 0; j < arrIndex; j++) {
                        stringArray[j] = splitStrings[j];
                    } 
                }
                return stringArray; 
            }


    _> И кстати ещё одна коллекция по любому должна создаваться — итоговая, т.к. по ней сортировка идёт.


    Это да. Но это никак не оправдывает неленивую реализацию ReadAllLines.

    _>Ааа, ну да, но у нас же тут конкретный тестовый пример, а не работа вообще.


    Вот именно. Поэтому надо одинаковые алгоритмы использовать, а не разные.
    Re[32]: Коллекции .NET и контейнеры STL
    От: Ночной Смотрящий Россия  
    Дата: 10.04.12 22:57
    Оценка: 2 (2)
    Здравствуйте, alex_public, Вы писали:

    Итак. Сперва написал генератор, поскольку результат сильно зависит от того, какие параметры у входных данных.
      Скрытый текст
    var rnd = new Random();
    using (var sw = new StreamWriter("Numbers.txt"))
        for (var line = 0; line < 1000; line++)
        {
            var sb = new StringBuilder();
            for (var i = 0; i < 10000; i++)
            {
                if (sb.Length != 0)
                    sb.Append(',');
                sb.Append(rnd.Next());
            }
            sw.WriteLine(sb.ToString());
        }


    Померял. Получилось 2600 мс на моей машине. Начал смотреть что там время жрет. Оказалось — Int32.Parse. И жрет оно не потому что плохо написано, а потому что этот метод учитывает кучу тонкостей типа сепараторов в числе, настроек локали и т.п. Что то мне подсказывает, что в С++ варианте все намного примитивнее в этом плане.
    Заменяем парсинг на простейший вариант, который все изучали в школе:
    static int IntParseFast(string value)
    {
        var result = 0;
        for (var i = 0; i < value.Length; i++)
        {
            var letter = value[i];
            result = 10 * result + (letter - 48);
        }
        return result;
    }


    Замеряем. Получаем ровно в два раза быстрее — 1300 мс.
    Смотрим трассу — расклад совсем другой. Примерно 35% времени занимает string.Split(). Еще 9% — IntParseFast. 7% — Console.WriteLine() (т.е. даже твой тест с малым количеством строк и большой их длиной тратит ощутимое время на консоль). Наконец 25% занимает ReadAllLines() (но у меня SSD и много много оперативки).

    Памятуя о живительной силе чтения сразу всего в память, пишем такой код:
    static IEnumerable<string> ReadAllLines(string fileName)
    {
        var fi = new FileInfo(fileName);
        var buffer = new byte[fi.Length];
        using (var fs = new FileStream(fileName, FileMode.Open))
            fs.Read(buffer, 0, buffer.Length);
    
        string line;
        using (var sr = new StreamReader(new MemoryStream(buffer)))
            while ((line = sr.ReadLine()) != null)
                yield return line;
    }

    Результат не изменился. Это говорит о том, что реализация файловых потоков в FW существенно лучше.

    Ну и на закуску, добавляем после ReadAllLines ровно одну коротенькую строчку, .AsParallel(). И получаем результат 900 мс.

    Дальше надо оптимизировать Split.

      Полный исходник
    using System;
    using System.Collections.Generic;
    using System.Diagnostics;
    using System.IO;
    using System.Linq;
    using System.Text;
    
    namespace FileLinesTest
    {
        static class Program
        {
            static void GenerateSample()
            {
                var rnd = new Random();
                using (var sw = new StreamWriter("Numbers.txt"))
                    for (var line = 0; line < 1000; line++)
                    {
                        var sb = new StringBuilder();
                        for (var i = 0; i < 10000; i++)
                        {
                            if (sb.Length != 0)
                                sb.Append(',');
                            sb.Append(rnd.Next());
                        }
                        sw.WriteLine(sb.ToString());
                    }
            }
    
            static void ForEach<T>(this IEnumerable<T> src, Action<T> action)
            {
                foreach (var item in src)
                    action(item);
            }
    
            static int IntParseFast(string value)
            {
                var result = 0;
                for (var i = 0; i < value.Length; i++)
                {
                    var letter = value[i];
                    result = 10 * result + (letter - 48);
                }
                return result;
            }
    
            static IEnumerable<string> ReadAllLines(string fileName)
            {
                var fi = new FileInfo(fileName);
                var buffer = new byte[fi.Length];
                using (var fs = new FileStream(fileName, FileMode.Open))
                    fs.Read(buffer, 0, buffer.Length);
    
                string line;
                using (var sr = new StreamReader(new MemoryStream(buffer)))
                    while ((line = sr.ReadLine()) != null)
                        yield return line;
            }
    
            static void Main(string[] args)
            {
                //GenerateSample();
                var sw = Stopwatch.StartNew();
                File
                    .ReadAllLines("Numbers.txt")
                    //.AsParallel()
                    .Select(line => line.Split(','))
                    .Where(numbers => numbers.Length > 2)
                    .Select(numbers => numbers.Aggregate(0, (total, number) => total ^ IntParseFast(number)))
                    .OrderByDescending(result => result)
                    .ForEach(Console.WriteLine);
                sw.Stop();
                Console.WriteLine("{0} ms", sw.ElapsedMilliseconds);
            }
        }
    }
    Re[32]: Красота и краткость
    От: Ночной Смотрящий Россия  
    Дата: 10.04.12 23:11
    Оценка: +1 :)
    Здравствуйте, alex_public, Вы писали:

    _>Который через boost работает:

    _>
    multiset<int> result;
    _>vector<int> row;
    _>auto calc=[&](...){if(row.size()>2) result.insert(accumulate(row.begin(), row.end(), 0, [](int a, int n){return a^n;})); row.clear();};
    _>parse(buf.get(), buf.get()+size, (*(int_[ph::push_back(ph::ref(row), _1)] % ',' >> -eol)[calc]));


    Ужас то какой.

    _>Но тогда слишком громоздкая строка была бы (как у того примера на Linq), надо было переносить её и т.д...


    Так перенес бы, в чем проблема? Или чем меньше строк, тем круче код?

    _>Так вот этот вариант легко модифицируется на такие случаи, которые в linq получится впихнуть только с дикими изращениями, если вообще возможно.


    Примеры таких случаев приведешь?

    _>А вот map, filter и т.п. — это классические термины из функционального стиля. Который вовсе не подразумевает декларативность.


    Хм, вообще то чистый функциональный код по определению декларативен.

    _> Так что если нравится декларативность, то имена самое оно. )))


    Не знаю где ты там в линке sql увидел — в примере обычная цепочка вызовов методов.

    _>И кстати сейчас в мире намечается тенденция ухода от повсеместного использования sql баз.


    В очень узких областях. Там, где хранятся структурированные данные больших объемов, альтернатив SQL-серверам нет и в обозримом будущем не предвидится.

    Q>>Ну-ну, расскажи, как Linq приводит к падению производительности по сравнению с рукописными циклами над контейнерами. Ты его устройство хоть примерно представляешь?


    _>Какая мне разница как он устроен внутри, если я вижу конкретные цифры на тесте?


    Только что эти цифры означают — ты не видишь. А реальные замеры показывают, что накладные расходы линка в тесте в микроскоп не разглядишь. Ну потому что тест такой — конструирование цепочки ленивых энумераторов выполняется ровно один раз.

    P.S. С++ тест ты, надеюсь, с 16-тибитным чаром скомпилировал?
    Re[33]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 11.04.12 03:43
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

    НС>Какая такая команда split? Ты про System.String.Split() что ли? Вот один из вариантов:

    НС>
      Скрытый текст
    НС>
    НС>        // This function will not keep the Empty String 
    НС>        private String[] InternalSplitOmitEmptyEntries(Int32[] sepList, Int32[] lengthList, Int32 numReplaces, int count) {
    НС>            Contract.Requires(numReplaces >= 0); 
    НС>            Contract.Requires(count >= 2, "Count>=2");
    
    НС>            // Allocate array to hold items. This array may not be
    НС>            // filled completely in this function, we will create a 
    НС>            // new array and copy string references to that new array.
     
    НС>            int maxItems = (numReplaces < count) ? (numReplaces+1): count ; 
    НС>            String[] splitStrings = new String[maxItems];
     
    НС>            int currIndex = 0;
    НС>            int arrIndex = 0;
    
    НС>            for(int i=0; i< numReplaces && currIndex < Length; i++) { 
    НС>                if( sepList[i]-currIndex > 0) {
    НС>                    splitStrings[arrIndex++] = Substring(currIndex, sepList[i]-currIndex ); 
    НС>                } 
    НС>                currIndex=sepList[i] + ((lengthList == null) ? 1 : lengthList[i]);
    НС>                if( arrIndex == count -1 )  { 
    НС>                    // If all the remaining entries at the end are empty, skip them
    НС>                    while( i < numReplaces - 1 && currIndex == sepList[++i]) {
    НС>                        currIndex += ((lengthList == null) ? 1 : lengthList[i]);
    НС>                    } 
    НС>                    break;
    НС>                } 
    НС>            } 
    
    НС>            // we must have at least one slot left to fill in the last string. 
    НС>            Contract.Assert( arrIndex < maxItems, "arrIndex < maxItems");
    
    НС>            //Handle the last string at the end of the array if there is one.
    НС>            if (currIndex< Length) { 
    НС>                splitStrings[arrIndex++] = Substring(currIndex);
    НС>            } 
     
    НС>            String[] stringArray = splitStrings;
    НС>            if( arrIndex!= maxItems) { 
    НС>                stringArray = new String[arrIndex];
    НС>                for( int j = 0; j < arrIndex; j++) {
    НС>                    stringArray[j] = splitStrings[j];
    НС>                } 
    НС>            }
    НС>            return stringArray; 
    НС>        }
    НС>



    Ну так я как раз вижу здесь создание новых сущностей, как я и предполагал.

    НС>Это да. Но это никак не оправдывает неленивую реализацию ReadAllLines.


    Собственно разница должна быть только в расходе памяти. И соответственно для нашего примера не имеет значения (т.к. он влезает в память целиком и значит быстродействие не страдает), но вообще конечно лучше ленивое. Кстати, мой изначальный stl пример как раз так и работал, построчно.
    Re[33]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 11.04.12 04:01
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

    НС>Померял. Получилось 2600 мс на моей машине. Начал смотреть что там время жрет. Оказалось — Int32.Parse. И жрет оно не потому что плохо написано, а потому что этот метод учитывает кучу тонкостей типа сепараторов в числе, настроек локали и т.п. Что то мне подсказывает, что в С++ варианте все намного примитивнее в этом плане.

    НС>Заменяем парсинг на простейший вариант, который все изучали в школе:
    НС>
    НС>static int IntParseFast(string value)
    НС>{
    НС>    var result = 0;
    НС>    for (var i = 0; i < value.Length; i++)
    НС>    {
    НС>        var letter = value[i];
    НС>        result = 10 * result + (letter - 48);
    НС>    }
    НС>    return result;
    НС>}
    НС>


    Только он отрицательные числа не учитывает. ) Ну я подправил в одну строку, что бы вывод у двух тестовых программ совпадал. Кстати, эта строка на быстродействие не повлияла.

    НС>Результат не изменился. Это говорит о том, что реализация файловых потоков в FW существенно лучше.


    Да, C++ потоки — это безусловные тормоза. И раньше про это слышал и вот на этих примерах сам убедился.

    НС>
      Полный исходник
    НС>
    НС>using System;
    НС>using System.Collections.Generic;
    НС>using System.Diagnostics;
    НС>using System.IO;
    НС>using System.Linq;
    НС>using System.Text;
    
    НС>namespace FileLinesTest
    НС>{
    НС>    static class Program
    НС>    {
    НС>        static void GenerateSample()
    НС>        {
    НС>            var rnd = new Random();
    НС>            using (var sw = new StreamWriter("Numbers.txt"))
    НС>                for (var line = 0; line < 1000; line++)
    НС>                {
    НС>                    var sb = new StringBuilder();
    НС>                    for (var i = 0; i < 10000; i++)
    НС>                    {
    НС>                        if (sb.Length != 0)
    НС>                            sb.Append(',');
    НС>                        sb.Append(rnd.Next());
    НС>                    }
    НС>                    sw.WriteLine(sb.ToString());
    НС>                }
    НС>        }
    
    НС>        static void ForEach<T>(this IEnumerable<T> src, Action<T> action)
    НС>        {
    НС>            foreach (var item in src)
    НС>                action(item);
    НС>        }
    
    НС>        static int IntParseFast(string value)
    НС>        {
    НС>            var result = 0;
    НС>            for (var i = 0; i < value.Length; i++)
    НС>            {
    НС>                var letter = value[i];
    НС>                result = 10 * result + (letter - 48);
    НС>            }
    НС>            return result;
    НС>        }
    
    НС>        static IEnumerable<string> ReadAllLines(string fileName)
    НС>        {
    НС>            var fi = new FileInfo(fileName);
    НС>            var buffer = new byte[fi.Length];
    НС>            using (var fs = new FileStream(fileName, FileMode.Open))
    НС>                fs.Read(buffer, 0, buffer.Length);
    
    НС>            string line;
    НС>            using (var sr = new StreamReader(new MemoryStream(buffer)))
    НС>                while ((line = sr.ReadLine()) != null)
    НС>                    yield return line;
    НС>        }
    
    НС>        static void Main(string[] args)
    НС>        {
    НС>            //GenerateSample();
    НС>            var sw = Stopwatch.StartNew();
    НС>            File
    НС>                .ReadAllLines("Numbers.txt")
    НС>                //.AsParallel()
    НС>                .Select(line => line.Split(','))
    НС>                .Where(numbers => numbers.Length > 2)
    НС>                .Select(numbers => numbers.Aggregate(0, (total, number) => total ^ IntParseFast(number)))
    НС>                .OrderByDescending(result => result)
    НС>                .ForEach(Console.WriteLine);
    НС>            sw.Stop();
    НС>            Console.WriteLine("{0} ms", sw.ElapsedMilliseconds);
    НС>        }
    НС>    }
    НС>}
    НС>



    Проверил у себя. Этот код выполняется быстрее варианта stl с потоками, приблизительно одинаковое время с stl загружающей данные через fread (кстати очень характерный момент) и в 2,4 раза медленнее варианта с Boost'ом или же кодом в лоб.
    Re[33]: Красота и краткость
    От: alex_public  
    Дата: 11.04.12 04:51
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

    НС>Ужас то какой.


    Такая реакция на некоторые разделы Boost'a наблюдается у многих. )))

    НС>Так перенес бы, в чем проблема? Или чем меньше строк, тем круче код?


    Не, это мои личные стилевые предпочтения. Из вариантов "две команды на две строки", "одна длинная команда на одну длинную строку", "одна длинна команда на 2 строки" я всегда предпочитаю первый вариант. В соответствие с ним я и написал пример, но на всякий случай уточнил что он вполне записываем и в двух других, т.к. я там просто вынес лямбду в отдельную переменную.

    НС>Примеры таких случаев приведешь?


    Так я вроде бы привёл пример здесь http://www.rsdn.ru/forum/flame.comp/4695770.aspx
    Автор: alex_public
    Дата: 10.04.12
    после чего человек, называвший это отрывом от реальности, резко пропал.

    НС>Хм, вообще то чистый функциональный код по определению декларативен.


    Ха, а вот на эту тему в соседнем разделе был недавно спор. Который начался с тезиса о том что Лисп — это императивный язык. Могу кинуть ссылку, если интересно. Но вообще хочу заметить что даже среди очень немногих языков имеющих само понятие "чистоты функции" у нас наблюдается язык D (наследник C++ — ну никак не декларативный язык).

    НС>Не знаю где ты там в линке sql увидел — в примере обычная цепочка вызовов методов.


    Я уже писал, этo естественно не обращение к sql серверу в привычном понимание. Просто sql — это некий dsl. Он может быть реализован не только внешне, но и внутри любого языка. И соответственно linq — это своебразная реализация под C#. В принципе это только позитивно (мы же не убрали при этом из языка традиционные подходы к работе с коллекциями). Разве что надо понимать что 1. подобный синтаксический сахар сам по себе подходит не ко всем задачам 2. частенько это будет стоить определённых потерь в производительности.

    А вот некоторые фанатики не очень это понимают и уже даже думают что в будущем нечто подобное и в C++ заменит STL.

    НС>В очень узких областях. Там, где хранятся структурированные данные больших объемов, альтернатив SQL-серверам нет и в обозримом будущем не предвидится.


    Это уже вообще отдельная тема для разговора. Но хочу напомнить что как раз на очень больших объёмах nosql базы и начали интенсивно применяться. Достаточно вспомнить как хранят данные всякие там гуглы, фейсбуки, твитеры. И уже даже в opensource можно глянуть серьёзные наработки. HBase, Cassandra и т.п.

    НС>Только что эти цифры означают — ты не видишь. А реальные замеры показывают, что накладные расходы линка в тесте в микроскоп не разглядишь. Ну потому что тест такой — конструирование цепочки ленивых энумераторов выполняется ровно один раз.


    Так я и не говорю что тормозит сам linq, в смысле процесс связывания. Естественно проблемы где-нибудь в лишнем создание/копирование строк и т.п. Но тормозит именно из-за linq! Потому что этот синтаксический сахар навязывает нам определённую архитектуру приводящую к лишним накладным расходам. Просто во многих случаях всем наплеваеть на такие нюансы с памятью и быстродействием, так что можно спокойно наслаждаться симпатичным кодом (естественно когда задача ложится на slq стиль — это ещё не всегда).

    Кстати, замечу что если программировать на stl в её функциональном стиле, то опять же натыкаемся на похожие проблемы. А вот при использование всяческих boost хитростей или же написание императивного кода действующего в лоб уже никаких потерь нет. И кстати при этом boost код ещё и короче всех рассмотренных вариантов вообще.
    Re[34]: Красота и краткость
    От: Qbit86 Кипр
    Дата: 11.04.12 05:10
    Оценка: :))
    Здравствуйте, alex_public, Вы писали:

    _>Интересно чего будет стоить что бы модифицировать тот пример на linq под это условие?


    Императивный код на C# никто ведь не запрещает писать при необходимости.

    _>Код же на boost'е выше можно подправить под это условие парой букв.


    Каких букв?

    _>в xor должны попадать только числа или находящиеся на позиции не большей чем длинна предыдущей строки или стоящие после числа меньше их.


    Учёт предыдущих элементов обычно делается через зип со сдвигом.
    // В xor должны попадать только числа или находящиеся на позиции не большей,
    // чем длина предыдущей строки, или стоящие после числа меньше их.
    var lines = File.ReadAllLines("Numbers.txt").Select(line => line.Split(','));
    var previousLengths = lines.Select(numbers => numbers.Length).StartWith(0);
    var results = lines
        .Select(line => line.Select(Int32.Parse))
        .Zip(previousLengths, (numbers, previousLength) =>
            numbers.StartWith(Int32.MinValue)
                .Zip(numbers, (previous, current) => new { previous, current })
                .Select((value, index) => new { value.previous, value.current, index })
                .Where(value => value.index <= previousLength || value.previous < value.current)
                .Select(value => value.current)
                .Aggregate(0, (total, number) => total ^ number));
    results.OrderByDescending(result => result)
        .ForEach(Console.WriteLine);

    Да, иногда в коде могут использоваться расширения для Linq из Rx (точнее, System.Interactive.dll). Здесь это ForEach() и StartWith(). Но по запросу могу выложить полный трёхстрочный код этих функций.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[34]: Красота и краткость
    От: _d_m_  
    Дата: 11.04.12 06:11
    Оценка: :)
    Здравствуйте, alex_public, Вы писали:

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


    ___>>Ну-ну... хватит фантазий.


    _>Слова Redis, MongoDB и т.п. знакомы? Там ещё несколько десятков таких. И они сейчас уверенно выходят на сцену. Причём как раз в тех областях где раньше безраздельно царили всякие разновидности slq баз.


    Это просто модные тенденции, которые имеют под собой в основе то, что большинство потребителей данной продукции не смогли осилить SQL.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
    Re[35]: Красота и краткость
    От: MxMsk Португалия  
    Дата: 11.04.12 09:09
    Оценка: +1
    Здравствуйте, Qbit86, Вы писали:

    Q>Да, иногда в коде могут использоваться расширения для Linq из Rx (точнее, System.Interactive.dll). Здесь это ForEach() и StartWith(). Но по запросу могу выложить полный трёхстрочный код этих функций.

    А я вот поддерживаю мнение, что ForEach() — это все-таки не Linq. В силу его неленивости.
    Re[35]: Красота и краткость
    От: MxMsk Португалия  
    Дата: 11.04.12 09:17
    Оценка:
    Здравствуйте, _d_m_, Вы писали:

    _>>Слова Redis, MongoDB и т.п. знакомы? Там ещё несколько десятков таких. И они сейчас уверенно выходят на сцену. Причём как раз в тех областях где раньше безраздельно царили всякие разновидности slq баз.

    ___>Это просто модные тенденции, которые имеют под собой в основе то, что большинство потребителей данной продукции не смогли осилить SQL.
    Ты не понимаешь. У этого фаната Плюсов такой способ самоутверждаться — писать побольше базвордов.
    Re[36]: Iter
    От: Qbit86 Кипр
    Дата: 11.04.12 09:35
    Оценка:
    Здравствуйте, MxMsk, Вы писали:

    Q>>Да, иногда в коде могут использоваться расширения для Linq из Rx (точнее, System.Interactive.dll). Здесь это ForEach() и StartWith(). Но по запросу могу выложить полный трёхстрочный код этих функций.

    MM>А я вот поддерживаю мнение, что ForEach() — это все-таки не Linq. В силу его неленивости.

    Linq можно рассматривать как порт стандартных библиотек последовательностей из других функциональных языков. В некоторых наряду с map (Select) есть и iter (ForEach), например, в OCaml/F#.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[36]: Красота и краткость
    От: hattab  
    Дата: 11.04.12 12:03
    Оценка:
    Здравствуйте, MxMsk, Вы писали:

    MM> ___>Это просто модные тенденции, которые имеют под собой в основе то, что большинство потребителей данной продукции не смогли осилить SQL.

    MM> Ты не понимаешь. У этого фаната Плюсов такой способ самоутверждаться — писать побольше базвордов.

    А что, такой любитель передовых морковок все еще не наделся ни на одну из них? Странно это очень, смотри упустишь шанс и будешь потом слюни пускать... Хотя, я видимо упустил из виду, что передовые морковки хороши только от МС
    avalon 1.0rc3 build 428, zlib 1.2.3
    Re[37]: Iter
    От: MxMsk Португалия  
    Дата: 11.04.12 12:59
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Linq можно рассматривать как порт стандартных библиотек последовательностей из других функциональных языков. В некоторых наряду с map (Select) есть и iter (ForEach), например, в OCaml/F#.

    Они выполняются сразу же по месту вызова?
    Re[38]: Iter
    От: Qbit86 Кипр
    Дата: 11.04.12 13:04
    Оценка:
    Здравствуйте, MxMsk, Вы писали:

    Q>>..В некоторых [библиотеках] наряду с map (Select) есть и iter (ForEach), например, в OCaml/F#.

    MM>Они выполняются сразу же по месту вызова?

    А чего ещё ждать от функции с сигнатурой «List.iter : ('T -> unit) -> 'T list -> unit»?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[39]: Iter
    От: MxMsk Португалия  
    Дата: 11.04.12 13:11
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    MM>>Они выполняются сразу же по месту вызова?

    Q>А чего ещё ждать от функции с сигнатурой «List.iter : ('T -> unit) -> 'T list -> unit»?
    Ок. Я F# особо не изучал. Чисто теоретически ForEach можно реализовать как Select, возвращающий исходный список по-элементно, через yield, после применения функции.
    Re[40]: Iter
    От: Qbit86 Кипр
    Дата: 11.04.12 13:13
    Оценка:
    Здравствуйте, MxMsk, Вы писали:

    MM>>>Они выполняются сразу же по месту вызова?

    Q>>А чего ещё ждать от функции с сигнатурой «List.iter : ('T -> unit) -> 'T list -> unit»?
    MM>Ок. Я F# особо не изучал. Чисто теоретически ForEach можно реализовать как Select, возвращающий исходный список по-элементно, через yield, после применения функции.

    Но результирующий ленивый список придётся форсить, чтобы применения процедуры выполнились. Скажем, .ToList(). А зачем оно такое надо?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[41]: Iter
    От: MxMsk Португалия  
    Дата: 11.04.12 13:26
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    MM>>Ок. Я F# особо не изучал. Чисто теоретически ForEach можно реализовать как Select, возвращающий исходный список по-элементно, через yield, после применения функции.

    Q>Но результирующий ленивый список придётся форсить, чтобы применения процедуры выполнились. Скажем, .ToList(). А зачем оно такое надо?
    Форсить тогда, когда надо. ForEach был бы аналогом Observable.Do, чтобы не писать типа:
    query.Select(item => { Action(item); return item; })
    Re: Google code style
    От: Mystic Украина http://mystic2000.newmail.ru
    Дата: 11.04.12 13:26
    Оценка:
    Здравствуйте, Аноним, Вы писали:

    А>А что Вы думаете по этому поводу?


    Еще интернационализация, проще перевести один большой формат целиком, чем гадать, какой кусок от какой фразы мы переводим, если там в серединке вставлен вывод переменной. И будет ли осмыслена вообще потом полученная фраза.
    Re[42]: Iter
    От: Qbit86 Кипр
    Дата: 11.04.12 13:31
    Оценка: +1
    Здравствуйте, MxMsk, Вы писали:

    MM>Форсить тогда, когда надо. ForEach был бы аналогом Observable.Do, чтобы не писать типа:


    Не, на самом деле, ForEach был аналогом Observable.Run() :) Он даже так и назывался в первых версиях Ix.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[38]: Iter
    От: FR  
    Дата: 11.04.12 15:00
    Оценка:
    Здравствуйте, MxMsk, Вы писали:

    Q>>Linq можно рассматривать как порт стандартных библиотек последовательностей из других функциональных языков. В некоторых наряду с map (Select) есть и iter (ForEach), например, в OCaml/F#.

    MM>Они выполняются сразу же по месту вызова?

    И OCaml и F# и даже их предок вообще-то ко всему и вполне полноценные императивные языки
    Правда тот же List.iter в OCaml изменить список по месту не даст, так как список иммутабельный,
    но вот функцию с сигнатурой 'a -> unit бессмысленной в чистом ФЯ вызывает без проблем.
    Re[34]: Коллекции .NET и контейнеры STL
    От: Ночной Смотрящий Россия  
    Дата: 11.04.12 21:47
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ну так я как раз вижу здесь создание новых сущностей, как я и предполагал.


    Не понял, что ты там видишь.
    Re[34]: Коллекции .NET и контейнеры STL
    От: Ночной Смотрящий Россия  
    Дата: 11.04.12 21:47
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Только он отрицательные числа не учитывает. )


    Ну ты же понимаешь, что анализ минуса заметно на перформансе не скажется?

    _>Да, C++ потоки — это безусловные тормоза. И раньше про это слышал и вот на этих примерах сам убедился.


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

    _>Проверил у себя. Этот код выполняется быстрее варианта stl с потоками, приблизительно одинаковое время с stl загружающей данные через fread (кстати очень характерный момент) и в 2,4 раза медленнее варианта с Boost'ом или же кодом в лоб.


    Ну, код в лоб я и на .NET написать могу.
    Re[34]: Красота и краткость
    От: Ночной Смотрящий Россия  
    Дата: 11.04.12 21:47
    Оценка: 1 (1)
    Здравствуйте, alex_public, Вы писали:

    НС>>Ужас то какой.

    _>Такая реакция на некоторые разделы Boost'a наблюдается у многих. )))

    И?

    НС>>Так перенес бы, в чем проблема? Или чем меньше строк, тем круче код?

    _>Не, это мои личные стилевые предпочтения.

    Ну то есть таки да

    НС>>Примеры таких случаев приведешь?


    _>Так я вроде бы привёл пример здесь http://www.rsdn.ru/forum/flame.comp/4695770.aspx
    Автор: alex_public
    Дата: 10.04.12
    после чего человек, называвший это отрывом от реальности, резко пропал.


    Вот эта фраза:

    в xor должны попадать только числа или находящиеся на позиции не большей чем длинна предыдущей строки или стоящие после числа меньше их.


    по правилам русской грамматики не парсится.

    НС>>Хм, вообще то чистый функциональный код по определению декларативен.


    _>Ха, а вот на эту тему в соседнем разделе был недавно спор. Который начался с тезиса о том что Лисп — это императивный язык. Могу кинуть ссылку, если интересно. Но вообще хочу заметить что даже среди очень немногих языков имеющих само понятие "чистоты функции" у нас наблюдается язык D (наследник C++ — ну никак не декларативный язык).


    Pure function и pure functional это не одно и тоже.

    In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.


    _>Я уже писал, этo естественно не обращение к sql серверу в привычном понимание. Просто sql — это некий dsl. Он может быть реализован не только внешне, но и внутри любого языка.


    А list comprehension в Лиспе — это тоже sql? Что то я не пойму, в какой момент у тебя continuation monad превращается в sql?

    _> И соответственно linq — это своебразная реализация под C#.


    Реализация чего? Просто какого то DSL? В C# много подобных "DSL". Все из них являются sql? Или только какие то конкретные синтаксические конструкции? Какие и почему?

    _>Разве что надо понимать что 1. подобный синтаксический сахар сам по себе подходит не ко всем задачам


    Какой синтаксический сахар ты имеешь в виду? По сравнению с С++ в тесте ровно одна новая конструкция — extension methods. К каким задачам он не подходит?

    _> 2. частенько это будет стоить определённых потерь в производительности.


    extension methods никогда не приводят к потерям производительности, это просто статические методы, только синтаксис вызова похитрее. Или ты про лямбды?

    _>А вот некоторые фанатики не очень это понимают и уже даже думают что в будущем нечто подобное и в C++ заменит STL.


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

    НС>>В очень узких областях. Там, где хранятся структурированные данные больших объемов, альтернатив SQL-серверам нет и в обозримом будущем не предвидится.


    _>Это уже вообще отдельная тема для разговора.


    Не я ее завел.

    _> Но хочу напомнить что как раз на очень больших объёмах nosql базы и начали интенсивно применяться.


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

    _> Достаточно вспомнить как хранят данные всякие там гуглы, фейсбуки, твитеры.


    Вот вот. Осталось задаться вопросом, почему ни одна ERP не использует эти новомодные map-reduce сотоварищи.

    _>Так я и не говорю что тормозит сам linq, в смысле процесс связывания.


    А что тормозит? extension methods? Лямбды? foreach?

    _> Естественно проблемы где-нибудь в лишнем создание/копирование строк и т.п.


    Нет там лишнего копирования.

    _> Но тормозит именно из-за linq!


    LINQ это абстракция. Из-за него не может ничего тормозить. Но мне очень интересно, на основании чего ты сделал такие выводы.

    _> Потому что этот синтаксический сахар навязывает нам определённую архитектуру приводящую к лишним накладным расходам.


    Что именно он навязывает? Конкретно.

    _> Просто во многих случаях всем наплеваеть на такие нюансы с памятью и быстродействием, так что можно спокойно наслаждаться симпатичным кодом (естественно когда задача ложится на slq стиль — это ещё не всегда).


    Что такое sql-стиль?

    _>Кстати, замечу что если программировать на stl в её функциональном стиле, то опять же натыкаемся на похожие проблемы.


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

    _> А вот при использование всяческих boost хитростей или же написание императивного кода действующего в лоб уже никаких потерь нет.


    Если это всегда выливается в тот ужас ужас, что ты продемонстрировал, то такое надо применять только в сверхкрайних случаях.

    _> И кстати при этом boost код ещё и короче всех рассмотренных вариантов вообще.


    Ну еще бы, если все в одну строчку запихать.
    Re[36]: Красота и краткость
    От: Ночной Смотрящий Россия  
    Дата: 11.04.12 21:52
    Оценка:
    Здравствуйте, MxMsk, Вы писали:

    MM>А я вот поддерживаю мнение, что ForEach() — это все-таки не Linq. В силу его неленивости.


    Неленивость это фигня, даже в standard query pattern дофига неленивых методов, тот же Count или там Any. Прежде всего он императивен и с побочными эффектами.
    Re[35]: Красота и краткость
    От: alex_public  
    Дата: 11.04.12 22:32
    Оценка: :)
    Здравствуйте, Qbit86, Вы писали:

    Q>Императивный код на C# никто ведь не запрещает писать при необходимости.


    Вооот, наконец то! И я про это. Что частенько императивный код намного эффективнее. А linq заточен совсем под другую модель, так что в определённых случаях неудобен (а позиционировался то тут как универсальные контейнеры). Что я и сказал, а ты сразу про отрыв от реальности... )))

    _>>Код же на boost'е выше можно подправить под это условие парой букв.

    Q>Каких букв?

    Там две лямбды (первая вызывается после каждого числа, а вторая после каждой строки). Из второй if убираем, а в первую добавляем. И всё. По объёму код даже не изменится.

    Q>Учёт предыдущих элементов обычно делается через зип со сдвигом.

    Q>
    Q>// В xor должны попадать только числа или находящиеся на позиции не большей,
    Q>// чем длина предыдущей строки, или стоящие после числа меньше их.
    Q>var lines = File.ReadAllLines("Numbers.txt").Select(line => line.Split(','));
    Q>var previousLengths = lines.Select(numbers => numbers.Length).StartWith(0);
    Q>var results = lines
    Q>    .Select(line => line.Select(Int32.Parse))
    Q>    .Zip(previousLengths, (numbers, previousLength) =>
    Q>        numbers.StartWith(Int32.MinValue)
    Q>            .Zip(numbers, (previous, current) => new { previous, current })
    Q>            .Select((value, index) => new { value.previous, value.current, index })
    Q>            .Where(value => value.index <= previousLength || value.previous < value.current)
    Q>            .Select(value => value.current)
    Q>            .Aggregate(0, (total, number) => total ^ number));
    Q>results.OrderByDescending(result => result)
    Q>    .ForEach(Console.WriteLine);
    Q>


    А вот это и есть реальная жуть. Причём исключительно из-за желания всунуть linq туда, куда оно не подходит. На том же C# можно было написать императивный код намного короче, яснее и при этом скорее всего быстрее работающий (чем этот, а не C++ естественно ).

    Тестировать быстродействие этого дела даже не буду — наверняка там что-то уже совсем печальное. ))) Да и собственно уже ни к чему. Т.к. когда у нас есть некий синтаксических сахар, позволяющий писать красивый код ценой некого падения быстродействия, то имеет смысл оценить размер этого падения (вдруг он допустимый для нашей задачи). Как было в примере на предыдущую задачку (там я не спорю, что решение на linq выглядело красиво). А тут у нас уже и код страшный — даже уже нет смысла смотреть что-то дальше.
    Re[35]: Красота и краткость
    От: alex_public  
    Дата: 11.04.12 22:40
    Оценка:
    Здравствуйте, _d_m_, Вы писали:

    ___>Это просто модные тенденции, которые имеют под собой в основе то, что большинство потребителей данной продукции не смогли осилить SQL.


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

    А теперь уже и мелкие системы идут по тому же пути, только используя не свои велосипеды, а коллективные разработки или же подаренные теми же корпорациями. Естественно вовсе не потому что nosql решения могут держать большую нагрузку и проще масштабироваться, а просто по глупости — обезьянничают со старших коллег. )))
    Re[36]: Синтаксический сахар
    От: Qbit86 Кипр
    Дата: 11.04.12 22:53
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>>>Код же на boost'е выше можно подправить под это условие парой букв.

    Q>>Каких букв?
    _>Там две лямбды (первая вызывается после каждого числа, а вторая после каждой строки). Из второй if убираем, а в первую добавляем. И всё. По объёму код даже не изменится.

    Всё же конкретнее. Даже исходная формулировка задачи на русском была непростой для парсинга, пусть тут полежит законченный кусок на C++ для сравнения. Может, окажется, что я и условие-то неправильно понял.

    Q>>Учёт предыдущих элементов обычно делается через зип со сдвигом.

    _>А вот это и есть реальная жуть.

    Усложнилась задача — усложнилось решение.

    _>Причём исключительно из-за желания всунуть linq туда, куда оно не подходит.


    У меня такого желания нет: «Императивный код на C# никто ведь не запрещает писать при необходимости». Просто предоставил требуемый вариант.

    _>Тестировать быстродействие этого дела даже не буду — наверняка там что-то уже совсем печальное. )))


    К тебе как эксперту по языкам
    Автор: alex_public
    Дата: 16.02.12
    вопрос: есть представление об итераторах (yield return) в C#?

    _>Т.к. когда у нас есть некий синтаксических сахар, позволяющий писать красивый код ценой некого падения быстродействия, то имеет смысл оценить размер этого падения (вдруг он допустимый для нашей задачи).


    Можешь сформулировать, в чём заключается этот синтаксический сахар?

    _>А тут у нас уже и код страшный — даже уже нет смысла смотреть что-то дальше.


    Сложность кода возросла сообразно сложности задачи.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[35]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 11.04.12 23:11
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

    _>>Ну так я как раз вижу здесь создание новых сущностей, как я и предполагал.

    НС>Не понял, что ты там видишь.

    Создание массива строк.
    Re[35]: Коллекции .NET и контейнеры STL
    От: alex_public  
    Дата: 11.04.12 23:27
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

    _>>Только он отрицательные числа не учитывает. )

    НС>Ну ты же понимаешь, что анализ минуса заметно на перформансе не скажется?

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

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


    Хм, что-то я не уверен что там дело в примитивности. Больше ощущение что там что-то лишнее делается. Т.к. низкоуровневый C код работает без потерь скорости. Вообще лень копаться в этом уже, т.к. на практике я не использую ни то, ни другое. ))) Но для себя я однозначный вывод в тормознутость C++ потоков сделал.

    НС>Ну, код в лоб я и на .NET написать могу.


    Не сомневаюсь. Кстати, аналог этого раздела Boost'а для .Net тоже есть, сам видел. Так что в теории и на .Net возможен похожий вариант. Правда есть небольшой нюанс Boost — это стандарт де факто C++, постепенно переползающий в стандартную библиотеку, а для .Net я видел просто частное решение... Но в принципе возможно. Вот было бы интересно сравнить их по скорости — это было бы уже сравнения типа native vs. clr. ))) Но не охота, и так тема уже утомила, да и проблемность linq с которой всё началось уже всем показана.
    Re[35]: Красота и краткость
    От: alex_public  
    Дата: 12.04.12 00:29
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

    НС>Вот эта фраза:

    НС>

    НС>в xor должны попадать только числа или находящиеся на позиции не большей чем длинна предыдущей строки или стоящие после числа меньше их.

    НС>по правилам русской грамматики не парсится.

    A Qbit86 без проблем понял и даже умудрился втиснуть задачку в рамки linq. )))

    НС>Pure function и pure functional это не одно и тоже.

    НС>

    НС>In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.


    Вот именно. ) Это именно парадигма. Причём большинство современных популярных языков являются мультипарадигменными. Например D поддерживает функциональную парадигму побольше многих и при этом не является декларативным. А Пролог — пример декларативного языка без функциональной парадигмы. Так что я не пойму зачем смешивать эти понятия.

    НС>Что то я не пойму, в какой момент у тебя continuation monad превращается в sql?


    С того момента, как это было задумано их создателями. )

    НС>Реализация чего? Просто какого то DSL? В C# много подобных "DSL". Все из них являются sql? Или только какие то конкретные синтаксические конструкции? Какие и почему?

    Я вроде бы всё очень конкретно написал. Читай внимательнее. )

    НС>Какой синтаксический сахар ты имеешь в виду? По сравнению с С++ в тесте ровно одна новая конструкция — extension methods. К каким задачам он не подходит?

    Синтаксический сахар может реализовываться не только самим языком, но и библиотеками. Вся linq — это один больший синтаксический сахар.

    НС>extension methods никогда не приводят к потерям производительности, это просто статические методы, только синтаксис вызова похитрее. Или ты про лямбды?

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

    НС>Я не фанатик, но с появлением лямбд обязательно что то похожее появится. Хотя без замыканий, конечно, будет тяжко.


    Вообще то они давно есть (и появились раньше linq), но используют их исключительно как синтаксический сахар к доступу на sql сервера. Как замену стандартным контейнерам никто даже и не думает использовать подобные конструкции.

    Ну и с замыканиями то тоже проблем не видно — собственно мой код в этой теме их постоянно использовал.

    НС>Неструктурированных данных. Я даже выделил жирным ключевое слово, но ты таки умудрился его проигнорировать.


    Там разные есть и далеко не только ключ-значение. Посмотри внимательнее например MongoDB.

    НС>Вот вот. Осталось задаться вопросом, почему ни одна ERP не использует эти новомодные map-reduce сотоварищи.


    Когда я писал что эти технологии наступают, я не имел в виду что все бросились срочно переписывать свой код под новые принципы. Тем более такие монстры — у них переписывание кода по любому не окупиться. Процесс идёт по другому: новые проекты всё чаще и чаще берут за базис эти технологии. Так что не удивлюсь если какая-то новая ERP использует такой подход. А старые естественно пока остануся с sql. Слишком много в него уже вложено.

    НС>Нет там лишнего копирования.


    Судя по коду функции split более чем достаточно его.

    _>> Потому что этот синтаксический сахар навязывает нам определённую архитектуру приводящую к лишним накладным расходам.

    НС>Что именно он навязывает? Конкретно.

    Провоцирует генерировать лишние промежуточные структуры данных (которые программист часто и не видит), которые реально и не нужны в решение данной задачи.

    _>>Кстати, замечу что если программировать на stl в её функциональном стиле, то опять же натыкаемся на похожие проблемы.

    НС>Мы натыкаемся на гораздо большее количество проблем, с чего, собственно, этот тред и начался.

    Где больше то? Размер и читабельность кода одинаковая, быстродействие выше. Где большие проблемы?

    _>> А вот при использование всяческих boost хитростей или же написание императивного кода действующего в лоб уже никаких потерь нет.

    НС>Если это всегда выливается в тот ужас ужас, что ты продемонстрировал, то такое надо применять только в сверхкрайних случаях.

    На самом деле это всего лишь Форма Бэкуса—Наура адаптированная под C++ синтаксис. Так что никакого "ужас ужас" для хотя бы раз взглянувших на документацию библиотеки там нет.

    _>> И кстати при этом boost код ещё и короче всех рассмотренных вариантов вообще.

    НС>Ну еще бы, если все в одну строчку запихать.

    linq пример помнится был вообще в одну строку, только такую, что её пришлось перенести мнооого раз. )))
    Re[37]: Синтаксический сахар
    От: alex_public  
    Дата: 12.04.12 02:34
    Оценка: :)
    Здравствуйте, Qbit86, Вы писали:

    Вот ты будешь смеяться, но пока я писал Ночному Смотрящему про недостатки навязываемые linq, то понял что я сам умудрился засунуть подобный недостаток (хотя и мелкий совсем) даже в код с Boost'ом! Вот до чего доводить копипаст и автоматическая работа, вместо того что бы на секунду задуматься. Естественно там не нужен никакой промежуточный вектор (он пришёл копипастом из stl кода) и вся эта фигня с алгоритмами. Даже не представляю как я мог ТАКУЮ ерунду пропустить, устал видимо. Или же вредное влияние linq коснулось уже и меня и надо скорее заканчивать это обсуждение, пока совсем не заразился.))) Поправил код сейчас. И что самое забавное, особо быстрее он конечно не стал, но зато стал намного проще и читабельнее. Вот нормальный вариант:

    multiset<int> result;
    int xor=0, count=0;
    parse(buf.get(), buf.get()+size,
        (*(int_[[&](int n,...){xor^=n; count++;}] % ',' >> -eol)[[&](...){if(count>2) result.insert(xor); count=xor=0;}]));
    for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;


    Q>Всё же конкретнее. Даже исходная формулировка задачи на русском была непростой для парсинга, пусть тут полежит законченный кусок на C++ для сравнения. Может, окажется, что я и условие-то неправильно понял.


    Что касается нового варианта, то раз вектора у нас уже нет, то придётся не только if подвинуть, но и переменную добавить, ну и на этом всё:

    multiset<int> result;
    int xor=0, count=0, prev=0, prev_count=0;
    parse(buf.get(), buf.get()+size,
        (*(int_[[&](int n,...){if(++count<=prev_count||n>prev) xor^=n; prev=n;}] % ',' >> -eol)[[&](...){result.insert(xor); prev_count=count; prev=count=xor=0;}]));
    for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;


    Q>Усложнилась задача — усложнилось решение.

    Да не настолько то она усложнилась. Ну условие чуть другое, немного сложнее, но это же не повод что бы писать ТАКИЕ многоэтажные конструкции.

    Q>У меня такого желания нет: «Императивный код на C# никто ведь не запрещает писать при необходимости». Просто предоставил требуемый вариант.


    Я прекрасно понимаю что ты не стал бы писать такое в реальности, а сделал бы нормальный императивный код. Просто тогда тебе осталось честно признать что есть много задач на которые linq парадигма плохо ложиться. Как я собственно и утверждал в самом начале, посмотрев на неё.

    Q>К тебе как эксперту по языкам
    Автор: alex_public
    Дата: 16.02.12
    вопрос: есть представление об итераторах (yield return) в C#?


    Такое же как в Питоне? Оно частенькое используется у нас в серверном коде)

    Q>Можешь сформулировать, в чём заключается этот синтаксический сахар?


    SQL подобный синтаксис обработки коллекций.

    Q>Сложность кода возросла сообразно сложности задачи.


    Даже близко не сравнимо.
    Re[36]: Upwards funarg problem
    От: Qbit86 Кипр
    Дата: 12.04.12 05:28
    Оценка: +1
    Здравствуйте, alex_public, Вы писали:

    _>A Qbit86 без проблем понял и даже умудрился втиснуть задачку в рамки linq. )))


    Ну, я не сказал бы, что понял без проблем :)

    НС>>Хотя без замыканий, конечно, будет тяжко.

    _>Ну и с замыканиями то тоже проблем не видно — собственно мой код в этой теме их постоянно использовал.

    Лямбды в C++ не решают upwards funarg problem, поэтому не могут считаться полноценными замыканиями.

    _>linq пример помнится был вообще в одну строку, только такую, что её пришлось перенести мнооого раз. )))


    Нет, то был один statement, разбитый на несколько строк для выделения логических единиц. (Это как раз противоположно тому, чтобы запихнуть много statement'ов в одну строку.) Такой «конвейер» вполне типичен для ФЯПов, см., например, оператор |> в F# или его (противоположно направленного) коллегу $ из Haskell. В C++ аналогом такой конструкции мог бы служить operator <<().
    Глаза у меня добрые, но рубашка — смирительная!
    Re[38]: Синтаксический сахар
    От: Qbit86 Кипр
    Дата: 12.04.12 05:40
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>
    multiset<int> result;
    _>int xor=0, count=0, prev=0, prev_count=0;
    _>parse(buf.get(), buf.get()+size,
    _>    (*(int_[[&](int n,...){if(++count<=prev_count||n>prev) xor^=n; prev=n;}] % ',' >> -eol)[[&](...){result.insert(xor); prev_count=count; prev=count=xor=0;}]));
    _>for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;

    Q>>Усложнилась задача — усложнилось решение.
    _>Да не настолько то она усложнилась. Ну условие чуть другое, немного сложнее, но это же не повод что бы писать ТАКИЕ многоэтажные конструкции.

    Так в плюсовом варианте не менее многоэтажная конструкция, просто записана в одну строку.

    _>>>Тестировать быстродействие этого дела даже не буду — наверняка там что-то уже совсем печальное. )))

    Q>>К тебе как эксперту по языкам
    Автор: alex_public
    Дата: 16.02.12
    вопрос: есть представление об итераторах (yield return) в C#?

    _>Такое же как в Питоне? Оно частенькое используется у нас в серверном коде)

    И что в этих итераторах печального?

    _>>>Т.к. когда у нас есть некий синтаксических сахар, позволяющий писать красивый код ценой некого падения быстродействия, то имеет смысл оценить размер этого падения (вдруг он допустимый для нашей задачи).

    Q>>Можешь сформулировать, в чём заключается этот синтаксический сахар?
    _>SQL подобный синтаксис обработки коллекций.

    Так я его не использовал. Я использовал простые конструкции типа «вызов метода», «анонимный метод», etc. Даже если б использовал сахар, то CLR всё равно о нём ничего не знает, компилирует всё в обычные вызовы, в чём можно убедиться, декомпилировав сборку в Рефлекторе. В чём здесь выразится падение быстродействия fluent-вызовов («цепочки», «конвейера») «x.h().g().f()» по сравнению с вложенными вызовами «(f(g(h(x))))»?
    Глаза у меня добрые, но рубашка — смирительная!
    Re[36]: Красота и краткость
    От: _d_m_  
    Дата: 12.04.12 06:42
    Оценка:
    Здравствуйте, alex_public, Вы писали:

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


    ___>>Это просто модные тенденции, которые имеют под собой в основе то, что большинство потребителей данной продукции не смогли осилить SQL.


    _>Ну да, конечно, всякие там гуглы, амазоны, фейсбуки, яндексы — это просто неумехи. Они хотели бы на mysql построить свои системы, но не осилили просто. Поэтому пришлось городить свои велосипеды. )))


    На чем на чем? На самом говне из всех SQL-ей — на MySQL?
    А таки гугли лепили себе узкоспециализированое решение, и дешевле им было сваять с нуля, чем покупать лицензии у каких-нибудь Ораклов, МС или АйБиЭм. Ну если ты пишешь второй гугль — то тогда канешна... Флаг в руки и электричка навстречу

    _>А теперь уже и мелкие системы идут по тому же пути, только используя не свои велосипеды, а коллективные разработки или же подаренные теми же корпорациями. Естественно вовсе не потому что nosql решения могут держать большую нагрузку и проще масштабироваться, а просто по глупости — обезьянничают со старших коллег. )))


    +500
    Даже людям с альтернативным развитием приходят в голову умные мысли. Только они думают, что это полный идиотизм
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
    Re[37]: Upwards funarg problem
    От: alex_public  
    Дата: 12.04.12 07:20
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Лямбды в C++ не решают upwards funarg problem, поэтому не могут считаться полноценными замыканиями.


    Хы, ну в C++ все уже привыкли сами следить за ресурсами, организовавать ROII, знать что выделять на стеке. Так что это не проблема. Как видно из моих примеров тут замыкания используются по полной и всё очень удобно.

    Q>Нет, то был один statement, разбитый на несколько строк для выделения логических единиц. (Это как раз противоположно тому, чтобы запихнуть много statement'ов в одну строку.) Такой «конвейер» вполне типичен для ФЯПов, см., например, оператор |> в F# или его (противоположно направленного) коллегу $ из Haskell. В C++ аналогом такой конструкции мог бы служить operator <<().


    Да я понял. Кстати в Boost такой конвеер задаётся оператором |. Просто я не люблю организовывать такие длинные выражения. И одновременно не люблю переносить одно выражение на несколько строк. Мне приятнее написать допустим 2 выражения на 2 строки. Но это мои личные вкусовые пристрастия. И я для примера написал последний Boost пример уже в виде одного выражения на несколько строк (т.е. не в своём стиле). Хотя там без проблем можно 2 лямбды выделить в отдельные выражения.
    Re[39]: Синтаксический сахар
    От: alex_public  
    Дата: 12.04.12 07:47
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Так в плюсовом варианте не менее многоэтажная конструкция, просто записана в одну строку.


    Эээ, она почти не изменилась с предыдущими примером. Т.е. у нас ситуация следующая:
    Первый пример — linq код красив, boost код читаем
    Второй пример — linq код дико ужасен, boost код практически не изменился.

    Об этом и была речь. И я думаю что никто не сомневается что можно придумать ещё множество условий приводящих к ещё более печальной ситуации с linq.

    Q>И что в этих итераторах печального?


    Ничего печального) yield — очень хорошая и удобная вещь.

    Q>Так я его не использовал. Я использовал простые конструкции типа «вызов метода», «анонимный метод», etc. Даже если б использовал сахар, то CLR всё равно о нём ничего не знает, компилирует всё в обычные вызовы, в чём можно убедиться, декомпилировав сборку в Рефлекторе. В чём здесь выразится падение быстродействия fluent-вызовов («цепочки», «конвейера») «x.h().g().f()» по сравнению с вложенными вызовами «(f(g(h(x))))»?


    Оооооооооооооооох. Я же вроде бы уже десяток раз в этой темке ткнул в нужное место.

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

    А больше всего меня забавляет что со мной спорят именно по этому вопросу. Смотри, у нас есть неоспоримый экспериментальный факт тормознутости linq кода в 5 (!!!) раз по сравнению с C++. Я пытаюсь хоть как-то объяснить его происхождение, хотя это как бы не моё дело — мне достаточно самого экспериментального факта, т.к. я то со стороны C++ смотрю. Но со мной не соглашаются, при этом не выдвигая никаких своих вариантов. Ну предположим что я не прав и парадигма навязываемая linq ни при чём. Что тогда то? Просто сам clr и .net кривые и тормознутые что ли? Или что? )))
    Re[37]: Красота и краткость
    От: alex_public  
    Дата: 12.04.12 07:51
    Оценка:
    Здравствуйте, _d_m_, Вы писали:

    ___>На чем на чем? На самом говне из всех SQL-ей — на MySQL?


    Это была ирония. ))) Раз трудности даже с пониманием этого, то беседовать дальше просто бесполезно. )
    Re[40]: Синтаксический сахар
    От: Qbit86 Кипр
    Дата: 12.04.12 08:12
    Оценка: :)
    Здравствуйте, alex_public, Вы писали:

    _>Эээ, она почти не изменилась с предыдущими примером. Т.е. у нас ситуация следующая:

    _>Первый пример — linq код красив, boost код читаем
    _>Второй пример — linq код дико ужасен, boost код практически не изменился.

    Ну, это субъективные оценочные суждения :)

    _>Оооооооооооооооох. Я же вроде бы уже десяток раз в этой темке ткнул в нужное место.

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

    Так это к Linq'у вообще никакого отношения не имеет, к синтаксическому сахару какому-то тем более. String.Split() из Framework Class Library — это первый попавшийся под руку кондовый прямолинейный метод из, емнип, ещё до'generic'овой эпохи .NET, когда Linq'а и в помине не было.

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


    Код методов-расширений из Linq чудовищно простой и катастрофически прямолинейный. Например,
    public static TAccumulate Aggregate<TSource, TAccumulate>(
      this IEnumerable<TSource> source, TAccumulate seed, Func<TAccumulate, TSource, TAccumulate> func)
    {
      if (source == null)
      {
        throw Error.ArgumentNull("source");
      }
      else if (func == null)
      {
        throw Error.ArgumentNull("func");
      }
      else
      {
        TAccumulate accumulate = seed;
        foreach (TSource source1 in source)
          accumulate = func(accumulate, source1);
        return accumulate;
      }
    }


    _>А больше всего меня забавляет что со мной спорят именно по этому вопросу. Смотри, у нас есть неоспоримый экспериментальный факт тормознутости linq кода в 5 (!!!) раз по сравнению с C++.


    Доказательство в духе «Как вы можете не верить, что я, Мюнхгаузен, вытащил себя за косичку из болота? Вот же я, живой!» Т.е. ты свои измерения трактуешь произвольно.

    _>Но со мной не соглашаются, при этом не выдвигая никаких своих вариантов.


    Ты переоцениваешь желание собеседников профилировать библиотечный код и что-то там доказывать про призводительность.

    _>Ну предположим что я не прав и парадигма навязываемая linq ни при чём. Что тогда то? Просто сам clr и .net кривые и тормознутые что ли? Или что? )))


    Это вопросы к Ants Memory Profiler.
    Глаза у меня добрые, но рубашка — смирительная!
    Re[41]: Синтаксический сахар
    От: alex_public  
    Дата: 12.04.12 10:54
    Оценка:
    Здравствуйте, Qbit86, Вы писали:

    Q>Так это к Linq'у вообще никакого отношения не имеет, к синтаксическому сахару какому-то тем более. String.Split() из Framework Class Library — это первый попавшийся под руку кондовый прямолинейный метод из, емнип, ещё до'generic'овой эпохи .NET, когда Linq'а и в помине не было.


    Ох. Да дело не в быстродействие split. Вы можете хоть заоптимизировать её, но всё равно будут те же проблемы. Дело в том, что для применения linq методов вам необходима коллекция, пускай даже и ленивая. Поэтому её надо как-то обязательно создать. В данном случае это делает split (и возможно оно действительно не такое быстрое как могло бы быть), но в принципе это не важно. Главное сам факт существования этой коллекции, потому что если реально посмотреть на задачу, то никакие коллекции кроме начального массива данных и итогового (и то только для сортировки) нам не нужны! Но мы создаём промежуточные, что бы использовать linq.

    Так что вы можете вылизывать подобный код сколько угодно, заменить все функции своими вариантами, но пока хотите работать в парадигме linq у вас по любому будет провал в производительности на подобных задачах.

    Хотя как я уже писал для многих случаев это вполне терпимо.

    Q>Доказательство в духе «Как вы можете не верить, что я, Мюнхгаузен, вытащил себя за косичку из болота? Вот же я, живой!» Т.е. ты свои измерения трактуешь произвольно.


    Я вообще то все коды здесь выкладывал — любой может повторить. Если у кого проблемы с компилятором C++ или Бустом, то могу выложить exe. Каждый может убедиться сам.

    Q>Это вопросы к Ants Memory Profiler.


    Ну в любом случае это не ко мне. Мне достаточно что я знаю распределение в C++ коде и знаю что он быстрее .Net варианта в 5 раз. Остальное оставлю другим экспериментаторам.

    И вообще думаю что пора завершить дискуссию. В данный момент мне кажется что мы наконец то до конца поняли позиции друга друга и все обоснования позиций. И даже умудрились отбросить всякие оскорбительные выпады, перейдя к более менее конструктивному диалогу. Правда этого оказалось недостаточно что бы одна из сторон публично признала правоту другой, ну да ладно, хотя бы так. )))
    Re[36]: Красота и краткость
    От: Ночной Смотрящий Россия  
    Дата: 12.04.12 18:18
    Оценка: 1 (1) -1
    Здравствуйте, alex_public, Вы писали:

    _>Вот именно. ) Это именно парадигма.


    И?

    _> Причём большинство современных популярных языков являются мультипарадигменными.


    И?

    _>А Пролог — пример декларативного языка без функциональной парадигмы.


    И?

    _> Так что я не пойму зачем смешивать эти понятия.


    А кто их смешивает? Ты хвостом то не верти — я тебе пытался объяснить одну простую вещь: чистый функциональный стиль декларативен по определению. При чем тут парадигма, популярные языки и Пролог?

    НС>>Что то я не пойму, в какой момент у тебя continuation monad превращается в sql?

    _>С того момента, как это было задумано их создателями. )

    Т.е. с 91 года, когда монады появились в ФП? Или еще раньше, когда одноименное понятие появилось в теории категорий?

    НС>>Реализация чего? Просто какого то DSL? В C# много подобных "DSL". Все из них являются sql? Или только какие то конкретные синтаксические конструкции? Какие и почему?

    _>Я вроде бы всё очень конкретно написал.

    Нет, ты не написал ничего конкретного. Единственная фраза была про то, что виноват linq. Но linq это не синтаксическая конструкция, это просто маркетинговый бренд. Поэтому еще раз — какие конкретно элементы синтаксиса C# ответственны за превращение в SQL и тормоза?

    НС>>Какой синтаксический сахар ты имеешь в виду? По сравнению с С++ в тесте ровно одна новая конструкция — extension methods. К каким задачам он не подходит?

    _>Синтаксический сахар может реализовываться не только самим языком, но и библиотеками.

    В C# не может, там метапрограммирования нет даже в том страшном виде, в каком оно есть в С++. Так что никаких библиотек. Да если бы и библиотеки — я тебе почти все использованные методы класса Enumerable воспроизведу на коленке за 10 минут.
    К примеру:
    public static IEnumerable<T> Where<T>(this IEnumerable<T> src, Func<T, bool> predicate)
    {
      foreach (var item in src)
          if (predicate(item))
              yield return item;
    }
    
    public static IEnumerable<P> Select<T,P>(this IEnumerable<T> src, Func<T, P> projector)
    {
      foreach (var item in src)
            yield return projector(src);
    }

    Что здесь SQL? Что здесь тормозит? Если вместо IEnumerable<T> аргументом для query pattern будет T[], а внутри вместо foreach будет обычный for, это все равно будет SQL?

    А больше там ничего хоть отдаленно имеющего отношение к LINQ нет.

    _> Вся linq — это один больший синтаксический сахар.


    Предположим. Так что конкретно там тормозит? Или тормозят вообще все нововведения в C# 3?

    НС>>extension methods никогда не приводят к потерям производительности, это просто статические методы, только синтаксис вызова похитрее. Или ты про лямбды?

    _>Я про навязываемую архитектуру.

    Моя твоя не понимать. Какую такую архитектуру?

    _> Естественно умные люди просто не будут применять её в неподходящих случаях (или же будут, если их априори не волнует быстродействие в данном участке кода).


    Мммм. Я дождусь, наконец, от тебя конкретики? Что конкретно, по твоему, тормозит?

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


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

    _>Вообще то они давно есть


    Лямбды? В предыдущем С++? Ты о чем? Об изврате из буста что ли? Это не лямбды, это плохая пародия на них.

    _>но используют их исключительно как синтаксический сахар к доступу на sql сервера.




    _> Как замену стандартным контейнерам никто даже и не думает использовать подобные конструкции.


    Ты о чем вообще? Нить разговора не потерял?

    НС>>Неструктурированных данных. Я даже выделил жирным ключевое слово, но ты таки умудрился его проигнорировать.

    _>Там разные есть и далеко не только ключ-значение. Посмотри внимательнее например MongoDB.

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

    НС>>Вот вот. Осталось задаться вопросом, почему ни одна ERP не использует эти новомодные map-reduce сотоварищи.

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

    А что тогда понимается под наступлением? Количество пиара на всяких фрикерских эвентах?

    _>Процесс идёт по другому: новые проекты всё чаще и чаще берут за базис эти технологии.


    Какой ERP проект взял за базис nosql хранилище? Есть что нибудь кроме персистентного кеша веб-приложений или индексов различных поисковиков и майнеров?

    _> Так что не удивлюсь если какая-то новая ERP использует такой подход.


    Зато я удивлюсь. Так факты будут?

    _>>> Потому что этот синтаксический сахар навязывает нам определённую архитектуру приводящую к лишним накладным расходам.

    НС>>Что именно он навязывает? Конкретно.

    _>Провоцирует генерировать лишние промежуточные структуры данных


    Какие? Вот в примере — какая структура данных лишняя?

    НС>>Мы натыкаемся на гораздо большее количество проблем, с чего, собственно, этот тред и начался.

    _>Где больше то? Размер и читабельность кода одинаковая

    Ну, если только ну очень захотеть. А так — читать твой код практически невозможно. Каша.

    НС>>Ну еще бы, если все в одну строчку запихать.

    _>linq пример помнится был вообще в одну строку, только такую, что её пришлось перенести мнооого раз. )))

    Еее не пришлось перенести, ее специально перенесли, чтобы легко читать было. Результат — такой код легко понятен даже тем, кто с С№ совсем не знаком. А вот в твоей каше с первого взгляда не разберешься.
    Re[36]: Коллекции .NET и контейнеры STL
    От: Ночной Смотрящий Россия  
    Дата: 12.04.12 18:25
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    НС>>Не понял, что ты там видишь.


    _>Создание массива строк.


    А что взамен? Range хранить? Ну можно. Только тогда придется и парсинг на эти range переделать. А самое интересное — тот код, который Qbit привел, от этого не изменится. Просто подставятся другие реализации Split и Parse. Так что тема фатальных проблем в LINQ не раскрыта.
    Re[36]: Коллекции .NET и контейнеры STL
    От: Ночной Смотрящий Россия  
    Дата: 12.04.12 18:25
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Не повлиял. Просто мне же надо было убедиться что программы выводят одно и тоже. ) Ну так, на всякий случай... )))


    Это все полнейшая ерунда. Куда интереснее другое — ты даже в теории не предполагал, что основные проблемы в методе int.Parse.

    _>Хм, что-то я не уверен что там дело в примитивности. Больше ощущение что там что-то лишнее делается.


    Так как раз не делается. Не делается нормальная буферизация.

    _>да и проблемность linq с которой всё началось уже всем показана.


    Не знаю кому она там показана, но я пока от тебя так и не добился внятного ответа, в чем же linq провинился конкретно.
    Re[40]: Синтаксический сахар
    От: Ночной Смотрящий Россия  
    Дата: 12.04.12 18:38
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Но не создавая его не получится использовать linq


    Получится.

    _>А больше всего меня забавляет что со мной спорят именно по этому вопросу. Смотри, у нас есть неоспоримый экспериментальный факт тормознутости linq кода в 5 (!!!) раз по сравнению с C++.


    Как оказалось, все таки в 2 раза.
    Re[42]: Синтаксический сахар
    От: Ночной Смотрящий Россия  
    Дата: 12.04.12 18:38
    Оценка: +1
    Здравствуйте, alex_public, Вы писали:

    _>Ох. Да дело не в быстродействие split. Вы можете хоть заоптимизировать её, но всё равно будут те же проблемы.


    Какие и почему?

    _> Дело в том, что для применения linq методов


    Нет никаких linq методов. Есть класс Enumerable, но он, по большей части, тривиален.

    _> вам необходима коллекция, пускай даже и ленивая


    Нет, коллекция не нужна, только энумератор. А можно и свой аналог написать, вообще исключительно со своими типами.

    _>. Поэтому её надо как-то обязательно создать.


    Энумератор это, логически, просто указатель на элемент коллекции, это не сама коллекция, ничего ужасного в его создании 1 раз нет.

    _>Но мы создаём промежуточные, что бы использовать linq.


    Вывод неверный. Промежуточный массив создает метод Split, который никакого отношения к linq не имеет. А без массива индексов, который создает внутри OrderBy, ты и руками сортировку не сделаешь.

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


    Тебе кажется.
    Re[43]: Синтаксический сахар
    От: alex_public  
    Дата: 13.04.12 07:41
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

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

    НС>Ты даже не представляешь как часто и как глубоко я задумывался над такими вопросами как на прошлой работе, так и на текущей. А последние пару месяцев я большую часть рабочего времени занимаюсь исключительно перформансом.


    Сомнительно. Т.к. в этом случае для нашего конкретного примера и при условии заточки на производительность ты бы просто не стал брать linq вообще.

    НС>А что взамен? Range хранить? Ну можно. Только тогда придется и парсинг на эти range переделать. А самое интересное — тот код, который Qbit привел, от этого не изменится. Просто подставятся другие реализации Split и Parse. Так что тема фатальных проблем в LINQ не раскрыта


    Ох, как же головы любителей linq затуманены этим сахаром, если не видят очевидного. И Range хранить не надо. Более того, даже изначальное разделение файла на коллекцию из строк не нужно, т.к. оно приводит к лишнему проходу по данных. Ладно, сейчас объясню так, что точно поймёшь.

    Напиши на C# тупой императивный код (на C++ мне для этого минута наверное понадобилась) реализующий следующее (упрощённо, на своебразном псевдокоде):
    загрузить файл в buf
    цикл по buf{
        если текущий элемент:
        ',' то xor^=преобразования к int текущего куска buf; count++
        '\n' то xor^=преобразования к int текущего куска buf; count++; если count>2 добавить xor в отсортированый массив result; обнулить xor;
    }
    вывести result

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

    Другое дело что подобный код некрасивый, низкоуровневый, неудобно расширяемый, так что использовать его есть смысл только если вопрос о производительности критичен. А в остальных случаях (естественно если задача ложится на sql синтаксис вообще — как мы видели по второму примеру это тоже далеко не всегда) использование linq вполне логично.

    Для C++ Boost решает проблему для подобных задач, предоставляя универсальное высокоуровневое решение, не требующее создания лишних сущностей.

    НС>Вывод неверный. Промежуточный массив создает метод Split, который никакого отношения к linq не имеет. А без массива индексов, который создает внутри OrderBy, ты и руками сортировку не сделаешь.


    К результирующему массиву никаких претензий нет — он есть и в C++ варианте и является следствием пункта о сортировке в условиях задачи. А вот без какой-либо разновидности split написать на linq решение этой задачи не выйдет.

    НС>Тебе кажется.


    Вообще то я писал Qbit86. Но собственно теперь это можно уже обобщить на всю тему. Я уже не просто сказал всё, я это повторил по несколько раз в разных формулировках. Наедоло. Если кто-то до сих пор и не понял, то мне уже всё равно. )))
    Re[44]: Синтаксический сахар
    От: Ночной Смотрящий Россия  
    Дата: 13.04.12 14:22
    Оценка: +1 :)
    Здравствуйте, alex_public, Вы писали:

    _>Меня если честно утомил твой стиль дискуссии


    Когда требуют фактов, которых нет, согласен, это неприятно

    _>Так что я в этот раз не буду цитировать все эти бесконечные простыни демагогии


    Перевожу — проигнорирую все неудобные вопросы. Ты поскипал (ожидаемо) все конкретные вопросы, оставил только то, на что можно растечься мыслью по древу.

    НС>>Ты даже не представляешь как часто и как глубоко я задумывался над такими вопросами как на прошлой работе, так и на текущей. А последние пару месяцев я большую часть рабочего времени занимаюсь исключительно перформансом.


    _>Сомнительно. Т.к. в этом случае для нашего конкретного примера и при условии заточки на производительность ты бы просто не стал брать linq вообще.


    Предположение неверное.

    НС>>А что взамен? Range хранить? Ну можно. Только тогда придется и парсинг на эти range переделать. А самое интересное — тот код, который Qbit привел, от этого не изменится. Просто подставятся другие реализации Split и Parse. Так что тема фатальных проблем в LINQ не раскрыта


    _>Ох, как же головы любителей linq затуманены этим сахаром, если не видят очевидного.


    А ты не допускаешь, что сам чего то не видишь?

    _>Напиши на C# тупой императивный код (на C++ мне для этого минута наверное понадобилась) реализующий следующее (упрощённо, на своебразном псевдокоде):

    _>
    загрузить файл в buf
    _>цикл по buf{
    _>    если текущий элемент:
    _>    ',' то xor^=преобразования к int текущего куска buf; count++
    _>    '\n' то xor^=преобразования к int текущего куска buf; count++; если count>2 добавить xor в отсортированый массив result; обнулить xor;
    _>}
    _>вывести result

    _>Так вот, думаю что такой вариант будет уступать по скорости C++ уже точно не в разы.

    Вот только это тоже можно переписать в стиле линка, не потеряв в скорости. Именно поэтому я 50 раз спросил, что конкретно, по твоему, тормозит. И ты так упорно не хочешь отвечать потому что ответа то ты и не знаешь.

    _>А в остальных случаях (естественно если задача ложится на sql синтаксис вообще


    Напоминаю, ты так и не смог рассказать, что же ты понимаешь под "sql синтаксиcом".

    _>К результирующему массиву никаких претензий нет — он есть и в C++ варианте и является следствием пункта о сортировке в условиях задачи. А вот без какой-либо разновидности split написать на linq решение этой задачи не выйдет.


    Но split не обязан что либо копировать. И уж точно не имеет отношения к линку.

    _>Вообще то я писал Qbit86. Но собственно теперь это можно уже обобщить на всю тему


    Не надо ничего обощать, пока у тебя нет конкретики.

    _>. Я уже не просто сказал всё, я это повторил по несколько раз в разных формулировках. Наедоло. Если кто-то до сих пор и не понял, то мне уже всё равно. )))


    Это называется "не смогла".
    Re[45]: Синтаксический сахар
    От: alex_public  
    Дата: 14.04.12 00:25
    Оценка:
    Здравствуйте, Ночной Смотрящий, Вы писали:

    НС>Вот только это тоже можно переписать в стиле линка, не потеряв в скорости.


    OK. Если ты так считаешь, то жду от тебя кода решения изначального примера на linq и при этом не уступающему по скорости C++ варианту. Пока его не будет, говорить с тобой на эту тему дальше бессмысленно.

    НС>Напоминаю, ты так и не смог рассказать, что же ты понимаешь под "sql синтаксиcом".


    Мы можем играться в слова сколько угодно, но реальность это не изменит. Все прекрасно видели как красивый код на linq из примера 1 превратился в дикий ужас на примере 2, в котором просто слегка поменяли условие фильтрации исходных данных. Так что любому вменяемому человеку очевидно, что есть класс задач где использовать linq глупо.

    И это всё уже никак не связано с быстродействием.

    НС>Но split не обязан что либо копировать. И уж точно не имеет отношения к линку.


    Факт наличия split в коде программы имеет прямое отношение к linq. В то время как сама по себе задача не требует наличия split.
    Re[46]: Синтаксический сахар
    От: Ночной Смотрящий Россия  
    Дата: 14.04.12 04:19
    Оценка: -1 :)
    Здравствуйте, alex_public, Вы писали:

    _>OK. Если ты так считаешь, то жду от тебя кода решения изначального примера на linq и при этом не уступающему по скорости C++ варианту.


    Сколько заплатишь?

    НС>>Напоминаю, ты так и не смог рассказать, что же ты понимаешь под "sql синтаксиcом".


    _>Мы можем играться в слова сколько угодно


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

    _>И это всё уже никак не связано с быстродействием.


    Ты с темы не уходи. Тебе задали вопросы про именно быстродействие и про твой загадочный sql стиль.

    НС>>Но split не обязан что либо копировать. И уж точно не имеет отношения к линку.


    _>Факт наличия split в коде программы имеет прямое отношение к linq.


    Нет.

    _> В то время как сама по себе задача не требует наличия split.


    Задача требует деления строки по разделителю. Стандартно есть только один метод, который это делает — string.Split.
    Re: Google code style
    От: AlexanderVX США  
    Дата: 14.04.12 12:38
    Оценка:
    А>А что Вы думаете по этому поводу?

    Принципы хорошие, как и любые другие, которые вам позволяют писать хороший надёжный код. Хоть вообще совсем другие.
    Re[12]: Контейнеры
    От: RedUser Россия  
    Дата: 14.04.12 13:08
    Оценка:
    Q>Ну вот Кормен—Лейзерсон—Ривест — это подходящая книжка по алгоритмам? Там то, что в C++ называется std::list, называется singly linked list.
    Почему singly-то? По нему можно в обратном направлении пройтись.
    Re[47]: Синтаксический сахар
    От: alex_public  
    Дата: 14.04.12 19:06
    Оценка: -2
    Здравствуйте, Ночной Смотрящий, Вы писали:

    _>>OK. Если ты так считаешь, то жду от тебя кода решения изначального примера на linq и при этом не уступающему по скорости C++ варианту.

    НС>Сколько заплатишь?

    ))) Ну всё должно быть в соответствие с C++ программистом. Давай посчитаем... Ему на эти две строчки на Boost потребовалось бы наверное секунд 30. Ну накинем ещё 30 на проверку на тестовом файле. В итоге минута. Если возьмём за среднюю зарплату допустим 100К р/м, то получаем... Вот, 10 рублей дам за решение.

    А вообще, главным выводом этого всего для тебя должно быть, что если не можешь ответить за свои слова, то и не вылезай лучше.

    НС>Ты с темы не уходи. Тебе задали вопросы про именно быстродействие и про твой загадочный sql стиль.


    К linq в этой теме было два отдельных вида претензий.
    1. По быстродействию. Демонстрировалось на примере1. Там со всем разобрались, разве что кроме твоей упёртости. Соответственно беседовать тут дальше бесполезно, пока не предоставишь linq вариант работающий со скоростью C++.
    2. По красоте кода. Сильно зависит от условия задачи и в определённых случаях (а всего то чуть изменили условии фильтрации) может получаться дикий ужас. Это демонстрировалось на примере2.

    Быстродействие в примере2 никто уже не тестировал, т.к. смысла не было. В примере1 у нас был хотя бы красивый код — соответственно было понятно ради чего жертвовать быстродействием. А тут уже и сам код жуть. Хотя думаю что если протестировать linq код из второго примера, то вообще дикие тормоза будут. )))

    _>>Факт наличия split в коде программы имеет прямое отношение к linq.

    НС>Нет.


    НС>Задача требует деления строки по разделителю. Стандартно есть только один метод, который это делает — string.Split.


    Если задача этого обязательно требует, то тогда какой магией работает тот императивный код? Там никаких массивов строк не создаётся. Только один проход по изначальной строке и всё — печатаем результат.
    Re[48]: Синтаксический сахар
    От: Ночной Смотрящий Россия  
    Дата: 15.04.12 19:36
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>А вообще, главным выводом этого всего для тебя должно быть, что если не можешь ответить за свои слова, то и не вылезай лучше.


    Ясно. На сем я с тобой разговор закончил.
    Re[48]: Синтаксический сахар
    От: _d_m_  
    Дата: 16.04.12 05:34
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    Клиника. В сад, к землеройкам.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
    Re[46]: Синтаксический сахар
    От: FR  
    Дата: 16.04.12 11:21
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>OK. Если ты так считаешь, то жду от тебя кода решения изначального примера на linq и при этом не уступающему по скорости C++ варианту. Пока его не будет, говорить с тобой на эту тему дальше бессмысленно.


    Александреску продолжает измываться над D, и вот докатился практически до того же синтаксиса что и в linq

    http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/


    auto answer = recurrence!"a[n-1] + a[n-2]"(1, 1)
                  .until!"a > 4_000_000"()
                  .filter!"a % 2 == 0"()
                  .reduce!"a + b"();


    в теории это должно насмерть оптимизироваться практически в аналог кода написанного
    в лоб так как все это основано на range, надо будет проверить, погонять.
    Re[47]: Синтаксический сахар
    От: alex_public  
    Дата: 16.04.12 16:30
    Оценка:
    Здравствуйте, FR, Вы писали:

    FR>Александреску продолжает измываться над D, и вот докатился практически до того же синтаксиса что и в linq


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

    FR>http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/

    FR>
    FR>auto answer = recurrence!"a[n-1] + a[n-2]"(1, 1)
    FR>              .until!"a > 4_000_000"()
    FR>              .filter!"a % 2 == 0"()
    FR>              .reduce!"a + b"();
    FR>


    Не плохо. Надо бы взглянуть на детали.

    FR>в теории это должно насмерть оптимизироваться практически в аналог кода написанного

    FR>в лоб так как все это основано на range, надо будет проверить, погонять.

    Вообще говоря в теории с помощью STL тоже можно провернуть подобное, благодаря фирменной особенности — итератором может служить не только какой-то спец. класс, но и любой указатель. Т.е. мы можем задавать куски большой строки просто двумя указателями внутри неё, передавая их как итераторы в различные алгоритмы. Но это уже будет не так симпатично как в D, т.к. тут у нас многие другие обычные функции (типа преобразования в int) не рассчитаны на этот подход — их тогда надо дописывать.
    Re[4]: Google code style
    От: Sni4ok  
    Дата: 22.10.13 18:04
    Оценка:
    Здравствуйте, Marty, Вы писали:

    M>Будет типобезопасный форматный вывод в printf — хм, Nemerle (да и все остальное) не нужен.


    я ниразу в жизни не юзал printf- может вы типа сишного динозовра и вам пора поботать что-то новое, ну там boost::format к примеру?
    Re[4]: Google code style
    От: jazzer Россия Skype: enerjazzer
    Дата: 22.10.13 18:25
    Оценка:
    Здравствуйте, Marty, Вы писали:

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


    _>>>Хы, одному мне кажется что потоки и контейнеры C++ тут обсуждают больше всего C# люди, которые уже "забыли всё" (или вообще не знали)? )))


    Q>>Не больше, чем люди, которые кроме C++ ничего во внешнем мире не видели, и сравнивать могут лишь с Си.


    M>Что-то видел, что-то нет. C++ довольно сложен и многословен. Но после всех его минусов — auto уже есть в последнем стандарте, остался только форматный вывод. Будет типобезопасный форматный вывод в printf — хм, Nemerle (да и все остальное) не нужен.


    Он уже есть, гугль в помощь.
    Навскидку:
    http://abel.web.elte.hu/mpllibs/safe_printf/printf.html
    https://github.com/c42f/tinyformat
    jazzer (Skype: enerjazzer) Ночная тема для RSDN
    Автор: jazzer
    Дата: 26.11.09

    You will always get what you always got
      If you always do  what you always did
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.