LINUX.ORG.RU

Один из лучших компиляторов C++ для Linux прекращает существование


2

0

Один из лучших компиляторов С++ для Linux, KAI C++, прекращает свое существование с 30 апреля 2002 года, через два года после покупки Kuck & Accociates Inc. компанией Intel. 30 апреля будут прекращены продажи, поддержка и исправление ошибок в существующих релизах будут продолжаться до конца 2003 года. Технологии KAI будут интегрированы в компиляторы Intel. В настоящее время компиляторы Intel уступают KAI как по уровню совместимости со стандартом, так и по возможностям оптимизации.

>>> Подробности



Проверено:

Не мне нравится, народ считает время выполнения программы в многозадачной системе используя ftime... Большей глупости представить сложно...

anonymous
()

2All:

Народ, знает ли кто, что за новый Матогенератор объявился - anonymous(AKA asoneofus)? Луговского - Антихриста наконец-то стало можно читать, и он четко перестал нести бред, начал выдавать что-то полезное, нет тут еще какой-то придурок объявился... С наклонностями... И опять пошел бред!

Так не может ли кто опознать "anonymous'a(AKA asoneofus)" ибо он видимо то ли представитель доблестных органов, то ли еще какой-нибудь "гос. служащий", раз ссылается на оскорбление при исполнении. Хотя где же это платят за флейм?

anonymous
()

2Antichrist:

Есть пара вопросов:

1) Исключительно благодаря этой теме начал смотреть OCaml, насколько я понимаю, одним из наиважнейших его приемуществ над C++ в ряде задач является возможность передачи функций, как параметров. Так вот я прав? Если ошибаюсь - то в чем? Конечно это обстоятельство несколько меняет логику построения программы, но казалось бы не настолько сильно. Подобная же возможность есть и в С++ (например for_each), только конечно намного менее удобно (надо писать класс).

2) А где можно найти документацию по Eiffel (eiffel-forum.org кажется накрылся. По крайней мере у меня он не прозванивается)?

Заранее спасибо.

anonymous
()
Ответ на: комментарий от anonymous

>народ считает время выполнения программы в многозадачной системе используя ftime...
когда время большое, и разница большая (14 секунд против 200), на "многозадачность системы" можно забить.

AC
() автор топика

Блин, классный флейм - а мне некогда :(((
Все же, вставлю свои 5 копеек:

2AC (*) (2002-04-26 17:37:08.88):
> А ниша C++ -- фортран будущего.
Здорово сказал! Так и будет, несмотря на то, что по эффективности числодробил
эти языки даже сравнивать нельзя...

2anonymous (*) (2002-04-26 21:51:44.532)
> ROOT/GEANT на C++ написаны и ведь прекрасно написаны (ведь никого из здесь
> присутствующих не тянет улучшать их
ROOT был ВЫСТРАДАН с огромным трудом, Брюн его лет 10 пинал ногами.
И написан он так, что меня просто в дрожь бросает. Еси ты считаешь, что ROOT
- образец для подражания, то мы друг друга не поймем...

2 (anonymous (*) (2002-04-27 14:13:52.832) aka Bear) & Виндузятник:

>> Так все-таки результаты от этого действа положительные,
>> отрицательные, или одно из трех? :)
Да, это я был - в привате высказал Виндузятнику все, что думаю о
попытках переползти с Фортрана на Це++. Но, ATTENTION! -- 2Виндузятник --
я писАл про DESY, где переводят ЦЕРНовские либы под Це++. Про сам ЦЕРН я
не знаю.

>> 2Виндузятник

> Я попробую узнать, что смогу. Будут новости - сообщу.
> Но очевидно, что быстро такой процесс пройти не может.
Он ОЧЕНЬ быстро идет!

> очень много действующих физиков, которые владеют
> только Фортраном. Физики среднего возраста уже не
> хотят переучиваться на С/C++.
> Очевидно переход происходит
> "путем вымирания сторонников старой теории".
Верно!

> Но как мне сказали новое ПО пишется преимущественно
> на C/C++.
Верно!
Могу добавить - про С никто не вспоминает, все лабают на C++ - к сожалению...
(Все ж Фортран - порядочное дерьмо.).

> Конечно я не могу утверждать все это
> абсолютно, так как сам в процессе не учавствую.
Я маленько участвую ;) НУ И БРЕД!!!

> Думаю, что причины, побудившие меня самого перейти на
> C/C++ слишком понятны любому, кто пробовал написать
> программу не просто просчитывающую какой либо процесс
> или решающую уравнение или систему,
> но удобную для изменеия и применения к изменившимся
> начальным данным, материалам, сложному окружению.
> Потери скорости при счете в этих случаях в каждом
> цикле минимальны( если постараться,
> а если нужно их вообще можно избежать ),
> а получение результатов для совокупности условий
> и для преведения анализа - выше, причем иногда на порядки.
Чесслово, я написАл много программ, весьма разных - от на раз написанных
числодробилок на Фортране и драйверов на Постскрипте до Tcl/Tk оболочек и
нудноразвиваемых многодесяткотысячестрочных проектов на Це++ - чесслово,
не вижу большой разницы между всякими языками. Ежели, конечно, не ваять
прямо в компьютер готовую программу, как сейчас принято.

Самые большИе проблемы у меня вызывает Фортран - комментариев в программах
приходится лепить раза в 2 больше прочего текста.

> Я не говорю о других преимуществах, которых хоть отбавляй.
> Ясно, что C/C++ программера ограничивает только его
> знания и матерство. Любой другой язык ( о которых я знаю ;-0))
> рано или поздно начинает бесить своей ограниченностью.
Про C согласен - программера ограничивает только его знания и матерство.
C++ - извиняюсь, как морская свинка...

Die-Hard ★★★★★
()
Ответ на: комментарий от anonymous

>1) Исключительно благодаря этой теме начал смотреть OCaml, насколько я понимаю, одним из наиважнейших его приемуществ над C++ в ряде задач является возможность передачи функций, как параметров.

