Почему гуру выбирают си

>Я ж смайл влепил! Извини, если задел...

Фигасе, тут какая-то рекурсия получается! :D

Ладно, я спать. Всем спокойной!

> Разве PyQt использует message passing?

Ну да!

Оно так не называется, правда, но суть от этого не меняется: надо взять объект на одном языке, посвистеть, результат передать из/в интерпретатор, опять посвистеть, и только потом продолжать. Да, а когда оно в Питон передается, надо еще и интерпретатор рекурсивно позвать...

Избежать прохода всего этого через ядро возможно лишь потому, что сам Питон на Це написан, и КуТевые расширения с ним без проблем линкуются.

> посвистеть, результат передать из/в интерпретатор, опять посвистеть, и только потом продолжать

Я не понял, чем это отличается от, скажем, PyGTK или любой обернутой либы, ну да ладно...

Кстати, вот ещё вариант, хотя такой подход многие считают грязным, но, тем не менее.. При знании C и С++ использовать так называемый гибрид - "C с плюсами". Иной раз бывает полезно.

> ...Я не понял, чем это отличается от, скажем, PyGTK или любой обернутой либы,...

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

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

Впрочем, поскольку ядра всех рантайменвайрментов написаны на Це, всегда можно написать соответствующее расширение -- оять-таки на Це! -- которое позволит клепать обертки для Це/ЦеПП либ так, чтобы не гонять данные через ядро операционки. Но внутреннее представление данных придется конвертировать туда - сюда по некоторому протоколу...

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

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

Это так, но 1) это плата за более высокий уровень языка 2) обернуть Си++ в Си - задача тривиальная 3) SWIG - наше ффсио.

Думаю, что вызвать Хаскель из Лиспа потруднее будет :)

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

ЗЫ все мои реальные задачи требовали си+стл+(иногда)исключения.

> генерить исключения - самоубийство

А зачем их генерить? Весь Qt прекрасно без них обходится.

>А зачем их генерить? Весь Qt прекрасно без них обходится.

про qt-шный бред с moc - отдельный разговор.

2generatorglukoff:

> ...все мои реальные задачи требовали си+стл+(иногда)исключения.

Часто СТЛ -- зло.

>> генерить исключения - самоубийство

>А зачем их генерить? Весь Qt прекрасно без них обходится.

Да. обходится. Но не прекрасно. Это им вожжа под мантию попала.

>>А зачем их генерить? Весь Qt прекрасно без них обходится.

> про qt-шный бред с moc - отдельный разговор.

>generatorglukoff

Оно и видно. это как-бы перпендикулярные темы...

>>> Ко многим интерпретируемым языкам есть биндинги.

>> Через высокие протоколы и мессадж пассинг.

> Разве PyQt использует message passing?

Для связи Qt-PyQt не использует. спи без кошмаров :)

>Часто СТЛ -- зло.

а насколько часто? предлагаешь переписывать все основные алгоритмы с нуля?

Прочитав топик я выделю основные минусы С++:
1. name mangling, binary incompatibility
2. полумистические "принципы юникса"
3. сложность
4. "убогость" ООП (я так понимаю, Smalltalk (CLOS) это вершина эволюции, всё остальное убого)
5. что-то связанное с исключениями (забавно, что исключения работают немного быстрее чем код с проверками возвращаемого значения, когда исключения не бросаются)
6. СТЛ (которое по сути в хорошем компиляторе не отличается от макросов с точки зрения производительности)

по-мне - реальный минус - #1. Значим он или нет - зависит от задачи.

> ...предлагаешь переписывать все основные алгоритмы с нуля?

Спорный вопрос...

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

Сделали бы давно "Сборник Стандартных Описаний", откуда каждый писатель мог бы взять каноническую версию и, подставив параметры (названия мест/ имена своих героев), не тратить время на очередное изобретение велосипедов, а сосредоточиться на детальной проработке сюжета... Думаю, массовая литература от такого только выиграет!

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

> СТЛ (которое по сути в хорошем компиляторе не отличается от макросов с точки зрения производительности)

Ну, с точки зрения производительности СТЛ не отличается от макросов в любом компиляторе...

