Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Константин Л., Вы писали:
КЛ>>Люди, но неужели вы до сих пор не поняли, что на с# нельзя писать программы с нетривиальной логикой просто потому, что он для этого не предназначен? АХ>А где в предыдущем сообщении VladD2 говорил про C#?
это не важно. Зуб даю, что до появления немерле он с таким же смаком ломал людям кайф и в неподходящих местах ругал с++ и хвалил c#. У него жизненное кредо такое, наверное.
КЛ>> Он просто убог для этого. АХ> Программы с нетривиальной логикой можно писать на любом Тьюринг-полном языке. На C, который прост как табуретка, вон Oracle всякие написаны.
КЛ>>Одно отсутствие const параметров методов — это убийство. АХ>Ну соглашусь, что это недостаток.
это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться.
А как тебе читабельность?
1) отмена :: есть большая ошибка.
2) возможность называть переменные, свойства и т.п. так же, как и типы — еще одна ошибка.
АХ>С другой стороны и у C++ много косяков. Как насчет отсутствия override?
ерунда.
АХ>Также можно сказать, что так как в C++ нет GС, то писать на нем — это убийство .
отсутствие GC — самое последнее, что заботит с++ программера. Конечно приходится "достраивать", используя smart pointers etc., но это настолько просто, что это даже не обсуждается. И это дает возможность выбора.
АХ>Вообще для меня нет пока идеального языка.
K>>Да на ассемблере тоже можно неплохой движок написать. DC>Напиши . Я хочу на это посмотреть . Видел демки 200-300Кб с нормально 3D графикой и музыкой, но это не движок
Такие демки даже intro 64 практически все написаны на Си или C++
Здравствуйте, VladD2, Вы писали:
DC>>ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .
VD>Это заблуждение. С++ уже ни для чего кроме возни с битами не подходит хорошо.
VD>Тут как-то пробегала ссылка на презентацию ролов создающих (если не ошибаюсь) новый Анрлиэл. Там как раз говорилось, что С++ не удоволетворяет современных потребностей и что нужен новый язык. Описывлись требования к этому новому языку. И что забавно большинство из этих требований удивительно пересекались с Немерле.
Там говорилось не про язык для создания движков а про язык для прикладного кода игры.
Здравствуйте, Константин Л., Вы писали:
КЛ>это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться.
Про const_cast расказывать надо?
КЛ>А как тебе читабельность?
Гораздо лучше чем в С++
КЛ>1) отмена :: есть большая ошибка. КЛ>2) возможность называть переменные, свойства и т.п. так же, как и типы — еще одна ошибка.
Обоснований конечно не будет.
АХ>>С другой стороны и у C++ много косяков. Как насчет отсутствия override? КЛ>ерунда.
Ой не скажи...
КЛ>отсутствие GC — самое последнее, что заботит с++ программера.
И кто тут занимается шапкозакидательством?
КЛ>Конечно приходится "достраивать", используя smart pointers etc., но это настолько просто, что это даже не обсуждается. И это дает возможность выбора.
А ты знаешь что для того чтобы реализовать эти самые smart pointers нужен счетчик ссылок. А то что счетчик ссылок не работает в присутствии циклических связей что приводит к тому что нужно кувалдой расправлять простую и понятную систему с циклическими связями в дерево?
А то что в многопоточной среде для него необходимы как минимум Interlocked функции которые в многопроцессорных системах очень дороги?
А ты знаешь что банальные new/delete в многопоточной среде каждый раз лочатся? Хоть эти локи и можно иногда оптимизировать при помощи страшных платформозависимых вывертов но также просто и эффективно как ГЦ всеравно работать не будет. А если ГЦ еще и region inference поможет то плюсовый хип вобще будет в пролете.
АХ>>Вообще для меня нет пока идеального языка. КЛ>а его и не будет, наверное )
А разве это не С++?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, dr.Chaos, Вы писали:
K>>>Да на ассемблере тоже можно неплохой движок написать. DC>>Напиши . Я хочу на это посмотреть . Видел демки 200-300Кб с нормально 3D графикой и музыкой, но это не движок
FR>Такие демки даже intro 64 практически все написаны на Си или C++
Вполне возможно . Я их не писал .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, WolfHound, Вы писали:
WH>А то что в многопоточной среде для него необходимы как минимум Interlocked функции которые в многопроцессорных системах очень дороги?
Да ну? lock xadd dword ptr [ecx],eax не такая дорогая инструкция.
WH>А ты знаешь что банальные new/delete в многопоточной среде каждый раз лочатся? Хоть эти локи и можно иногда оптимизировать при помощи страшных платформозависимых вывертов но также просто и эффективно как ГЦ всеравно работать не будет.
Пардон, а выделение памяти из разных потоков в условиях GC как отрабатывает? Разве лок при этом не нужен?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Plague, Вы писали:
VD>>У Оберона вроде как ЖЦ убитый. Если только заменить... P>А что у него с GC? можно где-нить почитать?
У него поколений нет. И инкрементально собирать мусор тоже не умеет.
Те если есть миллион фоновых объектов то тушите свет...
Это если конечно с последнего флейма ничего не изменилось(что врятли).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
КЛ>>это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться. WH>Про const_cast расказывать надо?
ой и плохо же ты обо мне думаешь. Согласись, что допустить ошибку с пом. const_cast гораздо тяжелее, тк его надо *написать*. Те человек сознательно это делает. Разницу улавливаешь?
КЛ>>А как тебе читабельность? WH>Гораздо лучше чем в С++
КЛ>>1) отмена :: есть большая ошибка. КЛ>>2) возможность называть переменные, свойства и т.п. так же, как и типы — еще одна ошибка. WH>Обоснований конечно не будет.
будут. Не понятно, что зовется. То-ли инстанс-метод, то-ли статический.
про 2), думаю, объяснять не нужно.
АХ>>>С другой стороны и у C++ много косяков. Как насчет отсутствия override? КЛ>>ерунда. WH>Ой не скажи...
ой скажу
КЛ>>отсутствие GC — самое последнее, что заботит с++ программера. WH>И кто тут занимается шапкозакидательством?
ну меня не заботит. Спроси 100 квалифицированных с++ программеров, и 95 скажут, что не заботит.
КЛ>>Конечно приходится "достраивать", используя smart pointers etc., но это настолько просто, что это даже не обсуждается. И это дает возможность выбора. WH>А ты знаешь что для того чтобы реализовать эти самые smart pointers нужен счетчик ссылок. А то что счетчик ссылок не работает в присутствии циклических связей что приводит к тому что нужно кувалдой расправлять простую и понятную систему с циклическими связями в дерево?
конечно не знаю, я знаю только new
С циклическими связями косяк, но и он разрешим.
WH>А то что в многопоточной среде для него необходимы как минимум Interlocked функции которые в многопроцессорных системах очень дороги?
хм. Да. Но даже при этом это будет капля в море по сравн. с издержками .net.
WH>А ты знаешь что банальные new/delete в многопоточной среде каждый раз лочатся? Хоть эти локи и можно иногда оптимизировать при помощи страшных платформозависимых вывертов но также просто и эффективно как ГЦ всеравно работать не будет. А если ГЦ еще и region inference поможет то плюсовый хип вобще будет в пролете.
да ничего я не знаю, я улицы подметаю обычно. Вот комп первый раз показали, я и решил тут поважничать.
Хм...А в .net не так? Может быть быстрее, но в итоге все равно lock
АХ>>>Вообще для меня нет пока идеального языка. КЛ>>а его и не будет, наверное ) WH>А разве это не С++?
Здравствуйте, CreatorCray, Вы писали:
WH>>А то что в многопоточной среде для него необходимы как минимум Interlocked функции которые в многопроцессорных системах очень дороги? CC>Да ну? lock xadd dword ptr [ecx],eax не такая дорогая инструкция.
Пока у тебя один процессор...
CC>Пардон, а выделение памяти из разных потоков в условиях GC как отрабатывает? Разве лок при этом не нужен?
Там очень легко делается по куче на процессор.
Далие делаем синхронную сборку мусора...
И чем глубже в систему это интегрируешь тем лучше это будет работать.
Например если сделать ОС полностью управляемой то никто не мешает просто запрещать прирывания на данном процессоре во время выделения памяти.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, CreatorCray, Вы писали:
CC>Пардон, а выделение памяти из разных потоков в условиях GC как отрабатывает? Разве лок при этом не нужен?
Полностью остонавливает все потоки на некторых стадиях сборки
И для C++ и для разных вариантов GC есть неблокирующие или малоблокирующие распределители памяти, так что подавать это как преимущество GC неккоректно.
Здравствуйте, FR, Вы писали:
FR>Полностью остонавливает все потоки на некторых стадиях сборки
А в С++ память освобождать не нужно?
FR>И для C++ и для разных вариантов GC есть неблокирующие или малоблокирующие распределители памяти, так что подавать это как преимущество GC неккоректно.
Нука покажи мне реализацию неблокирующего менеджера памяти для С++.
Только смотри я его на четырехроцессорной машине запущу...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, FR, Вы писали:
FR>>Полностью остонавливает все потоки на некторых стадиях сборки WH>А в С++ память освобождать не нужно?
Нет конечно
FR>>И для C++ и для разных вариантов GC есть неблокирующие или малоблокирующие распределители памяти, так что подавать это как преимущество GC неккоректно.
WH>Нука покажи мне реализацию неблокирующего менеджера памяти для С++.
А ты покажи полностью неблокирующий GC.
WH>Только смотри я его на четырехроцессорной машине запущу...
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, CreatorCray, Вы писали:
WH>>>А то что в многопоточной среде для него необходимы как минимум Interlocked функции которые в многопроцессорных системах очень дороги? CC>>Да ну? lock xadd dword ptr [ecx],eax не такая дорогая инструкция. WH>Пока у тебя один процессор...
Теперь скорее не на многопроцессорность а на многоядерность упор. На двух ядрах — полет нормальный.
WH>Там очень легко делается по куче на процессор.
Грубо говоря по куче на поток. Это можно и без GC. WH>Далие делаем синхронную сборку мусора...
Т.е. останавливаем на этот момент вообще все потоки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
VD>>Значит ты согласен, что вхождение библиотеки в комплект поставки продукта от МС еще не означает, что библиотека становится стандратной? CC>Да. Тут у нас с тобой ничья
У нас нет ничьей. Просто я поставил тебя на место тех кто с тобой пытается дискутировать. Теперь ты сам видишь неверность своих посылок.
CC>Ну, потому как ошибочно считал что WinForms входит в стандартные библиотеки.
Тогда и MFC входит. Стандарт показать конечно не смогу, так как это стандарт де-факто являющися таковым только для тех кто использует MFC.
Так что ты уж определись.
Или не переносимы и C++ и CLI-сборки, так как у них у обоих нет стандартного ГУИ. Или тебе прийдется признать, что переносимо и то и другое и и то и другое для переносимости требует тщательного выбора используемых библиотек. Так если хочешь не иметь проблем с ГУИ в переносимом приложении, то прийдется использовать GTK.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Сильно сложее. Я знаю оба языка, но в твоем варианте разобраться с ходу не могу. Немерловый же я читаю потчи так же легко как грамматику.
То что ты не хочешь признать очевидных вещей выдает в тебе остуствие конструктивизма. Общаться при этом смысла нет.
T>Может будешь аргументировать свои высказывания, иначе получается просто трёт.
А что тут аргументировать? Сравин объем кода. Сравни количество неинформативной грязи. Сравни схожесть с исходной грамматикой.
T>Или тебе просто так трепаться по приколу, заваливая собеседников едкими ответами подкреплёнными только гонором и спесью?
У собеседников проблемы даже не с гонором и спесью. У них проблемы с банальной адекватностью.
ОК можно попытаться вырзить все в цифрах. Итак:
* Исходная грамматика содержит 81 символ без пробелов.
* Вариант Вольфхаунда 372 символа без пробелов.
* Твой вариант 653 символа без пробелов.
При этом исходная грамматика не содержит семантики в отличии от двух других вариантов. За счет нее можно дать исходной грамматике 100% гандикапа. И того идеальным размером парсера был бы ~160 символов. Вольфхаунд превысил этот показатель более чем в двое, ты более чем в 4 раза.
Еще что-то доказывать надо?
При этом твой код это еще к тому же и банальное машейничество. Ведь самого распознования тут нет. Тут присуствует вызов каких-то функций которые по видимости должны заниматься распознованием токенов. Прибавь этот код и он уже будет ужасно огромным.
T>Ты даже не заметил ошибок в моём коде, которые были бы невозможны в декларативном синтаксисе.
А что их замечать? Код ужасен и без этого.
T>Ну и можно создать двольно общую библиотеку.
В Бусте есть Спирит. Что-то он сильно проигрывает по гибкости встроенному сопсоставлению с образцом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
VD>>Ну, нормальный человек и так прочесть может . Здесь очевидно разбирается некий язык токены которого лежат в списке decls.
КЛ>ну ты никогда не можешь удержаться, чтобы не попытаться унизить собеседника.
Что-ты, что-ты? Собеседник унижает сбея сам.
КЛ>Оказывается большинство программистов уже просто обязаны "читать" немерле, дожили...
Нет, нет. Только нормальные программисты которые не хотят оставаться в рамках одной идеологии.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
хм...По-моему тут унижает себя сам только один человек, и это не я. Задумайся над этим. Ты у меня уже давно потерял уважение. Думаю не только у меня. Ну это уже твои проблемы.
Здравствуйте, jazzer, Вы писали:
J>Разница была еще и в том, что Ада не была объектно-ориентированной.
А вот это смотря что считать ООП. В Аде 83 года не было tagged types. Это что-то вроде virtual в C++. Причём не сказать, что в Аде вообще не было ООП. Были инкапсуляция, наследование. А с полиморфизмом разобрались только к 95 (точно не знаю, но видимо до этого его реализовывали обходными путями). При этом в стандарте 83 года уже были generics.
Здравствуйте, dr.Chaos, Вы писали:
DC>>>ИМХО С++ довольно неплохо подходит для создания графических движков, это одна из тех задач, откуда его будет очень не просто вытеснить .
K>>Да на ассемблере тоже можно неплохой движок написать. DC>Напиши . Я хочу на это посмотреть . Видел демки 200-300Кб с нормально 3D графикой и музыкой, но это не движок
Да ладно, не вопрос. Только мне понадобится $2'000'000'000 и 10 лет.
Программы с нетривиальной логикой можно писать на любом Тьюринг-полном языке. На C, который прост как табуретка, вон Oracle всякие написаны. 
.
