LINUX.ORG.RU
Новости — Проприетарное ПО  

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


2

0

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

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

★

Проверено:

 ← 1 2 3 4 5 6 7 8 9 10 11 12 →

2 anonymous (*) (2002-04-30 10:25:12.409)

>Не хочется быть занудой ;), но for_each -- это т.н. non-modifying >sequence operation (в отличии от transform, которая mutating sequence >operation), поэтому изменять с помощью неё элементы контейнера не есть >хорошо. Для double это как правило будет работать, но для остальных >случаев -- не факт.

Кто вам сказал? Будет все прекрасно работать для ЛЮБЫХ STL контейнеров.
Non-modifying значит что как был sequence<Obj> так и останется тот же самый sequence тех же самых Obj. А то что Objs поменяют свое состояние - ничего не значит. this то у них не изменится.
И как раз для double for_each не подходит, так как это встроенный тип и Вы не можете для него определить double::doSomething().

--
With best wishes,
Nick.

bugfixer ★★★★★
()

В догонку моей последней мессаге (bugfixer (*) (2002-04-30 17:57:07.353))

Спешу поправиться: for_each будет прекрасно работать для любого sequence<double> если модифицирующая функция / функтор принимает аргумент по non-const reference.

--
With best wishes,
Nick

bugfixer ★★★★★
()

2anonymous (*) (2002-04-30 14:47:51.604)(AKA Bear):

Насчет "нахаляву узнать" - это принцип НАУКИ... Здесь обсуждают достаточно общие вещи, для того, чтобы они были не секретными, а скорее из области Computer Science. Если Вы посмотрите на здешние высказывания, то увидете, что тут очень много людей, имеющий отношение по крайней мере к физике.

И потом, честно говоря я ничего у Вас не узнал. Самое забавное, что и попыток не было что-либо узнать от Вас.

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

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

anonymous
()

2АС:

Насчет 4-х кратной вложенности: любой алгоритм нужно рассматривать в контексте задачи.

Глупо писать на asm программу типа cat, глупо во внутренний цикл пихать вызов по указателю, если этого можно избежать.

Вне - в управляющей части главное - надежность и прозрачность, но отнюдь не скорость. Глупо оптимизировать код, вызывающийся раз в 2 минуты на незагруженной машине и занимающий 1 минуту. Даже в такой пропорции оптимизация не нужна.

Вы же не знаете, где эта 4-х кр. вложенность была и нужно ли по факту от нее отказываться.

anonymous
()

2Antichrist (*) (2002-04-30 16:57:34.748):

Во-первых - какому? (Я поддерживаю анонимность, но не настолько) Во-вторых, а где опечатка. Без ссылки все это сотрясание воздуха.

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

2 anonymous: >Вы же не знаете, где эта 4-х кр. вложенность была и нужно ли по факту от нее отказываться.
Можно воспользоваться аргументацией "умудренных опытом практических программистов" и сказать, что по моему крууутейшему опыту, вложенность больше 2х ведет к ошибкам, является следствием проблем с проектированием и в подавляющем большинстве случаем не нужна. Можно, конечно, и четырехмерное пространство представлять как такой указатель -- а оно надо?

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

2AC (*) (2002-04-30 20:05:53.053):

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

anonymous
()

AC (*) (2002-04-30 20:05:53.053):

Добавление - я видел, как Вы относитель к (AKA Bear), а как я - anonymous (*) (2002-04-30 19:51:26.466). Он для меня не авторитет.

anonymous
()

2Antichrist (*) (2002-04-30 20:17:31.009): Понял, каюсь.

anonymous
()

2 anonymous: >тающимся изобрести велосипед, т.е. оптимизировать не свою задачу, решение которой вы не видели, а про ее постановку слышали лишь пару обрывочных фраз.
Ну так у нас тут вся дискуссия в таком стиле. Каждый пытается решить за других... Мне-то, в общем, все равно, хоть четыре уровня у кого-то, хоть десять, и кто как предпочитает извращаться. Но раз уж флеймим -- так что ж не пофлеймить.

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

2AC (*) (2002-04-30 20:29:08.363):

Не ну классно! Флейм, пусть флейм, но ругать то зачем в таком тоне... Это по меньшей мере обидно.

anonymous
()

2 anonymous (2002-04-30 20:43:43.711):
был неправ.

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

to antichrist
>По поводу OpenVMS - ты слишком уж упёрто и бездоказательно стоял на своей ложной позиции. Такое поведение наказуемо - более того, упёртость хотя бы по одной позиции - несмываемое пятно на репутации. Может я и старомоден, но для меня если кто проявил себя врагом, то это окончательно и бесповоротно.

Странно... Три мессаги про то что "ещё раз повторяю, мне сказали"... :) Тем более после более чем агрессивного нашествия... А не поменять-ли тебе ник на "Агрессор"?...:)
Репутация моя - это ничто и нигде... Вытерпит... :) К сожалению, до сих пор никак не увижу "первоисточник"... (Кстати, процы Альфы от самсунга - такое....:) - с руками у меня всё в порядке...:) )

> Твой список же, претендующий на отражение рыночной действительности, грешит позорными упущениями. Ты забыл Форт как наиболее массовое средство для низкоуровневых ембеднутых задач,
Форт помню, помню даже отечественный форт-процессор. И описываю то что вижу - и то что доступно:
около 50 тыс. строк кода для проца, вместе с ним благополучно скончались, насколько вижу у соседей: тоже... Хотя проц был не худшей идеей...
Что осталось? Попытки портировать компилятор (Форта) на платформу MSC51/MSC96 - такие полуфабы получились...А пока народ "перегонял" - Си природнился... И чёткое представление (У всех окружающих) - надо писать на си, мало асма - а то если этой элементной базе крандец: чтобы из этой ж... легче было выбираться.
Конечно, если ты эмбед-ом считаешь "покрупнее" девайсы, то и у них сейчас не густо... ну а впрочем и они. Посмотри вокруг! - где остался Форт? В очень древних проектах, в основном снятых с производства изделиях - да и то, бинарики, и обгрызки форт-исходников, по которым нешиша не воспроизведёшь... Хотя, может у тебя в конторе и иная ситуация...

>ты записал C++ в средства рисования гуйни, забыв даже Tcl и такую попсу, как VB и Дельфи.
>И вообще, не надо про массу. "Миллиарды мух не могут ошибаться - всё же, в говне что-то есть!".
Спорить здесь смысла нет: голосование есть :) на эту тему (фуфловое, но всёж)...

Опять-таки, я не претендовал "на абсолют" - но в моём окружении нет ни одного проекта, где был-бы использован VB, есть старые проекты - которые с Дельфей люди гонят на Си и его "Диалекты", Есть маненько (процентов 30) Джавы и баловство (пока) с Tcl/Tk
А ещё больше - перегоняют на кп библиотеки проекты... (которые, как ты бы сказал, коньюктурщики, гонят в основном на С++). Которые в общем, не на базе этих библиотек созданы - и это суровая необходимость контор, необходимо одно, однотипное средство для решения определённых задач:
И куча спецов, каждый из которых способен разобраться в писанине другого... Вот и решили (директивно) VHDL:ASM/C:C,C++,OC... Когда шёл разговор о возможности использования перечисленных тобой языков (около года - двух назад), то решили их не использовать:
1) Большой уровень вложений (начальных) (Объектив Камл тогда где - в до 3.0.0 версии был)
2) Невозможность быстрой переподготовки спецов - и издержки на это.
4) Отсутствие базы для (2)
3) Невозможность получения готовых спецов без переподготовки (см. 4)

К тому-же специфика: "наука" у нас, никогда не была "в почёте" - а способность быстро и качественно выдать продукт :( ("хороший" аргумент, слава богу, в прошлом - тебе платят зарплату, вот на неё и учись)
Так что с "новациями" - острый напряг.

Конечно, про "мух" - это приемлимое сравнение, но пока из института не придут парни с "горящими глазами", и не скажут: "а не идите - ли вы нафиг с вашим замшелым с++", причём будут с функторами и полиморфизмом на "ты" (и несомненно сделают нечто работающее, причём с чудесами производительности) - до тех пор, для любого кирпича будут считать достаточным связку асм+си (а уж открутят от гнутостей и с++ пристроят)
Вот до тех пор будет и непонятка: А нафига это нужно?

Кстати, народ, в основном, кроме гуевиков, пишет на асм+си, с элементами с++ :)
Платформы: x86, AVR, XMS, MIPS

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

Одному из анонимных посетителей :)
(Вы б хоть перенумеровались, что-ли, для ориентирвки :)
anonymous0, 1,2...)

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

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

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

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

Есть задачи, решения которых элегантно и коротко записываются на
lisp, ocaml, haskel и иже с ними. Но, пример из жизни недельной
давности. Мои коллеги из соседнего отдела слепили для своего
большого проекта фильтрации почты писанного на схеме (scheme -
это лисп такой) макет SMTP-прокси (принимает письма с 25-го порта
и складыват ее в виде файлов на диск). И написали этот макет,
естественно, на схеме. Бо умеют. А потом прибежали к нам.
А мы, для своего файервола написли проксю на C. Прибежали со словами
"уж больно наша прокся ресурсов много жрет. Нельзя в бой идти с
таким тяжелым грузом. Давайте мы вашу малотребовательную проксю
заиспользуем..." Если бы мы написали приксю на С++, то не думаю,
что ресурсов она жрала бы сильно больше. Если, конечно ACE и
прочую объектную шнягу не использовать :).

Еще. Тут народ рещил померять по скорости ocaml и С++.
Кстати, не факт, что ocaml проиграет. Очень может быть, что и нет.
Рекомендую, также, померять программы не только по скорости, но и по
объему занимаемой памяти, требованию к системе и пр. Если память
нонче дешева, то еще не повод писать программы так, что бы
_сознательно_ занять ее всю. Уверяю вас, оккупация всей памяти
пройдет без вашего участия и незаметно для вас :) Если, конечно,
ваша сепер-пупер-программа не ставит своей целью продать вместе
с ней заказчику супер-пупер-сервер для ее на нем монопольного
исполнения :)))

Вот так вот. Выводы делайте сами.

gns ★★★★★
()

2gns (*) (2002-05-01 00:40:13.442):

Есть! Первый! :-) Как-то пока ломает регистрироваться. Меня только эта тема так задела, что тут около 40-50-ти моих постингов. А обычно я не пишу комментарии. Наверно это чувствуется.

anonymous
()

2gns (*) (2002-05-01 00:40:13.442):

Мои же дополнения к anonymous (*) (2002-05-01 01:21:45.745).

Во-первых - теоремы существования сильно помогают. И это неправда, что они физику как телеге пятое колесо. Даже в полупроводниках нужно. Ибо иногда решаешь методом Фурье, что-то странное получаешь, долго обдумываешь, а потом радостно обнаруживаешь, что функцию-то обращать нельзя - под теорему не подпадает. А ведь можно было бы и статью тиснуть, люди же засмеют.

Во-вторых - OCaml и C++ так по-дурацки сравнивал я. Впрочем тут же пнули и за дело. Я действительно перепутал компилятор bytecode и нормальный.

В случае подсчета чисел Фибоначчи (обязательно с рекурсией, тот что в примерах по OCaml) OCaml быстрее С++ (все из ALT Master Beta2, gcc - 3.0, -O3) раза в два-три (не суть). Из-за того, что компилятор преобразует рекурсию в итерации. Bytecode на этой же задаче, как я писал медленнее С++ в 7 раз. Но это так - только тест на вшивость, который OCaml прошел (мне надо было пощупать руками и только, поэтому не надо ссылаться на этот постинг в своих утверждениях).

anonymous
()

оПН 4-ЙПЮРМШЕ СЙЮГЮРЕКХ Х function pointers

й ЯНФЮКЕМХЧ, ОНЙЮГЮРЭ МЕНАУНДХЛНЯРЭ ХЯОНКЭГНБЮМХЪ 4-СПНБМЕБШУ СЙЮГЮРЕКЕИ дкъ днярхфемхъ бшянйни опнхгбндхрекэмнярх МЕ ОПЕДЯРЮБКЪЕРЯЪ ГДЕЯЭ БНГЛНФМШЛ, Р.Й. ЩРН ОНРПЕАСЕР МЕ РНКЭЙН ДНКЦХУ НАЗЪЯМЕМХИ, МН Х ОПХБЕД╦Р Й МЮПСЬЕМХЧ ОПЮБ ХМРЕККЕЙРСЮКЭМНИ ЯНАЯРБЕММНЯРХ. бШ СФ ЛЕМЪ ОПНЯРХРЕ :)

вРН ФЕ ЙЮЯЮЕРЯЪ СЙЮГЮРЕКЕИ МЮ ТСМЙЖХХ, РН ОПХБЕДС ОПХЛЕП *ОНВРХ* ХГ ОПЮЙРХЙХ, ЯХКЭМН СОПНЫ╦ММШИ: оПНЦПЮЛЛЮ ГЮМХЛЮЕРЯЪ ВРЕМХЕЛ ХГ ад Х ГЮОХЯЭЧ Б РЕЙЯРНБШИ ТЮИК, ХКХ XML, ХКХ MQ, ХКХ FTP РЕЙЯРБНШИ ТЮИК, ХКХ external loader (ЙРН МЕ ГМЮЕР - ЩРН ДКЪ ЯСОЕП АШЯРПНИ ГЮОХЯХ АНКЭЬХУ НАЗ╦ЛНБ Б ад), ХКХ SAP BW. мСФМЮ ОНДДЕПФЙЮ ЙЮЙ ASCII, РЮЙ Х UNICODE ПЕФХЛНБ (ОПХВ╦Л, ХЛЕММН ПЮГДЕКЭМН, Р.Й. ЛМНЦХЛ ГЮЙЮГВХЙЮЛ МЮ UNICODE МЮОКЕБЮРЭ, Х НМХ УНРЪР ЯЩЙНМНЛХРЭ МЮ НДМНЛ АЮИРЕ Б йюфднл ЯРПНЙНБНЛ ЯХЛБНКЕ). рЮЙФЕ, МЕНАУНДХЛН ОНДДЕПФХБЮРЭ ЙЮЙ fixed-width, РЮЙ Х delimited ТНПЛЮРШ БШБНДЮ. нАЫХЛ ДКЪ БЯЕЦН ЩРНЦН ЪБКЪЕРЯЪ, ВРН: 1. вХРЮЕЛ Б column-major ТНПЛЮРЕ (ДЮ, ЛЕКЙНЛЪЦЙХЕ СЯХКЕММН ОПНАХБЮЧР row-major ТНПЛЮР Я OLE DB, МН ХМЕПЖХЪ Б МЮЬЕЛ ДЕКЕ ВПЕГБШВЮИМН БШЯНЙЮ, РЮЙ ВРН ОПНИД╦Р ЕЫ╦ МЕЛЮКН БПЕЛЕМХ, ОНЙЮ ЩРН ОНКСВХР ЬХПНЙСЧ ОНДДЕПФЙС Б high-end ЯХЯРЕЛЮУ) 2. оХЬЕЛ БЯ╦ Б РЕЙЯРНБНЛ БХДЕ 3. *йЮФДШИ* РХО ОНКЪ ДНКФЕМ ТНПЛЮРХПНБЮРЭЯЪ ОН-ПЮГМНЛС 4. нАЫЕЕ ЙНКХВЕЯРБН РЮЙХУ РХОНБ - ГЮ 30 (ЩРН СФЕ ЖХТПЮ ХГ ОПЮЙРХЙХ)

йЮЙ ХГБЕЯРМН - ДКЪ ДНЯРХФЕМХЪ БШЯНЙНИ ОПНХГБНДХРЕКЭМНЯРХ мюдн ЯПЮГС БШВХЯКХРЭ БЯ╦, ВРН ЛНФМН, Х ГЮОХЯЮРЭ ЩРН ЦДЕ-МХАСДЭ. х ЕЫ╦, МЕОКНУН АШ япюгс ОПХМЪРЭ ПЕЬЕМХЪ, ВРНАШ ЯМХГХРЭ ЙНКХВЕЯРБН if()else ХКХ switch(). оНЙЮ БНГПЮФЕМХИ МЕРС? (еЯКХ ЕЯРЭ, РН ДЮКЭЬЕ ЛНФМН МЕ ВХРЮРЭ... бЯ╦ ПЮБМН РНКЙС МЕ АСДЕР)