Это -- вообще не преимущество, как ты сам же далее и пишешь. Это и Цэ имеется.

Преимущества, на мой взгляд -- великолепная система типов и разрешения неполной типизации; человеческий полиморфизм (++ в этом вопросе -- полное убожество, несмотря на мою скорее любов к этому языку); человеческие же параметризованный типы (см. предыдущее примечание), подключаемые модули.

Что касаемо функций -- тут скорее лучший, чем у Цэ возврат функций в качестве значений...

Вот только с объектами чего-то непонятное накручено...

Смоляное Чучелко

anonymous
()

2Die-Hard (*) (2002-04-29 01:29:08.431):

Первое - довольно очевидная мысль - разницы между языками не видно, если ты используешь только их общее подмножество с совсем незначительными вариациями. Так, если не использовать макросы, рекурсию, указатели, объявлять все функции до их вызова и еще выполнять довольно иного требований, тем не менее леегко выполнимых при желании (или привычке) в относительно небольшой программе, то ты будешь одинаково программировать на BASIC, FORTRAN, C, C++, Pascal, OCaml и т.д.

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

Второе - какой-то последний абзац не понятен и не однозначен в толковании. Поскольку ANSI/ISO C - подмножество ISO C++, то казалось бы первое утверждение и для С++ верно... Другое дело если есть мысль, что он перегружен...

Насчет ROOT - я слава богу не очень долго в нем разбирался, только чтобы построить одну гистограмму (бог миловал, курсовик закончился... :-)), но насколько я помню, там наворочено с этими HF1, HF2 и т.д. Причем сердце чувствует, можно сделать и на С++ и на С значительно проще...

anonymous
()

2anonymous (*) (2002-04-29 02:33:44.236)

он же Смоляное Чучелко:

Спасибо за ответ. Дело в том, что я не слишком далеко в изучении OCaml продвинулся, застряв еще на функциональной части. Меня несколько угнетает совершенно другой синтаксис, поэтому в программах, которые я пишу очень много ошибок. Другая причина в ошибках - то, что я плохо понимаю, когда надо ставить, а когда не надо ставить запятые в перечислении параметров в описаниях функций... :-)

По поводу функций я писал исключительно потому, что это значительно удобнее С++, я не так давно писал числодробительную программу на С++, так там мне безумно надоело писать все эти классы. ( хотя их 2 :-) ) Я еще представил, что если их с десяток. Ужас!

Насчет типов - не раз накалывался, когда в С (или С++, без разницы), что-либо считаешь, а посередине выражения все конвертируется double->int или int->double или float<=>double. Не приятно... Потом получаются чудеса вроде sqrt( 0.0*0.0) и domain error. Так что это очень приятно.

А насчет любви - мне кажется у С++ очень красивый синтаксис. В конце концов template<class T> напоминает бра- и -кет вектора Дирака.

anonymous
()

2AC: "когда время большое, и разница большая (14 секунд против 200), на "многозадачность системы" можно забить."
И где ты там такую разницу усмотрел? Вот если я вместо ftime буду считать реальное время (user+kernel) то у меня получается 13.98 секунды, при этом ftime дает 15 секунд, т.е. ftime выдает на 7.5% завышенное знаечение. Нормальное "можно забить". И это в тот момент когди ни одного приложения не открыто, а если бы браузер открыт с флашевыми рекламами или еще что в этом же духе?

anonymous
()

2all:
Скажите честно, а ЛИЧНО вам KAI нужен? Сильно подозреваю, что если человек не программист, то не нужен, т.к. и ядро, и большинство прикладух под линукс написаны на голом C (и KAI тут не нужен), а оставшиеся 2%, написанные на C++, как правило слишком заточены под g++ и легко могут не собраться на KAI.

Так что все эти споры носят скорее теоретический интерес...

Хотя компилятор всё равно жалко. Сначала Win32-версия, теперь linux-версия.

anonymous
()

to anonymous (*) (2002-04-29 02:51:16.988):

> А насчет любви - мне кажется у С++ очень красивый синтаксис.

"Красивый синтаксис" еще не означает "удобный".

