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

кому что важнее - пусть выбирает сам. любители попкорна - выбирают Java, цэпэпэ, оффтопик и кока-колу !! да здравствует выбор, anway !

>кому что важнее - пусть выбирает сам.

Тогда зачем ты здесь? LOR'овская семантическая машина настроена на то, чтобы убеждать посетителей в чём-то конкретном и прямом. О самостоятельном выборе не может быть и речи, так как такой выбор заведомо неверен!

>Бугагага. А в Qt например используется множественное наследование?

Да. Очередной сурприз? :)

> Читатели заметят что нам есть что сказать в главе 3 о локальном состоянии , но мы ни разу не упоминаем классы и наследование. Мы подозреваем что на самом деле эти проблемы нельзя рассматривать только в терминах проектирования языков программирования, без обращения к работам по представлению знаний и автоматическому логическому выводу

Что за книга?

То что автор подозревает -- по-моему вообще очевидно.

Видимо "подозреваю" -- это такой оборот речи, чтобы не доказывать то, что доказать действительно сложно.

> Ага, тоесть ЯП нужен что-бы его годами изучать, захлебываясь слюной обсуждать на РСДН костыльную реализацию темплейтами казалось бы простых фич, которые должны быть встроены в язык напрямую и приносить в полнолуние жертвы Александреску?

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

Впрочем, метапрограммирование в плюсах надо переделать немного.

> которые должны быть встроены в язык напрямую

Это правда. Замыканий (не кривых) в плюсах нет, они нужны, это видно было не меньше 15 лет назад, и вот наконец их все-таки сподобились предложить в стандарт...

> С тех пор я довольно подозрительно отношусь к преимуществам C++ перед C. Хороший программист легко обойдется без наворотов C++.

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

Выход я в вижу в синтаксически ориентированном макропроцессоре или в метапрограммировании поверх С.

>Если команда более чем из двух программистов, если у цели более чем 2 версии, если это не драйвер под космическое оборудование - чёрта с два вам позволят всунуть туда С++.

Вот тебе пример: SIP-клиент. Команда --- много больше, чем 2 человека. Версий --- много больше, чем 2 (емнип, около 5 разных параллельно разрабатываемых). Ни разу не драйвер, как сам понимаешь. Но вот в чём закавыка: сначала это была именно жаба, ибо там сидели такие же "умники", как и ты :) Предлагаю угадать с 3-х раз, на чём он пишется сейчас ;)

> Я не говорю уже о том что в каждом С++-фреймворке почитают за честь завести свой смарт-указатель из-за чего на границах модулей надо иметь перефасовочный код, который не делает ничего полезного.

Ты где берешь критику плюсов? Иногда она у тебя бывает по делу.

я и есть "LOR'овская семантическая машина"(r), глупый !! а убеждаю я в сравнительно простой вещи - самореклама должна быть если не конструктивной, то хотя бы мало-мальски содержательной. пример - проведите паралели между содержимым книги и речугами г-на Страуса. И вы увидите в лучшем случае "синус", вместо паралелей.

> Вот тебе пример: SIP-клиент. Команда --- много больше, чем 2 человека. Версий --- много больше, чем 2 (емнип, около 5 разных параллельно разрабатываемых). Ни разу не драйвер, как сам понимаешь. Но вот в чём закавыка: сначала это была именно жаба, ибо там сидели такие же "умники", как и ты :) Предлагаю угадать с 3-х раз, на чём он пишется сейчас ;)

Неужели на Delphi ? )

>Троллизм в моем понимании - это когда в топике про [SubjA] говорить, что "оно сасьод, а рулитЪ [SubjB]", а я сейчас на стороне обиженных, убиваю свое время =)

Но я и не говорю, что C++ сосёт. Просто у него специфическая область применения, причём во многих случаях C++ не является единственной альтернативой.

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

>я наверное без поиска и не скажу, что это такое )))

Сходите уже по ссылкам новости :)

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

Можно, но сложнее. Всё-таки чистый C проще C++.

>это же ТУПО!!! или вы несогласны? )))
Но тем не менее
>а я сейчас на стороне обиженных, убиваю свое время =)
Это же тоже ТУПО, или вы не согласны?

Пришли оба потупить и поубивать время :)

>А преимущества от управляемости кода весьма сомнительны (и это показал тот факт что джава существует с 93(!) года), многие вещи, даже контроль утечек памяти, контроль границ массивов удалось реализовать на c++.

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

>Кстати в c++ можно пользоваться обычными указателями, а для контроля утечек использовать специальные анализаторы кода.

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

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

Кстати вируальная машина в Java непонятно с какого перепугу взялась, я считаю это чистым маркетингом. Если бы Java не имел этого тяжелого камня на шее, мне кажется он значительно сильнее потеснил бы C++.