оПХ ОПЮБХКЭМНЛ ДХГЮИМЕ, МЮЖЕКЕММНЛ МЮ ДЮКЭМЕИЬЕЕ ПЮЯЬХПЕМХЕ Х СДНАЯРБН ЯНОПНБНФДЕМХЪ, НАЪГЮРЕКЭМН ОНЪБХРЯЪ МЕЯЙНКЭЙН ОПНЯКНЕЙ Б ЩРНЛ БЯ╦Л ОХПНЦЕ: 1. сОПЮБКЕМХЕ АКНЙЮЛХ ДЮММШУ - ОЕПЕЯШКЙЮ ХУ НР ЛНДСКЪ ВРЕМХЪ Й ЛНДСКЧ ГЮОХЯХ (РНФЕ, ЙЯРЮРХ, ГЮДЮВЕ МЕ МЮЯРНКЭЙН РПХБХЮКЭМЮЪ, ЕЯКХ ОНДДЕПФХБЮРЭ multithread ХКХ, РЕЛ АНКЕЕ, clusters) ~~~дЮКЭЬЕ АСДС НОХЯШБЮРЭ РНКЭЙН ЛНДСКЭ ГЮОХЯХ~~~ 2. лНДСКЭ ОНЯРПНВМНИ НАПЮАНРЙХ АКНЙЮ (MQ ХКХ BW АСДЕР НРКХВЮРЭЯЪ НР FlatFile ХКХ FTP РЕЛ, ВРН Б ЙНМЖЕ ЙЮФДНИ ЯРПНЙХ МЮДН ОПНХГБНДХРЭ ПЮГМШЕ ДЕИЯРБХЪ, ОПХВ╦Л ДКЪ XML ЩРХ ДЕИЯРБХЪ АСДСР ЯНБЕПЬЕММН МЕОНУНФХЛХ МЮ БЯЕ ДПСЦХЕ, *ОКНЯЙН-РЮАКХВМШЕ* РХОШ) 3. лНДСКЭ ОНЙНКНМНВМНИ НАПЮАНРЙХ ЯРПНЙ. щРНР ЛНДСКЭ АСДЕР ПЮГМШЛ ДКЪ fixed-width Х delimited БЕПЯХИ, Р.Й. ДКЪ delimited МЮДН ХМНЦДЮ БЯРЮБКЪРЭ ЩРХ ЯЮЛШЕ ПЮГДЕКХРЕКХ. оЕПБЮЪ НЯРЮМНБЙЮ! дКЪ ЙЮФДНЦН РХОЮ ОНКЪ МЮДН БШГБЮРЭ ЯБНЧ ТСМЙЖХЧ. вРН, АШЯРПЕЕ switch() МХВЕЦН МЕРС??? еЯРЭ (ДЮМН ДЮКЭЬЕ) 4. лНДСКЭ ЙНМБЕПРХПНБЮМХЪ ЙЮФДНЦН ОНКЪ Б РЕЙЯР. опхеуюкх! бНР РСР-РН Х ЯНАЮЙЮ ОНПШКЮЯЭ. бЕДЭ ГДЕЯЭ МЮЛ МЮДН ДЕКЮРЭ ЛМНФЕЯРБН if()else ХКХ switch(). рЮЙ ЙЮЙ ХЛЕММН ГДЕЯЭ КЕФЮР ПЮГКХВХЪ НАПЮАНРЙХ ASCII/UNICODE Х fixed-width/delimited (Й ОПХЛЕПС - ОПНБЕПХРЭ overflow). нОЪРЭ ОНЯРНЪММН ОПНБЕПЪРЭ isModeASCII() == TRUE ХКХ isFixedWidth() == TRUE. хКХ ЕЯРЭ ВЕЦН ОН-КСВЬЕ? 5. дЮ, ЩРН АШК МЕ ОНЯКЕДМХИ СПНБЕМЭ :) мСФМЮ ЕЫ╦ ЮАЯРПЮЙЖХЪ media. рН КХ ЩРН ТЮИК, РН КХ MQ, МН Х РН Х ДПСЦНЕ, Б ЙНМЕВМНЛ ХРНЦЕ - РЕЙЯР. рЮЙ ВРН, МЮ ОПЕДШДСЫЕЛ СПНБМЕ ЛШ ОНКСВХКХ ярпнйнбне ОПЕДЯРЮБКЕМХЕ МЮЬХУ ДЮММШУ, Х НРДЮКХ ЕЦН МЮ ПЮЯРЕПГЮМХЕ БНР ЩРНЦН ЯКНЪ. й ЯКНБС - ХЛЕММН ГДЕЯЭ, Б physical layer, АСДЕР Х АСТЕПХГЮЖХЪ, Х low-level/system calls. х ГДЕЯЭ МЮЛ МЕ БЮФЕМ ТНПЛЮР ДЮММШУ. дЮКХ АСТЕП - ЛШ ЕЦН НРНЯКЮКХ. бЯ╦.

рЕОЕПЭ, МЮЙНМЕЖ, Ъ ОНЙЮФС Б ЙЮЙНЛ ЛЕЯРЕ ФХБСР СЙЮГЮРЕКХ МЮ ТСМЙЖХХ. х ЕЯКХ ЙРН ЛМЕ ДЮЯР АНКЕЕ ЩКЕЦЮМРМНЕ ПЕЬЕМХЕ, АСДС РНКЭЙН АКЮЦНДЮПЕМ (Х ОПХЦКЮЬС МЮ ПЮАНРС Б МЮЬС ТХПЛС).

б ЯКНЕ ╧4, МЮ йюфдсч ЙНЛАХМЮЖХЧ РХО/ПЕФХЛ/ТНПЛЮР, ЕЯРЭ ТСМЙЖХЪ, ЛЮЙЯХЛЮКЭМН НОРХЛХГХПНБЮМЮЪ ДКЪ ХЛЕММН ЩРНЦН ЯКСВЮЪ. йНМЕВМН, МЕЙНРНПШЕ ТСМЙЖХХ ОПНЯРН БШГШБЮЧР АНКЕЕ НАЫХЕ ТСМЙЖХХ (Й ОПХЛЕПС, ДКЪ РХОНБ short Х long АСДЕЛ ХЯОНКЭГНБЮРЭ НДМС Х РС ФЕ КНЙЮКЭМС ТСМЙЖХЧ, ПЮАНРЮЧЫСЧ Я long), МН ЩРН СФЕ ОНДПНАМНЯРХ ДХГЮИМЮ. тЮЙР Б РНЛ, ВРН ДКЪ ЮАЯНКЧРМН ЙЮФДНЦН ЙНМЙПЕРМНЦН ЯКСВЮЪ ЕЯРЭ ПНБМН ндмю ТСМЙЖХЪ, ГЮРНВЕММЮЪ ХЛЕММН ОНД ЩРНР РХО/ПЕФХЛ/ТНПЛЮР.

мЮ ЩРЮОЕ ХМХЖХЮКХГЮЖХХ, ДКЪ ЙЮФДНЦН ОНКЪ ГЮБНДХРЯЪ ЯРПСЙРСПЮ Я metadata. б МЕИ, ОНЛХЛН БЯЕЦН ОПНВЕЦН, ГЮОХЯЮМ СЙЮГЮРЕКЭ МЮ ТСМЙЖХЧ ХГ ЯКНЪ 4. р.Н., ДКЪ ЙЮФДНЦН ОНКЪ Б ЯКНЕ ╧3 (ЦДЕ ЛШ НАПЮАЮРШБЮЕЛ ЯРПНЙХ, one field at a time), ЛШ ОПНЯРН МЮОПЪЛСЧ БШГШБЮЕЛ ЯОЕЖХЮКХГХПНБЮММСЧ ТСМЙЖХЧ.

бНР Х БЯ╦. дЮБЮИРЕ, ОПЕДКЮЦЮИРЕ АНКЕЕ АШЯРПШИ йювеярбеммши БЮПХЮМР

дЮ, МЮОНЛМЧ - БЯ╦ ЩРН ДНКФМН ЯРПНХРЭЯЪ/ПЮАНРЮРЭ МЮ МЕЯЙНКЭЙХУ ОКЮРТНПЛЮУ. бНР, Й ЯКНБС ОПХЬКНЯЭ - ОНЙЮ Ъ ПЮАНРЮК ХЛЕММН МЮД БШЬЕСЙЮГЮМШЛ ЙНДНЛ, ОПХЬКНЯЭ РПХФДШ ОНЛЕМЪРЭ МЕЙНРНПШЕ СВЮЯРЙХ ХГ-ГЮ КХАН АЮЦНБ ЙНЛОХКЪРНПЮ, КХАН МЕЯНБЛЕЯРХЛНЯРХ НМШУ, КХАН ОПНЯРН ХУ МЕЯННРБЕРЯРБХЪ ЯРЮМДЮПРС я++. яЮЛШЛ ОНРПЪЯМШЛ АШК АЮЦ Б MSVC (ЛМНЧ НВЕМЭ ДЮФЕ КЧАХЛШЛ IDE), ЦДЕ РЮЙ Х МЕ СДЮКНЯЭ БШГБЮРЭ ХГ НДМНИ DLL ТСМЙЖХЧ-ВКЕМ ОН СЙЮГЮРЕКЧ, ЕЯКХ РЮ МЮУНДХКЮЯЭ Б ДПСЦНИ DLL. бШГНБ ОПНХЯУНДХК ОН ЯНБЕПЬЕММН КЕБНЛС ЮДПЕЯС, МН БЯЕЦДЮ Я НДХМЮЙНБШЛ ЯЛЕЫЕМХЕЛ ОН НРМНЬЕМХЧ Й *ОПЮБХКЭМНЛС*...

P.S. оПНЬС ОПНЫЕМХЪ ГЮ БЯРЮБЙХ МЮ ЮМЦКХИЯЙНЛ. ъ СФЕ ДЮБМН ФХБС Б АСПФСХМХХ, Х МЕЙНРНПШЕ ТПЮГШ ОПНЯРН МЕ ОНКСВЮЕРЯЪ ЮДЕЙБЮРМН ОЕПЕМЕЯРХ МЮ ПСЯЯЙХИ. мН, Ъ МЮДЕЧЯЭ, ЯПЕДХ ОПНЦПЮЛЛХЯРНБ МЕРС КЧДЕИ, МЕ ГМЮЧЫХУ ЮМЦКХИЯЙХИ УНРЭ ЛХМХЛЮКЭМН :) P.P.S. нУ Х МЕКЕЦЙН ФЕ МЮАХПЮРЭ ЙХПХККХЖС БЯКЕОСЧ :(

YePhIcK ★
()

оПН 4-ЙПЮРМШЕ СЙЮГЮРЕКХ Х function pointers

Somehow, the post has gotten into message board with the wrong encoding :( Sorry for that. Hope this one will get in properly

й ЯНФЮКЕМХЧ, ОНЙЮГЮРЭ МЕНАУНДХЛНЯРЭ ХЯОНКЭГНБЮМХЪ 4-СПНБМЕБШУ СЙЮГЮРЕКЕИ дкъ днярхфемхъ бшянйни опнхгбндхрекэмнярх МЕ ОПЕДЯРЮБКЪЕРЯЪ ГДЕЯЭ БНГЛНФМШЛ, Р.Й. ЩРН ОНРПЕАСЕР МЕ РНКЭЙН ДНКЦХУ НАЗЪЯМЕМХИ, МН Х ОПХБЕД╦Р Й МЮПСЬЕМХЧ ОПЮБ ХМРЕККЕЙРСЮКЭМНИ ЯНАЯРБЕММНЯРХ. бШ СФ ЛЕМЪ ОПНЯРХРЕ :)

вРН ФЕ ЙЮЯЮЕРЯЪ СЙЮГЮРЕКЕИ МЮ ТСМЙЖХХ, РН ОПХБЕДС ОПХЛЕП *ОНВРХ* ХГ ОПЮЙРХЙХ, ЯХКЭМН СОПНЫ╦ММШИ: оПНЦПЮЛЛЮ ГЮМХЛЮЕРЯЪ ВРЕМХЕЛ ХГ ад Х ГЮОХЯЭЧ Б РЕЙЯРНБШИ ТЮИК, ХКХ XML, ХКХ MQ, ХКХ FTP РЕЙЯРБНШИ ТЮИК, ХКХ external loader (ЙРН МЕ ГМЮЕР - ЩРН ДКЪ ЯСОЕП АШЯРПНИ ГЮОХЯХ АНКЭЬХУ НАЗ╦ЛНБ Б ад), ХКХ SAP BW. мСФМЮ ОНДДЕПФЙЮ ЙЮЙ ASCII, РЮЙ Х UNICODE ПЕФХЛНБ (ОПХВ╦Л, ХЛЕММН ПЮГДЕКЭМН, Р.Й. ЛМНЦХЛ ГЮЙЮГВХЙЮЛ МЮ UNICODE МЮОКЕБЮРЭ, Х НМХ УНРЪР ЯЩЙНМНЛХРЭ МЮ НДМНЛ АЮИРЕ Б йюфднл ЯРПНЙНБНЛ ЯХЛБНКЕ). рЮЙФЕ, МЕНАУНДХЛН ОНДДЕПФХБЮРЭ ЙЮЙ fixed-width, РЮЙ Х delimited ТНПЛЮРШ БШБНДЮ. нАЫХЛ ДКЪ БЯЕЦН ЩРНЦН ЪБКЪЕРЯЪ, ВРН: 1. вХРЮЕЛ Б column-major ТНПЛЮРЕ (ДЮ, ЛЕКЙНЛЪЦЙХЕ СЯХКЕММН ОПНАХБЮЧР row-major ТНПЛЮР Я OLE DB, МН ХМЕПЖХЪ Б МЮЬЕЛ ДЕКЕ ВПЕГБШВЮИМН БШЯНЙЮ, РЮЙ ВРН ОПНИД╦Р ЕЫ╦ МЕЛЮКН БПЕЛЕМХ, ОНЙЮ ЩРН ОНКСВХР ЬХПНЙСЧ ОНДДЕПФЙС Б high-end ЯХЯРЕЛЮУ) 2. оХЬЕЛ БЯ╦ Б РЕЙЯРНБНЛ БХДЕ 3. *йЮФДШИ* РХО ОНКЪ ДНКФЕМ ТНПЛЮРХПНБЮРЭЯЪ ОН-ПЮГМНЛС 4. нАЫЕЕ ЙНКХВЕЯРБН РЮЙХУ РХОНБ - ГЮ 30 (ЩРН СФЕ ЖХТПЮ ХГ ОПЮЙРХЙХ)

йЮЙ ХГБЕЯРМН - ДКЪ ДНЯРХФЕМХЪ БШЯНЙНИ ОПНХГБНДХРЕКЭМНЯРХ мюдн ЯПЮГС БШВХЯКХРЭ БЯ╦, ВРН ЛНФМН, Х ГЮОХЯЮРЭ ЩРН ЦДЕ-МХАСДЭ. х ЕЫ╦, МЕОКНУН АШ япюгс ОПХМЪРЭ ПЕЬЕМХЪ, ВРНАШ ЯМХГХРЭ ЙНКХВЕЯРБН if()else ХКХ switch(). оНЙЮ БНГПЮФЕМХИ МЕРС? (еЯКХ ЕЯРЭ, РН ДЮКЭЬЕ ЛНФМН МЕ ВХРЮРЭ... бЯ╦ ПЮБМН РНКЙС МЕ АСДЕР)

оПХ ОПЮБХКЭМНЛ ДХГЮИМЕ, МЮЖЕКЕММНЛ МЮ ДЮКЭМЕИЬЕЕ ПЮЯЬХПЕМХЕ Х СДНАЯРБН ЯНОПНБНФДЕМХЪ, НАЪГЮРЕКЭМН ОНЪБХРЯЪ МЕЯЙНКЭЙН ОПНЯКНЕЙ Б ЩРНЛ БЯ╦Л ОХПНЦЕ: 1. сОПЮБКЕМХЕ АКНЙЮЛХ ДЮММШУ - ОЕПЕЯШКЙЮ ХУ НР ЛНДСКЪ ВРЕМХЪ Й ЛНДСКЧ ГЮОХЯХ (РНФЕ, ЙЯРЮРХ, ГЮДЮВЕ МЕ МЮЯРНКЭЙН РПХБХЮКЭМЮЪ, ЕЯКХ ОНДДЕПФХБЮРЭ multithread ХКХ, РЕЛ АНКЕЕ, clusters) ~~~дЮКЭЬЕ АСДС НОХЯШБЮРЭ РНКЭЙН ЛНДСКЭ ГЮОХЯХ~~~ 2. лНДСКЭ ОНЯРПНВМНИ НАПЮАНРЙХ АКНЙЮ (MQ ХКХ BW АСДЕР НРКХВЮРЭЯЪ НР FlatFile ХКХ FTP РЕЛ, ВРН Б ЙНМЖЕ ЙЮФДНИ ЯРПНЙХ МЮДН ОПНХГБНДХРЭ ПЮГМШЕ ДЕИЯРБХЪ, ОПХВ╦Л ДКЪ XML ЩРХ ДЕИЯРБХЪ АСДСР ЯНБЕПЬЕММН МЕОНУНФХЛХ МЮ БЯЕ ДПСЦХЕ, *ОКНЯЙН-РЮАКХВМШЕ* РХОШ) 3. лНДСКЭ ОНЙНКНМНВМНИ НАПЮАНРЙХ ЯРПНЙ. щРНР ЛНДСКЭ АСДЕР ПЮГМШЛ ДКЪ fixed-width Х delimited БЕПЯХИ, Р.Й. ДКЪ delimited МЮДН ХМНЦДЮ БЯРЮБКЪРЭ ЩРХ ЯЮЛШЕ ПЮГДЕКХРЕКХ. оЕПБЮЪ НЯРЮМНБЙЮ! дКЪ ЙЮФДНЦН РХОЮ ОНКЪ МЮДН БШГБЮРЭ ЯБНЧ ТСМЙЖХЧ. вРН, АШЯРПЕЕ switch() МХВЕЦН МЕРС??? еЯРЭ (ДЮМН ДЮКЭЬЕ) 4. лНДСКЭ ЙНМБЕПРХПНБЮМХЪ ЙЮФДНЦН ОНКЪ Б РЕЙЯР. опхеуюкх! бНР РСР-РН Х ЯНАЮЙЮ ОНПШКЮЯЭ. бЕДЭ ГДЕЯЭ МЮЛ МЮДН ДЕКЮРЭ ЛМНФЕЯРБН if()else ХКХ switch(). рЮЙ ЙЮЙ ХЛЕММН ГДЕЯЭ КЕФЮР ПЮГКХВХЪ НАПЮАНРЙХ ASCII/UNICODE Х fixed-width/delimited (Й ОПХЛЕПС - ОПНБЕПХРЭ overflow). нОЪРЭ ОНЯРНЪММН ОПНБЕПЪРЭ isModeASCII() == TRUE ХКХ isFixedWidth() == TRUE. хКХ ЕЯРЭ ВЕЦН ОН-КСВЬЕ? 5. дЮ, ЩРН АШК МЕ ОНЯКЕДМХИ СПНБЕМЭ :) мСФМЮ ЕЫ╦ ЮАЯРПЮЙЖХЪ media. рН КХ ЩРН ТЮИК, РН КХ MQ, МН Х РН Х ДПСЦНЕ, Б ЙНМЕВМНЛ ХРНЦЕ - РЕЙЯР. рЮЙ ВРН, МЮ ОПЕДШДСЫЕЛ СПНБМЕ ЛШ ОНКСВХКХ ярпнйнбне ОПЕДЯРЮБКЕМХЕ МЮЬХУ ДЮММШУ, Х НРДЮКХ ЕЦН МЮ ПЮЯРЕПГЮМХЕ БНР ЩРНЦН ЯКНЪ. й ЯКНБС - ХЛЕММН ГДЕЯЭ, Б physical layer, АСДЕР Х АСТЕПХГЮЖХЪ, Х low-level/system calls. х ГДЕЯЭ МЮЛ МЕ БЮФЕМ ТНПЛЮР ДЮММШУ. дЮКХ АСТЕП - ЛШ ЕЦН НРНЯКЮКХ. бЯ╦.