Вот, к примеру, синтаксис Лиспа я считаю удобным (для себя) потому, что EMACS по скобочным выражениям ходит/выделяет одним-двумя нажатиями клавиш, а еще для моих задач удобно то, что я могу именно благодаря скобочной записи определять сколько угодно символов новых операций, не сталкиваясь при этом с проблемой, как задать их приоритеты/ассоциативность. А что по этому поводу сказал Страуструп? Он отделался заявлением, что реализовать возможность определения новых операторов слишком сложно (как будто это не он в той же книге писал, что усложнение компилятора ничего не значит). Кстати, ему сложно, а разработчикам, к примеру, Pascal-XSC --- нет. Правда, насчет ассоциативности там просто забыли (если не ошибаюсь).

--

SVK

anonymous
()

2gns: >Может FP и не панацея вовсе? А так - что-то вроде теорем >cуществования и единственности решения дифура для физика, который и >так знает, что у его уравнения движения шарика по наклонной >плоскости решение заведомо есть и оно непрерывно :)

аднака красивая аналогия, только её продолжить надобно - в случае с шариком оно так,а во всяких суперструнах и тому подобных неочевидных вещах теоремы очень даже пригодятся. Тоже самое , имхо, применимо и к программированию. ЗЫ: что-то я смотрю тут физики собрались :))

anonymous
()

>А что по этому поводу сказал Страуструп? Он отделался заявлением, что реализовать возможность определения новых операторов слишком сложно

или я чего то не понял или перегрузки и определения операторов уже в с++ нет .. берем класс - определяем для него какие угодно операторы с какими угодно типами опрандов справа или слева, да хоть унарные - без разницы, расписываем это все в определении класса и все.. страус же так и говорит, что нет принципиальной разницы между базовыми типами и операторами и теми, что описаны в классах.. или не так?

anonymous
()

2anonymous (*) (2002-04-29 11:55:18.498)(AKA SVK):

Видишь ли, красоту можно рассматривать, как удобство чтения. И потом, там очень, очень много параметров. Смотри статьи, выданные А/Х (стр 6), особенно первую. Я не совсем согласен с автором в выводах, но список параметров по которым оценивается язык приведенный там очень велик и правилен (хотя что-то может быть упущено).

Вообще, для удобства набора наверное лучше asm... Надо решать задачу оптимизации, а это очень и очень сложно.

anonymous
()
Ответ на: комментарий от anonymous

2anonymous (*) (2002-04-29 02:39:26.226):
> Первое - довольно очевидная мысль - разницы между языками не видно, если ты используешь
> только их общее подмножество с совсем незначительными вариациями.
Ну, я как-то вырос из такого возраста.

Если пользуешь язык - будь добр придерживаться правил игры, под которые он заточен.
Правда, каюсь - под С++ меня самого частенько заносит в сторону чистого С.

> Второе - какой-то последний абзац не понятен и не однозначен в толковании. Поскольку
> ANSI/ISO C - подмножество ISO C++,
Не совсем. Синтаксис в С++ значительно строже, несколько другие соглашения
о передаче параметров (char, sizeof) и т.д.
> то казалось бы первое утверждение и для С++ верно... Другое дело если есть мысль,
> что он перегружен...
Перегружен - это во-первых.
Во-вторых - совершенно иная парадигма разработки программ, да и приемы кодирования
несколько отличаются, e.g. шаблоны vs. макросы; перегрузка операций, делающая
программы малочитабельными (IMHO); дикая смесь inline и виртуальных методов;
возможность передачи параметров по ссылке (Вообще маразм! Одно это сразу отдаляет
С++ от С и приближает его к Фортрану и Паскалю); и т.п. - короче, С++ - как морская
свинка. И не морская, и не свинка. Сильнораскрученная ошибка природы, вернее,
Страуструпа.

Почитай его (Страуструпа) - не возникает ощущения, что у него мозги набекрень?
Он даже свои мысли выражать не умеет!

> Насчет ROOT - я слава богу не очень долго в нем разбирался...
Повезло!
> Причем сердце чувствует, можно сделать и на С++ и на С значительно проще...
Основная проблема Рута - его создатель очень долго пинал свое чадо ногами,
не особо задумываясь о логической структуре. Брюн был в Церне главным вдохновителем
PAW, основная идея которого была - "А я не знаю ничего, кроме Фортрана,
и пюлевал я на ваши юниксы с пайпами, да и не Юниксом единым жив человек!"
Потом появился ЦеПП, и Брюн резко на него запАл, - "О, это то, что мне надо!"
- и начал везде ЦеПП пихать.

Рута он очень долго всем сватал. Его (Брюна) отовсюду гоняли, а он с бешеной энергией
его всем пихал. А Рут не работал, падал на каждый чих; структура постоянно менялась,
документация безнадежно отставала - короче, до позапрошлого года пользоваться Рутом
было невозможно, он был похож на Старофис.

Удивительно, все же Брюн его допинал до более-менее работоспособного состояния.
Хоть и монстр получился чудовищный, но боль-мень работает. Теперь главная проблема в
том, что программа постоянно подкручиваетя независимо от документации, так что
сделать что-либо сложное на нем затруднительно.

