Здравствуйте, Cyberax, Вы писали:
C>Да, и во всех есть _полная_ реализация WinForms?
WinForms имеет такое же отношение к .NET как MFC к С++. Так что мимо кассы.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Да, и во всех есть _полная_ реализация WinForms? > WinForms имеет такое же отношение к .NET как MFC к С++. Так что мимо кассы.
Простите, а за что мне 5 минусов тогда поставили в ответе про GUI и БД?
Кроме того, я специально спросил ".NET Framework".
Здравствуйте, Cyberax, Вы писали:
C>>>Не предмет первой необходимости. IT>>Батенька, на дворе давным давно 21 век, а вы всё никак из командной строки не вылезите. Однако, явно наблюдается задержка в развитии C>Ну что сделать, если у меня во многих задачах не нужно больше
Вот! Я же тебе уже говорил, что тебе надо почаще добавлять к своим выступлениям ИМХО, т.к. ты находишься в подавляющем меньшинстве.
>>>> — Database access C>>>_Далеко_ не предмет первой необходимости. IT>>Как минимум если бы не было одной, то эту свою гениальную мысль ты не смог бы выразить так ярко. C>Смотрим связку Windows+Office: в самой Windows нигде БД через обобщенный интерфейс не используются (хотя в MSI и MMI есть свои реализации недо-SQL), в Word/Excel используются для дополнительных фич (типа привязки таблиц к источникам данных). Хотя да, есть исключение — MS Access
Ты когда-нибудь видел интернет? По сайтам разным ходил? Сообщения свои оставлял? Покупал что-нибудь в интернет магазинахх? Просматривал новости? Открою тебе страшный секрет — это всё сделано на базах данных и для тебя они, получается, предмет первейшей необходимости. Если ты когда-нибудь видел, конечно, интернет
C>>>Было обсуждение по включению XML-библиотеки в Boost, но пока завязло IT>>А почему завязло? C>Решили, что нет смысла создавать yet another XML-библиотеку. Тот же libxml с С++-биндингами вполне адекватен.
Если буст претендует на стандарт, то смысл создавать есть и даже очень. Как раз для того, чтобы покончить со зверинцем XML библиотек.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT wrote: > IT>>Батенька, на дворе давным давно 21 век, а вы всё никак из командной > строки не вылезите. Однако, явно наблюдается задержка в развитии > C>Ну что сделать, если у меня во многих задачах не нужно больше > Вот! Я же тебе уже говорил, что тебе надо почаще добавлять к своим > выступлениям ИМХО, т.к. ты находишься в подавляющем меньшинстве.
Аналогично. Стоило бы написать:
ИМХО:
— GUI
— GUI
— GUI
...
> Ты когда-нибудь видел интернет? По сайтам разным ходил? Сообщения свои > оставлял? Покупал что-нибудь в интернет магазинахх? Просматривал > новости? Открою тебе страшный секрет — это всё сделано на базах данных и > для тебя они, получается, предмет первейшей необходимости.
И поэтому интерфейсы для доступа к enterprise-базам данных должны быть
на каждом десктопе?
> C>Решили, что нет смысла создавать yet another XML-библиотеку. Тот же > libxml с С++-биндингами вполне адекватен. > Если буст претендует на стандарт, то смысл создавать есть и даже очень. > Как раз для того, чтобы покончить со зверинцем XML библиотек.
А зачем? Вот в Java в свое время взяли и зафиксировали версию
Xercex+Xalan в "стандартном" JDK. Потом появились (точнее стали
популярны) намного более удобные JDom/Dom4J, но заменить старые классы
для XML на новые — уже нельзя (на них уже много завязано).
Можно пойти по пути MS и просто добавить JDom/Dom4J в JDK рядом с
Xerces'ом. Но тогда размер JDK быстро начнет расти.
Или другой пример — MS в свое время стандартизовалась (с совершенно
благими намерениями "поддержки всех языков") на UCS2 для представления
Unicode'а. В результате сейчас C# и WinAPI ограничены BMP (Basic
Multilingual Plane), из-за чего появляются проблемы с языками, которых
нет в BMP (и у японцев, которым не нравится китайский порядок сортировки
иероглифов в BMP). _Уже_ начинаются полуработающие извращения с
самопальной поддержкой суррогатов и их несовместимостью с половиной .NET FW.
Я таких примеров еще могу найти. В общем "premature standardization is
the root of all evil".
Я вообще считаю, что в стандарте на язык и его окружение не должно быть
ничего кроме самого важного (контейнеры, алгоритмы, базовый ввод/вывод).
То что вряд ли будет меняться со временем, а остальное лучше обеспечить
библиотеками.
Здравствуйте, Cyberax, Вы писали:
>> C>Да, и во всех есть _полная_ реализация WinForms? >> WinForms имеет такое же отношение к .NET как MFC к С++. Так что мимо кассы. C>Простите, а за что мне 5 минусов тогда поставили в ответе про GUI и БД?
C>Кроме того, я специально спросил ".NET Framework".
Тогда задайся еще вопросом "Что сложнее .NET Framework или Windows". Думаю у тебя выйдет, что .NET Framework сложнее, так как для его реализации придется реализовать Windows как базовый компоенет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Это проблемы не языка, а библиотек. Их собственно и в спецификации C# и Java не найдешь. И все эти библиотеки для C++ существуют.
Здравствуйте, eao197, Вы писали:
E>А если учесть что в двух местах используется одинаковый код, то хотелось иметь возможность написать так: E>
E>auto predicat = bool lambda( int x ) { return ( 5 < x && x <= 10 };
E>int count = count_if( ints.begin(), ints.end(), predicat );
E>...
E>auto int_it = find_if( ints.begin(), ints.end(), predicat );
E>
E>Вот это было бы для меня удобно. И нормально.
Да, уже несомненно лучше. Если теперь убрать бессмысленные "ints.begin(), ints.end()" и "vector<int>::iterator", а так же написать часную функцию count_if на базе универсальной FoldLeft, то получится код на Namerle.
def seq = [1, 30, 5, 7, 2, 6, 6];
def countIf(seq, predicate)
{
seq.FoldLeft(0, fun(x, i){ if (predicate(x)) i + 1 else i });
}
def result = countIf(seq, fun(x){ 5 < x && x <= 10 });
Nemerle.IO.printf("Result: %d\n", result);
Result: 3
Короче, на С++ лучше не писать в функциональном стиле. Тогда его убогость будет видна не так сильно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Просто в качестве мысли вслух. Интересно, какому-нибудь столь же распространенному языку, как C++, удалось сохранить единую концепцию и стройность языка за двадцать лет своего развития и после столько кардинальных доработок, как в C++ (исключения и шаблоны ведь в C++ не сразу появились)?
Можно список координальных доработок за последние 10 лет?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, igna, Вы писали:
I>Концепция итератора заметно богаче концепции кой-чего с методом FoldLeft.
Если бы ты знал какую глупость ты сейчас произнес.
Я не гуру в этих вопросах но даже мне ясно, что итераторы всего лишь паттерн для перебора последовательности. Между тем есть всего два варианта перебора 1) цикл, 2) рекурсия. FoldLeft — это рекурсивный перебор. На чем он делается уже не важно.
I>Некоторые даже полагают, будто:
I>
I>... iterator theories are as central to Computer Science as theories of rings or Banach spaces are central to Mathematics. <i>(Alex Stepanov)</i>
Я начну слушать Степанова когда он начнет писать внятный код. Хотя на С++ это вообще зделать очень не просто.
В общем, счасливо изучать концепции итераторов дальше. А я лучше буду писать максимально краткий и ясный код.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>Кроме того, я специально спросил ".NET *Framework*". > Тогда задайся еще вопросом "Что сложнее .NET *Framework* или Windows". > Думаю у тебя выйдет, что .NET Framework сложнее, так как для его > реализации придется реализовать Windows как базовый компоенет.
Ну вот. В С++ примерно тоже — язык, в котором есть несколько ловушек,
требующих для реализации кучу кода.
Поэтому ваш аргумент "сложный, а значит плохой" — не совсем правильный.
VladD2 wrote: > E>Просто в качестве мысли вслух. Интересно, какому-нибудь столь же > распространенному языку, как C++, удалось сохранить единую концепцию и > стройность языка за двадцать лет своего развития и после столько > кардинальных доработок, как в C++ (исключения и шаблоны ведь в C++ не > сразу появились)? > Можно список координальных доработок за последние 10 лет?
Шаблоны с частичной специализацией, метапрограммирование.
Здравствуйте, Cyberax, Вы писали:
C>А зачем? Вот в Java в свое время взяли и зафиксировали версию C>Xercex+Xalan в "стандартном" JDK. Потом появились (точнее стали C>популярны) намного более удобные JDom/Dom4J, но заменить старые классы C>для XML на новые — уже нельзя (на них уже много завязано).
Вас обманули. XML-парсеры описываются стандартом JAXP (Java API for XML Processing). Стандарт есть уже давно (где то с версии джавы 1.2), но реализации в JRE до версии 1.3 не было. В 1.3 добавили апачевский парсер, но он полностью совместимм с JAXP и на нем основан. Так что если реализация парсера соответствует стандарту, то никаких проблем заменить Xerces нет.
C>Можно пойти по пути MS и просто добавить JDom/Dom4J в JDK рядом с C>Xerces'ом. Но тогда размер JDK быстро начнет расти.
А что, у .NET есть две публичных реализации парсера XML?
... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>
AndrewVK wrote: > Вас обманули. XML-парсеры описываются стандартом JAXP (Java API for XML > Processing). Стандарт есть уже давно (где то с версии джавы 1.2), но > реализации в JRE до версии 1.3 не было. В 1.3 добавили апачевский > парсер, но он полностью совместимм с JAXP и на нем основан. Так что если > реализация парсера соответствует стандарту, то никаких проблем заменить > Xerces нет.
Я это знаю, но дело в том что этот стандарт (кстати, он писался вслед за
Xerces) очень неудобен. Вот статья на эту тему: http://www-128.ibm.com/developerworks/library/x-injava2/
> C>Можно пойти по пути MS и просто добавить JDom/Dom4J в JDK рядом с > C>Xerces'ом. Но тогда размер JDK быстро начнет расти. > А что, у .NET есть две публичных реализации парсера XML?
Нет, просто есть копии сборок для 1.0, 1.1 и 2.0.
Если нам не помогут, то мы тоже никого не пощадим.