рЕОЕПЭ, МЮЙНМЕЖ, Ъ ОНЙЮФС Б ЙЮЙНЛ ЛЕЯРЕ ФХБСР СЙЮГЮРЕКХ МЮ ТСМЙЖХХ. х ЕЯКХ ЙРН ЛМЕ ДЮЯР АНКЕЕ ЩКЕЦЮМРМНЕ ПЕЬЕМХЕ, АСДС РНКЭЙН АКЮЦНДЮПЕМ (Х ОПХЦКЮЬС МЮ ПЮАНРС Б МЮЬС ТХПЛС).

б ЯКНЕ ╧4, МЮ йюфдсч ЙНЛАХМЮЖХЧ РХО/ПЕФХЛ/ТНПЛЮР, ЕЯРЭ ТСМЙЖХЪ, ЛЮЙЯХЛЮКЭМН НОРХЛХГХПНБЮМЮЪ ДКЪ ХЛЕММН ЩРНЦН ЯКСВЮЪ. йНМЕВМН, МЕЙНРНПШЕ ТСМЙЖХХ ОПНЯРН БШГШБЮЧР АНКЕЕ НАЫХЕ ТСМЙЖХХ (Й ОПХЛЕПС, ДКЪ РХОНБ short Х long АСДЕЛ ХЯОНКЭГНБЮРЭ НДМС Х РС ФЕ КНЙЮКЭМС ТСМЙЖХЧ, ПЮАНРЮЧЫСЧ Я long), МН ЩРН СФЕ ОНДПНАМНЯРХ ДХГЮИМЮ. тЮЙР Б РНЛ, ВРН ДКЪ ЮАЯНКЧРМН ЙЮФДНЦН ЙНМЙПЕРМНЦН ЯКСВЮЪ ЕЯРЭ ПНБМН ндмю ТСМЙЖХЪ, ГЮРНВЕММЮЪ ХЛЕММН ОНД ЩРНР РХО/ПЕФХЛ/ТНПЛЮР.

мЮ ЩРЮОЕ ХМХЖХЮКХГЮЖХХ, ДКЪ ЙЮФДНЦН ОНКЪ ГЮБНДХРЯЪ ЯРПСЙРСПЮ Я metadata. б МЕИ, ОНЛХЛН БЯЕЦН ОПНВЕЦН, ГЮОХЯЮМ СЙЮГЮРЕКЭ МЮ ТСМЙЖХЧ ХГ ЯКНЪ 4. р.Н., ДКЪ ЙЮФДНЦН ОНКЪ Б ЯКНЕ ╧3 (ЦДЕ ЛШ НАПЮАЮРШБЮЕЛ ЯРПНЙХ, one field at a time), ЛШ ОПНЯРН МЮОПЪЛСЧ БШГШБЮЕЛ ЯОЕЖХЮКХГХПНБЮММСЧ ТСМЙЖХЧ.

бНР Х БЯ╦. дЮБЮИРЕ, ОПЕДКЮЦЮИРЕ АНКЕЕ АШЯРПШИ йювеярбеммши БЮПХЮМР

дЮ, МЮОНЛМЧ - БЯ╦ ЩРН ДНКФМН ЯРПНХРЭЯЪ/ПЮАНРЮРЭ МЮ МЕЯЙНКЭЙХУ ОКЮРТНПЛЮУ. бНР, Й ЯКНБС ОПХЬКНЯЭ - ОНЙЮ Ъ ПЮАНРЮК ХЛЕММН МЮД БШЬЕСЙЮГЮМШЛ ЙНДНЛ, ОПХЬКНЯЭ РПХФДШ ОНЛЕМЪРЭ МЕЙНРНПШЕ СВЮЯРЙХ ХГ-ГЮ КХАН АЮЦНБ ЙНЛОХКЪРНПЮ, КХАН МЕЯНБЛЕЯРХЛНЯРХ НМШУ, КХАН ОПНЯРН ХУ МЕЯННРБЕРЯРБХЪ ЯРЮМДЮПРС я++. яЮЛШЛ ОНРПЪЯМШЛ АШК АЮЦ Б MSVC (ЛМНЧ НВЕМЭ ДЮФЕ КЧАХЛШЛ IDE), ЦДЕ РЮЙ Х МЕ СДЮКНЯЭ БШГБЮРЭ ХГ НДМНИ DLL ТСМЙЖХЧ-ВКЕМ ОН СЙЮГЮРЕКЧ, ЕЯКХ РЮ МЮУНДХКЮЯЭ Б ДПСЦНИ DLL. бШГНБ ОПНХЯУНДХК ОН ЯНБЕПЬЕММН КЕБНЛС ЮДПЕЯС, МН БЯЕЦДЮ Я НДХМЮЙНБШЛ ЯЛЕЫЕМХЕЛ ОН НРМНЬЕМХЧ Й *ОПЮБХКЭМНЛС*...

P.S. оПНЬС ОПНЫЕМХЪ ГЮ БЯРЮБЙХ МЮ ЮМЦКХИЯЙНЛ. ъ СФЕ ДЮБМН ФХБС Б АСПФСХМХХ, Х МЕЙНРНПШЕ ТПЮГШ ОПНЯРН МЕ ОНКСВЮЕРЯЪ ЮДЕЙБЮРМН ОЕПЕМЕЯРХ МЮ ПСЯЯЙХИ. мН, Ъ МЮДЕЧЯЭ, ЯПЕДХ ОПНЦПЮЛЛХЯРНБ МЕРС КЧДЕИ, МЕ ГМЮЧЫХУ ЮМЦКХИЯЙХИ УНРЭ ЛХМХЛЮКЭМН :) P.P.S. нУ Х МЕКЕЦЙН ФЕ МЮАХПЮРЭ ЙХПХККХЖС БЯКЕОСЧ :(

YePhIcK ★
()

оЕПЕБНД:

Somehow, the post has gotten into message board with the wrong encoding :( Sorry for that. Hope this one will get in properly
й ЯНФЮКЕМХЧ, ОНЙЮГЮРЭ МЕНАУНДХЛНЯРЭ ХЯОНКЭГНБЮМХЪ 4-СПНБМЕБШУ СЙЮГЮРЕКЕИ дкъ днярхфемхъ бшянйни опнхгбндхрекэмнярх МЕ ОПЕДЯРЮБКЪЕРЯЪ ГДЕЯЭ БНГЛНФМШЛ, Р.Й. ЩРН ОНРПЕАСЕР МЕ РНКЭЙН ДНКЦХУ НАЗЪЯМЕМХИ, МН Х ОПХБЕД╦Р Й МЮПСЬЕМХЧ ОПЮБ ХМРЕККЕЙРСЮКЭМНИ ЯНАЯРБЕММНЯРХ. бШ СФ ЛЕМЪ ОПНЯРХРЕ :)

вРН ФЕ ЙЮЯЮЕРЯЪ СЙЮГЮРЕКЕИ МЮ ТСМЙЖХХ, РН ОПХБЕДС ОПХЛЕП *ОНВРХ* ХГ ОПЮЙРХЙХ, ЯХКЭМН СОПНЫ╦ММШИ: оПНЦПЮЛЛЮ ГЮМХЛЮЕРЯЪ ВРЕМХЕЛ ХГ ад Х ГЮОХЯЭЧ Б РЕЙЯРНБШИ ТЮИК, ХКХ XML, ХКХ MQ, ХКХ FTP РЕЙЯРБНШИ ТЮИК, ХКХ external loader (ЙРН МЕ ГМЮЕР - ЩРН ДКЪ ЯСОЕП АШЯРПНИ ГЮОХЯХ АНКЭЬХУ НАЗ╦ЛНБ Б ад), ХКХ SAP BW. мСФМЮ ОНДДЕПФЙЮ ЙЮЙ ASCII, РЮЙ Х UNICODE ПЕФХЛНБ (ОПХВ╦Л, ХЛЕММН ПЮГДЕКЭМН, Р.Й. ЛМНЦХЛ ГЮЙЮГВХЙЮЛ МЮ UNICODE МЮОКЕБЮРЭ, Х НМХ УНРЪР ЯЩЙНМНЛХРЭ МЮ НДМНЛ АЮИРЕ Б йюфднл ЯРПНЙНБНЛ ЯХЛБНКЕ). рЮЙФЕ, МЕНАУНДХЛН ОНДДЕПФХБЮРЭ ЙЮЙ fixed-width, РЮЙ Х delimited ТНПЛЮРШ БШБНДЮ. нАЫХЛ ДКЪ БЯЕЦН ЩРНЦН ЪБКЪЕРЯЪ, ВРН: 1. вХРЮЕЛ Б column-major ТНПЛЮРЕ (ДЮ, ЛЕКЙНЛЪЦЙХЕ СЯХКЕММН ОПНАХБЮЧР row-major ТНПЛЮР Я OLE DB, МН ХМЕПЖХЪ Б МЮЬЕЛ ДЕКЕ ВПЕГБШВЮИМН БШЯНЙЮ, РЮЙ ВРН ОПНИД╦Р ЕЫ╦ МЕЛЮКН БПЕЛЕМХ, ОНЙЮ ЩРН ОНКСВХР ЬХПНЙСЧ ОНДДЕПФЙС Б high-end ЯХЯРЕЛЮУ) 2. оХЬЕЛ БЯ╦ Б РЕЙЯРНБНЛ БХДЕ 3. *йЮФДШИ* РХО ОНКЪ ДНКФЕМ ТНПЛЮРХПНБЮРЭЯЪ ОН-ПЮГМНЛС 4. нАЫЕЕ ЙНКХВЕЯРБН РЮЙХУ РХОНБ - ГЮ 30 (ЩРН СФЕ ЖХТПЮ ХГ ОПЮЙРХЙХ)

йЮЙ ХГБЕЯРМН - ДКЪ ДНЯРХФЕМХЪ БШЯНЙНИ ОПНХГБНДХРЕКЭМНЯРХ мюдн ЯПЮГС БШВХЯКХРЭ БЯ╦, ВРН ЛНФМН, Х ГЮОХЯЮРЭ ЩРН ЦДЕ-МХАСДЭ. х ЕЫ╦, МЕОКНУН АШ япюгс ОПХМЪРЭ ПЕЬЕМХЪ, ВРНАШ ЯМХГХРЭ ЙНКХВЕЯРБН if()else ХКХ switch(). оНЙЮ БНГПЮФЕМХИ МЕРС? (еЯКХ ЕЯРЭ, РН ДЮКЭЬЕ ЛНФМН МЕ ВХРЮРЭ... бЯ╦ ПЮБМН РНКЙС МЕ АСДЕР)

оПХ ОПЮБХКЭМНЛ ДХГЮИМЕ, МЮЖЕКЕММНЛ МЮ ДЮКЭМЕИЬЕЕ ПЮЯЬХПЕМХЕ Х СДНАЯРБН ЯНОПНБНФДЕМХЪ, НАЪГЮРЕКЭМН ОНЪБХРЯЪ МЕЯЙНКЭЙН ОПНЯКНЕЙ Б ЩРНЛ БЯ╦Л ОХПНЦЕ: 1. сОПЮБКЕМХЕ АКНЙЮЛХ ДЮММШУ - ОЕПЕЯШКЙЮ ХУ НР ЛНДСКЪ ВРЕМХЪ Й ЛНДСКЧ ГЮОХЯХ (РНФЕ, ЙЯРЮРХ, ГЮДЮВЕ МЕ МЮЯРНКЭЙН РПХБХЮКЭМЮЪ, ЕЯКХ ОНДДЕПФХБЮРЭ multithread ХКХ, РЕЛ АНКЕЕ, clusters) ~~~дЮКЭЬЕ АСДС НОХЯШБЮРЭ РНКЭЙН ЛНДСКЭ ГЮОХЯХ~~~ 2. лНДСКЭ ОНЯРПНВМНИ НАПЮАНРЙХ АКНЙЮ (MQ ХКХ BW АСДЕР НРКХВЮРЭЯЪ НР FlatFile ХКХ FTP РЕЛ, ВРН Б ЙНМЖЕ ЙЮФДНИ ЯРПНЙХ МЮДН ОПНХГБНДХРЭ ПЮГМШЕ ДЕИЯРБХЪ, ОПХВ╦Л ДКЪ XML ЩРХ ДЕИЯРБХЪ АСДСР ЯНБЕПЬЕММН МЕОНУНФХЛХ МЮ БЯЕ ДПСЦХЕ, *ОКНЯЙН-РЮАКХВМШЕ* РХОШ) 3. лНДСКЭ ОНЙНКНМНВМНИ НАПЮАНРЙХ ЯРПНЙ. щРНР ЛНДСКЭ АСДЕР ПЮГМШЛ ДКЪ fixed-width Х delimited БЕПЯХИ, Р.Й. ДКЪ delimited МЮДН ХМНЦДЮ БЯРЮБКЪРЭ ЩРХ ЯЮЛШЕ ПЮГДЕКХРЕКХ. оЕПБЮЪ НЯРЮМНБЙЮ! дКЪ ЙЮФДНЦН РХОЮ ОНКЪ МЮДН БШГБЮРЭ ЯБНЧ ТСМЙЖХЧ. вРН, АШЯРПЕЕ switch() МХВЕЦН МЕРС??? еЯРЭ (ДЮМН ДЮКЭЬЕ) 4. лНДСКЭ ЙНМБЕПРХПНБЮМХЪ ЙЮФДНЦН ОНКЪ Б РЕЙЯР. опхеуюкх! бНР РСР-РН Х ЯНАЮЙЮ ОНПШКЮЯЭ. бЕДЭ ГДЕЯЭ МЮЛ МЮДН ДЕКЮРЭ ЛМНФЕЯРБН if()else ХКХ switch(). рЮЙ ЙЮЙ ХЛЕММН ГДЕЯЭ КЕФЮР ПЮГКХВХЪ НАПЮАНРЙХ ASCII/UNICODE Х fixed-width/delimited (Й ОПХЛЕПС - ОПНБЕПХРЭ overflow). нОЪРЭ ОНЯРНЪММН ОПНБЕПЪРЭ isModeASCII() == TRUE ХКХ isFixedWidth() == TRUE. хКХ ЕЯРЭ ВЕЦН ОН-КСВЬЕ? 5. дЮ, ЩРН АШК МЕ ОНЯКЕДМХИ СПНБЕМЭ :) мСФМЮ ЕЫ╦ ЮАЯРПЮЙЖХЪ media. рН КХ ЩРН ТЮИК, РН КХ MQ, МН Х РН Х ДПСЦНЕ, Б ЙНМЕВМНЛ ХРНЦЕ - РЕЙЯР. рЮЙ ВРН, МЮ ОПЕДШДСЫЕЛ СПНБМЕ ЛШ ОНКСВХКХ ярпнйнбне ОПЕДЯРЮБКЕМХЕ МЮЬХУ ДЮММШУ, Х НРДЮКХ ЕЦН МЮ ПЮЯРЕПГЮМХЕ БНР ЩРНЦН ЯКНЪ. й ЯКНБС - ХЛЕММН ГДЕЯЭ, Б physical layer, АСДЕР Х АСТЕПХГЮЖХЪ, Х low-level/system calls. х ГДЕЯЭ МЮЛ МЕ БЮФЕМ ТНПЛЮР ДЮММШУ. дЮКХ АСТЕП - ЛШ ЕЦН НРНЯКЮКХ. бЯ╦.