Главное - парадигма меня не возбуждает. Рут - идейный наследник PAW, с заменой Фортрана
на C++ (ну и гуй в духе времени). Т.е. он сделан для тех в первую очередь,
кто принципиально не желает знать ничего в этой жизни, кроме ЦеПП.

Die-Hard ★★★★★
()
Ответ на: комментарий от anonymous

1) Да, существование high order functions и partial application - наиболее сильная сторона функциональных языков, и именно эти возможности в первую очередь и определяют технологию работы с ними.

В качестве крайне красивого и в то же время доступного примера использования функциональных комбинаторов (правда, примеры на Хаскелле, но там всё понятно) могу послать сюда:

http://research.microsoft.com/~conal/papers/bridges2001/

(кстати, кто тут гнал, что Microsoft не пишет open source?)

Подобной возможности ни в Си, ни в Си++ нет. Передача указателя на функцию абсолютно ничего общего с передачей closure не имеет.

2) В online - ничего не знаю. Я книгами пользовался. :(

Antichrist
()

Когда мало кто знал, что значит Ctrl-Alt-Del, Когда не каждый ребенок калькулятор имел, А под словом "Паскаль" понимался обычно философ, Еще не все перфораторы пустили на слом, Но мы пришли в этот мир, и мы пошли напролом, И не знали покоя от новых идей и вопросов.

Мы были молоды и не страшились преград, Где не спасет перезапуск, поможет format, А если не было копий, мы тактику брали иную - По дискетам мы ползали, и по частям Собирали останки погибших программ, И шестнадцатеричные dump'ы вводили вручную.

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

Мы не боялись тогда - мы были много смелей - Ни плохих секторов, ни магнитных полей, И даже сбой по питанию не был источником страха. Нам было все трын-трава, нам было просто совсем Одним нажатием на кнопку повесить СМ, Нам служил ДВК, и нам повиновалась Yamaha.

Но перед нами прогресс открывал все пути, И, бросив старых друзей ради новых ХТ, Мы выжимали, что можно, из DOS и из архитектуры, Меняли коды команд, трассировали INT'ы Дизассемблировали BIOS и писали в порты То, что я б не позволил печатать на месте цензуры.

Но это время прошло, но это было давно, Теперь у каждого нудной работы полно, И заказчик-дурак тычет мышкой в картиночки гордо. И мы пиратство уже почти считаем грехом, И обросли Aidstest'ами, как дерево мхом - У нас так много защит, что порой забываем password'ы.

А ведь когда-то не боялись мы программы любой, И с одним лишь debug'ом выходили на бой, И искусно написанный вирус встречали как брата. А теперь мы, чуть что, нажимаем reset... Да, куда не пойдешь - везде наткнешься на RET, И еще хорошо, если в стеке есть адрес возврата.

Теперь нам лень изощряться, оптимизировать код, И интерфейс с дураками мы пишем из году в год, Свыклись с мощной машиной, отвыкли от всякого риска. Забыли коды команд и старых трюков запас, И только ненависть к Windows порою у нас Зажигает огонь в глазах, как индикатор Hard Disk'a...

gelios
()

Когда мало кто знал, что значит Ctrl-Alt-Del,
Когда не каждый ребенок калькулятор имел,
А под словом "Паскаль" понимался обычно философ,
Еще не все перфораторы пустили на слом,
Но мы пришли в этот мир, и мы пошли напролом,
И не знали покоя от новых идей и вопросов.

Мы были молоды и не страшились преград,
Где не спасет перезапуск, поможет format,
А если не было копий, мы тактику брали иную -
По дискетам мы ползали, и по частям
Собирали останки погибших программ,
И шестнадцатеричные dump'ы вводили вручную.

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

Мы не боялись тогда - мы были много смелей -
Ни плохих секторов, ни магнитных полей,
И даже сбой по питанию не был источником страха.
Нам было все трын-трава, нам было просто совсем
Одним нажатием на кнопку повесить СМ,
Нам служил ДВК, и нам повиновалась Yamaha.

Но перед нами прогресс открывал все пути,
И, бросив старых друзей ради новых ХТ,
Мы выжимали, что можно, из DOS и из архитектуры,
Меняли коды команд, трассировали INT'ы
Дизассемблировали BIOS и писали в порты
То, что я б не позволил печатать на месте цензуры.

Но это время прошло, но это было давно,
Теперь у каждого нудной работы полно,
И заказчик-дурак тычет мышкой в картиночки гордо.
И мы пиратство уже почти считаем грехом,
И обросли Aidstest'ами, как дерево мхом -
У нас так много защит, что порой забываем password'ы.

А ведь когда-то не боялись мы программы любой,
И с одним лишь debug'ом выходили на бой,
И искусно написанный вирус встречали как брата.
А теперь мы, чуть что, нажимаем reset...
Да, куда не пойдешь - везде наткнешься на RET,
И еще хорошо, если в стеке есть адрес возврата.

Теперь нам лень изощряться, оптимизировать код,
И интерфейс с дураками мы пишем из году в год,
Свыклись с мощной машиной, отвыкли от всякого риска.
Забыли коды команд и старых трюков запас,
И только ненависть к Windows порою у нас
Зажигает огонь в глазах, как индикатор Hard Disk'a...

gelios
()
Ответ на: комментарий от anonymous

Синтаксис у OCaml, кстати, вполне себе естественный - как ты лямбда--выражения пишешь, так почти однозначно их на ML переписываешь. Особенно если пользовать Tuareg mode в [X]Emacs - там function заменяется на греческую лямбду, стрелочки там всякие и прочие подобные красивости.

По поводу же самых основ функционального программирования - лямбда--исчисления, логики предикатов, комбинаторов и т.д. - советую читать Харрисона. Ссылку я тут уже ОЧЕНЬ много раз давал, ну да не поленюсь ещё раз написать:

http://www.cl.cam.ac.uk/Teaching/Lectures/funprog-jrh-1996/index.html

По поводу запятой - читай в том же Харрисоне про то, что такое currying. Есть два способа определить функцию нескольких переменных (чисто математически функция по определению имеет только один аргумент): либо определить её на декартовом произведении типов аргументов, либо определить функцию на множестве функций с зажатым параметром. В лямбда--исчислении принято использовать второй подход.

Краткая запись \lambda x y . t[x,y] на самом деле обозначает \lambda x . (\lambda y . t[x,y]) x

Про синтаксис Си++ - да фигня всё это. Перегруженный весьма синтаксис. Кроме того, синтаксис никого не должен волновать - для того же OCaml ты можешь приделать ЛЮБОЙ синтаксис, на который ложилась бы его семантика - для этого есть препроцессор camlp4 (в отличии от C-шного препроцессора он генерит не текст, а сразу распарсенный AST, так что в некоторых пределах можно варьировать и семантику языка).

Antichrist
()

2vsl: Попробуй посмотреть на этот вопрос с другой стороны - назови задачу, которая не решается средствами C++? Причем таких, где он принципиально для этого дела не подходит...

ZhekaSmith
()

Вот, ещё один красивейший пример использования комбинаторов вспомнился: описано в Харрисоне в главе 9.2, про parser combinators. Меня это в своё время так впечатлило, что я с Лиспов на строгие языки и пересел.

Antichrist
()
Ответ на: комментарий от ZhekaSmith

Если задача принципиально решается, то её, потрахавшись, можно даже в терминах нормальных Марковских алгоритмов описать. И что из этого? Я говорю, что C++ неудобен для практики и немерянно крив с точки зрения теории. Так зачем же его пользовать? Чтоб потрахаться? Тогда лучше сразу в кодах писать. Или, того лучше, на марковских подстановках... Кстати, для любителей потрахаться и функциональный язык есть специальный - unlambda называется.

Antichrist
()
Ответ на: комментарий от Antichrist

Ниша C++

"Я вот давно и безнадёжно пытался выпытать у любителей C++ определение ниши этого языка. Увы, так ничего и не добился, кроме..."

Ниша C++ - написание программ в тех случаях, когда специального языка для решения задач подобного типа не существует и его разработка нецелесообразна, а использование различных виртуальных машин (java, etc) невозможно (производительность, и т.д). Желающие опровергнуть - с примерами, пожалуйста.

anonymous
()

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

ZhekaSmith
()
Ответ на: комментарий от Antichrist

"И выпады про "да ты C++ просто не понял" как правило исходят от непрошибаемых ламеров, которые кроме дурацкого C++ ничего другого понять не смогли, и жутко этим гордятся". Почему-то большинство критиков C++ упорно не называют его альтернативы. Ну вот предложи мне пожалуйста альтернативу C++ для моего проекта (простенький разговорник с распознаванием английской речи внутри и "красивым"/нестандартным интерфейсом, платформа - Pocket PC).

anonymous
()
Ответ на: Ниша C++ от anonymous

Я просил конкретный пример, а не общие слова. Или тебя в детском садике логике не обучали? Отрицательное утверждение опровергается одним единственным примером. В твоём же случае можно привести бесконечность противоположных примеров, но это никак не укажет на несуществование примера, когда твоё утверждение истинно.

Так что вперёд, сначала в детский садик, логику доучивать, а потом сюда, с готовым примером.

Antichrist
()
Ответ на: комментарий от anonymous

НАСКОЛЬКО ?
Читал сегодня Chip там тестились Athlon XP и Pentium4. 5 разных реальных прог (а не суперзаточки). Во всех прогах атлон проиграл аж 7 % !!! Ес !!! Атлон мас дай ! Интел форевер...
При этом цена комплекта процессор+материнка атлона на 350 (!) баксов дешевле интеловского. 50$ за 1 % !
IMHO: нахрен вообще за этим "прогрессом" гнаться. Duron 950 MHz прекрасно сработает и дома и на работе. А через год-полтора цена атлона хапэ рухнет раза в 2 с половиной ... тут мы его и ущучим :)))

