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

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

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

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

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

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

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

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

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

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

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

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

Нас спасет http://www.fastformat.org/
P.S. И, да, он таки быстрее буста. И безопасное форматирование есть. Песня. 8-)

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

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


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

_>или перейти к кроссплатформенным инструментам (не помню у них такого ни разу)...
Если метро + их апстор взлетят, то все тихо и мирно вернуться на винду и всё. В смысле все разрабы, ну просто большинству будет ничего не надо больше.

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

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

Ну конкретно .Net контейнеры в С++ неудобны, потому, что им нужен GC. Или, наоборот, удобны...
Но, например, std::string -- малоюзабелен. Если появится удобная и стандартная, хотя бы на винде С++ строка, то это будет концом std::basic_string. Та же фигня с потоками, ну и далее по списку

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

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

Здравствуйте, 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* — тогда просто не соберётся если передать его.

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

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

Нафига геморроиться, есть жеж нормальные variadic templates

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

M>Мне бы
_>>удобное, безопасное — printf
M>можно сделать?

В С++0х лехко

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

M>Будет типобезопасный форматный вывод в printf — хм, Nemerle (да и все остальное) не нужен.
Уже реализуем без проблем.

Здравствуйте, 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.

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

T>Нас спасет http://www.fastformat.org/
T>P.S. И, да, он таки быстрее буста. И безопасное форматирование есть. Песня. 8-)

Какой нереальный трындец.

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

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

Ну такие же ландухи приплюснутые там и написали.

Здравствуйте, Трололоша, Вы писали:

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

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

Тебе по любому, чтобы передать строку в TextBox, надо её полностью сформировать.
Так что твоя троллевая аналогия некорректна.

Здравствуйте, 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, т.к. не везде ещё поддерживаются.

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

N>Так что твоя троллевая аналогия некорректна.
Вполне корретна. Для формирования готовой зубной щётки достаточно держать её в руке, а не в заднице.

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

MessageFormat в Яве был всегда — ну ладно, как минимум с 1.3, которой 100 лет в обед. Он не являлся полным аналогом printf, потому что был заточен под многоязычную локализацию. В некоторых применениях он более удобен, чем printf.

А вот уже 1.5 (которая тоже не вчера вышла) добавили полный аналог printf.

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

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

___>Ну такие же ландухи приплюснутые там и написали.

Я вот не пойму, как можно аргументировать что-то статьей из википедии, и сразу же писать, что в википедии туфта?

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

E>Не-не-не. Исторически оно сложилось, как ARRAY[1..5[ OF...

Это про списки было, возможно, неверно сформулировал.

Здравствуйте, 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 до сих пор нет — это расстраивает, т.к. из-за этого не можем использовать такую приятную плюшку (вот прямо в коде выше она бы тоже пригодилась).

Здравствуйте, 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 и прочей поддержки со стороны библиотеки — нет.