>> Я не говорю уже о том что в каждом С++-фреймворке почитают за честь завести свой смарт-указатель из-за чего на границах модулей надо иметь перефасовочный код, который не делает ничего полезного.

>Ты где берешь критику плюсов? Иногда она у тебя бывает по делу.

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

>Не знаю ни одного серьезного приложения, написанного на джаве.

У моего провайдера биллинг на Java написан.

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

Реализацию исключений на С в студию! Потом реализацию вызова деструктора при выходе из области видимости, в том числе при исключениях.

>Правда Гугловые сервисы написаны на плюсах - но это совсем экзотика.

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

> частный случай из частного ТЗ

Таких частных случаев - прорва задач, где надо именно решение, а не поиск утечек памяти. Ну да ладно. Возьмем более популярную задачу - пользовательский интерфейс. Задача великолепно решается специализированными средствами, например, тиклем или XML. Или SQL. Каким боком тут можно использовать С++ в качестве языка предметной области?

> Не используй на плюсах ооп -- код будет того же размера как и на с

А смысл тогда использовать С++, если все его преимущества идут лесом?

>> С тех пор я довольно подозрительно отношусь к преимуществам C++ перед C. Хороший программист легко обойдется без наворотов C++.

>1 хороший прогаммист. А если их много, тогда в С захочется хотя бы приватных членов структур, как это (естественно!) захотелось гномерам.

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

>Выход я в вижу в синтаксически ориентированном макропроцессоре или в метапрограммировании поверх С.

А я вижу выход в делении программ на модули (объекты/библиотеки) с ясными хорошо описанными интерфейсами и с предельным сокрытием деталей реализации, того что находится за этим интерфейсом. C/C++ для таких целей не очень подходят, в них по сути модульности-то нет, одна лишь раздельная компиляция. В h-файлах обязательно вылазят ну хоть какие-то лишние детали реализации интерфейса.

открой для себя pimpl

> открой для себя pimpl

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

>причём во многих случаях C++ не является единственной альтернативой.

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

>Можно, но сложнее. Всё-таки чистый C проще C++.

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

>>а я сейчас на стороне обиженных, убиваю свое время =) >Это же тоже ТУПО, или вы не согласны?

нет, это благородно и повышает мое ЧСВ =)

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

>Реализацию исключений на С в студию!

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

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

При выходе из области видимости переменная тупо удаляется из стека. Если хотите произвести над переменной какие-то действия - нужно сделать это явно. Также как в С++ объект созданный оператором new должен быть вовремя удалён вызовом delete.

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

Я не пытаюсь всех пересадить с C++ на C. Просто по моему мнению C++ занимает какое-то промежуточное положение между C и Java/Python. То есть во многих случаях вместо использования C++ логичнее выбрать язык либо на уровень ниже либо на уровень выше или использовать смесь языков. Критические по производительности вещи писать на C, а пользоваться ими на более высоком уровне из Python/Java. Если посмотреть на C++ в таком разрезе, становится понятно, что этот язык не №1, не маст хэв и не киллер всех языков.

> Кстати, увеличение частоты процессора (замена Athlon X2 3800+ на 5400+) время компиляции предыдущей сборки OOo 2.4.1_1 не уменьшилось!

Use ccache, Luke!

>> Кстати, увеличение частоты процессора (замена Athlon X2 3800+ на 5400+) время компиляции предыдущей сборки OOo 2.4.1_1 не уменьшилось!

> Use ccache, Luke!

Тупая трата ресурсов. Тот же D компилируется на порядок быстрее.

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

И в С++ то же есть! А вообще сигналы - палатформоcпецифичная штука, поэтому не катит

>>причём во многих случаях C++ не является единственной альтернативой.

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

Так и я не утверждаю этого.

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

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

>нет, это благородно и повышает мое ЧСВ =)
Симметрично не отвечу, и не ждите :P

Re^2: Страуструп о будущем семантических средств разработки с комментариями

> На C++ используя библиотеки и шаблоны можно писать ЛЮБОЕ приложение так же эффективно, как и на узкоспециализированном языке. За исключением областей, где C++ почти совсем не используется. Чтобы не написать глюкогенную неподдерживаемую муть нужно имень квалификацию выше.

А вот это мне уже интересно. Покажи-ка как на плюсах писать элегантные гуйки.

Re^2: Страуструп о будущем семантических средств разработки с комментариями

>>Множественное наследование

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

Да-да, а зачем тогда то там, то тут в языках без множественного наследования появляются то несколько аггрегированных подклассов, то в язык вводится понятие partial classes?

Re^2: Страуструп о будущем семантических средств разработки с комментариями

>>Бугагага. А в Qt например используется множественное наследование?

> Да. Очередной сурприз? :)

И давно там можно делать множественное наследование классов, наследованных от QObject? В 4.1 точно нельзя было.