Krozilo
()
Ответ на: комментарий от anonymous

НАСКОЛЬКО ?
Читал сегодня Chip там тестились Athlon XP и Pentium4. 5 разных реальных прог (а не суперзаточки). Во всех прогах атлон проиграл аж 7 % !!! Ес !!! Атлон мас дай ! Интел форевер...
При этом цена комплекта процессор+материнка атлона на 350 (!) баксов дешевле интеловского. 50$ за 1 % !
IMHO: нахрен вообще за этим "прогрессом" гнаться. Duron 950 MHz прекрасно сработает и дома и на работе. А через год-полтора цена атлона хапэ рухнет раза в 2 с половиной ... тут мы его и ущучим :)))

Krozilo
()
Ответ на: комментарий от anonymous

Распознавание речи? Это как раз задача для функциональщины. Все последние исследования в этой области на всяких Схемах, Хаскеллях и прочих Clean-ах. Интерфейс - это вообще та задача, к которой C++ на милю подпускать нельзя. Так что я просто в шоке, что ты выбрал такой кривой язык для этой задачи.

Скорее всего, кстати, я бы на твоём месте остановился на Erlang-е. Самое оно, как раз на таких задачах обкатанное. Другой вариант, как бы тут кто не смеялся - Форт.

Antichrist
()
Ответ на: комментарий от Antichrist

