Здравствуйте, Константин Л., Вы писали:
КЛ>это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться.
Передавай объекты через интерфейсы с немутирующими методами, и будет тебе щастье!
WolfHound wrote: > FR>И для C++ и для разных вариантов GC есть неблокирующие или > малоблокирующие распределители памяти, так что подавать это как > преимущество GC неккоректно. > Нука покажи мне реализацию неблокирующего менеджера памяти для С++. > Только смотри я его на четырехроцессорной машине запущу...
Hoard (http://www.hoard.org/) лично наблюдал на 8-процессорном сервере
Здравствуйте, CreatorCray, Вы писали:
WH>>Пока у тебя один процессор... CC>Теперь скорее не на многопроцессорность а на многоядерность упор. На двух ядрах — полет нормальный.
Куда теперь упор это вопрос весьма спорный. В конторе где я работаю есть машинки с четырьмя двуядерными процессорами...
WH>>Там очень легко делается по куче на процессор. CC>Грубо говоря по куче на поток.
Нет. Кучу нужно вешать на процессор. Ибо например у меня есть сервачек в котором потоки исчисляются сотнями тысяч...
CC>Это можно и без GC.
Очень сложно. Есть проблемы с удалением объектов созданных в другом потоке.
WH>>Далие делаем синхронную сборку мусора... CC>Т.е. останавливаем на этот момент вообще все потоки.
Что лучше один раз тормознуть и прибраться или постоянно лочить шину на каждый чих?
В любом случае оптимизация менеджера памяти не снимает проблему счетчиков ссылок.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, FR, Вы писали:
WH>>Нука покажи мне реализацию неблокирующего менеджера памяти для С++. FR>А ты покажи полностью неблокирующий GC.
Колличество локов сравни...
WH>>Только смотри я его на четырехроцессорной машине запущу... FR>Тут http://www.garret.ru/~knizhnik/threadalloc/readme.html принцип, тот же кстати что и в некторых моделях GC используется. Искать ссылки на конкретные библиотеки сейчас некогда.
Тупой алгоритм. У меня лучше.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Константин Л., Вы писали:
КЛ>>это огромнейший недостаток. const это не только способ документирования кода, но и способ избавления от многих ошибок. В c# каждый метод — черный ящик. Что он может сделать с твоим объектом можно только догадываться.
K>Передавай объекты через интерфейсы с немутирующими методами, и будет тебе щастье!
Здравствуйте, Константин Л., Вы писали:
K>>Передавай объекты через интерфейсы с немутирующими методами, и будет тебе щастье! КЛ>шутишь?
А что по товоему методы с модификатором const как не описание интерфейса объекта с немутирующиме методами?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
>> Только смотри я его на четырехроцессорной машине запущу... C>Hoard (http://www.hoard.org/) лично наблюдал на 8-процессорном сервере
Это наверное глупость но я без крайней нужды не пользуюсь кодом в котором смешаны табы и пробелы.
Ну не верю я в то что человек небрежный в таких мелочах может сделать что-то что работает хорошо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: >> > Только смотри я его на четырехроцессорной машине запущу... > C>Hoard (http://www.hoard.org/) лично наблюдал на 8-процессорном сервере > Это наверное глупость но я без крайней нужды не пользуюсь кодом в > котором смешаны табы и пробелы. > Ну не верю я в то что человек небрежный в таких мелочах может сделать > что-то что работает хорошо.
А ты не смотри — просто подлинкуй его, он у нас работал без каких-либо
проблем ВООБЩЕ. Мы его в итоге даже купили.
Здравствуйте, Cyberax, Вы писали:
C>А ты не смотри — просто подлинкуй его, он у нас работал без каких-либо проблем ВООБЩЕ. Мы его в итоге даже купили.
Я так не могу.
Я перед новым годом уже выловил квадратичный алгоритм в стороннем коде который вобще без проблем работал два года пока туда приходило по 10-30 байт. Но когда пришлось обходить ограничение другой поделки пришлось туда загнать 100К данных. И вот тут то все и всплыло.
Заменили алгоритм на линейный и все сразу начало летать.
Так что я лучше буду читать исходники перед тем как их использовать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>А ты не смотри — просто подлинкуй его, он у нас работал без каких-либо > проблем *ВООБЩЕ*. Мы его в итоге даже купили. > Я так не могу. > Я перед новым годом уже выловил квадратичный алгоритм в стороннем коде > который вобще без проблем работал два года пока туда приходило по 10-30 > байт. Но когда пришлось обходить ограничение другой поделки пришлось > туда загнать 100К данных. И вот тут то все и всплыло. > Заменили алгоритм на линейный и все сразу начало летать.
Ну так сломается — тогда и можно смотреть. Ну и заранее потестить на
нагрузке, естественно.
> Так что я лучше буду читать исходники перед тем как их использовать.
Я тоже предпочитаю делать RTFS перед использованием. Поэтому я и не
люблю продукты MS.
Андрей Хропов wrote: > C>Через два года. > Это они только > expressed a strong desire
Ну остается только надеятся
> C>Следующий ISO-стандарт для C# тоже еще не близко. > Так то, что я привел, уже стандарт и уже реализовано в MS.NET и Mono.
Оно де-факто есть и в С++ почти везде. Только вот в реальных
невычислительных программах нужно еще кучу всего.
> C>Ну это точно такая же ситуация, как и с С++. Необходимо будет > C>тестировать на совместимость со всеми средами так же, как и в случае с > C>С++ требуется тестировать с разными компиляторами. > Если у тебя портабельная библиотека, то это требует минимальных усилий > (ну как с Java ситуация).
С Java ситуация почти идеальная, фактически, есть только одна JDK на
куче платформ. Остальные на нее ориентируются и обычно достаточно
совместимы.
> C>Ну так и в C# точно так же, используешь какой-нибудь системно-зависимый > C> контрол — и привет портируемости. > Ну естественно. Но это уж, что называется, сам виноват.
Так вот, MS делает такие ляпы ну уж ОЧЕНЬ легкими.
> Вот, например, возьмем тот же GUI. Каким он должен быть — на нативных > контролах или одинаковый на всех платформах? Иконки растровые или > векторные? Должен смену скинов поддерживать или нет? Слишком много > разных требований, на всех не угодишь.
Swing в Java Может использовать свои скины или эмуляцию родного GUI
для платформы. Работает достаточно прилично.
> C>Вот в Java, фактически, такой стандарт есть — это Sun JDK, который есть > C>на куче платформ. А сейчас вообще открытым стал. > Да, ну так там тоже зоопарк. GUI на чем делать — на AWT или Swing?
AWT? Это что такое?
Сейчас есть два фреймворка — Swing и SWT. SWT — обертка над нативным API.
. VD>Сильно сложее. Я знаю оба языка, но в твоем варианте разобраться с ходу не могу. Немерловый же я читаю потчи так же легко как грамматику.
То что ты не смог разобраться может говорить о чём уггодно — например и не пытался, или о том, что свои ты знания несколько преувеличиваешь.
Я тоже не мог разобраться в варианте Немерле, пока ты не привёл грамматику.
VD>То что ты не хочешь признать очевидных вещей выдает в тебе остуствие конструктивизма. Общаться при этом смысла нет.
И чего я не хочу признавать? Резолюций от VladD2:
Код ужасен и без этого.
— мне они по барабану.
T>>Может будешь аргументировать свои высказывания, иначе получается просто трёт. VD>А что тут аргументировать? Сравин объем кода. Сравни количество неинформативной грязи. Сравни схожесть с исходной грамматикой.
Выделенное простим как непроизвольную неинформативную грязь. VD>ОК можно попытаться вырзить все в цифрах. Итак: VD>* Исходная грамматика содержит 81 символ без пробелов. VD>* Вариант Вольфхаунда 372 символа без пробелов. VD>* Твой вариант 653 символа без пробелов.
VD>При этом исходная грамматика не содержит семантики в отличии от двух других вариантов. За счет нее можно дать исходной грамматике 100% гандикапа. И того идеальным размером парсера был бы ~160 символов. Вольфхаунд превысил этот показатель более чем в двое, ты более чем в 4 раза. VD>Еще что-то доказывать надо?
И что это доказывает? То что мой код в 2 раза больше немерловского и так сразу видно.
Если перевести это на J — оно, вполне возможно сильно меньше получиться.
Без пробелов, табуляций и прочих переводов строк не один из этих вариантов читаться не будет никак.
Если нарисовать эту грамматику кисточкой — символов почти не будет, зато читаться будет великолепно, а вот вычисляться — опять таки никак.
Кстати, про объем — код я нарисовал пока пытался разобраться в исходном — т.е это просто "подстрочник" с немерля на С++. Если нужно будет реально работать в этой области, код будет меньше по крайней мере на 1/4 без потери наглядности.
Хотя, если всё-таки реально работать, то лучше честный генератор LL чем показанный рекурсивный спуск.
VD>При этом твой код это еще к тому же и банальное машейничество. Ведь самого распознования тут нет. Тут присуствует вызов каких-то функций которые по видимости должны заниматься распознованием токенов. Прибавь этот код и он уже будет ужасно огромным.
Я не знаю Немерл, и предположил, что символы Identifier, Round, Semicolon, Brace, а так же parseMessage и parseState — это не ключевые слова языка, а нечто определённое пользователем. Вот и заменил на как мне кажеться, соответствующие конструкты С++.
Т.е. Identifier, Round, Semicolon, Brace — классы а parseMessage и parseState — свободные функции. Semicolon наверное в немерле простая константа, но т.к. всё таки эмуляция сопоставления, пришлось и её сделать классом, правда довольно простым и легко параметризуемым.
Если я прав, то мой код не более мошенничество чем немерлевский — ведь к ниму тоже не прилагается определения этих символов.
А вот что ты понимаешь под самим распознаванием каюсь, не понял.
И там и здесь проверяется соответствие входной последовательности определённому шаблону. При совпадении выполняються некоторые вычисления, и рекурсивно вызывается та же функция разбора.
T>>Ну и можно создать довольно общую библиотеку. VD>В Бусте есть Спирит. Что-то он сильно проигрывает по гибкости встроенному сопоставлению с образцом.
Я как бы в курсе.
Кстати, если уж сопоставлять Спирит с сопоставлением, то какой класс грамматик поддерживает сопоставление в Немерле?
Я согласен, что декларативный синтаксис, в частности сопоставление с образцом и списковые дополнения в сочетании со статической типизацией и автоматическим выводом типов очень удобные и мощные языковые механизмы. С их помощью многие вещи можно записать более выразительно.
Но от того, что язык их содержит, он не становится автоматически лучшем_языком_в_мире_на_котором_невозможно_писать_неправильные_программы,
и наоборот, не имеющий этих наворотов язык не становиться от этого полным_отстоем, как это можно заключить по твоим высказываниям.
Читая твои посты, создаётся впечатление, что мы не в форуме "философия программирования" а на митинге в поддержку .Net + ХХХ и заклеймению непохожих.
Если тебе платят за это — скажи, я наверно пойму. (с) Б.Г.
Здравствуйте, eao197, Вы писали:
E>Я, прежде всего, предлагаю не осуждать кого-либо за использование какого-либо инструмента.
Согласен. Осуждать в данном случае не размуно. Надо просто смеяться, как смеемся мы глядя на то как кто-то попытается забить гвоздь каменным молотком.
E> И исхожу из того, что люди в большинстве своем, вполне разумны и делают осмысленный выбор
Идиалист, блин. Если бы это было так, то в 30-ых годах просшого века к власти не пришел бы Гитлер в Германии, в 90-ых Ельцин в России, а в 21 веке уже никто бы не писал на С++.
E> на основании своих конкретных условий. Если кто-то использует C++ -- значит в его конкретных условиях это нормально и выгодно.
Или он попросту поддался настроению толпы.
E>А развешивание ярлыков вроде "доисторических" инструментов вызывает только неприятие как самого говорящего такие вещи, так и его идей.
Дык не развешивай. Я выражаю свое мнение. В 21 веке С++ не место. Это динозавро который забыл вымереть.
E>Тем более, что даже в наше время использование GPS приемников не всегда возможно как по техническим, так и по финансовым, так и по идеологическим причинам.
Дык в области программирования технические и финансовые условия не работают. А вот идеологические конечно сильно влияют. Религия и фанатизм вещь суровая. Тут уж ничего не поделаеть.
E> Например, не может наша военка устанавливать на военную технику GPS приемники в качестве основного средства навигации
Да, да, это замечательное оправдание использование астролябии для запуска болистических ракет. А уж какое это оправдание для использования оной в народном хазяйсвте. О том как это влияет на С++ и его использовние вообще лучше умолчать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plague, Вы писали:
P>Здравствуйте, VladD2, Вы писали: VD>>У Оберона вроде как ЖЦ убитый. Если только заменить...
P>А что у него с GC? можно где-нить почитать?
А ничего. Используется один из примитивнеших алгоритмов. На простых тестах довольно шустро, но в реальных условиях практически не применимо. Тут где-то рядом кто-то делал тест (после пиара Губановым крутости ЖЦ Оберона), так там Оберон умер после создания нного количества объектов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Что именно? То что неплохо подходит или то что непросто вытеснить? Хм, а графический движок не с битами возиться? Или я чего-то недопонимаю?
Нет, не с битами. Они уже давно такой фигней не страдают. Почитай внимательно призентацию. Там есть про это не мало слов. На ассемблере они уже ничего не пишут. Все вычисления хотят сделать фукнциональными, чтобы ошибок по меньше было, и чтобы параллелились они хорошо.
Графика давно живет в разных дитеркиксах и шейдерах.
DC>Дык я и не утверждал что инструмент лучший. Но только на данный момент есть только требования к новому языку, но языка то еще нет. Так что мимо кассы, как появиться инструмент так и говорить можно будет.
В общем-то ОКамл или Немерле удовлетворяют большинству указанных там требований. Не всем конечно, но уж точно они в сто раз ближе к тому идеалу чем С++.
Собственно весь разговор о том, что ищется замена С++.
DC>Полагаю что новый стандарт решит часть проблем в С++.
Ни одной!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>чего стоит мой — я знаю. А вот чего стоит твой? Кроме шапкозакидательства, хамства, снобизма, и т.п. пока ничего толкового не увидел.
Большое видится на растоянии.
КЛ>На днях планирую посмотреть подробнее на немерле и написать о впечатлениях.
Давай. Здоровый юмор никогда не бывает лишним.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Константин Л., Вы писали:
K>>>Передавай объекты через интерфейсы с немутирующими методами, и будет тебе щастье! КЛ>>шутишь? WH>А что по товоему методы с модификатором const как не описание интерфейса объекта с немутирующиме методами?
Здравствуйте, VladD2, Вы писали:
P>>А что у него с GC? можно где-нить почитать?
VD>А ничего. Используется один из примитивнеших алгоритмов. На простых тестах довольно шустро, но в реальных условиях практически не применимо. Тут где-то рядом кто-то делал тест (после пиара Губановым крутости ЖЦ Оберона), так там Оберон умер после создания нного количества объектов.