рЕОЕПЭ, МЮЙНМЕЖ, Ъ ОНЙЮФС Б ЙЮЙНЛ ЛЕЯРЕ ФХБСР СЙЮГЮРЕКХ МЮ ТСМЙЖХХ. х ЕЯКХ ЙРН ЛМЕ ДЮЯР АНКЕЕ ЩКЕЦЮМРМНЕ ПЕЬЕМХЕ, АСДС РНКЭЙН АКЮЦНДЮПЕМ (Х ОПХЦКЮЬС МЮ ПЮАНРС Б МЮЬС ТХПЛС).

б ЯКНЕ ╧4, МЮ йюфдсч ЙНЛАХМЮЖХЧ РХО/ПЕФХЛ/ТНПЛЮР, ЕЯРЭ ТСМЙЖХЪ, ЛЮЙЯХЛЮКЭМН НОРХЛХГХПНБЮМЮЪ ДКЪ ХЛЕММН ЩРНЦН ЯКСВЮЪ. йНМЕВМН, МЕЙНРНПШЕ ТСМЙЖХХ ОПНЯРН БШГШБЮЧР АНКЕЕ НАЫХЕ ТСМЙЖХХ (Й ОПХЛЕПС, ДКЪ РХОНБ short Х long АСДЕЛ ХЯОНКЭГНБЮРЭ НДМС Х РС ФЕ КНЙЮКЭМС ТСМЙЖХЧ, ПЮАНРЮЧЫСЧ Я long), МН ЩРН СФЕ ОНДПНАМНЯРХ ДХГЮИМЮ. тЮЙР Б РНЛ, ВРН ДКЪ ЮАЯНКЧРМН ЙЮФДНЦН ЙНМЙПЕРМНЦН ЯКСВЮЪ ЕЯРЭ ПНБМН ндмю ТСМЙЖХЪ, ГЮРНВЕММЮЪ ХЛЕММН ОНД ЩРНР РХО/ПЕФХЛ/ТНПЛЮР.

мЮ ЩРЮОЕ ХМХЖХЮКХГЮЖХХ, ДКЪ ЙЮФДНЦН ОНКЪ ГЮБНДХРЯЪ ЯРПСЙРСПЮ Я metadata. б МЕИ, ОНЛХЛН БЯЕЦН ОПНВЕЦН, ГЮОХЯЮМ СЙЮГЮРЕКЭ МЮ ТСМЙЖХЧ ХГ ЯКНЪ 4. р.Н., ДКЪ ЙЮФДНЦН ОНКЪ Б ЯКНЕ ╧3 (ЦДЕ ЛШ НАПЮАЮРШБЮЕЛ ЯРПНЙХ, one field at a time), ЛШ ОПНЯРН МЮОПЪЛСЧ БШГШБЮЕЛ ЯОЕЖХЮКХГХПНБЮММСЧ ТСМЙЖХЧ.

бНР Х БЯ╦. дЮБЮИРЕ, ОПЕДКЮЦЮИРЕ АНКЕЕ АШЯРПШИ йювеярбеммши БЮПХЮМР

дЮ, МЮОНЛМЧ - БЯ╦ ЩРН ДНКФМН ЯРПНХРЭЯЪ/ПЮАНРЮРЭ МЮ МЕЯЙНКЭЙХУ ОКЮРТНПЛЮУ. бНР, Й ЯКНБС ОПХЬКНЯЭ - ОНЙЮ Ъ ПЮАНРЮК ХЛЕММН МЮД БШЬЕСЙЮГЮМШЛ ЙНДНЛ, ОПХЬКНЯЭ РПХФДШ ОНЛЕМЪРЭ МЕЙНРНПШЕ СВЮЯРЙХ ХГ-ГЮ КХАН АЮЦНБ ЙНЛОХКЪРНПЮ, КХАН МЕЯНБЛЕЯРХЛНЯРХ НМШУ, КХАН ОПНЯРН ХУ МЕЯННРБЕРЯРБХЪ ЯРЮМДЮПРС я++. яЮЛШЛ ОНРПЪЯМШЛ АШК АЮЦ Б MSVC (ЛМНЧ НВЕМЭ ДЮФЕ КЧАХЛШЛ IDE), ЦДЕ РЮЙ Х МЕ СДЮКНЯЭ БШГБЮРЭ ХГ НДМНИ DLL ТСМЙЖХЧ-ВКЕМ ОН СЙЮГЮРЕКЧ, ЕЯКХ РЮ МЮУНДХКЮЯЭ Б ДПСЦНИ DLL. бШГНБ ОПНХЯУНДХК ОН ЯНБЕПЬЕММН КЕБНЛС ЮДПЕЯС, МН БЯЕЦДЮ Я НДХМЮЙНБШЛ ЯЛЕЫЕМХЕЛ ОН НРМНЬЕМХЧ Й *ОПЮБХКЭМНЛС*...

P.S. оПНЬС ОПНЫЕМХЪ ГЮ БЯРЮБЙХ МЮ ЮМЦКХИЯЙНЛ. ъ СФЕ ДЮБМН ФХБС Б АСПФСХМХХ, Х МЕЙНРНПШЕ ТПЮГШ ОПНЯРН МЕ ОНКСВЮЕРЯЪ ЮДЕЙБЮРМН ОЕПЕМЕЯРХ МЮ ПСЯЯЙХИ. мН, Ъ МЮДЕЧЯЭ, ЯПЕДХ ОПНЦПЮЛЛХЯРНБ МЕРС КЧДЕИ, МЕ ГМЮЧЫХУ ЮМЦКХИЯЙХИ УНРЭ ЛХМХЛЮКЭМН :) P.P.S. нУ Х МЕКЕЦЙН ФЕ МЮАХПЮРЭ ЙХПХККХЖС БЯКЕОСЧ :(

anonymous
()
Ответ на: 4-level and function pointers от YePhIcK

2 YePhIck: я тут перекодировал ваши "крякозябры" -- интересно. По-поводу указателей на функции -- все нижеследующее применимо, если нужен более быстрый вариант. Так вот, если "цепочки" (графы) между вышеописанными "элементарными" функциями известны на compile-time, то все можно выстроить опять-таки на любимом мною встраивании и шаблонах. Тогда все цепочки будут "разрешаться" статически, и на этапе компиляции разворачиваться в последовательности вызова функций, а если компилятор сможет и встроить, то вообще в plain-код. Как это делается, можно посмотреть на примере properties в библиотеке boost, особенно в Boost.Graph. Ecли же на стадии компиляции ничего не известно, и такие цепочки собираются "на ходу", забирая функции, к примеру, из dll, то естественно ничего лучше указателей на функции не придумать. Я говорил, что указатели на функции -- зло, потому что я не люблю их только с точки зрения оптимизации, поскольку оптимизатор не работает "вокруг" вызова функции через указатель и не может оптимизировать "через границу" таких функций. Если же быстродействие не важно, то с ними все прекрасно.

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

2 Yephick: да, а с точки зрения самого приведенного вами дизайна в общем -- тут довольно трудно придумать что-то еще, кроме "цепочек фильтров" -- насколько я понимаю, это довольно известная pattern для таких задач. Вопрос только, собирать ли такие цепочки во время компиляции на шаблонах, или на ходу на указателях. Все вышеприведенное -- естественно, навскидку:)

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

К сожалению, именно в нашем примере на этапе компиляции это всё сделать никак (по многочисленным причинам, включая совсем даже не технические), так что приходится динамически всё делать

YePhIcK ★
()

Про 4-кратные указатели и function pointers

Теперь я попробую перевести ;) :

К сожалению, показать необходимость использования 4-уровневых указателей ДЛЯ ДОСТИЖЕНИЯ ВЫСОКОЙ ПРОИЗВОДИТЕЛЬНОСТИ не представляется здесь возможным, т.к. это потребует не только долгих объяснений, но и приведёт к нарушению прав интеллектуальной собственности. Вы уж меня простите :)

Что же касается указателей на функции, то приведу пример *почти* из практики, сильно упрощённый: Программа занимается чтением из БД и записью в текстовый файл, или XML, или MQ, или FTP текствоый файл, или external loader (кто не знает - это для супер быстрой записи больших объёмов в БД), или SAP BW. Нужна поддержка как ASCII, так и UNICODE режимов (причём, именно раздельно, т.к. многим заказчикам на UNICODE наплевать, и они хотят сэкономить на одном байте в КАЖДОМ строковом символе). Также, необходимо поддерживать как fixed-width, так и delimited форматы вывода. Общим для всего этого является, что: 1. Читаем в column-major формате (да, мелкомягкие усиленно пробивают row-major формат с OLE DB, но инерция в нашем деле чрезвычайно высока, так что пройдёт ещё немало времени, пока это получит широкую поддержку в high-end системах) 2. Пишем всё в текстовом виде 3. *Каждый* тип поля должен форматироваться по-разному 4. Общее количество таких типов - за 30 (это уже цифра из практики)

Как известно - для достижения высокой производительности НАДО сразу вычислить всё, что можно, и записать это где-нибудь. И ещё, неплохо бы СРАЗУ принять решения, чтобы снизить количество if()else или switch(). Пока возражений нету? (Если есть, то дальше можно не читать... Всё равно толку не будет)

При правильном дизайне, нацеленном на дальнейшее расширение и удобство сопровождения, обязательно появится несколько прослоек в этом всём пироге: 1. Управление блоками данных - пересылка их от модуля чтения к модулю записи (тоже, кстати, задаче не настолько тривиальная, если поддерживать multithread или, тем более, clusters) ~~~Дальше буду описывать только модуль записи~~~ 2. Модуль построчной обработки блока (MQ или BW будет отличаться от FlatFile или FTP тем, что в конце каждой строки надо производить разные действия, причём для XML эти действия будут совершенно непохожими на все другие, *плоско-табличные* типы) 3. Модуль поколоночной обработки строк. Этот модуль будет разным для fixed-width и delimited версий, т.к. для delimited надо иногда вставлять эти самые разделители. Первая остановка! Для каждого типа поля надо вызвать свою функцию. Что, быстрее switch() ничего нету??? Есть (дано дальше) 4. Модуль конвертирования каждого поля в текст. ПРИЕХАЛИ! Вот тут-то и собака порылась. Ведь здесь нам надо делать множество if()else или switch(). Так как именно здесь лежат различия обработки ASCII/UNICODE и fixed-width/delimited (к примеру - проверить overflow). Опять постоянно проверять isModeASCII() == TRUE или isFixedWidth() == TRUE. Или есть чего по-лучше? 5. Да, это был не последний уровень :) Нужна ещё абстракция media. То ли это файл, то ли MQ, но и то и другое, в конечном итоге - текст. Так что, на предыдущем уровне мы получили СТРОКОВОЕ представление наших данных, и отдали его на растерзание вот этого слоя. К слову - именно здесь, в physical layer, будет и буферизация, и low-level/system calls. И здесь нам не важен формат данных. Дали буфер - мы его отослали. Всё.

Теперь, наконец, я покажу в каком месте живут указатели на функции. И если кто мне даст более элегантное решение, буду только благодарен (и приглашу на работу в нашу фирму).

В слое ╧4, на КАЖДУЮ комбинацию тип/режим/формат, есть функция, максимально оптимизированая для именно этого случая. Конечно, некоторые функции просто вызывают более общие функции (к примеру, для типов short и long будем использовать одну и ту же локальну функцию, работающую с long), но это уже подробности дизайна. Факт в том, что для абсолютно каждого конкретного случая есть ровно ОДНА функция, заточенная именно под этот тип/режим/формат.

На этапе инициализации, для каждого поля заводится структура с metadata. В ней, помимо всего прочего, записан указатель на функцию из слоя 4. Т.о., для каждого поля в слое ╧3 (где мы обрабатываем строки, one field at a time), мы просто напрямую вызываем специализированную функцию.

Вот и всё. Давайте, предлагайте более быстрый КАЧЕСТВЕННЫЙ вариант

Да, напомню - всё это должно строиться/работать на нескольких платформах. Вот, к слову пришлось - пока я работал именно над вышеуказаным кодом, пришлось трижды поменять некоторые участки из-за либо багов компилятора, либо несовместимости оных, либо просто их несоответствия стандарту С++. Самым потрясным был баг в MSVC (мною очень даже любимым IDE), где так и не удалось вызвать из одной DLL функцию-член по указателю, если та находилась в другой DLL. Вызов происходил по совершенно левому адресу, но всегда с одинаковым смещением по отношению к *правильному*...

P.S. Прошу прощения за вставки на английском. Я уже давно живу в буржуинии, и некоторые фразы просто не получается адекватно перенести на русский. Но, я надеюсь, среди программистов нету людей, не знающих английский хоть минимально :) P.P.S. Ох и нелегко же набирать кириллицу вслепую :(

YePhIcK (*) (2002-05-01 02:55:46.429)

ZhekaSmith ★
()

YePhicK: "Вот и всё. Давайте, предлагайте более быстрый КАЧЕСТВЕННЫЙ вариант "

В самом общем случае вариант с указателями на функции sыглядит лучшим.

Но можно попробовать другие варианты, для поддержания разговора так сказать ;))

Если длина строки ограничена, то можно попробовать обрабатывать наборы по 1000 строк, обрабатывая одинаковые поля сверху вниз. Функция перевода может быть быстрее, если работает не с одним полем, а с большим числом одинаковых полей. Однако, возникают проблемы с кэшами ;)

Другой вариант - оптимизировать общую функцию, предвычисляя некоторые параметры. Скажем перевод чисел в десятичную и восьмеричную форму будет различаться параметром делителя (10 и 8 соответственно). Общая функция, естественно, будет медленнее, но уменьшится оверхед на ее выбор. Впрочем, если есть 30 вариантов типов полей, то сомнительно, чтобы это прошло.

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

ZhekaSmith ★
()

KAI очень жаль - был хорош. Я точно также жалею о Watcom и с
нетерпением жду что у ребят получится с OpenWatcom!!
А пока SunCC и gcc! :))) Первое - работа, второе - хобби! :)))

2 ifconfig (*) (2002-04-26 17:29:21.32)
>>> Зря.. MS VC++ очень хороший компилятор...
ну то что компилиятор я пожалуй соглашусь. но лишь по одной причиние:
в соответствии с определением компилятора, всётаки переводит в нативный
код процессора.
>>> очень хороший
ну наверно, если ничего сложнее "hello world!" не писать!!!
а так - убожество страшное!!!!

2 anonymous (*) (2002-04-27 08:48:41.309)
>>...Что же касается IDE - после VC++ кодировать в линухе это как
>>пересеть с мерседеса в горбатый вонючий запор, сорри :)........
Ну во первых, для тех кто только что с виндузы есть КDevelop, KDeStudio, Anjunta, C-Forge.... это только то, что я лично пробовал.
Плюс еще куча, народ меня поправит если я забыл что-то важное. Но до сих пор лучшее IDE для юниксов всех типов это Emacs/XEmacs!(хотя vi/vim мне тоже нравится, но для ежедневной работы - XEmacs :)))