>Скорее всего, кстати, я бы на твоём месте остановился на Erlang-е.
А есть ли Erlang для Pocket PC? А сколько бабла за него просят?

AC
() автор топика

меня уже давно пытаются убедить, что я уже стар,
а это все "игры молодых"(для одаренных - Паули о Борне).

Може я и в самом деле старый и тупой
(думайте что хотите - на меня уже не действует),
но во что я никак не въеду так это вот во что:

Имея возможность указывать на _что_угодно_
(т.е. на любой АТД) почему это я не могу передать
куда угодно (в любой АТД в том числе и в функцию)
это смое "что угодно" на что смотрит указатель?

Заканчиваю писульку с чувством что старый и тупой это 
кто угодно, но не я.[:-))))).

Bear

 

anonymous
()

2ZhekaSmith (*) (2002-04-29 15:48:30.232):
> Основная фича C++ - универсальность.
2anonymous (*) (2002-04-29 15:35:57.308):
> Ниша C++ - написание программ в тех случаях, когда специального языка для решения
> задач подобного типа не существует...
А чем С не подходит в таких случаях? Проще, читабельнее, меньше, быстрее,
портабильнее, а в принципе - примерно то же самое.

Как мне кажется, с С++ случилось то же, что и с Лиспом в свое время -
он позиционировался как панацея, а на проверку базовая парадигма оказалась
чисто академической. Но, в отличие от Лиспа, ЦеПП сумели раскрутить -
в немалой степени благодаря "встроенному подмножеству" чистого Це.

IMHO у ЦеПП есть 2 native ниши.
1. Любителям ваять проги прямо в компьютер, с помощью какого-нибудь билдера,
С++ предлагает "встроенный" механизм контроля создаваемого API посредством
инкапсуляции и скрытия данных. Это позволяет коллективу ламеров, вытаращив глаза,
коллективно "пинать" проект - обычный стиль проектирования/кодирования сегодня.

2. Заменитель Фортрана для физиков/математиков/биологов и прочей околонаучной гвардии.
Действительно, удобно. Во-первых, все-таки синтаксис С++ значительно прозрачнее
фортрановского, к тому же возможно разделение труда - классы пишутся более
профессиональными программистами, а основная масса пользователей пинает уже готовые
классы, не заглядывая внутрь и ничего не зная о всяких наследованиях с полиморфизмами,
то есть пользуются крайне ограниченным подмножеством языка.

Die-Hard ★★★★★
()

Вот сижу читаю Joyner'а
стр 10
претензия

class A
{
public:
void nonvirt(){cout<<"A nonvirt"<<endl;}
virtual void virt(){cout<<"A virt"<<endl;}
};

class B : public A
{
public:
void nonvirt(){cout<<"B nonvirt"<<endl;}
void virt(){cout<<"B virt"<<endl;}
};

main()
{
A a;
B b;
A *ap=&b;
B *bp=&b;

ap->nonvirt(); // Претензия class B has extended or replaced routine
bp->nonvirt(); // то есть к тому что B и A имеют одинаковые имена
// вывод о не правильности ООП (Joyner)

ap->virt();
bp->virt();

((A*)ap)->nonvirt(); // Вопрос достаточна ли обоснованна претензия?
((B*)ap)->nonvirt(); // и вообще уместна ли?
((A*)bp)->nonvirt(); // правилен ли вывод?
((B*)bp)->nonvirt();
}

P.S.
упрекать "ты дальше почитай" не стоит и так прочитаю только время нужно
Best regards Ilnur

ilnurik
()

>По поводу функций я писал исключительно потому, что это значительно >удобнее С++, я не так давно писал числодробительную программу на >С++, так там мне безумно надоело писать все эти классы. ( хотя их >2 :-) ) Я еще представил, что если их с десяток. Ужас! 


