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

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

VD>>Значит С++ не кросплатформный? У него в стандарте тоже нет переносимого ГУИ.
CC>Пардон, WinForms входит в комплект библ .NET. По сути является стандартной библиотекой. В С++ в стандартной библиотеке этого нет.

MFC входит в комплект VC, и по сути является стандартной библиотекой.
Чувствуещь свою логику?
WinForms стандартной библиотекой не является. Он является частной библиотекой МС.
В стандарт входит очень небольшая часть библиотек дотента и она практически полностью реализована в Моно.

VD>>А в Моно есть поддержка GTK.
CC>GTK есть в стандартных библиотеках .NET? Нету? Тогда мимо кассы...

А что QT или MWC есть? А может VCL?
Ты шутник одако. Или с логикой большие нелады.

CC>Стоп! Вот отсюда помедленнее: моно все таки это .NET под никсы или это что то отдельное, но бинарно совместимое?

.NET — это зарегистрированная торговая марка МС. .NET Framevork — это название выпускаемого МС продукта реализующего стандарты ECMA им же и введенные.
Моно — реализация этих стандартов почти независимыми (от Новела) программистами.
Моно и .NET полностью совместимы по формату бинарных файлов, реализуют одни и те же стандарты и обеспечивают бинарную переносимость исполняемых модулей. Таки образом Моно и .NET позволяют создавть софт который будет работать на них без перекомпиляции.

Все тоже самое творится в мире С++-компиляторов, только в добавок совместимость обеспечивается исключительно на уровне исходников и очень плохо.

CC> Если отдельное то при чем тут вообще Моно к портируемости .NET? То, что моно переносим — отдельная песТня. Речь изначально шла исключительно про кроссплатформенность .NET

Практически все что написано под Моно будет работать на Дотнете. "Практически" я упомянул потому как мы живем в реальном мире и в любой программе есть баги.

VD>>Вторая — многим тем кто выбирает технологии МС просто начхать и растереть на все что делается пол Уних в общем, и под Линукс в частности.
CC>Т.е. все утверждения что гипотетическая кроссплатформенность .NET это ее бааальшой плюс можно сразу отправлять в void, уже по причине полной ненужности этой самой кроссплатформенности.

То есть реальная переносимость дотнетного кода откровенно не колышит большинство тех кто использует .NET. И это не имеет никакого отношения к его переносимости.

CC>Более правильным было бы сказать "только в рассчете на один из компиляторов С++,

Да, я опечатался. Хотел написать "в рассчете на VC++".

CC>Реализация VM для дотнета только одна. Компилеров С++ же много, они бинарно несовместимы в большинстве своем. Пиши под один GCC на все нужные тебе платформы и будет тебе щасте!

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

VD>>И сам процесс поддержания прогаммы способной одинаково хорошо работать на разных платфомах сложнее.
CC>Гм. x86, PS2, XBOX — наше двигло вроде нормально на них работало, Один код, только разделение по hardware dependent уровню и все.

Скромный список вопросов.
1. Ты лично занимался обеспечением работоспособности "вашего двигла" на этих платформах?
2. В какой игре можно увидить "ваше двигло"?
3. Сколько лет вы его разрабатываете?

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

VD>>Мне кажется, он имел в виду, что на С++ очень сложно писать переносимый код.

Ш>Это утверждение противоречит моему опыту.

А какой у тебя опыт написания переносимых программ на других языка?

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

VD>>Попробуй, например, с его помощью прочитать что-то из внешнего файла.

dmz>Попробуй с его помощью разобрать SQL-запрос в виде строки и добавить в класс поля,
dmz>соответствующие его колонкам.

Курим макрос ExecuteReaderLoop из http://nemerle.org/svn/nemerle/trunk/macros/Data.n
Поля в классах он правда не создает, но создает типизированные переменные, что в данном случае то же самое.

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

VD>>Re[6]: Сложный язык для сложных срограмм.

Автор: jazzer
Дата: 30.01.07