А можно тогда узнать чем конкретно не устраивает класс std::vector ? И ситуация, в которой может потребоваться его переписывание?

che za bred? O_o

IMHO, всё нытьё об убогости С++ исходит от неасиливших этот самый С++. _Язык_ выбирается _под_задачу_.

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

>>Что-то я сомневаюсь в твоем :Е

Так я и написал сюда, так как понимаю различие этих языков, если бы я не понимал я бы остался на мнении, что с++ продолжение си.

Пусть гуру выберают си, а кому надо работать, выбирают объектный паскаль за четкий, ясный язык, за реальную переносимость, за быстроту компиляции, никаких тебе мейкфайлов. Все это на самом деле экономит время и позволяет писать безглючные программы, которые не выпадают в segfault при каждом чихе...

>Пусть гуру выберают си, а кому надо работать, выбирают объектный паскаль за четкий, ясный язык, за реальную переносимость, за быстроту компиляции, никаких тебе мейкфайлов. Все это на самом деле экономит время и позволяет писать безглючные программы, которые не выпадают в segfault при каждом чихе...

Как уже писалось выше: надо писать простой код для работы с простыми данными и простой код для перевода сложных данных в простые. Простой код на всех перечисленных языках выглядит примерно одинаково.

"Кому надо" не видят отличия между мейкфайлом и компилятором? Впрочем, и так понятно, что за "чёткость и ясность" объектного паскаля его адепты расплачиваются собственным IQ ;)

GLib b glibc - сегодня смотрел, там практический все что в том же самом с++. Что мне еще нравиться в с++ это namespaces.

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

И что же выбирать, если не то и не то? На чем же наши русские программировать собираются?

na Lispe. hehe.. :)

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

Полгода назад разместил на нескольких подобных сайтах своё резюме (unix/linux c/c++), через месяц убрал. Звонят до сих пор. Предлагают з/п в диапазоне $1.5-3k в сферах деятельности от dsp/embedded до околобиржевых дел через касперских, др.вебов и т.п.

Вывод: кто ищет, тот найдёт. Но с тем фактом, что за бугром юникс и си гораздо востребованней - согласен.

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

Гуру всегда выбирают сиси.

>Думаю, массовая литература от такого только выиграет!

Массовая - возможно. Иначе - сравнение прибора с пальцем. Сразу видно, оратор с классическими произведениями не знаком. :Е

Про сравнение русского (впрочем как и _любого_ друго ествесственного языка) умолчу, это вообще диагноз.

.. про сравнение с языком программирования, конечно же. )

Чушь это. А работу искать по каким-то сайтам не надо, за тебя должно это делать агенство, тогда с поиском работы unix/c++ за >3k$ никаких проблем не будет.

> чем конкретно не устраивает класс std::vector ?

Очень хороший пример.

"Умный" массив настолько часто нужен, а соответствующие операции настолько часто являются узким местом, что применение std::vector в прогах, претендующих на оптимальность, в половине случаев просто невозможно. С другой стороны, в каждом конкретном случае реализация нужной функциональности настолько тривиальна, что не стОит трудов по инстанцированию вектора.

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

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

Но самое неприятное -- в большинстве алгоритмов требуется совершенно конкретное специализированное управление памятью.

> И ситуация, в которой может потребоваться его переписывание?

Как раз сейчас производим операцию по снятию коллег с этих граблей.

Прога, решающая сотни миллионов линейных уравнений. Коэффициенты -- отношения полиномов над целыми неорграниченной длины. Мужики уравнения сделали СТЛными векторами. Естественно, уперлись в присущую ГНУтой либЦе проблему фрагментации памяти.

Полгода секса с ислледованием проблемы и прикручиванием левых маллоков через ЛДпрелоад ни к чему не привели: либо фрагментируется, либо слишком медленно. Наконец, переписали со своим вектором вместо std::vector -- почти в точности повторили его (упрощенно, конечно), только памятью "вручную" рулят -- вроде, начало работать...

Сэкономили пару часов (ок, дней) на СТЛ -- потеряли полгода...