А может в твоей задаче вообще не надо было классы 
использовать?
Страуструп советовал не применять средства языка
которые не до конца поняты.
Если не знаешь зачем тебе классы -
пиши в духе Фортрана. Лучще в духе => Фортран90.
Надеюсь, что задача реализации модульности 
(а модули -почти как классы ;-))) 
на С или С++ ни у кого не вызовет приступа любви к 
эпистолярному жанру.


Bear


anonymous
()

> Основная фича C++ - универсальность.
Машина Тьюринга тоже универсальна. Речь вообще-то идет о эффективности труда программиста, т.к. для 99% проектов это определяет их технический успех или неудачу.
Конечно, C++ не самый худший инструмент, но и не лучший. Даже не хороший - удовлетворительный. И залог успеха C++ - это инстинкт толпы.

Viking
()
Ответ на: комментарий от Viking

>, C++ не самый худший инструмент, но и не лучший. 
>Даже не хороший - удовлетворительный. 
>И залог успеха C++ - это инстинкт толпы.

2Viking

Здесь не все из толпы(хотя многие).
Скажи какой инструмент лучще и в каком смысле лучше.
Попробуем. Оценим.


Bear.

anonymous
()

> Как мне кажется, с С++ случилось то же, что и с Лиспом в свое время - он позиционировался как панацея, а на проверку базовая парадигма оказалась чисто академической.
Немного не так. Лисп позиционировался в середине 80-x как "AI Language", а когда пену сдуло и оказалось что никто понятия не имеет о том *как* этот ИИ делать, вину возложили на инструмент (как если бы Perl обвинили в крахе доткомов и "новой экономики"). Так что до настоящего времени Lisp это "black buzzword", и большинство его пользователей (если отбросить эксцентричных миллионеров типа Paul Graham) его не сильно афишируют.
К тому же многие лисперы настоящие снобы, по причинам понятным только лисперам. На эту тему поучительная песня:
http://artists.mp3s.com/artist_song/234/234762.html

Viking
()
Ответ на: комментарий от anonymous

Ты понимаешь, что в C++ практически нереализуемо понятие "текущего окружения"? Как в такой ситуации можно closure передавать - я, честно говоря, вовсе не представляю. Не, конечно же, если попу порвать от натуги, то всё, что угодно изобразить можно - вот только зачем?

Antichrist
()
Ответ на: комментарий от Die-Hard

>2 Die-Hard: А чем С не подходит в таких случаях? Проще, читабельнее, меньше, быстрее, портабильнее, а в принципе - примерно то же самое.
Хочу параметризованные классы, generic programming, инлайнинг, базовую поддержку ООП, базовую поддержку инкапсуляции, перегрузку операторов. Где это все в С?
Далее, что проще и читабельнее?:
1.
struct specific_matrix_form_double {
//bla-bla-bla
}
double specific_matrix_form_double_element(specific_matric_form_double* Matrix,int i,int j) {
//extract element
}
void inverse_specific_matric_form_double(const specific_matrix_form_double* A,specific_matrix_form_double* Res) {
//somewhere in code:
double elem = specific_matrix_form_double_element(A,i,j);
}
или же:
2.
template<class t_elem>
class specific_matrix_form {
public:
typedef t_elem t_element;
t_elem& element(int i,int j) //a eще лучше
t_elem& operator()(int i,int j) {
}
}

template<class matrix> inverse(const t_matrix& A,t_matrix& Res) {
//somewhere in code:
typename t_matrix::t_element& e=A(i,j);
}

AC
() автор топика

2Die-Hard (*) (2002-04-29 14:12:50.918):

Наверно ты прав насчет ссылок и указателей, в большинстве случаев они дублируют друг друга (я по крайней мере пишу в основном в списке аргументов функций).

Про ROOT ты несколько не прав, поскольку все же на мой взгляд на С++ можно было сделать значительно более красивую и удобную вещь. А так она даже не понятно какая. Вроде и FORTRAN так просто совсем не задумываясь не переложишь и на лицо какое-то бесконечное дублирование кода. А мне кажется, что это и есть наипервейший признак плохого программирования, в смысле тут уже и вопросов возникать не должно. Може быть я не прав, чтож, тогда поправят.

anonymous
()
Ответ на: комментарий от anonymous

Ну вот опять. Сколько можно долбить пургу? Не "какой инструмент лучше", а "какой инструмент лучше для какой задачи". СЕРЕБРЯННОЙ ПУЛИ НЕТ. C++ никоим образом не является универсальным языком - он универсален не более, чем ассемблер.

Antichrist
()

2anonymous (*) (2002-04-29 16:39:43.376):

Друг мой, я склоняюсь к тому, что ты скорее "старый и тупой", поскольку перед ответом на замечание его стоит читать. Это мне говорил учитель физики в школе и как мне сейчас кажется он был прав.

Как ты мог догадаться из прочитения написанного мной, я прекрасно осознаю, зачем мне классы и почему нельзя мне писать только функциями.

А если ты ТОЖЕ пишешь на С++ и у тебя есть книга "Язык программирования С++" 3 издание, то посмотри например на страницу 582. Там прямо посередине стоит описание класса less_than. Теперь чуть чуть прикинь, зачем вводится именно класс, а не просто ОДНА функция сравнения.