J>А, ну так ты споришь со словами, вырванными из контекста. Прочитай выше. Если все равно будет непонятно, о чем я говорил — прочитай мой разговор с eao197 — он в результате смог понять, что я имел в виду

Нет, я указываю на дремучие заблуждения одно из товарищей.

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

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

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

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

>>> А в кваке нет ничего такого, что требовало бы четырёхэтажных
>>> скриптов. Фактически, почти вся игра состоит из одного движка. Движки
>>> действительно писать можно только на C++, а жаль . Может быть, в будущем
>>> что-то изменится.
C>>А зачем?

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

Мощный — это как?
ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .

VD>Грамматика следующая:
VD>

VD>Message ::= "message" Identifier '(' parms ')' ';'.
VD>State   ::= "state"   Identifier '{' decls '}'.
VD>...
VD>

Ок.
Чем этот код плох?

void parse(list<Messages>& messages, list<States>& states pair<TokenIterator> tokens) {
  Identifer name;
  TokenIterator cur;
  {
    cur = tokens.first;
    Round params;
    if (
      Identifer("messages")(cur, tokens.second) && name(cur, tokens.second) &&
      params(cur, tokens.second) && Semicolon()(cur, tokens.second)
    ) {
      messages.bush_front(parseMessage(name, params));
      parse(messages, states, make_pair(cur, tokens.second));
    }
  } {
    cur = tokens.first;
    Brace decls;
    if (
      Identifer("state")(cur, tokens.second) && name(cur, tokens.second) && 
      decls(cur, tokens.second)
    ) {
      states.push_front(parseState(name, decls));
      parse(messages, states, make_pair(cur, tokens.second));
    }
  } if (tokens.first != tokens.second)
    throw CompileError(*tokens.first)
}

Вполне помоему читаемый и прозрачный код

Пример одного из классов реализации:

struct Semicolon {
  bool operator(TokenIterator& cur, TokenIterator end) {
    return cur != end && *cur == ';';
  }
}

Вроде тоже всё читаемо.

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

dmz> Из этого определенным образом следует, что при разработке серверов БД нам нужна вся
dmz> производительность до капли — это критично.
dmz> Но тут, внимание, вопрос — а на С++ ли они пишутся? Не на C ли, случаем?
Как минимум Firebird на С++.

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

VD>MFC входит в комплект VC, и по сути является стандартной библиотекой.
С каких пор VC стало стандартом С++ ?
VD>WinForms стандартной библиотекой не является. Он является частной библиотекой МС.
Равно как и MFC в таком случае.

CC>>GTK есть в стандартных библиотеках .NET? Нету? Тогда мимо кассы...
VD>А что QT или MWC есть? А может VCL?
VD>Ты шутник одако. Или с логикой большие нелады.
См свою же тираду про MFC. Вопрос про логику переадресую назад.

CC>>Стоп! Вот отсюда помедленнее: моно все таки это .NET под никсы или это что то отдельное, но бинарно совместимое?
VD>.NET — это зарегистрированная торговая марка МС. .NET Framevork — это название выпускаемого МС продукта реализующего стандарты ECMA им же и введенные.
Т.е. микрософт придумала стандарт и сама же под него и пишет.

VD>А главное, не притягивай за уши совсем уж никудышные аргументы.
Это не являлось аргументом

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

VD>Нет, я указываю на дремучие заблуждения одно из товарищей.

Товарищ — это я? На какие "дремучие заблуждения"? Что препроцессор в С — это метапрограммирование? Я, по-моему, внятно объяснил, что я имел в виду. И не один раз. Напоминаю для тех, кому лень подняться на два сообщения назад: флейм начался из-за утверждения, что рефлексия — это базовая вещь, и ее отсутствие ставилось в упрек С++. Цитата:

В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.

Если тебе на эти объяснения наплевать и ты предпочитаешь цепляться к словам, выдранным из контекста, прикрываясь при этом смайликами — чести тебе это не делает.

P.S. Заодно научи меня, как воспользоваться мощнейшими рефлексивными способностями сишного препроцессора.

You will always get what you always got
  If you always do  what you always did

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