К вопросу об VC++ как _среды_разработки_ ...
1. он что уже научился работать без минимум 10 костылей типа
VisualAssist (www.wholetomato.com)(который, ксати платный),
WinTab... и кучи addon-ов (замена во многих файлах...)!
2. а расчветивать вывод? ошибки одним цветом, варнинги другим...
3. а _нормальное_ автодополние кода?
4. что уже появился отдельный конфиг файл который я могу унести на
другую машину и продолжить работать в уже настроеном окружении. Или
все еще надо тратить время и настраивать после каждой новой
инсталяции/переинсталяции?
5. про родной контроль версий я вообще промолчу, а то у меня кроме
мата слов нет. Хорошо еще что ClearCase цепляется на ура! :)))

вот так! Что-то упустил/забыл - добавят!

2 ZhekaSmith (*) (2002-05-01 16:57:36.744)
>>> P.P.S. Ох и нелегко же набирать кириллицу вслепую :(
Практикуйся чаще! :))))Я вот после 3 месяцев писания писем домой,
очень даже ничего набивать начал! :))))

2 Antichrist
за Джойнера спасибо!

2 bugfixer (*) (2002-04-26 21:20:50.515)
>>> А много здесь физтехов сейчас?
:) УПИ (Уральский Политехнический Институт,Свердловск) ФизТех - каф.
теор. физики. выпуск 1995 г.

alexnav ★
()

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

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

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

"преждевременная оптимизация --- корень всех зол" /Кнут

anonymous
()

ой, предидущая мессага для YePhIcK

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

>Мои же дополнения к anonymous (*) (2002-05-01 01:21:45.745).

>Во-первых - теоремы существования сильно помогают.
>И это неправда, что они физику как телеге пятое колесо.

А я разве утверждал, что теоремы не нужны?
Да и телеге пятое колесо не помешает. Запаска, однако... :))

>Даже в полупроводниках нужно. Ибо иногда решаешь методом Фурье,
>что-то странное получаешь, долго обдумываешь, а потом радостно
>обнаруживаешь, что функцию-то обращать нельзя - под теорему
>не подпадает. А ведь можно было бы и статью тиснуть, люди же засмеют.

Если в программе лажанешся, в GPL'ной, то тоже ошибки в генетическом
коде искать станут :) И, что самое смешное. найдут-ведь... :)
Тут и спорить нечего.

>Во-вторых - OCaml и C++ так по-дурацки сравнивал я.
>Впрочем тут же пнули и за дело. Я действительно перепутал компилятор
>bytecode и нормальный.

Бывает... Признать ошибку -- великое дело :).

>В случае подсчета чисел Фибоначчи (обязательно с рекурсией,
>тот что в примерах по OCaml) OCaml быстрее С++ (все из ALT Master
>Beta2, gcc - 3.0, -O3) раза в два-три (не суть). Из-за того, что
>что компилятор преобразует рекурсию в итерации. Bytecode на этой же
>задаче, как я писал медленнее С++ в 7 раз. Но это так - только тест

Ожидаемый результат.

>на вшивость, который OCaml прошел (мне надо было пощупать
>руками и только, поэтому не надо ссылаться на этот постинг в
>своих утверждениях).

Если ты заметил, я ни на чьи постинги в явном виде и не ссылался.
Да и наехать на кого-то бы ни было у меня цели нет и не было.

P.S: Кстати, криптография всякая, реализованная на ФП-языках должна,
по моим понятиям, отвратительно исполняться. Тут и С-то, зачастую,
скорости не хватает. Моим коллегам на одной из прошлых работ как-то
давно даже на альфовом ассемблере возведение в степень длинных чисел
писать пришлось... И неплохо получилось. Обогнали родной DEC C
в разы.




gns ★★★★★
()

Не знаю как KAI не юзал. Но вот в сторону MSVC++ плюнуть хочу!
Я как-то начинал изучать C++ и начал с простых прог из книжки Страутсрупа (самого нового издания). Дык вот я написал свой Hello, World :))) в линухе закомпайлил его с g++ запустил и все нормально. Ну думаю надо и с VC++ поиграться взял тот же искодник пытаюсь скомпайлить его и бум ошибки ругается на using namespace std; я почесал в затылке и убрал это а в код вместо cout вставил std::cout и все скомпилелось. И стали меня терзать смутные сомнение может я не так понял то что страутсруп написал и линух случайно скомпайлил код? Аннннет потом умные люди сказали (кстати где-то тут-же в обсуждении какой-то другой новости) что это баг VC++ за номером таким-то.
Вот я и не пойму тех кто хвалит VC++. Вы что не наталкивались на этот баг который видно сразу на простейшем хелоу ворде? Разработчики не видели этот баг что он прожил успешно до 6-го релиза уже не помню какого сервиспака? Или виндоузных программеров учат по отдельным книжкам?

anonymous
()

RE: 4-level pointers

2ZhekaSmith Во-первых, большое спасибо за *перевод* :)

> Если длина строки ограничена, то можно попробовать обрабатывать наборы по 1000 строк, обрабатывая одинаковые поля сверху вниз Очень корректно подмечено, что данные читаются и, логично, хранятся в column-major формате. Да, такая задача прямо напрашивается на по-колоночный вывод в буффер :) К сожалению, есть осложнения...

1. Такой подход нелегко адаптировать к варианту delimited output format in ASCII mode 2. Ещё сложнее для UNICODE mode, т.к. здесь ещё надо и в MBCS всё это конвертировать перед окончательным выводом 3. Fixed-width ASCII mode смотрится обещающе... До тех пор, пока не начинается error-detection :) Строки, в которых есть переполнения по ширине поля, должны быть удалены. Но, в принципе, сделать это можно 4. Fixed-width UNICODE mode - это вообще больная тема, если взять за единицу *ширины поля* байт, а не символ. Каждое поле будет необходимо транслировать в MBCS отдельно, *догоняя*, скажем, пробелами до нужной ширине, при необходимости

Из-за всех этих пунктов 1-4, приходится делать такой более-менее *общий* вариант, т.к. это всё надо после написания ещё и поддерживать :) И поддерживать будет не всегда тот же инженер, который этот код писал, так что о чистом, цельном дизайне тоже забывать нельзя.

Подсыплю ещё масла в огонь - если добавить поддержку user-defined decimal and/or thousand separators для чисел, то получается ещё веселее.

А вообще, именно этот вариант решения я сейчас продумываю для следующего этапа оптимизации, так что я рад, что не я один считаю этот путь правильным ;)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Скажем перевод чисел в десятичную и восьмеричную форму будет различаться параметром делителя (10 и 8 соответственно)

Я бы, всё же, сделал две отдельный функции. Даже (если дизайн потребует) виртуальные. Потому что перевод целых чисел в 10-й и 8-й формат оптимизируется кардинально разными способами. Каждую цифру восьмиричного числа можно очень даже быстро получить битовым смещением и маской :). Для десятичного же этот метод наприменим в принципе

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2alexnav

>2 ZhekaSmith (*) (2002-05-01 16:57:36.744) >>> P.P.S. Ох и нелегко же набирать кириллицу вслепую :( >Практикуйся чаще! :))))Я вот после 3 месяцев писания писем домой, очень даже ничего набивать начал! :))))

Это, я так понимаю, мне :) ZhekaSmith не виноват

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2anonymous #58 :) > Вот я и не пойму тех кто хвалит VC++.

Имеется в виду MSVC Уважаемый, вы бы попробовали не Hello World забилдить, а что-нибудь по-заковыристее отдебагать. Вы бы, наверняка, обнаружили и полюбили некоторые полезности MSVC. Моими любимыми являются Edit-and-continue и Set Next Execution Statement. В новейшем IDE от SUN вроде есть подобное, 5 лет спустя, между прочим...

P.S. Так надеюсь, что в этот раз IE не оплошает с кодировкой ;)

YePhIcK ★
()
Ответ на: RE: 4-level pointers от YePhIcK

>>>...Имеется в виду MSVC Уважаемый, вы бы попробовали не Hello World >>> забилдить, а что-нибудь по-заковыристее отдебагать. Вы бы,
>>> наверняка, обнаружили и полюбили некоторые полезности MSVC. Моими
>>> любимыми являются Edit-and-continue и Set Next Execution
>>> Statement. В новейшем IDE от SUN вроде есть подобное, 5 лет
>>> спустя, между прочим...
Извините но я в корне _не_согласен_!!! Если что-то сложнее "Hello World!" - то там начинается такая головная боль что и не рассказать!
Пример: строка содержит "select statement" для выборки из базы... ну пусть будет по 5 полям, и что мы увидим в этом отладчике? хорошо еще если хотя-бы первые символов 16-32 увидим! Про остальные STL
контейнеры я вообще не говорю! Я не говорю что выдрать информацию
из него нельзя, можно, но какой ценой/временем?

Про IDE от SUN. Вы имеете в виду Forte? Возможно вы и правы, я просто не задавался этим вопросом :))) Потому как у меня IDE выглядит как
XEmacs+Suncc+dbx(это дебагер от Сан с намордником в виде DDD) либо
XEmacs+пcc+gdb(с намордником в виде DDD) :))))) И всё это там есть давно. Хотя если честно, пользовался я этим ну очень не часто. :)))


>>> ... Практикуйся чаще!
>>> Это, я так понимаю, мне :) ZhekaSmith не виноват
это ни в коем случае не укор, это просто так. :)))) пока буковки родные на клавиатуре были, я лично, так и не сподобился научиться печатать в слепую. Как говорится - "лень-матушка, раньше нас родилась" :)))

alexnav ★
() 

Часть 1. Жаба
--------------------- 
Заметки про Жабу. 
 
Замечание. Везде в этих заметках слово "жаба" означает язык Java, разработанный 
фирмой Sun, кажется, в 1995 году. Я его буду использовать, потому что 
переключать регистры мне лень. 
 
Кроме собственно жабы, существует комплекс явлений, которые я бы назвал 
околожабством (назвал бы жабницей, да труднопроизносимо). Это вещи, происходящие 
вокруг и около, в частности, великий шум, поднятый вокруг жабы. Их я тоже 
собираюсь затронуть. Казалось бы - почему? Ведь мы говорим о языке, а не о том, 
что около. Скажем, говоря про С, не говорим про всякую околосишность. Но, увы, 
приходится. Это околожабство громадно по своим размерам и своему напору, сильно 
больше, чем околосишность или околофортранность. Оно тесно переплелось с самой 
жабой, и поэтому приходится о нем поневоле говорить. Я делю околожабство на 
политическое, техническое и индивидуальное, и напишу о каждом из них, но сперва 
о самой жабе. 
 
Часть 1. Жаба 
 
Общее замечание о Жабе - что ее разработали и реализовали студенты-троечники, 
второпях, не подумав, а такие же троечники-мэнэджеры, по несчастию обладающие 
ресурсами фирмы Sun, стали ее продвигать на рынок. Вообще, мало кто из нас в 
детстве не изобретал свой собственный язык программирования. Но обычно этому 
предшествовало хотя бы беглое знакомство с бругими языками. С жабой, похоже, 
вышло не так. 
 
Теперь по порядку. 
 
1) Основное свойство Жабы, которое, по замыслу, должно обеспечить большое 
преимущество перед С++ - ее простота. Посмотришь на язык в первый раз - душа 
радуется. Какой красивый, маленький язычок! Копнешь поглубже - в языке есть 
немало тонких и сложных мест, некоторые унаследованы еще с С, некоторые 
привнесены позже. Вложенные классы, например, вовсе не являются простой вещью, а 
хитрый порядок инициализации указателя на объемлющий объект может приводить к не 
менее тонким и трудноуловимым эффектам, чем, скажем, порядок вызова 
конструкторов в С++. А анонимный вложенный класс - вообще дьявольское 
изобретеине, иной цели, кроме как сделать программу нечитаемой, не преследующее. 
 
2) Даже лексика Жабы неочевидна - правила о том, что раньше раскрывается, \n или 
\u, кого угодно сведут с ума. Скажите-ка, что выведется таким вот операторомж 
 
System.out.println ("a\u005Cnb"); 
 
3) Неясно, зачем у Жабы синтаксис, смахивающий на С. Единственное объяснение - 
желание завлечь программистов, пишущих на С или С++. То есть выбор синтаксиса по 
политическим, а не по техническим причинам. Синтаксис С хорош только если язык, 
сделанный поверх этого синтаксиса - С. Когда можно написать 
 
while (*p++ = *q++); 
 
Если же такого написать нельзя, то следует принять наиболее безопасный с точки 
зрения возможных ошибок синтаксис. Синтаксис С - не для чайников. Он требует 
внимания. Можно забыть фигурные скобки, можно поставить (случайно) точку с 
запятой после заголовка while. Профессионалы никогда не сделают подобных ошибок. 
Но ведь Жаба-то разрабатывалась для не совсем профессионалов! 
 
Некоторые проблемы, связанные с синтаксисом С, в Жабе решены. Скажем, требование 
типа boolean в условном операторе почти что решает проблему употребления там 
одного равенства вместо двух. Решает, однако, не полностью, поскольку можно 
написать 
 
if (a = b) 
 
где a и b - оба типа boolean. И надо заметить, что все компиляторы с С выдают 
предупреждение в этом случае. 
 
А вот неполный список проблем синтаксиса С, которые в Жабе не решены: 
- странные приоритеты ряда операций (у >> ниже, чем у +, и у + выше, чем у &) 
- отсутствие явной закрывающей скобки цикла и условного оператора и применение 
вместо этого фигурных скобок - очень сильно чревато ошибками 
- оператор switch, где люди очень часто забывают break 
- совпадение оператора выхода из цикла (break) и из ветви switch 
 
В общем, хоть я и не люблю синтаксис Модулы-2, в особенности клюбчевые слова 
большими буквами, но готов признать, что надежность программирования на Модуле-2 
выше (в случае не особо высокой квалификации программиста), так что я бы 
предпочел, чтобы Жаба имела близкий к Модуле-2 синтаксис. 
 
4) Авторы Жабы выкинули несколько вещей, которые они либо боялись использовать, 
либо не знали, что это такое. В частности, сохранив блочную структуру языка, они 
выкинули перекрытие переменных в блоках. Теперь во вложенном блоке нельзя 
описать переменную, совпадающую с переменной в объемлющем блоке. Объясняется это 
"слишком сложным характером" этого дела - явно студенты просто не поняли. 
 
5) Они выкинули goto. Знаю, знаю, что сейчас тысяча возмущенных людей напишут 
мне, что goto вреден, должен быть запрещен, и без него программы лучше и яснее. 
Отвечу - оператор присваивания не менее вреден, ведь с помощью него можно 
составить совершенно нечитаемые программы. Не зря его нет в LISP. Впрочем, 
программы на LISP ничуть не яснее, из чего следует, что и вызов процедуры должен 
быть запрещен тоже. Более того, все неправильные, не работающие или ненужные 
программы, как правило, содержат хотя бы один из указанных операторов. 
 
Вообще, когда что-то выкидывают из языка из идеологиченских соображений, я 
всегда отношусь к этому с подозрением. Язык нужен для того, чтобы на нем писать, 
а не чтобы удовлетворять идеологии. 
 
6) Я никогда не видел языка с модульной структурой, такой же идиотской, как в 
Жабе. Близко к тому - видел. Скажем, у Ады модульная система достаточно убогая. 
Но Жаба! Ощущение такое, что люди вообще не знали ни одного языка, и никаких 
книжек не читали. Для сравнения. 
 
В Модуле-2 есть два способа проимпортировать объект из модуля: 
- IMPORT module; 
- FROM MODULE import object; 
 
В первом случае объект употребляется как module.object, во втором - просто 
object. В итоге по любому объекту всегда есть возможность определить, откуда он 
пришел - достаточно только посмотреть на начало файла. И наоборот, посмотрев на 
начало любого файла, всегда видно, что конкретно используется в файле. На жабе 
же есть три способа: 
 
- import пакет.класс, например, import com.dvsoft.cts.event.CallEvent; 
- import пакет.*, например, import com.dvsoft.cts.event.*; 
- вообще без импорта, просто использовать в тексте с полным именем: 
 
com.dvsoft.cts.event.CallEvent event = new com.dvsoft.cts.event.CallEvent (); 
 
В результате сказать, кого импортирует данный класс, никогда нельзя. При 
использовании второго механизма нельзя сказать, из какого пакета произошел класс 
CallEvent. При использовании первого способа список импорта имеет гигантский 
размер, что усложняется необходимостью для каждого класса иметь свой оператор 
импорта. Кто придумал такое, заслуживает очень неприятной смерти. 
 
7) Вообще, система с пакетами через точку явно непродумана. Например, 
отсутствует относительная адресация. Нельзя написать 
 
import com.dvsoft.cts.*; 
 
и потом употребить event.CallEvent - только полная квалификация! И если наш 
класс сам принадлежит к пакету com.dvsoft.cts - к подпакету доступ тоже только с 
полным путем! 
 
