Здравствуйте, IT, Вы писали:
E>>Еще раз -- C++ не задумывался как безопасный язык.
IT>Откуда такие подробности? Ты свечку держал когда он задумывался? У меня вот, например, как у жителя эрии где непосредственно разрабатывался C++ есть про его создателя некоторые интимные подробности. Но про безопасный язык я что-то не слышал
Что-то мы друг друга не понимаем. Не делал Страуструп безопасный язык. Безопаснее C -- делал. Но не настолько безопасный, как какой-нибудь Smalltalk, Ada или Modula.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, IT, Вы писали:
АХ>>Зависит от задач. Где Java/.NET рулят (server-side) там на них во многом и перешли. АХ>>А в number crunching что-то не видно.
IT>Там рулят фортраны. Впрочем, если не сложно, дай ссылку на такой алгоритм перемалывания.
Есть у меня инсайдерская информация об использовании C++ и Intel-овских технологий (компиляторов и специальных библиотек) в расчете погоды на каких-то опупенно мощных кластерах.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[30]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, VladD2, Вы писали:
VD>Лямбда — это возможность создать анонимный метод. А чтобы на нее можно былопередать ссылку нужен функциональный стиль. Вот делегат это их разновидность. Не лучшее решение, на самом деле, но уж точно лучше его отсуствия или указателей на члены в С++.
VD>Понимаеш, я спокойно отношусь к тому, что эта возможность может быть не нужна какой-то части аудитории языка. Но так как она не мешает, и так как она нужна другой части, то не вижу причин почему не ввести в язык поддержку функционального типа и лямбды (ака анонимного метода с поддержкой замыканий).
Насколько я понимаю, при проектировании C++ как раз внимание уделяется именно тем вещам, которые нужны разным слоям пользователей C++. Mutable -- это фундаментальная особенность, она нужна для любой предметной области, чтобы не прибегать к хакам. Свойства -- напротив. Лямбды так же нужны не всем. Более того, интерес к лямбдам повышается с популяризацией к функциональному стилю. И еще не факт, что лямбды на самом деле так удобны, как об этом говорят. Лично я по опыту использования блоков кода в Ruby не сильно в этом уверен.
VD>И что же мы слышим в ответ? "Язык надо развивать библиотеками..." Но позвольте, реализация функционального типа и лямбды средствами С++ жутко сложное занятие и не приводящее к удовлетворительному для всех результату. За 20 лет существования языка было сделано множество попыток, но все они имели те или иные недостатки. А уж их сложность, объемность и тормоза при компиляции стали христоматийными.
VD>Так с чем собственно борьба?
Так вот с этим и борьба -- не нужно делать какое-то одно универсальное средство, которое не будет удобно всем и эфективно во всех применениях.
E>>Нет уж, увольте. С меня хватило нескольких попыток поизучать OLE, OLE2 и того, что шло за ними.
VD>Раз ты изучал данные технологии, то должен знать главное отличие ОЛЕ от ОЛЕ2. В чем оно заключается?
Вот уж чего никогда не мог понять, так это жем же отличаются OLE, ActiveX, COM, COM+ и пр.
VD>Ну, ладно, раз читать ты про КОМ не хочешь, то в предь не говори про него не чего. А то групость получается. Поверь просто на слово, что КОМ делали именно на С++. С++ и С — это два языка на которых можно разрабатывать КОМ-объекты без поддержки со стороны компилятора. Причем на С это выглядит просто ужасно, так как при этом эмулируются такие вещи как VTBL C++.
И сделали так удачно, что сложность работы с COM на C++ стала притчей во языцах.
VD>>>За одно можешь подумать почему биндинг для КОРБы получился "кривым" (с).
E>>Потому, что биндинг CORBA -- результат работы комитета. Ребята из www.zeroc.com для своего Ice более удобное решение нашли. Потому что были кровно заинтересованы в результате.
VD>Согласен. Но комитета по плюсам, так как на Яве и дотнете биндинг выглядит отлично.
В Java и .NET есть сборка мусора.
Про ее отсутствие при проектировании биндинга на C++ почему-то забыли. Из-за чего это было сделано -- из-за элементарного ламерства или создания "унифицированного" биндинга для всех языков я не знаю.
VD>>> И почему 99% библитек для С++ выглядят запутанными и не удобны в испльзовании.
E>>Очень сильно сомневаюсь, что тебе довелось познакомиться хотя бы с 0.1% C++ библиотек.
VD>Это твои личные проблемы. Мало ли в чем сомневаюсь я...
Ты действительно работал с 99% процентами библиотек для C++? Или же это был литературный авторский прием, гипербола?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[31]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, VladD2, Вы писали:
VD>>>Поправляю, tcl сюда был приплетен в опровдание тому факту, что на С++ без внешних подпорок нельзя создавать полноценный ГУЙ. Оправдание правда скорее является приговором, но многим фанатам этого устаревшего языка и оно сойдет.
NB>>цитату не затруднит? могу даже помочь
VD>Меня как-то пугает полная неадекватность оппонентов. Ты же сам привел ссылку в которой видно, что tcl появился совершенно от балды, в подветке где обсуждалась проблема построения гуи на С++? Одну подпорку (генераторы кода в QT) подменили второй подпоркой tcl.
ага. закончились аргументы, переходим не личность. знакомо.
для самых одареных объясняю.
tcl был приведен как пример того, как надо делать гуи.
потом IT попросил показать код.
назавать tcl подпоркой С++ такой же смысл, что и питон.
так понятно?
VD>Причем вторая имеет еще меньшее отношение к С++.
ага. вобще не имеет отношения. это самостоятельный язык.
вот QT -- вполне себе библиотека. для плюсов их больше десятка.
NB>>PS: может вам все-таки стоит ознакомится с языком tcl. хотя-бы поверхностно.
VD>Это как-то поможет встраиванию в С++ средств построения ГУИ? Если нет, то спасибо. Я знаю куда более удобные для меня пути построения качественного ГУИ.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Зависит от задач. Где Java/.NET рулят (server-side) там на них во многом и перешли. АХ>>А в number crunching что-то не видно.
IT>Там рулят фортраны.
Ну, общеизвестно что самая популярная библиотека численных расчетов в мире LAPACK написана на Fortran.
Есть также популярный ее порт на C — CLAPACK.
Но это скорее по историческим причинам (люди которые ее писали проходили Fortran в университетах).
В Фортране единственно чуть удобнее работать с индексами и компилятор теоретически может порождать чуть более быстрый код взасчет того, что
матрицы встроены в язык, а не как указатели в C++
(на практике именно на вычислительных задачах можно посмотреть их сравнение здесь,
в большинстве случаев C++ впереди),
а в остальном он — ****.
(это я на своем опыте говорю, немного пописал на нем, так как в школе проходили, больше не захотелось ).
Вот здесь люди собирают подписи за то, чтобы формально отказались от Фортрана.
Ну а вообще в этой области (number crunching) начинают рулить шейдеры : ( здесь )
и соответственно такие языки как Cg, DirectX HLSL и GLSL.
IT> Впрочем, если не сложно, дай ссылку на такой алгоритм перемалывания.
Вот есть такой каталог ссылок по поводу Scientific Computing Software.
Там
Fortran,
C, C++,
Python (ядро вычислений в библиотеках использует те же C/C++, Fortran ) и
MATLAB (MATLAB использует LAPACK для расчетов, а оболочка теперь переписана на Java, поэтому весьма тормозит и пямять отжирает сотнями мегабайт )
в основном.
Есть библиотека Intel IPP (она правда на чистом C).
Ну вот я использую довольно большую библиотеку для компьютерного зрения vxl, где полно математики
(там внутри сидит netlib, но не для всего).
Есть еще вот библиотеки для довольно сложных задач минимизации на графах.
Подавляющее большинство игр, где как раз много математических расчетов, написано на C++.
Популярные физические движки ( Havok, ODE)
также написаны на C/С++.
Здравствуйте, eao197, Вы писали:
E>Насколько я понимаю, при проектировании C++ как раз внимание уделяется именно тем вещам, которые нужны разным слоям пользователей C++. Mutable -- это фундаментальная особенность, она нужна для любой предметной области, чтобы не прибегать к хакам.
Да, да. По этому есть тонны программистов которые работали не в одной области и ни разу не использовали этой возможности. И видимо именно по этому есть языки спокойно обходящиеся без mutable. Более того именно по этому идут разговоры о замене значения некоторых таких же "нужных" вещей (например auto).
E> Свойства -- напротив.
Серьезно? А вот мне ИТ они нужны. Неувязочка у вас. Хочешь проведем глосование? Сам увидишь, что минимум треть народа проголосует за то что свойства нужны.
E> Лямбды так же нужны не всем.
Еще одна не увязочка. Mutable почти никому не нужен и он есть. А лямбда нужна не всем, но очень многим и ее нет.
E> Более того, интерес к лямбдам повышается с популяризацией к функциональному стилю.
Напомню, функциональный стиль в С++ используется с 98-го года когда в С++ был добавлен STL. При этом используется через зад автогеном именно потому, что С++ не имеет нужных возможностей.
E> И еще не факт, что лямбды на самом деле так удобны, как об этом говорят.
Да, да, еще не факт, что ходить чистым и подстриженым так удобно как об этом говорят поганые менты гоняющие нас бомжей с улиц.
E> Лично я по опыту использования блоков кода в Ruby не сильно в этом уверен.
Лично ты не являешся пупом земли. И раз есть масса людей которые считают удобным и нужным некоторую возможность, то значит возможность нужна. И твое двуличие здесть выпячивается очень четко. Mutable ты считашь достоиным быть в языке, так как он хоть кому-то нужен (хотя эти кто-то так и не смогли привести пример в котром без него не обойтись), а лямбда не нужна, так как лично ты не видишь в этом необходимости.
ОК, раз ты считашь нормальным пдобные рассуждения, то экстрополируем это на меня. Лично я ни разу не использовал Руби ни для чего кроме тестов. Без Руби можно спокойно обходится. Значит Руби не нужен и не имеет права на существование? Обсурд? Несоменно! Вот так же обсурдны твои слова и слова твоих сторонников.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Зависит от задач. Где Java/.NET рулят (server-side) там на них во многом и перешли.
Ява и донетн "рулят" в куда большем количестве областей. И то что пока на них в этих областях не перешли является всего лишь проявлением людской недальновидности.
Более того есть не мало народу который жрет кактусы создавая серверы на С++.
АХ>А в number crunching что-то не видно.
Оптимизаторы пока не на высоте. Многие цепляются за 10-20 процентов производительности. Но масса рассчетов уже ведется и на Яве и на дотнете. Я знаю о том, что для химических рассчетов уже используются менеджед-языки и с успехом.
VD>> С++ морально устарел. АХ>Ну немолод
Знаешь, Лисп, например, куда более стар по сравнению с С++. И я бы сказал, что Лисп язык слишком своеобразный и вообще много чего нехорошего могу про него сказать. Но вот сказать о Лиспе, что он устарел я не могу. А языку уже около 60-ти.
VD>> Не имеет ни одного приемущества. АХ>Основное преимущество — быстрый код, сравнимый с C.
Это фобия, а не приемущество. Тут вот все компиляторы С++ слили Немерлу в Аккермане. В других тестах они выглядят на равных. По крайней мере скорость С++-компиляторов никак не соотносится с заслугами проетировщиков языка. Это заслуга тех кто делал оптимизации и кодогенерацию в конкретных компилторах. Нет проблем найти С++ компилятор который сольет дотнету или Яве в 99% тестов. А компиляторы которым старше 10 лет делают это практически в 100% случаев.
АХ>И существенная экономия памяти по сравнению с Java/.NET
Это правда, но не совсем. Когда программы начинают обрабатывать действительно огромные объемы данных, то разница нивилируется. На нашем сервере есть дотнет-процессы жрущие по 30-40 метров и нэйтив отедающие по 1.5 гига.
Ну, и память нынче стоит не так дорого, чтобы это действитльно было препятствием.
АХ>(не говоря уже про то, что хорошая реализация .NET пока есть только в Windows).
Моно неплохая реализация. Оптимизатор у нее явно слабый. Но сама реализация вполне ничего себе.
АХ>Впрочем все это уже 100 раз обсуждалось.
Ага. Но фобии остаются. И ты их еще раз выразил. Понимашь в чем дело? Вот eao197 пишет сервер приложений на С++ и прикладные серверные решения на нем же. Казалось бы уж в его то области дотнет или Ява — это явное конкурентное приемущество, а н нет. Прикрываясь перчечислеными фобиями и подогревая это все своими фобиями по переносимости, он уговаривает себя, что С++ лучший выбор. А на деле просто не пробовал альтернатив. От того и ищет что-то вроде Руби чтобы хотя бы на внутреннем коде не иметь тот геморой что он имеет в коммерческом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, VladD2, Вы писали:
VD>>> Не имеет ни одного приемущества. АХ>Да, и еще добавлю что у него есть нормальная поддержка обобщенного программирования на шаблонах, АХ>чего не видно в других распространенных языках (урезанные genericи совершенно не рулят).
Это еще одна фобия. Для чисто обобщенного программирования, то есть для создания кода не зависящего от типов дженериков хватает за глаза. Шаблоны имею примущество только в том смысле, что в них нет нужны обощать операции с помощью интерфейсов или фукнциональных типов. Однако еслив языке есть хороший синтаксис для последних, то приемуществ в обобщенном программировании у С++ не остается. Другое дело метапрограммирование на шаблонах. Но тут как мы знаем есть куда более выдающиеся решения.
АХ>Конечно, Nemerle способен предложить кое-что покруче, посмотрим что из этого выйдет...
Вот именно. И не просто по круче, а прямые решения без ануса и автогена. И не в области обоьщенного программирования (в Немерле тоже для этих целей используются дженерики), а в области метапрограммирования. Тут С++ сливает уже совершенно явно и очевидно.
Что же касается дженериков, то их ограничения в основном связаны с требованиями модульности и компонентности. Нельзя получать в одном и терять в другом. Дотент, Яву и Дельфи многие предпочитали в замен С++-у даже тоггда когда в этих языках вообще небыло обобщенного программирования. И вызванно это именно отличной поддержкой компонентного программирования. Кстати, Руби, Смолток и Питон тоже по сути не поддерживают обобщенное программирование в том смыле в котором его поддерживают C++, C# и Nemerle. В скриптовых языках типа Смолтока для обобщения используется динамический полиморфизм, а в С++ и Немерел параметрический. Так вот дженерики — это компромис позволяющий включить в язык параметрический полиморфизм при этом не нанеся ущерба компонентным возможностям языка, рантайма и кода.
Конечно было бы здорово если в качестве ограничений дженериков можно было бы использовать отдельные методы и операторы, но и без этого жить можно препиваючи. Как минимум поддрежка компонентности и невероятная простота работы окупают эти недостатки. Специализацию возможностей дженериков можно с успехом делать делегатами и функциональными типами. В Немерле это вообще выглядит замечательно. Так что С++ и здесь аутсайдер. Просто мноие не могут переключить мышление на другой лад.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, eao197, Вы писали:
E>Есть у меня инсайдерская информация об использовании C++ и Intel-овских технологий (компиляторов и специальных библиотек) в расчете погоды на каких-то опупенно мощных кластерах.
То есть еденичный случай?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, Дьяченко Александр, Вы писали:
ДА>Может всетаки 4 байтами?
Сори, я имел в виду двумя char-ами.
ДА> В UTF-16 вроде символы восновном 2 байтовые.
VD>>Огромная редкость и обычно их просто нет в шрифтах, но формально есть.
ДА>Ну если всего символов 130 тыс. то не такая уж и редкость каждый второй символ
Это простраство 130 тысяч, а реально используется только назначительная часть. Так что программы для 99% нужд можно писать думая что один char == один символ. Код вроде вычисления размера строк в пикселях учитывает эти особенности и выведет любой шрифт. А в обработке тебе все это не важно. А если важно, ну, что же... или переведешь в UTF-32, или помучашся с вычленением составных символов.
Возможно когде нибудь, когда память начнет измеряться терабайтами мы перейдем к UTF-32 и забудем вообще о всех проблемах. Но и переход к UTF-16 — это большой прогресс! Ведь для тех самых 99% случаев можно забить на все.
C>>>6. И как теперь нормально использовать quadchar'ы в CLR? VD>>Так в чем проблема то?
ДА>Действительно как? Мне просто интересно (врятли хоть раз использую...)
Мне тоже на эти подробности наплевать. Если интересно копать надо в сторону System.Globalization.UnicodeCategory, метода GetUnicodeCategory() и класса UTF32Encoding.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, Cyberax, Вы писали:
C>Это общая фраза, про некого абстрактного чайника.
Ну, вот и не надо конкретным людям про асбтрактных чайников вещать. А то ведь модумают плохое...
C>Вот только 99.99% программистов на .NET используют строки как UCS-2.
И что есть проблемы? Плевать всем на экзотику. А кому не плевать, тот разберется. Воспользуются UTF32Encoding в крейнем случае.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Синтаксический сахар или C++ vs. Nemerle :)
Здравствуйте, eao197, Вы писали:
E>Это уход от ответа.
Это ответ который тебя не удовлетворяет. Ищи проблемы в себе.
E>Если хеш хранится в объекте в виде атрибута, то как этот атрибут будет изменяться константным методом объекта для константного же объекта?
А зачем его делать константным? Еще раз название константный — это бред созданный Страуструпом.
Неизменяемый объект — это дизайн, а не атрибут. Я на C# без проблем делаю неизменямые объеты и уверен в их неизменности. А вот на С++ при наличии const я все равно ни в чем не уверен.
E>Это та же самая задача, словесную формулировку которой вы с IT просили у меня.
И в чем проблемы бло дать словесное описание?
E>Только в моем случае был не хеш (с которым возможны коллизии), а уникальная двоичная последовательность.
А есть ли разница? В конце концов данным можно держать и вне объекта, а в объекте держать их индекс в неком массиве. Тогда останется только сделать в конструктре приращение счетчика. Для C# или Немерла такой дизайн прост и прозрачен. А в С++ мы имеем проблемы.
Интересно, что авторы Немерла задумывались над проблемой неизменяемости кода и вообще над проблемой проверки инваринтов методов, объектов и даже циклов. И вывод был однозначным — определять неизменяемость обязан компилятор или отдельная утилита! Короче кто угодно на не человек.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Синтаксический сахар или C++ vs. Nemerle :)
VladD2 wrote: > Возможно когде нибудь, когда память начнет измеряться терабайтами мы > перейдем к UTF-32 и забудем вообще о всех проблемах.
Найти твою цитату про память, которая сейчас очень дешовая?
Увеличение размера символа в два раза плохо скажется только на
редакторах текстов. В остальных программах строки обычно занимают
процентов 10 памяти.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[28]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, eao197, Вы писали:
E>Mutable -- это фундаментальная особенность, она нужна для любой предметной области, чтобы не прибегать к хакам. E>Свойства -- напротив. Лямбды так же нужны не всем.
Гениально! Если так рассуждает консенсус комитетчиков, то многое становится ясным.
Значешь какую ошибку я считаю самой серьёзной и непростительной при разработке чего-либо? Это попытка решать что юзеру нужно, а без чего он обойдётся, решать, не спросив об этом самого юзера.
Свойства во многих языках используются уже много лет и очень хорошо себя зарекомендовали. Полноценные лямбды в C# я, например, жду с нетерпением, а пока во всю используют анонимные методы. А вот mutable в .NET совсем отсутствует, и никого это сильно не напрягает. В Java, кстати, тоже как-то без mutable нород живёт. А вместе с C# комьюнити это сегодня будет побольше, чем комьюнити C++. Тем не менее, ты можешь себе позволить вот так решить за всех что им нужно
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Tcl как обоснование ненужности поддержки компонентно
Здравствуйте, VladD2, Вы писали:
ДА>>Ну если всего символов 130 тыс. то не такая уж и редкость каждый второй символ VD>Это простраство 130 тысяч, а реально используется только назначительная часть. Так что программы для 99% нужд можно писать думая что один char == один символ. Код вроде вычисления размера строк в пикселях учитывает эти особенности и выведет любой шрифт. А в обработке тебе все это не важно. А если важно, ну, что же... или переведешь в UTF-32, или помучашся с вычленением составных символов.
Спасибо. Вобщем я и так догадывался что большая часть (если не все) этих 4-ех байтовых (2-х char-овых) символов не самая обще употребительная.
VD>Возможно когде нибудь, когда память начнет измеряться терабайтами мы перейдем к UTF-32 и забудем вообще о всех проблемах. Но и переход к UTF-16 — это большой прогресс! Ведь для тех самых 99% случаев можно забить на все.
Ну можно и пораньше переходить. Где-нить к через одной винде после Vista, ну или через 2 (Когда память перевалит рубеж в 32-64 гига и все давно уже будет 64 битным)
C>>>>6. И как теперь нормально использовать quadchar'ы в CLR? VD>>>Так в чем проблема то? ДА>>Действительно как? Мне просто интересно (врятли хоть раз использую...) VD>Мне тоже на эти подробности наплевать. Если интересно копать надо в сторону System.Globalization.UnicodeCategory, метода GetUnicodeCategory() и класса UTF32Encoding.
Спасибо. Уже сам посмотрел. Пользовать в случае крайней необходимости... (Вот интересно всякие отображалки (типа Console.WriteLine и Graphics.DrawString) нормально переваривают такие символы?)
Здравствуйте, Андрей Хропов, Вы писали:
АХ>(на практике именно на вычислительных задачах можно посмотреть их сравнение здесь,
Забавные тесты. Правда фортрана я там не нашёл. Зато обнаружил, что преславутые Руби и Tcl уверенно замыкают список практически во всех тестах, отставая от лидеров в десятки и сотни раз, а порой вообще имеют timeout.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
).
: ( здесь )
)
Если нам не помогут, то мы тоже никого не пощадим.