E> Или почему в большинстве языков используется специальные соглашения для атрибутов класса (вроде префикса m_, суффикса _ или записи this.something),

Немного оффтопа. Это, конечно, дело вкуса, но я вот не могу нормально читать код, в котором члены класса начианиются с m_ или _. ИМХО, это нечитабельно. Только просьба ко всем: флейма не надо разжигать.

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

E>По поводу GC: Страуструп создавал C++ имея опыт работы на языке с автоматической сборкой мусора. Поэтому он принципиально сделал C++ без таковой. И все последствия именно из этого.

Но почему же он не прдусмотрел более-менее человеческого способа прикрутить опициональный GC на уровне библиотек (то, что имеется, ИМХО, выглядит страшновато).

K>>Наконец, почему, чтобы понять C++, нужно от и до внимательно прочитать Страуструпа, а потом ещё Липпмана?

E>Вы думаете этого достаточно?
E>Я сильно сомневаюсь. C++ -- он, имхо, как любой иностранный язык -- можно учить всю жизнь.

Ну, это конечно. Всего знать невозможно. Но базу надо иметь. А базу, как показал мой опыт, можно получить, осилив именно эти книжки (и нынче ещё Александреску), ну и, конечно, что-нибудь серьёзное написав.

K>>Но вот беда: есть языки, к которым подобных вопросов не задаётся.

E>Но, во-первых, вот и славно. Затем же в C++ камнями кидаться. Тем более, что как я понял, C++ вообще лежит далеко в стороне от ваших профессиональных задач и интересов.

Ну так я и не кидаюсь. Я же не становлюсь посреди улицы и не кричу "C++ — отсто-о-о-ой" (на самом деле я так не считаю). Просто порой я слышу фразу вроде "данную задачу удобнее решать на C++, потому что он уже 20 лет рулит, и ещё 100 лет рулить будет". Ну нельзя так. Если в C++ есть какие-то изъяны, то "крутизна" C++ не повод, чтобы это терпеть. Хотелось бы, чтобы ситуация изменилась к лучшему. Тут я вижу три выхода:

1. Отказ разработчиков C++ от совместимости с некоторой частью lagacy-кода, за счёт этого — очистка C++ от всякого "мусора".
2. Разработка языка, способного заменить C++ в области разработки высокопроизводительных программ.
3. Развитие managed-сред, так, чтобы они могли довольно сносно решать "низкоуровневые" задачи.

По крайней мере, что-то должно улучшаться, на месте стоть нельзя. В том числе это касается лично меня. А то вдруг я попаду, скажем, в сферу разработки игр, и меня затсавят писать на C++, когда есть что-то лучшее?

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

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

Да играйтесь на здоровье. C++ не такой уж плохой язык. Просто он уже старый, и объективно в нём понакопилось всякого мусора. Вот и раздражает, когда мусор хотят за достоинство выдать.

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

DC>Мощный — это как?

Это так, как мы себе и прдставить не можем. Вот рассказал бы кто-то про нынешние 3D-игры лет 20 назад, его бы психом посчитали.

DC>ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .

Да на ассемблере тоже можно неплохой движок написать. Просто сейчас C++ — это лучшее, что подходит для данной задачи. Но надо понимать, что это не навсегда.

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

C>Вообще, в тех же Q1/2/3 скрипты — это просто входные данные, как и
C>шейдеры или текстуры.

Ага, а native-код — это просто входные данные для процессора.

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

CC>Т.е. микрософт придумала стандарт и сама же под него и пишет.
Совершенно верно. При том она так не только с CLI поступает. Та же самая ситуация и с Open Office XML, XPS да и еще много с чем другим, тот же самый XML в значительной степени продвигался усилиями MS (хотя там и других заинтересованных лиц было много).

Дело в том, что стандарт дает больше солидности, фиксирует ABI/API, а в некоторых случаях (например, в государственных органах ЕС) открытость стандарта файлов является обязательным условием для его использования.

Да, кстати, это оказывает давление и на других, из-за угрозы стандартизации XPS Adobe решилась таки сделать PDF открытым форматом:

здесь

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

K>Немного оффтопа. Это, конечно, дело вкуса, но я вот не могу нормально читать код, в котором члены класса начианиются с m_ или _. ИМХО, это нечитабельно. Только просьба ко всем: флейма не надо разжигать.

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

K>Ну так я и не кидаюсь. Я же не становлюсь посреди улицы и не кричу "C++ — отсто-о-о-ой" (на самом деле я так не считаю).

Ну, на форуме вы устраиваете что-то подобное

Автор: konsoletyper
Дата: 19.01.07

K>Просто порой я слышу фразу вроде "данную задачу удобнее решать на C++, потому что он уже 20 лет рулит, и ещё 100 лет рулить будет". Ну нельзя так. Если в C++ есть какие-то изъяны, то "крутизна" C++ не повод, чтобы это терпеть. Хотелось бы, чтобы ситуация изменилась к лучшему. Тут я вижу три выхода:

K> 1. Отказ разработчиков C++ от совместимости с некоторой частью lagacy-кода, за счёт этого — очистка C++ от всякого "мусора".

Не, так не получится. В принципе. Поскольку ценность legacy кода нельзя преуменьшать.

K> 2. Разработка языка, способного заменить C++ в области разработки высокопроизводительных программ.

В этом плане интересно, что выйдет из D. Как раз очищенный от проблем C++ наследник. После C++ он очень легко осваивается.

K> 3. Развитие managed-сред, так, чтобы они могли довольно сносно решать "низкоуровневые" задачи.

Так это и сейчас уже идет очень быстрыми темпами. В некоторых вещах управляемые языки уже давно рвут C++ по производительности. А вот для очень уж низкоуровневых задач как раз управляемость и является помехой.

Выходит, что два пункта из ваших трех уже выполняются

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

Поверьте, если не вестись на пропаганду местных .NET евангелистов и не зачитываться экстремалами от C++ (Александреску того же), то на C++ можно писать очень даже спокойно, качественно и не напрягаясь.

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

VD>Здравствуйте, Шахтер, Вы писали:

VD>>>Мне кажется, он имел в виду, что на С++ очень сложно писать переносимый код.

Ш>>Это утверждение противоречит моему опыту.

VD>А какой у тебя опыт написания переносимых программ на других языка?

Речь шла о C++. Причем тут другие языки?

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

dmz>> Из этого определенным образом следует, что при разработке серверов БД нам нужна вся
dmz>> производительность до капли — это критично.
dmz>> Но тут, внимание, вопрос — а на С++ ли они пишутся? Не на C ли, случаем?
T>Как минимум Firebird на С++.

MS SQL Server вроде тоже.

Yuri Khomic wrote:
> C> Gen. GC в Java весьма сложно отключить
> Сорри, incremental GC хотел написать.
Его как раз отключать не надо, так как он сильно помогает уменьшить
частоту полных сборок.

> C> Механизм HotSpot напрямую к GC не относится.
> Не совсем понял. Разве то, что понимается под HotSpot не включает в себя
> generational GC?
HotSpot — это механизм перекомпиляции кода "на лету", по результатам
профилирования. Непосредственно к GC он отношения не имеет, в JRE от SUN
есть несколько независимых алгоритмов GC.

Андрей Хропов wrote:
> 5 The standard libraries:
> 5.1 General comments
> *
> 5.2 Runtime infrastructure library
> 5.3 Base Class Library (BCL)
> 5.4 Network library
> 5.5 Reflection library
> 5.6 XML library
> 5.7 Extended numerics library
> 5.8 Extended array library
> 5.9 Vararg library
> 5.10 Parallel library
> *
Это не сильно больше, чем в новом Стандарте С++.

То есть, как и на C/С++ писать переносимый код на стандартном языке — не
получится.

konsoletyper wrote:
> C>Вообще, в тех же Q1/2/3 скрипты — это просто входные данные, как и
> C>шейдеры или текстуры.
> Ага, а native-код — это просто входные данные для процессора.
Ну да. Только процессор — это уже не software.