Если, кстати, по каким-либо причинам я вынужден использовать два класса с 
одинаковыми именами из разных пакетов (ситуация вполне реальная - пакеты могли 
прийти от разных фирм- разработчиков), то один из них я обязан всюду в тексте 
использовать с полной квалификацией, от чего код не становится ни короче, ни 
понятнее. 
 
8) Ничто не мешает файлам из совершенно разных пакетов из самой разной глубины 
иерархии перекрестно импортировать друг друга, что делает связи между модулями 
совершенно неотслеживаемыми. 
 
9) Необходимость помещать каждый публичный класс в отдельный файл приводит к 
появлению сотен небольших файлов, и программу становится невозможно читать. Я 
хочу спросить у фанатов Жабы - вы свои программы хоть иногда печатаете? Не 
говорите мне, что это устарело и более ненужно. Просто вы не можете ее 
напечатать, вот и говорите так. А я свои программы изредка печатаю. Приятно 
почитать программу утром в кафе за чашкой двойного испрессо. 
 
А читать чужую программу с сотней классов просто невозможно! И разные 
класс-броузеры помогают слабо. Вообще я консервативен - программа должна иметь 
исходный текст, пригодный к чтению в обычном редакторе, и к напечатанию. А также 
к обработке различными текстовыми утилитами, хотя бы grep и diff. 
 
10) Классы загружаются по мере использования, в результате чего в момент запуска 
программы никогда неизвестно, вся она присутствует или не вся. Надежности это не 
добавляет. 
 
11) процедуры и классы можно использовать до описания. Это не только усложняет 
компилятор, но и делает программу менее понятной, потому что труднее найти 
определение нужного тебе объекта. 
 
Вообще отступление о компиляторах. В свое время языки писались для людей, без 
учета сложности компиляторов. Это часто приводило к зауми - достаточно упомянуть 
передачу параметров по изображению в Алголе-60. Написание компиляторов с 
некоторых языков было нетривиальной задачей - например, по синтаксическому 
разбору Ады или Алгола-68 защищались диссертации. Примерно со времени С и 
Паскаля наметилась тенденция делать языки так, чтобы их проще было 
компилировать, и оказалось, что такие языки и для человека удобнее, ведь человек 
- это тоже компилятор. Человек читает программу с целью ее понять, и язык, 
который легче разбирается компилятором, и для человека лучше. Так вот, в Жабе 
явный откат назад - считается, что машина железная, пусть и трудится. В итоге 
программы легче писать, но труднее читать. А читать - важнее. 
 
12) Лично я не люблю описания переменных в произвольных местах, люблю в начале 
процедуры. Тогда легче по переменной определить, где она описана, и, если хочешь 
ввести новую переменную, виднее, есть она уже или нет - это обычно касается 
простых временных переменных, вроде i и j. 
 
13) Переменную можно описать в заголовке цикла, но она не локальна в этом цикле, 
что похоже на маразм. 
 
14) Почти что во всяком серьезном языке есть возможности для 
метапрограммирования, то есть описания макросов. В некоторых языках они развиты 
очень хорошо (POP-2, PL/1, некоторый ассемблеры), в некоторых - похуже, как, 
скажем, в С. В некоторых языках их нет, но реализаторы добавляют их в виде 
расширений. В некоторых языках эти возможности присутствуют в виде средств 
расширения синтаксиса (Алгол-68), или написания обобщенных процедур (Ада, С++). 
И только в жабе их нет и не планируется. Это оправдывается тысячей аргументов - 
и непонятны, мол, макросы, и с помощью классов можно без них обойтись, надо 
только предусмотреть побольше виртуальных методов (черт с ней, с 
эффективностью). А в итоге писать сколько-нибудь сложную реальную программу 
практически полностью невозможно. 
 
Рассмотрим простой пример. Мы хотим иметь хэш-таблицу, ключами в которой 
являются целые числа - самый простой и эффективный вид хэш-таблицы. В то же 
время мы не хотим дублировать код для хэш-таблицы на все возможные случаи. Так 
вот, в С для этого мы напишем макрос, в Аде - generic package, в С++ хорошо 
сгодится template. В Жабе мы применим стандартный класс Hashtable, который берет 
в качестве ключей произвольные объекты, завернем целые числа в эти объекты, 
выделив каждый из них в куче, и будем вызывать в них виртуальные метода hashCode 
и equals. Ну да, работать будет. А кого в наше время заботит эффективность? 
 
15) То же касается условной компиляции. Любая серьезная программа всегда 
содержит куски, которые надо по-разному выполнять в зависимости от конкретной 
версии программы, конкретного применения и т.д. Обычно это делается с помощью 
условной компиляции, частенько в сочетании с макросами. 
 
Представьте себе программу для ракеты, имеющей три модификации - не требующей 
проверки двигателя, требующей и имеющей 10 двигателей, и требующей, но имеющей 
их 20, и еще в двух ступенях. На С это было бы написано примерно так: 
 
#if TEST_ENGINES 
#if TWO_STAGES 
for (i = 0; i < FIRST_STAGE_NENGINES; i++) 
check_engine (0, i); 
for (i = 0; i < SECOND_STAGE_NENGINES; i++) 
check_engine (1, i); 
#else 
for (i = 0; i < NENGINES; i++) 
check_engine (i); 
#endif 
 
А как на Жабе? Можно, конечно, заменить #if на обычный if, но имейте в виду, что 
определить константы в зависимости от внешних условий, нельзя, и поэтому это 
будут настоящие исполняемые операторы. А скорее всего, это вообще будут не 
константы, и даже не переменные, а вызовы виртуальных методов. В общем, будет 
что-то вроде такого: 
 
if (checkNeedTestEngines ()) { // виртуальный метод 
if (checkTwoStages ()) { // виртуальный метод 
for (i = 0; i < 2; i++) 
for (j = 0; j < StageManager.instance().getStage (i).getNumEngines (); 
j++) 
StageManager.instance().getStage (i).getEngine (j).check (); 
} else { 
for (i = 0; i < Stage.instance().getNumEngines (); i++) 
Stage.instance().getEngine (i).check (); 
} 
} 
 
Разумеется, можно заменить 2 на StageManager.instance().getNumStages (), можно 
перетащить код по проверке двигателей в класс Stage, можно сделать еще массу 
дизайнерских изысканий, но всегда сохранятся два свойства: 
- все проверки будут во время исполнения и будут есть время 
- на орбиту придется брать с собой весь код, то есть одноступенчатая ракета 
должна будет иметь столько же памяти, сколько и многоступенчатая. 
 
Неужели это именно то, чего добивались? 
 
Кроме того, условная компиляция и макросы очень удобны для отладки. Например, в 
текст вставляются вызовы макроса ASSERT, которые в отладочном режиме 
раскрываются в проверку условия, а в боевом - в ничего. На Жабе это невозможно - 
код будет исполняться и тратить время. Для этого придуман объезд - условие 
пишется в специального вида комментарии, а специальные программы вставляют его 
из комментария в код, после чего компилируют обычным компилятором. Не есть ли 
это маразм? 
 
16) Нормальные языки содержат конструкции для описания статических данных - 
инициализируемые массивы и записи, например. На Жабе с этим грустно. Есть убогое 
подобие инициализации массивов. Инициализация записей (гордо называемых 
классами) делается с помощью конструкторов. И то, и другое выполняется во время 
исполнения, то есть во время запуска такой программы куча времени будет съедена 
на эту инициализацию, и в программе будет, кроме самих данных, присутствовать 
код, исполняемый ровно один раз. Зачем это надо? Представьте себе, что вы пишете 
восходящий синтаксический анализатор. Такой анализатор имеет обычно 
большую-большую таблицу, которая на С записывается просто и естественно, и не 
тратит для своего создания ни такта процессорного времени. А на жабе это все - 
исполняемый код! 
 
Более того - большинство реализаций даже константы (то, что описано как public 
static final int) - определяет во время исполнения! 
 
17) Одно из замечательных изобретений Вирта - перечислимый тип. Жаль, что он от 
него отказался в Обероне. В каком-то виде этот тип пробрался даже в С. В Жабе 
его нет, и это очень неудобно. Вместо него - просто целые "константы", которые 
вовсе и не константы. Никакой проверки типов (которая была бы естественна для 
"надежного" языка). Иные удальцы применяют классы для этого - то есть передают 
указатели там, где нужно целое значение, и используют функции там, где нужно 
число, закодированное этим значением. В итоге программа становится совершенно 
нечитаемой, и к тому же на пустом месте теряется эффективность. 
 
18) Есть странный глюк - статические переменные (в том числе константы) можно 
описывать только во внешних или статических вложенных классах. Это крайне 
неудобно, потому что без определений констант нельзя описать функционально 
законченный класс, а часто хочется выделить локальный такой класс, без 
высовывания его наружу. 

19) Система экспорта-импорта в Жабе настолько сложна, что правильная ее 
реализация становится почти непосильной задачей. Особенно с учетом того, что 
импорт классов может быть взаимным. В результате ни в одной из существующих 
реализаций нельзя быть уверенным, что проект пересобран полностью. Это 
наблюдается в J++, JDK и JBuilder. Единственный надежный способ - стереть все 
class-файлы, после чего сделать полный Build. При этом надо, конечно, следить, 
чтобы в classpath случайно не было ссылок на так же называющиеся классы. В 
общем, поддержка проекта превратилась в постоянный геморрой и, похоже, так и 
было задумано. Более того, все стандартные компиляторы вслед за JDK валят 
class-файлы туда же, где уже лежат Java-файлы, делая крайне затруднительным 
стирание всех class-файлов. 
 
20) Это мало кто знает - я раньше не знал. В файле с каким-то публичным классом 
можно описать еще несколько непубличных (без атрибута public). Так вот, я всегда 
был уверен, что область видимости таких классов - текущий файл. Святая простота! 
Эта область - пакет! То есть, компилируя пакет, и увидев незнакомое имя в 
позиции, пригодной для имени класса (перед точкой, после new или в описании 
переменной), надо просмотреть все файлы из данного пакета, в поисках определения 
соответствующего класса. То же самое должен, конечно, делать читатель программы. 
 
21) Для "Надежного" языка разумно было бы иметь (возможно отключаемый) контроль 
целого переполнения. Либо язык для приложений - тогда нужен контроль. Либо для 
ковыряния битов (как в С) - тогда не нужен. Жаба вроде бы всегда провозглашалась 
языком для приложений. Так где этот контроль? 
 
22) Каждый раз, когда мы описываем структуру (она же запись, она же класс), 
происходит выделение памяти в куче. Каждый раз, когда мы ее потом используем, 
происходит обращение по указателю. Зачем? Я понимаю, все это может быть полезно 
для "классов" - из-за возможного наследования их как раз полезно в куче 
размещать. Но что, если мы просто определили структуру Point с двумя полями, x и 
y - ну зачем тут куча? А представьте себе, что мы определили "линию" как две 
точки: 
 
class Point 
{ 
int x; 
int y; 
} 
 
class Line 
{ 
Point p1; 
Point p2; 
} 
 
Line line = new Line (); 
line.p1 = new Point (); 
line.p2 = new Point (); 
line.p1.x = 10; 
line.p1.y = 20; 
line.p2.x = 30; 
line.p2.y = 40; 
 
Разумеется, с помощью конструкторов это можно сократить до 
 
Line line = new Line (new Point (10, 20), new Point (30, 40)); 
 
но внутренняя суть не изменится - будут три обращения к распределялке памяти. 
Соптимизировать их трудно, почти невозможно - никто никогда не уверен, что при 
вызовах методов ссылки на эти объекты нигде не остаюися. 
 
23) Хотя Сотрудник MS и пытался меня как-то убедить, что в сборщике мусора нет 
ничего страшного, я все же отношусь к нему подозрительно. Я предпочитаю точно 
знать, когда и что в программе происходит, и почему. Особенно в приложениях, 
критичных по времени. 
 
 
24) В языке отсутствуют VAR-параметры. Из-за этого, например, нет возможности 
вернуть два результата из функции. На С я, например, частенько решаю задачу 
разбора строки так: 
 
int gen_next_lexem (char ** p); 
 
next_lexem = get_next_lexem (&p); 
 
Функция выдает тип очередной лексемы и заодно продвигает указатель. Так вот, на 
жабе это невозможно. Вместо этого надо заводить класс, который скрывал бы этот 
указатель, вроде такого 
 
Parser pars = new Parser (p); 
 
next_lexem = pars.getNextLexem (); 
 
Вроде и красиво, но только жалко создавать класс без нужды. Класс из ничего, 
класс для ничего, класс только для обхода убогого синтаксиса языка. 
 
А теперь модифицируем это, чтобы возвращался не только тип лексемы, но и сама 
лексема. 
 
На С это так: 
 
int gen_next_lexem (char ** p, char ** lexem, int * lexem_len); 
 
next_lexem = get_next_lexem (&p, &lextext, &lexlen); 
 
На Жабе придется создавать еще один класс - лексема, в котором хранится и 
лексема, и ее длина, и ее тип. И, конечно, придется выделять память для нового 
класса и для нового объекта String (хорошо еще, если сам текст копировать не 
придется, но это зависит от реализации String). 
 
Ну зачем это все? Неужели специально все сделано, чтобы эффективность поменьше 
была? 
 
25) Одно из замечательных изобретений Вирта, реализованное в Модуле-2, а также в 
каком-то виде в С - это разделение текста на definition и implementation. 
Хорошо, когда отдельно описан интерфейс, отдельно - реализация. Соответственно, 
один файл содержит комментарии о том, что делается, а другой - как делается. И, 
чтобы понять, что делает данная процедура, не надо лопатить кучу текста. А файл 
с реализацией, в свою очередь, не содержит гигантских пользовательских 
комментариев, и потому более обозрим. Так вот, в жабе этого нет. Всегда советуют 
моделировать это с помощью интерфейсов либо абстрактных классов. То есть 
применять виртуальные методы. С какой, спрашивается, стати, я должен применять 
косвенный вызов процедуры, а не прямой, только из-за того, что язык сочиняли 
идиоты? 
 
 
26) Теперь немножко о библиотеке. Это не недостаток языка, а мое личное 
неудовлетворение. Бывают языки, содержащие библиотеку (или большую ее часть) в 
себе, например, PL/1 с его оператором PUT EDIT, или BASIC. Бывают языки, от 
библиотеки почти независимые, как С. Мне всегда больше нравились последние, 
потому что позволяли обходиться без библиотеки. Обычно, если ее не использовать, 
то в С можно обойтись небольшим рантаймом, что особенно здорово для встроенных 
приложений. 
 
В Жабе же реализован самый извращенный, третий вариант. А именно язык вроде бы и 
отделен от библиотеки, а вроде она и вылазит в самых неожиданных местах. Ну 
например, то, что строка в кавычках - значение класса String, а исключительная 
ситуация "указатель равен null" - класса NullPointerException. И таких случаев 
много - когда что-то является объектом какого-то левого класса. В результате 
никогда неясно, что используется в программе, а что нет. 
 
27) Сама библиотека оставляет желать лучшего. Почему, например, для узнавания 
текущей даты я должен выделять в памяти объект? А вот еще задачка, достойная 
пера. Напечатать текущую дату в формате 
 
дд.мм.гггг чч:мм:чч.МММ (МММ - миллисекунды). 
 
Ну все сделано, чтобы только сделать это невозможным! Вообще, опыт практического 
использования библиотеки заставляет подумать, что она была сделана левой ногой 
пьяного матроса. 
 
28) В Жабе появилось слово "deprecated". Это то есть когда в новой версии старый 
метод еще поддерживается, но не поощряется. Хорошая, на первый взгляд, 
возможность. Но вот почему выходит версия жабы (JDK 1.0), а через полгода другая 
(1.1), и в ней половина библиотечных функций уже "deprecated"? А о чем думали 
полгода назад? А еще "отдепрекатили" целую графическую библиотеку (AWT), сделав 
новую версию (Swing), причем специально сделали это, дождавшись, пока все 
выпустят инструменты для поддержки AWT. 
 
29) При написании на С много внимания уделяется всяким случаям вроде "А что если 
функция malloc вернула NULL?" Так вот, в Жабе считается, что память всегда есть. 
В общем-то никаких оснований для этого нет. А когда память кончится, будет 
брошена эксепция вроде OutOfMemoryException, которая есть объект и должна быть 
выделена в куче... 
 
30) Вообще, механизм исключительных ситуаций с обязательным описанием хорош 
только на первый взгляд. Как только применяется какой-нибудь метод разработки 
программ, при котором управление не передается непосредственно, а "ныряет" в 
переходник, то все это летит к черту. Например, если мы написали процедуру 
обхода дерева, которая в каждом узле вызывает пользовательскую процедуру, то 
вполне естественно, что в этой пользовательской процедуре что-то может пойти не 
так. Мало ли что - файл не пишется, ресурс не выделяется, ошибка в исходных 
данных. Тут бы и бросить ексепуию, прекратив обход, а фигу. Эксепция должна быть 
заранее предусмотрена еще при написании общей процедуры обхода дерева. 
 