> Про сравнение русского (впрочем как и _любого_ друго ествесственного языка) умолчу, это вообще диагноз.

Это я такую темплату заюзал, чтобы у лишенных юмора анонимусов от перенапряжения извилины не заклинивало :-). Аналогия называется.

> а кому надо работать, выбирают объектный паскаль за четкий, ясный язык, за реальную переносимость

Плакаль =)

> ...с тем фактом, что за бугром юникс и си гораздо востребованней - согласен.

Ну, в Германии наблюдается то же самое. Студенты - информатики последней выпечки не хотят ЦеПП юзать, плюсовый софт массово переписывается на ЦеШарп, новые проекты (из типично Жабкиной ниши) почти все начинаются на ДотНЕТе...

Спасибо за примеры буду думать :)

> Наконец, переписали со своим вектором вместо std::vector -- почти в точности повторили его (упрощенно, конечно), только памятью "вручную" рулят

По-моему в STL изначально закладывалась эта возможность в виде custom allocators - и не надо переписывать вектор.

ну так у СТЛ контейнеров есть параметр -- аллокатор. Можно obstack-like аллокатор зафигачить, самый мной уважаемый аллокатор..

У меня такое ощущение, что >Die-Hard (*) (05.08.2007 15:12:36) что-то недоосилил. :]

> Прочитав топик я выделю основные минусы С++:

> 1. name mangling, binary incompatibility

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

> 2. полумистические "принципы юникса"

глупость. слышал звон да не знаю где он.

> 3. сложность

да, C++ как инструмент достаточно сложен.

> 4. "убогость" ООП (я так понимаю, Smalltalk (CLOS) это вершина эволюции, всё остальное убого)

глупость, помноженная на красноглазие.

> 5. что-то связанное с исключениями (забавно, что исключения работают немного быстрее чем код с проверками возвращаемого значения, когда исключения не бросаются)

глупость помноженная на банальное неумение использовать исключения.

> 6. СТЛ (которое по сути в хорошем компиляторе не отличается от макросов с точки зрения производительности)

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

// wbr

> в STL изначально закладывалась эта возможность в виде custom allocators - и не надо переписывать вектор.

Тот боттлнэк так и нашли -- подсунули хитрый аллокатор, и посмотрели на то, что происходит.

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

> для проекта, написанного на С++ это явно не аргумент

проектом может быть библиотека, которую требуется использовать в разных языках, в этом случае это вполне аргумент. Проблемы также могут возникнуть при использовании классов в динамических библиотеках.

> STL - это всего лишь библиотека расширения, не более того. одна из массы других библиотек.

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

И, тем не менее, redhat и novel открывают в Европе дополнительные центры разработки, куда сотни сишных линуксовых программистов нужны.

> По-моему в STL изначально закладывалась эта возможность в виде custom allocators - и не надо переписывать вектор.

А чего тогда в boost::shmem (ныне boost::interpocesses) наклёпаны свои реализации самых попсовых контейнеров, работающих в расшаренном сегменте с кастомным аллокатором?

Кроме того, на этом самом shmem можно родить такого крокодила, на написание и отладку которого времени в 5 раз больше уходит, если всё делать вручную через mmap.

>> STL - это всего лишь библиотека расширения, не более того. одна из массы других библиотек.

> Это стандартная библиотека, поведение и требования к которой строго зафиксированы, чего нельзя сказать о массе других библиотек.

Только частные реализации этого стандарта не совместимы на 100% между собой, а также, зачастую, прибиты гвоздями к конкретному компилятору.

> redhat и novel открывают в Европе дополнительные центры разработки, куда сотни сишных линуксовых программистов нужны.

А в России такого нет разве?

Это ж капля по сравнению с потребностями в Оффтопике...

> Тот боттлнэк так и нашли -- подсунули хитрый аллокатор, и посмотрели на то, что происходит.

Инженеры эти, вероятно, были хорошими математиками, но плохими программистами, ибо не читали Мейерса. А без чтения груды макулатуры, как известно, на С++ хорошую программу не напишешь. Тот же Мейерс объясняет, почему, по его мнению, многие возможности С++ в реальной жизни использовать не стОит ;-)

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

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