В gtkmm можно. От базового класса идет виртуальное наследование.

Re^2: Страуструп о будущем семантических средств разработки с комментариями

> Угадай какой? Java! В 96 году бесплатный компилятор с бесплатной ВМЕНЯМОЙ библиотекой и бесплатным ВМЕНЯЕМЫМ GUI.

> ПС. С другой стороны тогда бешенной популярностью пользовался Visual Basic. Он первый предложил доступную IDE с доступной библиотекой и доступным GUI по доступной цене (в т.ч. и бесплатно). Причем сделал именно ПЕРВЫМ - в 91 году.

Библиотека Tk была написана в 90 году. Так что бижуал васик отнюдь не первый.

Не тупи. VB предложил еще и IDE.

> Библиотека Tk была написана в 90 году. Так что бижуал васик отнюдь не первый.

Просили, чтоб обязательно ООП

>И в С++ то же есть! А вообще сигналы - палатформоcпецифичная штука, поэтому не катит

Сигналы есть в ANSI C. Если на какой-то платформе заявлена поддержка стандарта, поддержка сигналов там обязана быть.

Re^2: Страуструп о будущем семантических средств разработки с комментариями

> От ООП в С++ толку нет - реюзаемость кода почти нулевая. Это в Жаве можно воткнуть половину апачевских библиотек в проект и не думать что там могут быть какие-то утечки или SIGENV'ы или прочая муть.

Угу, только следить за тем, что в многопоточной программе внезапно окажется, что vfs работает только если каждую операцию прикрыть мьютексом, а некоторые файлы лочатся пока мусорщик финализатор не дёрнет. Или что листинг по ftp не работает, если внезапно появится очень большая директория и в разборе вывода ls в нужном месте не окажется пробела.

Это всё не утечки. Но тоже весьма противные баги. Так что из огня да в полымя

Re^4: Страуструп о будущем семантических средств разработки с комментариями

> Не тупи. VB предложил еще и IDE.

Ты имел в виду "визуальное IDE"?

Для тк не редактор форм излишен, а для тикля code assistant-ы не нужны. Так что всё что нужно было.

Re^4: Страуструп о будущем семантических средств разработки с комментариями

>> Библиотека Tk была написана в 90 году. Так что бижуал васик отнюдь не первый.

> Просили, чтоб обязательно ООП

А зачем? Лично я не вижу преимуществ в том, чтобы делать иерархию классов контролов. Всё что в других языках требует ооп для этой задачи, в тикле делается без оного за счёт динамичности языка.

> А зачем? Лично я не вижу преимуществ в том, чтобы делать иерархию классов контролов.

Я тоже не вижу. Но челу захотелось чтоб и ООП, и чтоб ГУИ. И чтоб в 90-х. Потому и не ответил про тикль. хотя привел тикль в пример в другом посте

>>Бугагага. А в Qt например используется множественное наследование?

>Да. Очередной сурприз? :)

Множественное наследование в С++ связано с RTTI, а RTTI в Qt я так понимаю свой ввиду куцости дефолтного.

>> Библиотека Tk была написана в 90 году. Так что бижуал васик отнюдь не первый.

>Просили, чтоб обязательно ООП

Плюсовое ООП для гуйков подходит слабо - виртуальными функциями C++ для создания хандлеров типа onPaint или onMouseMove не пользуется никто.

>> открой для себя pimpl

>Открой для себя лишние выделениея памяти в куче благодаря pimpl. Не катит для универсального способа, ну никак.

Кроме того, написание pimpl - это еще одно место в С++ где надо писать инфраструктурный код который не делает ничего полезного.

> Плюсовое ООП для гуйков подходит слабо

я знаю. Но в первоначальном посте речь шла о том, что кроме жабы в 90-х ничего, чтоб и ООП, и Гуи, и бесплатно не было. Правда то, что ООП в гуи не очень в тему, чела не интересовало, но то другой вопрос.

>Но в первоначальном посте речь шла о том, что кроме жабы в 90-х ничего, чтоб и ООП, и Гуи, и бесплатно не было.

Оригинальный AWT честно говоря ужасен. Более-менее пристойны SWING и SWT, но они появились позднее.

> Если я хорошо знаю С++ и STL, то в принципе могу начинать работать.

На голом С++ и STL и совсем без "окружения"? И что вы будете делать - писать свои 48 велосипедов с квадратными колёсами?

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

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

>На C++ используя библиотеки и шаблоны можно писать ЛЮБОЕ приложение так же эффективно, как и на узкоспециализированном языке.

Покажи, как твои кресты сравняются по эфективности работы с текстом с регекспами и в работе с реляционными БД с SQL.

Читаем до конца:

> Это помимо общих знаний или знаний в области, в которой собираюсь работать.