Так вот мне не очень нравится то, что нужно тратить много времени на написание этого. А выше тут у A/X были ссылки (кажется page 6). В первой объясняется, что язык должен быть компактным. Конечно же это замечание не смертельно и я как писал классы для вышеприведенной цели так и буду их писать.

anonymous
()

2Die-Hard (*) (2002-04-29 16:18:28.97):

В общем да, но неужели большинство С++ программистов (по специальности) использует хотя бы шаблоны? Мне всегда казалось, что среднестатис. программисту достаточно классов, причем даже без перегрузки операций.

Если тут народ радостно говорит, что ему достаточно С. Достаточно большую систему на С нужно писать с исключительной аккуратностью, поскольку нет такой простой штуки, как класс. А есть структуры и функции по отдельности ( конечно черт с ними - с public, private, protected). В таком случае при передаче струткуры в функцию по указателю напахать проще. Нужно следить о передаче именно функции. Опять таки нет деструктора и поэтому довольно легко в 10-ти местах вставить Init и CleanUP, а в 11-том - нет.

А ведь о приемуществе С над С++ тут писал не один человек. Я думаю, что и С++ до такой степени, которая сейчас обсуждается обычно не используют. По крайней мере я лично знаком видимо только с одним человеком, который пишет именно на таком уровне. А java программисты имеют полное отсутствие generic программирования. И тем не менее орут, что java значительно круче C++. Как он может быть круче - он просто отсекает класс решений задачи, которые включает С++. Вот ОСaml - может быть, по крайней мере он включает generic. Дальше я не знаю - в процессе изучения.

anonymous
()

2 Bear: я могу посоветовать только несколько отправных точек, а дальше надо пробовать на вкус самому.

* Smalltalk - если хочешь посмотреть как может выглядеть нормальный OO-язык.
* Семейство ML (e.g. OCaml) - функциональные языки со строгой типизацией.
* Lisp - тут два основных диалекта: Scheme, упирающая на математическую элегантность, и ANSI Common Lisp, используемый для реальных приложений.

Лично я остановился на Common Lisp. Среди фич: макросы, позволяющие пошить синтаксис языка под конкретную проблему, после чего можно решать проблему в этом специализированном языке не отвлекаясь на мелочи. CLOS - объектная система по выразительности не похожая ни на что другое: можно переопределять класс на лету (при этом все его объекты автоматически обновляются), метаобъектный протокол позволяет прозрачно добавлять такие вещи как persistence или менять порядок вызова методов при наследовании; мультиметоды; возможность специализации метода на конкретный объект какого-либо класса. При этом стать компетентным в Лиспе возможно за приемлемое время.
Если интересно, пиши на viking at funcall.org - расскажу подробнее, а то я уже совсем в offtopic ушел.

Касательно остальных языков - тут пожалуй есть люди, которые расскажут о их достоинствах лучше меня.

Viking
()

Знаешь, маразматик, а тебе не надоело вы... ся?
Ну раз вылез из выгребной ямы отвечай...

asoneofus
()
Ответ на: комментарий от anonymous

На самом деле для Жабы были кой-какие наработки на тему generic. На уровне внешнего препроцессора, достаточно интеллектуального, однако. Они это дело pattern programming звали. Никаких комментариев по этому делу выдать не могу, читал давно и не помню где.

Generic programming в OCaml реализуется множеством разных способов - от функциональных комбинаторов и полиморфизма типов, и до использования функторов. Функторы, кстати, штука настолько мощная, что классы оказались практически никому не нужной, избыточной фичей.

Antichrist
()
Ответ на: комментарий от anonymous

2anonymous (*) (2002-04-29 17:47:40.095)
Уважаемый Смоляное Чучелко

Если я что не так понял, то извини.

А понял я это "не так" прочитав следующее:

>посередине выражения все 
>конвертируется double->int или 
>int->double или float<=>double. 
>Не приятно... Потом получаются чудеса 
>вроде sqrt( 0.0*0.0) и domain error


Ты уж извини, если я что не так прочел.
Потому и написал не подумав.

P.S. Я не насторлько стар что бы ты мне в
трамвае или метро (или где в другом 
месте где до конституции как до Марса) так ответил бы.

Bear



anonymous
()

2asoneofus: не вижу смысла метать бисер перед свиньями. Ты уже доказал свою непрошибаемость, когда я тебя на хую вертел по поводу якобы микроядерности OpenVMS. Замечание же о безграмотности касалось приведённого тобой убогого и лживого списка.

Antichrist
()
Ответ на: комментарий от anonymous

>но неужели большинство С++ программистов 
>(по специальности) использует хотя бы шаблоны? 

2anonymous (*) (2002-04-29 18:15:17.161)

Даже не профессионалам С++ иногда удобно
пользоваться ATL. Например комплексные числа
удобны. Не говоря о словарях списках и т.д.
(Я в курсе что в последнем С есть _Complex :))

Конечно, для того, что бы написать свои шаблоны
для это должны _созреть_ причины.

2Viking
Спасибо. 

2Antihrist
Тож спасибо. Не убедил, но очень много информации подкинул.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.