31) Меня очень раздражает оператор "+" для строк. Не люблю исключений. Вообще, 
значит, операторы не переопределяются, а вот для строк пожалуйста. При этом, 
если объект не строка, вызывается специальный метод со специальным именем 
toString... Ну зачем превращать язык в BASIC? Ясно же, что все так и будут 
применять этот оператор для складывания строк, плюя на эффективность. Есть класс 
StringBuffer, а кто им пользуется? 
 
32) С определяет int как "наиболее эффективное целое число, не короче, чем 16 
бит". То есть если на машине длина слова 18 бит, то и целое будет 18 бит. Жаба 
же определяет int как ровно 32 бита, а long как ровно 64. И если на машине нет 
32-битных чисел (например, есть только 64-битные), придется моделировать. Мне 
это не нравится. Отсутствие беззнаковых чисел мне тоже не нравится. 
 
33) Жаба предоставляет некоторые особо высокоуровневые возможности, такие, как 
клонирование (глубокое копирование) объектов и сериализация. Обе опасны в 
неумелых руках. Чайник, не задумываясь, склонирует (или сериализует) громадный 
граф, лишь бы добиться какой-то сиюминутной цели. Сериализация уже привела к 
тому, что программмы хранят свои настройки не в приятных для глаза ini-файлах, и 
не в Registry, а в многочисленных файлах, полученных путем сериализации 
объектов. 
 
На сем я и закончу про жабу. Достаточно этого или надо еще? 


Часть 2. Околожабство. 
--------------------- 
 
2.1. Техническое околожабство. 
 
Техническое околожабство охватывает вопросы хранения, компиляции и выполнения 
программ на жабе, а также принятые, а вернее культивируемые, а еще вернее 
насаждаемые методы писания на жабе. 
 
1) Самое очевидное техническое околожабство в том, что жаба компилятор, и с 
самыми лучшими виртуальными машинами все же существенно отстает от С++ (при этом 
речь идет о ОО-программе на С++, то есть программе со всеми этими красотами 
вроде динамической памяти и виртуальных методов). От нормальной программы на С 
жаба отстанет еще больше. 
 
2) Далее, из-за переносимости жаба не позволяет нормально использовать 
возможности машины и ОС. Кто видел интерфейсы, писанные на жабе, даже с 
новомодным Swing, тот согласится, что по сравнению с виндами (а также по 
сравнению с Х-виндами) это просто убожество. Аналогично, Win32 имеет богатый 
набор примитивов синхронизации. Юникс тоже имеет (хотя и не столь богатый). На 
жабе все это недоступно по определению (если только не использовать native 
методы, интерфейс для которых разработан так, чтобы никто их не использовал). 
 
3) Стандартная форма программы на жабе - россыпь java-файлов. Стандартная форма 
ее поставки - россыпь class-файлов. При этом никогда неясно, какие конкретно 
классы будут использоваться - на то есть переменная classpath, которая вечно 
стоит не куда надо. Почему-то пользоваться несколькими компиляторами С 
одновременно гораздо проще, чем несколькими жабами. И часто случаются очень 
трудно уловимые ошибки - ишещь ее час, а выясняется, что class- файл взялся из 
другого места (переменная неправильно стояла). 
 
Кроме того, невозможно перетранслировать все, какие надо, файлы (но я об этом 
уже писал). Добавлю только вчерашний случай. Я взял чужую библиотеку в виде 
исходных файлов. Поставил вызов в свою программу и надеялся, что из-за этого 
все, что надо, перекомпилируется. Щас! Программа, оказалось, использовала RTTI, 
в изощренной форме - а именно формировала имя класса динамически, после чего 
этот коасс загружала. Причем все это было сделано без нужды, лишь бы 
выпендриться, а в итоге при работе программы в самый неподходящий момент 
вылетала исключительная ситуация NoClassDefException. 
 
4) Ни в одном языке, кроме Жабы, не пытались еще ввести обязательный формат 
записи - где и как скобки ставить. Считается, что это унифицирует запись и 
сделает программы понятнее. Фигу. Программы будут понятнее, если их будут писать 
разумные люди, и только тогда. Мое мнение такое - программист должен иметь свой 
стиль записи, в котором ему работать удобно. Он должен также уметь читать любой 
другой стиль записи. Скажем, я пишу с пробелами и короткие процедуры, а Толик - 
без пробелов и длинные, но я могу его тексты читать и иногда понимать, а он - 
иногда мои. И нет проблем. 
 
5) Жаба также вводит идиотские правила именования - классы с большой буквы с 
промежуточными большими буквами (ИмяКакогоТоКласса), методы - тоже с маленькой 
(вотКакПоДурацкиСмотрится), поля (данные) - тоже. Константы - целиком большими 
буквами через подчерк (ПОЛУЧАЕТСЯ_ВОТ_ТАК). Да, кстати, имена методов должны 
быть глаголами (getNextElement () вместо nextElement ()). И конечно, сам Sun это 
не соблюдает - у него методы называются как что попало. 
 
В общем, все эти схемы раскладки и именования отвлекают внимание от собственно 
программирования и приводят к плохо читаемым программам. 
 
6) Способ именования пакетов в жабе - отдельная песня. Они называются по адресу 
компании в обратном порядке. Скажем, мы зарегистрировали домен dvsoft.com - вот 
наши классы и называются com.dvsoft.... Это все хорошо, когда апплеты по сети 
приезжают, и совершенно бессмысленно при написании нормальных программ. Ведь 
кроме всего прочего единство имени не означает единства версии. Подход 
Микрософта с его COM мне нравится больше - не имя определяет интерфейс, а 
Глобальный Идентификатор. 
 
7) Обзор технического околожабства будет явно неполон без такого чуда, как 
javadoc. Это, кто не знает, когда перед процедурами, переменными и классами 
делаются офигенного размера вставки, написанные на диковинной смеси HTML и 
специальных тегов. Потом программа подается на вход специальной утилите, которая 
делает по этому делу красивый HTML с описанием интерфейса. Как правило, выглядит 
он по идиотски, например: 
 
int getNextNumber () 
- returns the nest number. 
Parameters: none 
Result: next number 
 
Читать это - одно удовольствие. Читать исходный текст - одно мучение, Вы хотели 
бы иметь HTML-теги у себя в программе? 
 
Мое мнение однозначно - комментарии это для человека. Или должен быть 
definition-модуль, в котором в красивом и понятном виде написано, что делает 
процедура. Если уж такого модуля нет, можно, конечно, и в основном тексте 
написать. Но - красиво и понятно, для человека, а не для машины. Хотите 
отдельный документ - пишите свои комментарии хотите в HTML, хотите в ворде - но 
отдельно. Не в исходном тексте. Этот текст еще людям читать. 
 
8) Еще одно техническое околожабство - так называемые методы доступа. Написав 
любую структуру. любой жабовский программист всегда первым делом начинает писать 
методы доступа. Например, если ему надо описать запись из двух полей, х и y, он, 
не задумываясь, на полном автомате напишет следующее: 
 
class Point { 
private int x, y; 
 
public Point (int x, int y) { 
this.x = x; 
this.y = y; 
} 
 
public int getX () { 
return x; 
} 
 
public int getY () { 
return y; 
} 
 
public void setX (int x) { 
this.x = x; 
} 
 
public void setY (int y) { 
this.y = y; 
} 
} 
 
Я спрашиваю - ЗАЧЕМ? Я бы еще понял, если бы эти переменные хранились в какой-то 
извращенной форме. А они хранятся как есть, и с большой вероятностью никогда не 
будут храниться по другому. Так зачем обращаться к ним через функции? Ну что 
этим достигается? Это явный идеологический бзик. 
 
Я убежден - методы, высовываемые из класса, должны делать какое-то сложное 
действие. Иногда, для data consistency, поля полезно скрыть. Скажем, если бы мы 
разрешали менять x и y только оба вместе, я был бы обеими руками за то, чтобы 
делать это через методы. Был бы метод 
 
void setXY (int x, int y) 
 
и все отлично. Хотя лично я в этом случае ввел бы в язык поля, доступные снаружи 
только на чтение, и избежал бы вызовов процедур для чтения переменных, оставив 
только для записи. А скрывать поля и тут же давать методы для доступа к этим 
полям ПООДИНОЧКЕ - это явный маразм. 
 
Апологеты этого способа дошли до того, что класс не только наружу не должен 
высовывать поля - внутри их не должен использовать! То есть должен сам 
пользоваться этими функциями доступа. Для этого рекомендуется начинать имена 
полей с подчерка, чтобы их противный внешний вид отвращал от их использования. 
 
9) Некоторым развитием этого служат так называемые "свойства" (properties). Это 
когда, считается, что у класса как бы есть поле (на самом деле нету), а мы как 
будто присваиваем этому полю, а при этом происходит какое-то действие. Например, 
есть свойство "FontSize", и мы пишем 
 
setFontSize (10); 
 
И при этом все перерисовывается и размер фонта меняется. В Дельфях так вообще 
синтаксис присваивания для этого используется. Так вот, мне это очень не 
нравится. Название должно отражать суть процесса. Если метод только выставляет 
переменную, пусть называется set-что-нибудь. А если делает что-то - то 
do-что-нибудь. Какой-нибудь осмысленный глагол. В нашем случае - какое-нибудь 
changeFontSize или enlargeFont, а еще лучше вообще такого не иметь, а иметь 
что-нибудь вроде 
 
changeTextFont (String type_face, int font_size); 
 
или 
 
changeTextFont (Font font); 
 
А то некрасиво - одним вызовом мы меняем фонт, другим - его размер, а в итоге 
все жутко моргает. Это, конечно, никого не волнует - когда что-то моргает. 
 
10) Жабцы очень любят "шаблоны разработки" (design pattern). Иногда дело доходит 
до смешного - например, они хотят запретить оператор switch, а всюду, где он 
нужен, использовать классы. Делается это так. 
 
Пусть у нас есть переменная x, принимающая числовые значения A, B, C, и мы 
хотели бы написать 
switch (x) 
{ 
case A: a (); break; 
case B: b (); break; 
case C: c (); break; 
} 
 
Так вот, вместо этого мы определяем классы A, B, C, их базовый класс ABCConst, а 
в нем - метод 
 
acceptVisitor (ABCVisitor v); 
 
где ABCVisitor - интерфейс с тремя методами 
 
void visitA (A a); 
void visitB (B b); 
void visitC (C b); 
 
Так вот, класс A определяет acceptVisitor так: 
 
acceptVisitor (ABCVisitor v) 
{ 
v.visitA (this); 
} 
 
После этого класс, в котором находится switch, определяется как реализующий этот 
самый visitor. 
 
Далее, оператор switch заменяется на вызов 
 
x.acceptVisitor (x); 
 
и к тому же в класс добавляются три метода такого вот вида: 
 
void void visitA (A x) 
{ 
a (); 
} 
 
и так далее. В итоге путем введения всего навсего двух интерфейсов и трех 
классов, то есть всего-то пяти файлов, от оператора switch мы избавились. Что 
делать, если в классе есть два оператора switch, оставлю читателю в качестве 
легкого упражнения. 
 
Замечу, что, если эти самые a(), b(), c() должны вернуть результат, он должен 
быть либо заранее предусмотрен при изготовлении интервейса ABCVisitor, либо 
записан в какое-нибудь поле объемлющего класса. А о том, чтобы в этих процедурах 
бросить ексепцию, вообще лучше забыть. Еще замечу, что экземпляр объемлющего 
класса нам теперь нужен (со свитчем можно было и статический метод иметь), 
поскольку в процедуру accept передается this. 
 
Все описанное называется "visitor design pattern". Меня хотели заставить с 
помощью него делать state machine. Там как раз два свитча - по текущему 
состоянию и по типу сообщения. Я сопротивился, в результате у меня один класс 
там, где могло быть пятьдесят. На самом деле я написал обе программы (а вернее 
нарисовал программу на С, которая сгенерировала обе программы, что почему-то 
удивило всех вплоть до директора фирмы), и всем продемонстрировал оба варианта. 
Вариант со свитчем еще и работал быстрее. 
 
Еще один пример - singleton design pattern. Это значит, если мы имеем дело с 
модулем - то есть с классом с одними статическими функциями - то все же сделать 
их нестатическими, и иметь ровно один экземпляр этого объекта, и все делать 
через него. Без всякой цели - просто так, чтобы служба медом не казалось. 
 
Разумеется, большая часть перечисленного - не есть свойство жабы. Я потому это и 
назвал околожабством. Просто наибольшее количество людей с вот таким образом 
испорченными мозгами тусуется около Жабы. Они есть и около С++, но все же их там 
поменьше. А около С и вовсе собрались разумные люди. 
 
 
2.2. Политическое околожабство 
 
Это околожабство заключается в великом шухере, поднятом вокруг жабы. Никогда еще 
ни вокруг какого языка такого шухера поднято не было. Посмотреть на это - так 
прямо серебряную пулю нашли, язык, который все проблемы человечества решит. 
Думаю, мой предыдущий текст показал, что это утверждение, мягко говоря, неверно. 
 
Все соревнуются - не только и не столько в том, кто сделает интерпретатор или 
компилятор с жабы получше, сколько в том, кто поизощреннее эту жабу применит. 
Скажем, наша фирма решила написать на жабе телефонный софт не в последнюю 
очередь из-за того, чтобы не оказаться в последних рядах - среди тех, кто еще 
ничего на жабе не написал. И, конечно, хвастаться можно заказчику - вот мы 
какие! На жабе написали! И он, которому по идее не должно быть дела, клюет и 
радуется. Вот странно - на Фортране написано было, на Сноболе 4 или на Симуле-67 
- это всегда было всем пофиг. Лишь бы работало. А на жабе - всем интересно. Как 
будто оно лучше от того, что на жабе. 
 
Наше начальство поставило небольшой эксперимент и заявило, что разработка 
программы на жабе занимает в два раза меньше времени, чем такой же на С++. С С 
они не сравнивали. Так вот, я в это не верю. Я вижу, сколько времени пишут тут 
программы на жабе. Конечно, этих людей я бы к С++ вообще близко не подпускал, и 
к С тоже. Но ведь не только такие люди есть. Я уж точно на С быстрее напишу, 
особенно если никто над душой стоять не будет со своими паттернами. 
 
Инструменты для жабы пока очень сырые. Они сыплются, несовместимы друг с другом, 
в общем - недоделаны. Это значит, что для промышленных целей жабу применять 
рано, место ей - в университете. 
 
Давайте зададим самый главный вопрос. Зачем жаба? Вообще, первый вопрос, который 
должен задать себе разработчик нового языка - зачем этот язык. Что с помощью 
него можно сделать, чего раньше было нельзя, и чего легко сделать, чего раньше 
было сложно. В случае жабы ответов три. 
 
1) Для писания апплетов, которые ездят по сети и работают на машине клиента. Я 
полностью согласен, что для этого необходим абсолютно надежный интерпретируемый 
язык. Возможно, жаба для этого и годится, хотя она для этой цели слишком велика. 
Для нормальных целей достаточно какого-нибудь скриптового языка (вроде того же 
жабаскрипта, имеющего к жабе отношения не больше, чем c-shell к С). 
 
Так вот, жаба нужна для апплетов. А для чего нужны апплеты? Где они, апплеты? 
 
90% апплетов, которые я до сих пор видел - это были красивые счетчики. Или иной 
оживляж - всякие мигалки, скроллящиеся строки и прочий маразм. Единственный раз, 
когда апплет был по делу - это во время матча Deep Blue с Каспаровым. Я помню, в 
первом матче после каждого хода закачивалась доска в виде GIF, а во втором - 
только ходы, а показывались они на клиенте с помощью апплета. 
 
Все! Больше путевых апплетов я не видел. Да что там - самый лучшей и полезный в 
мире сайт (угадайте какой) сделан с помощью чистого CGI. Так же устроены Amazon, 
сайты авиакомпаний, выдающие рекомендации по составлению маршрутов, сайты 
новостей - словом, все, что применяется по делу. 
 
Итак, апплеты - это большой мыльный пузырь, никому это не надо. 
 
2) Для писания переносимых программ. Мэнеджеры придумади термин - WORA, write 
once, run anywhere. Я бы лучше назвал это WOABNR - write once and better never 
run. Так вот, налицо технология, созданная для удобства програмимистов, а 
вернее, их мэнеджеров, а не пользователей. Представьте себе автомобиль, который 
умеет ездить по рельсам и дороге, на бензине и ацетоне, с левым рулем, который 
легко переставляется направо, но ездит только со скоростью до 5 км/ч. Купите вы 
такой? Так и с программами. Пользователю до большой балды, на чем написана 
программа и работает ли она на какой-либо еще платформе, кроме его собственной. 
Пользователю надо, чтобы программа хорошо работала на одной-единственной 
платформе - на его. Хорошо работала - это понятие многогранное. Оно включает в 
себя: 
- быстро работала на ней 
 
- имела бы внешний вид, принятый на этой платформе (например, Motif, Macintosh, 
Windows 95) 
 
- имела бы управляющие сигналы, принятые на данной платформе (например, на 
виндах - закрывалась бы по Alt-F4 и показывала бы хелп по F1) 
 
- сопрягалась бы с другими программами на данной платформе (скажем, понимала бы 
clipboard и drag & drop в виндах) 
 
- использовала бы на полную катушку возможности ОС в области многопоточности, 
многопроцессности, межпроцессного взаимодействия, файлового обмена и т.д. и с 
помощью этого добивалась максимальной эффективности и надежности. Например, не 
мещало бы, чтобы БД сбрасывала дисковый кэш по закрытию транзакции - как этого 
добиться на жабе? 
 
- использовала бы и юзерские возможности ОС тоже. Например, в виндах чтобы 
писала свои настройки в Registry, а не в странные файлы двоичного вида, 
получаемые при использовании жабовского механизма Serializable. 
 
Так вот, написание программы на жабе, по крайней мере в наше время, не отвечает 
поставленной задаче. На жабе можно слепить глюкалу, но не серьезную программу. 
 
Косвенное доказательство этому - ГДЕ ЭТИ ПРОГРАММЫ? Ну где эти продукты, 
написанные на жабе? Единственное, что мы имеем - это сановские инструменты из 
JDK. Скорость их работы позволяет подозревать, что они написаны на жабе. Также 
легко видно, что микрософтный компилятор написан не на жабе - работает со 
свистом. 
 
Corel предпринял попытку переписать свой офис на жабу. Я имел счастье лицезреть 
первую версию этого. WordPerfect и Quattro Pro, работающие в броузере! Со 
скоростью раз в пять меньше той, с которой аналогичные программы работали на 
Apple ][. Интересная была игрушка, но не более того. И известно, что Corel 
прикрыл эту работу, признав ее бесперспективнойю. 
 
Нечто подобное случилось в Микрософте. Микрософт с самого начала считал идею с 
апплетами неинтересной - вместо них они проталкивали свои ActiveX. Но они 
рассматривали вариант писания на жабе своих собственных программ - мол, хороший, 
красиыйя язычок, что ж не пописать? Я боюсь ошибиться, но, мне кажется, они 
очень скоро осознали, что идея бредовая, и пишут в основном, как и раньше - на С 
и С++. А Жабу только продают лохам, вроде нас, сами же не используют. 
 
Между прочим, количество переносимых программ, написанных на С, поражает 
воображение. 
 
3) Для обучения. Здесь язык уже смотрится неплохо. Производительность и качество 
программ тут неважны, а объектно-ориентированное программирование вообще - 
полезная (хотя и не абсолютная) концепция. Жаль только, что вокруг жабы 
собрались фанатики, и они же с большой вероятностью будут учителями. Так что 
может получиться хуже. Иными словами, если бы не шухер вокруг жабы, она была бы 
почти идеальным языком для обучения. Шухер прибивает к ней толпу придурков - для 
обучения это опасно. 
 
Наконец, хотелось бы заметить, что Жаба - отнюдь не первый 
объектно-ориентированный язык. До нее было немало симпатичных 
объектно-ориентированных языков, которые, однако, такого шухера не вызвали - 
взять ту же Симулу 67. Из современных можно посмотреть на Оберон, Актор и 
Модулу-3. Мне особенно понравилась Модула-3 - объектно-ориентированный язык на 
базе синтаксиса Модулы, с сохранением концепции definition-implementation, не 
претворяющийся проще, чем он есть, но и без лишней придури. Был разработан без 
участия Вирта фирмой DEC лет десять назад, но распространения не получил - 
видимо, у людей из фирмы DEC есть совесть. 
 
 
2.3. Личное околожабство. 
 
Каждый язык вызывает кучу ощущений и ассоциаций у пишущего на нем. Он как будто 
имеет психо-моторные и органо-лептические свойства. Писание на одном языке может 
отличаться от писание на другом, как поедание мяса от рыбы, или питье молока от 
вина, или езда на разных видах велосипедов. Некоторые языки вызывают приятное 
ощущение, некоторые - неприятное. Некоторые языки по ощущениям близки, некоторые 
- далеки. Скажем, для меня Модула далека от С, но не настолько, как Жаба. А 
наиболее близкий к жабе язык (для меня) - это Visual Basic. Почему-то ощущения 
почти один к одному совпадают. А Visual Basic мне глубоко противен. В первую 
очередь своим высоченным уровнем, из-за которого простые вещи приходится 
моделировать с помощью сложных. 
 
 
3. Прогноз. 
 
Мой личный прогноз - максимум через пять лет Жаба тихо помрет, или вернее сойдет 
с переднего плана, заняв подобающее ей место где-то возле Лого, Лиспа, Схемы, 
Снобола 4, Смолтока и Форта. 
 
4. Выводы. 
 
1) Когда вокруг шухер - сохраняйте ясную голову 
 
2) Не будьте тем, кто расшибает голову, когда молится 
 
3) Применяйте игрушки для игры, а серьезные вещи - для работы. Например, не 
пытайтесь делать себе серьезную аппаратуру из радиоконструктора. 
 
4) Не торопитесь запрыгивать в поезд - убедитесь, не отцепленный ли это вагон. 
 
--------------------- 
Вторник, 15 сентября 
Африканец

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

Сильно :) Комментировать такой длинный текст заняло бы много времени, скажу вот что -- Java сыграла знаковую роль в развитии IT индустрии и отрицать это было бы глупо. Можно сколько угодно говорить, что они не первые, у них есть недостатки, итд., но Java в 90-е сыграла примерно такую же роль, что и С++ в 80-е, а Lisp в 60-е. К тому же я считаю, что недопустимо рассматривать Java как только язык, поскульку Java как технология гораздо важнее. Идея того, что программы должны запускаться в защищенной среде (JVM), которая предоставляет более высокоуровненый интерфейс, чем ОС -- я думаю, хорошая идея. С развитием распределенных вычислений эта идея будет все более популярной и наверняка разработают вещи в чем-то похожие на Java. А Java стала первой широко распространившейся технологией, использовавшей эту идею. Точно так же С++ принес "в массы" ООП, а Lisp - ФП. Что касается производительности, то тут беда Java в том, что самая распространенная реализация JVM -- софтверная. В идеале производительность среды, в которой выполняются программы, должна обеспечиваться железом напрямую.

yakuza ★
()

2 Африканец: ваше эссе, конечно, впечатляет. Однако, я бы отметил несколько моментов:
* Авторы Java - не студенты-троечники, а одни из лучших профессионалов в compiler design.
* С-подобный синтаксис - действительно политическое решение, и никто этого не скрывает. Все попытки подсунуть C++ crowd язык с непохожим синтаксисом (напр. Dylan) с треском провалились.
* Java - не мой любимый язык, но за ним чувствуется *дизайн*, а за C++ - нет.
* Java проектировалась как язык для среднего программиста. Средний программист в наши дни - недоучка. Кто-то тут говорил, что правильный способ делать проект - вместо 10 дорогих профессионалов набрать 200 дешевых полупрофессионалов, а если не помогает, добавить еще 200. Ява для этого идеальный язык, грамотно бьющий по рукам неграмотному программисту. Раз уж вы решили доверить детсадовцам строить дом, лучший инструмент для этого - совочки, формочки и набор "Лего", а не бульдозер, циркулярка и перфоратор.

Viking ★
()

2 YePhIcK (*) (2002-05-02 10:26:28.033)

>Имеется в виду MSVC Уважаемый, вы бы попробовали не Hello World забилдить, а что-нибудь по-заковыристее отдебагать. Вы бы,
>наверняка, обнаружили и полюбили некоторые полезности MSVC. Моими любимыми являются Edit-and-continue и Set Next Execution
>Statement. В новейшем IDE от SUN вроде есть подобное, 5 лет спустя, между прочим...

А как у MS компилятора обстоят дела с partial template specialization ? Что то изменилось или до сих пор не поддерживается ?

--
With best wishes,
Nick.

bugfixer ★★★★★
()

2anonymous (*) (2002-05-02 11:10:58.878)

Это сильно, впечатляет.
За исключением редких моментов, когда ИМХО достоинства жабы были объявлены недостатками (ну это чисто ИМХО)
я полностью согласен с текстом.

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

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

2 bugfixer: >А как у MS компилятора обстоят дела с partial template specialization ? Что то изменилось или до сих пор не поддерживается ?
Нет, не поддерживается. ServicePack'и не меняют уровень совместимости со стандартом. Если в visual studio.net есть компилятор C++, то для него тоже ничего не изменилось. Однако, MS наняла секретаря ANSI/ISO C++ комитета и вообще довольно известного типа (Herb Suttler), дабы продвигать, насколько я мельком понял, будущие версии VC++ к совместимости со стандартом.

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

А я слыхал (правда из субьективного источника) что дела с C++ в vs.net стали еще хуже, типо какие-то фичи доступные раньше в vs.net урезали причем только для C++ а для VB и C# эти фичи есть. И заключение там делалось такое что MS пытается пересадить на свои языки VB и C#.

anonymous
()

>> А как у MS компилятора обстоят дела с partial template
>> specialization ? Что то изменилось или до сих пор не поддерживается ?

>Нет, не поддерживается.

Ну так и как же тогда можно говорить что он (MSVC) весь такой из себя распрекрасный и удобный? Я к тому что никакие рюшечки IDE не заменят _нормального_ компилятора. А отсутствие поддержки PTS еще прямым образом влияет на качество имплементации STL (далеко не лучшим образом). Если честно, я даже сейчас сходу представить себе не могу как красиво заимплементить многие вещи без PTS. (например vector<T*>, iterator_traits итд итп). Ну с другой стороны - это личное дело каждого, чем пользоваться ,)

--
With best wishes,
Nick.

bugfixer ★★★★★
()

2 Африканец (2002-05-02 11:10:58.878)

Действительно, интересно написано (хотя и не понятно, как это относится к субж. :) Видать - накипело...)

Я согласен с *anonymous (2002-05-03 03:47:48.637)* - почти всё в этом эссе сказано в тему. Правда, я его читал как человек предвзятый - поработал на этой Жабе некоторое время, и терпеть её ненавижу. Всё же мое первой и Большой любовью остаётся С/С++. Именно так - в симбиозе.

2 alexnav (*) (2002-05-02 10:59:22.545)

> Про IDE от SUN. Вы имеете в виду Forte? Возможно вы и правы, я просто не задавался этим вопросом :))) Потому как у меня IDE выглядит как > XEmacs+Suncc+dbx(это дебагер от Сан с намордником в виде DDD) либо > XEmacs+пcc+gdb(с намордником в виде DDD) :))))) И всё это там есть давно. Хотя если честно, пользовался я этим ну очень не часто. :)))

Я и сам предпочитаю именно DDD, когда сижу под Юниксом. Но какое же это всё же убожество, рядом с MSVC ;)

Ещё одну хорошую особенность именно MSVC отладчика вспомнил: родная поддержка UNICODE строк в дебагере. Сильная, знаете ли, вещица. В DDD я аналога не видел (и страдаем мы все от этого в нашей конторе сильно).

2 all:

А что у нас на других Юникс платформах имеется, сравнимое с DDD под Solaris?

Мы пользуем: на HP - wdb на AIX - xldb

Но ни тот, ни другой, даже с DDD ни в какое сравнение не годятся :(

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

2 YePhIcK (*) (2002-05-03 07:52:07.866)
>>> Но какое же это всё же убожество, рядом с MSVC ;)
эээ я лучше расценю это как шутку, :) судя по смайлику.

>>> Ещё одну хорошую особенность именно MSVC отладчика вспомнил:
>>> родная поддержка UNICODE строк в дебагере. Сильная, знаете ли,
>>> вещица.
Вот это точно шутка. Потому как пример у меня на соседнем столе у
коллеги стоит. Вводная: Win2k (fr) + MSVC (en)
Ну а сообщения в output/дебаг window - это вообще смех один. Все буквы с аксантами заменены на черный квадрат. И хоть ты заменяйся кодовые таблицы/шрифты... результатов 2 - либо с квадратиками либо вообще падает (иногда вместе с виндами :))).

>>> А что у нас на других Юникс платформах имеется, сравнимое с DDD
>>> под Solaris? Мы пользуем: на HP - wdb на AIX - xldb
DDD :-{))))))))
цитата: "GNU DDD is a graphical front-end for command-line debuggers such as GDB, DBX, _WDB_ , Ladebug, JDB, XDB, the Perl debugger, or the Python debugger. Besides ``usual'' front-end features such as viewing source texts, DDD has become famous through its interactive graphical data display, where data structures are displayed as graphs." (http://www.gnu.org/software/ddd/)

alexnav ★
()

тут кто-то написал что мол за С++ не видно дизайна, а за жабой видно...

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

кто не в курсе --- идут читать "дизайн и эволюция С++"

PS. всякие детские вопли про "проектирование/дизайн С++ с нуля и без груза С" в сад ибо он тогда бы не был _С_ ++

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

2anonymous (*) (2002-04-30 19:51:26.466)

>Вы сделали это нанесли мне оскорбление 

Я не хотел никого оскорблять.

Извините. Если я Вас чем то задел - Это произошло невольно.
Еще раз Извините. Любое свое высказывание, которое Вас задело прошу считать не высказанным. 
 
>у Вас хватает наглости сказать, что тут пытаются воровать Ваши идеи. 

Может я ошибаюсь ( в таком случае заранее извиняюсь), 
но мне кажется, что приведенная выше трактовка моих
слов - по-меньшей мере слишком прямолинейна, неконкретна,
приводится с добавлением терминов (слов, например слово "идеи") которые я не писал.
Кроме того этот мессаг (из которого Вы вольно трактуете мои слова)
вообще не Вам.


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

Да никто и не собирается. 
Слишком много зависит от конкретики.
Тов. АС не захотел это услышать (хотя было сказано почти прямо)
Поэтому мой ответ тов. АС и был таким эмоциональным 
( и дело совсем не в возрасте)

>"нахаляву узнать" - это принцип НАУКИ

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


2АС Перед Вам я так же извиняюсь.
Согласен со всем, что Вы говорите и думаете.
( В том числе обо мне)
 

Bear

P.S.
В одной книженке прочитал:
"Женшина добивается своего не столько тем, что она говорит,
сколько тем, сколько раз она это говорит."

P.P.S.
большая часть населения действительно 
живет "инстинктами".
Всякая часть общества моделируется его групой.
"Физически бесконечно малой группой"
Ибо переход к пределу приводит к другой мере 
и понятен далеко не каждому человеку с дипломом физика.

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


Еще раз Bear.

Все мои постинги, были подписаны непрсредственно 

Bear

anonymous
() 

Главное - это себя убедить, что был прав.
Благо это легко и почти никто не заметит, что бредил.
А кто заметит не захочет связываться.


Как прав был Ю.Семенов и Штирлиц вместе с ним:
"Невозможно работать. Развелось много идиотов,
говоряших правильные слова".

Это я никого не оскорбляю. 
Оскорбление - это когда плохо и неправду 
о других говорят.

Bear

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

>Слишком много зависит от конкретики.
Особенно классно это сочетается со следующими фразами:
"Для численного счета не нужны навороты!!! Классы и шаблоны и перегрузку надо использовать для управления окруженим(по моему мнению) иначе Вы терете производительность." (ну очень конкретное утверждение)
"Я думаю, что так лучше и быстрее и надежней. Я даже уверен, что my way is the best"
"всех известных мне случаях мой код работает _не_ медленнее любого другого."
И столько типа умных фраз и типа тонких намеков...

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

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

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

А я уже 500-ый... вот бы так быстро программы писали как тут языком по клаве ореплют, лепота была бы :-))

anonymous
()

Вот нашёл Африканца и его опус на http://www.javapower.ru/java/frog.htm Интересно, что в конце есть два линка - первый, чтоб отправить автору мыло; второй, чтоб узнать где был взят оригинал в далёком 1998 году. И так имеем - mailto:Pasha.Zemtsov@datavoice.co.za и http://www.anekdot.ru/ соответственно. Да, совсем забыл... там же, но вначале есть линк на обсуждение Африканца - http://www.javapower.ru/java/frog_res.htm очень советую почитать.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 7 8 9 10 11 12 →
Проприетарное ПО