LINUX.ORG.RU

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

 ,


2

0

У Страуструпа имеется книжка о развитии и о будущем средств разработки для языка C++, "Дизайн и эволюция языка C++", в частности о поддержке семантического программирования. Интерес представляют комментарии к книге данные Евгением Зуевым, одним из известных советских программистов и разработчика компилятора C++.

Отредактировано anonymous_incognito

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

anonymous

Проверено: anonymous_incognito ()
Ответ на: комментарий от Sidrian

> Дело в том, что я не только не крестовик и не жабакодер, я еще и не физик :)

Отчего же. В нашей школе стояла ДВК-2. Из общедоступных компиляторов там были трансляторы с языков Си, Паскаль и Фортран. Еще был бейсик и даже фиг-форт. Но суть в том, что когда-то фортран знали многие.

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

>Отчего же. В нашей школе стояла ДВК-2. Из общедоступных компиляторов там были трансляторы с языков Си, Паскаль и Фортран. Еще был бейсик и даже фиг-форт. Но суть в том, что когда-то фортран знали многие.

У меня в школе и на первом курсе изучали программирование с примерами на паскале. Жалко что не на Схеме, как в странах с нормальной системой образования, но вот про отсутствия там Фортрана я если честно не сильно жалею :)

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

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

В наше время его обычно не знали, а сдавали на нем лабы.

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

>>А вы значицца, за весь эмбед расписываетесь.

>Так я вроде не абстрактным эмбедом в вакууме занимаюсь.

А другие в вакууме живут, ничего не знают, ни с кем не разговаривают.

>куда бы там тебе предложили засунуть кресты?

Так а чего от вам подобных ожидать? Прям как в анекдоте: "Не люблю я кошек, от них запах, шерсть! -- Вы просто не умеете их готовить!"

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

>>Ой правда, что ли? А чем void (*)(void* handback, int percentDone) в C будет отличаться от того же в C++?

>В ООП языке чтобы сделать такую простую фичу надо воспользоваться Си-указателем на функцию и протаскивать указатель на объект через void*. Зашибись.

А что -- религия не позволяет? С++ -- это гибридный язык. И если вам для получения 2*2 требуется использовать ООП и шаблоны, то C++ здесь ну совершенно не причем.

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

>Так а чего от вам подобных ожидать? Прям как в анекдоте: "Не люблю я кошек, от них запах, шерсть! -- Вы просто не умеете их готовить!"

Логика на уровне детского сада: "Все, кто не любит кресты - плохие бяки". Так и запишем: у пациента наблюдается замедленое развитие.

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

> Да и с библиотеками для них не все хорошо -- для C/C++ всяких разных библиотек гораздо поболее будет.

Вот только не надо в одну кучу валить С и С++. У первого библиотек действительно много, но и работать с ними могут все "вменяемые" языки.

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

>>>Ой правда, что ли? А чем void (*)(void* handback, int percentDone) в C будет отличаться от того же в C++?

>>В ООП языке чтобы сделать такую простую фичу надо воспользоваться Си-указателем на функцию и протаскивать указатель на объект через void*. Зашибись.

>А что -- религия не позволяет? С++ -- это гибридный язык. И если вам для получения 2*2 требуется использовать ООП и шаблоны, то C++ здесь ну совершенно не причем.

Это на самом деле важно - как на С++ надо проектировать интерфейсы. Использовать char* либо тащить несколько десятков килобайт шаблонов для std::string. Использовать void(*)(...) либо тащить еще несколько десятков килобайт буста. Зашибись альтернативы.

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

>>Так а чего от вам подобных ожидать? Прям как в анекдоте: "Не люблю я кошек, от них запах, шерсть! -- Вы просто не умеете их готовить!"

>Логика на уровне детского сада: "Все, кто не любит кресты - плохие бяки".

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

>Так и запишем: у пациента наблюдается замедленое развитие.

В моем случае это уже скорее старческий маразм. Не приписывайте пожилым людям свои детские болезни.

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

>> Да и с библиотеками для них не все хорошо -- для C/C++ всяких разных библиотек гораздо поболее будет.

>Вот только не надо в одну кучу валить С и С++.

Почему же? Опять религиозные предпочтения?

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

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

>>А что -- религия не позволяет? С++ -- это гибридный язык. И если вам для получения 2*2 требуется использовать ООП и шаблоны, то C++ здесь ну совершенно не причем.

>Это на самом деле важно - как на С++ надо проектировать интерфейсы. Использовать char* либо тащить несколько десятков килобайт шаблонов для std::string. Использовать void(*)(...) либо тащить еще несколько десятков килобайт буста. Зашибись альтернативы.

В C++ у вас есть выбор. Что в этом плохого?

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

>Тогда уж так: те, кто не любят C++, не умеют на нем работать, да и вообще его не знают, но много тролят о том, какой он хреновый -- плохие бяки.

Вы лучше еще попердите в лужу о ордах девелоперов кернела и мировом доминировании крестов, забавно читать.

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

> а на С++ - писать красивые и выразительные исходники

4.2.

Можно на чем угодно писать красиво и выразительно, если руки прямые и если семантика предметной области не очень сильно по структуре своей отличается от семантики используемого языка программирования. Кривые исходники получаются или у дураков (вырожденный случай, не рассматриваем), или если язык употребляется не по назначению. Если надо на низком уровне жонглировать указателями и битики тасовать, с элементами ООП и generic programming для красоты - то C++ вполне уместен. Если надо решать системы логических уравнений, или GUI рисовать, или участки ДНК сравнивать - тогда C++ конечно же будет некрасив (я не говорю "неэффективен" - именно некрасив).

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

> У меня в школе и на первом курсе изучали программирование с примерами на паскале. Жалко что не на Схеме, как в странах с нормальной системой образования...

Зря так. Еще до середины 90-х наша система образования в области естественных наук была одной из лучших в мире. По крайней мере, не хуже американской. Не знаю как сейчас.

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

Что касается плюсов, то мне кажется, что он как бы "расплачивается" за свою безумную популярность в 90-е. Как водится, новое поколение начинает с того, что безуспешно отрицает опыт старого. Вот, и достается плюсам от молодежи...

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

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

> Тогда уж так: те, кто не любят C++, не умеют на нем работать, да и вообще его не знают, но много тролят о том, какой он хреновый -- плохие бяки.

Ну, я C++ не люблю. Писать на нём умею, и пишу уже лет 15 как. Но не люблю. Он меня ограничивает. Мне просто не интересна низкоуровневая кодерёжка, а на C++ без неё не обойтись, даже если тебя Александреску покусал.

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

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

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

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

>В C++ у вас есть выбор. Что в этом плохого?

switch(msg_id){case PAINT:... case MOUSE_MOVE:...}, char* и void(*)(void* handback, ...) мне и в Си доступны, спасибо.

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

> Ну, я C++ не люблю. Писать на нём умею, и пишу уже лет 15 как. Но не люблю. Он меня ограничивает. Мне просто не интересна низкоуровневая кодерёжка, а на C++ без неё не обойтись, даже если тебя Александреску покусал.

А если сравнить, кто в данной теме больше какашек в C++ бросил -- вы или Sidrian?

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

>Зря так. Еще до середины 90-х наша система образования в области естественных наук была одной из лучших в мире. По крайней мере, не хуже американской. Не знаю как сейчас.

По утверждениям местных в физике-математике вроде как и раньше все в порядке. А CS/SE как не было тогда, так и не появилось сейчас(давайте не будем демонстрировать комплексы и раздувать флейм на тему "Только из физиков получаются Настоящие Программисты").

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

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

>Что касается плюсов, то мне кажется, что он как бы "расплачивается" за свою безумную популярность в 90-е. Как водится, новое поколение начинает с того, что безуспешно отрицает опыт старого. Вот, и достается плюсам от молодежи...

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

>Тот же лисп может вызывать у многих не меньшее отвращение.

Только у ущербных.

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

> Почему же? Опять религиозные предпочтения?

1. Это разные языки.

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

2. А зачем лишать C-шных библиотек всех остальных? Они чем хуже?

> Которые можно использовать, в большинстве случаев, совершенно прозрачно, без биндингов.

3. При наличии нормального FFI "биндинги" сводятся к оформлению библиотеки в принятом в языке стиле. Да и плюсовики норовят обернуть С-либу ОО-враппером.

Т.е. C-шные библиотеки - это нисколько не заслуга С++.

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

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

Стандартная отмаза крестовиков про прямые руки. Вот тебе сорсы буста нравятся? Легко их читать? У разработчиков буста кривые руки и они не знают С++?

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

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

Лужи стынут

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

>> Почему же? Опять религиозные предпочтения?

>1. Это разные языки.

Их различия не многие сразу перечислят.

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

>2. А зачем лишать C-шных библиотек всех остальных? Они чем хуже?

Я их не лишал. Просто сказал, что в случае C++ у разработчиков будут как C, так и C++ библиотеки в распоряжении.

> Т.е. C-шные библиотеки - это нисколько не заслуга С++.

Я этого и не говорил.

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

> Я их не лишал. Просто сказал, что в случае C++ у разработчиков будут как C, так и C++ библиотеки в распоряжении.

Т.е. в контексте противопоставления С++ другим языкам С-библиотеки можно "опустить" как доступные всем. А теперь можно поговорить о _массе_ библиотек С++ (врапперы к С-библиотекам тоже вычёркиваем), используемых в _массе_ конечных программ на С++. "Крайние" отбрасываем, поэтому KDElibs+boost+STL не вспоминать!

P.S. Попутно можно было бы позвать джава-кодеров для "выставления" своих "наработок", но лучше не будем ;)

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

> CS/SE

Тогда программирование часто рассматривалось как часть прикладной математики. Хотя системное программирование уже оформилось как обособленная область. Мы ведь говорим о 80-x и 90-x.

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

С талантливыми студентами ничего плохо не произойдет. А быдлокодинг на Java и Бейсике по своей сути мало чем отличается. К тому же, причем здесь Бейсик? Использовался в основном Паскаль. На мой взгляд он очень удобен для обучения (и больше подходит чем Java, по крайней мере его Delhi-разновидность).

Что касается выбора Cхемы. Тут есть такой аспект. Американцы известны своей нелюбовью ко всему неамериканскому. Паскаль - детище европейское. Лисп - создание американцев. Это тоже могло повлиять на выбор в пользу Схемы. Как я уже написал, какой конкретно язык - не так уж и важно. Но точно это был бы не язык, созданный в Европе.

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

Для самого программирования это не так важно. Принципы мало измелись за последние десятилетия. Таже архитектура фон-Неймана. Вон тут уже писали, что первым ООП языком была Симула-67, т.е. 1967 год. Правда, она имела не совсем удачную реализацию.

> Только у ущербных.

В программирование очень много от психологии. Те же Си и Си++ имеют просто отвратительную систему сборки и оформления кода. Однако, оба языка безумно популярны. Технически этого никак не объяснить.

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

>> Я их не лишал. Просто сказал, что в случае C++ у разработчиков будут как C, так и C++ библиотеки в распоряжении.

>Т.е. в контексте противопоставления С++ другим языкам С-библиотеки можно "опустить" как доступные всем. А теперь можно поговорить о _массе_ библиотек С++ (врапперы к С-библиотекам тоже вычёркиваем), используемых в _массе_ конечных программ на С++.

Напомню, что я противопоставлял C++ таким языкам, как D и OCaml.

Можете привести для этих языков аналоги ACE и Crypto++, к примеру?

> "Крайние" отбрасываем, поэтому KDElibs+boost+STL не вспоминать!

С какой стати их отбрасывать?

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

> Вот тебе сорсы буста нравятся? Легко их читать?

А Boost - не то, для чего C++ предназначен. Такие вещи надо на Лиспе писать.

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

>> Вот тебе сорсы буста нравятся? Легко их читать?

> А Boost - не то, для чего C++ предназначен. Такие вещи надо на Лиспе писать.

Одной только функциональщиной boost не ограничивается, но ты ведь этого не знаешь, правда?

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

>С талантливыми студентами ничего плохо не произойдет.

Я все таки в этом вопросе склонен доверять Дейкстре ;)

>Что касается выбора Cхемы. Тут есть такой аспект. Американцы известны своей нелюбовью ко всему неамериканскому. Паскаль - детище европейское. Лисп - создание американцев. Это тоже могло повлиять на выбор в пользу Схемы. Как я уже написал, какой конкретно язык - не так уж и важно. Но точно это был бы не язык, созданный в Европе.

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

>Для самого программирования это не так важно. Принципы мало измелись за последние десятилетия.

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

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

>Одной только функциональщиной boost не ограничивается, но ты ведь этого не знаешь, правда?

Детко, он не о boost::lambda, а о метапрограммировании в целом.

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

>>Для самого программирования это не так важно. Принципы мало измелись за последние десятилетия.

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

Святая наивность.

Например, почему на Core2Duo 2GHz полуторачасовый фильм пережимается в другой формат не за 30 секунд, а за 30 минут? Современный уровень техники, по твоим словам, уже вполне достаточен для того, чтобы не считаться с трейдофами на производительность.

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

>Святая наивность. Например, почему на Core2Duo 2GHz полуторачасовый фильм пережимается в другой формат не за 30 секунд, а за 30 минут? Современный уровень техники, по твоим словам, уже вполне достаточен для того, чтобы не считаться с трейдофами на производительность.

И сколько процентво приложения реально требуют такую производительность? Сколько процентов программистов занято именно в этих областях?

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

> Паскаль не альтернатива Лиспу. С чем его реально можно сравнивать, так это с Ц. И заметьте, несмотря на то, что Ц полностью американкая разработка, в образование его там никто не пихал.

У меня есть такая версия. Может быть, чтобы студенты лучше усвоили то, что от самого языка зависит не так много, то и выбрали весьма экзотический вариант. К тому же десятилетие увлечения функциональщиной. В следующем десятилетии будет другой академический мейнстрим. Потом третий. И так далее. А было и так, что лисп был почти в полном забвении. К этому надо относиться проще.

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

Мой пойнт был в том, что компилятор Delphi наглядно показал, что код аналогичного качества можно собирать за многократно меньшее время. Выходит, технический изъян в Си с плюсам.

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

> Одной только функциональщиной boost не ограничивается, но ты ведь этого не знаешь, правда?

Дурачок, какое отношение Лисп имеет к функциональщине? Boost - извращенческое применение generic programming, которому в таких масштабах в низкоуровневом языке системного программирования просто не место.

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

> К тому же десятилетие увлечения функциональщиной

На Лиспах разных (включая Схему) там с 70х годов учат. Традиция-с. В MIT это исторически сложилось, а другие за ними просто повторяют не думая о последствиях.

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

>Может быть, чтобы студенты лучше усвоили то, что от самого языка зависит не так много, то и выбрали весьма экзотический вариант.

Выбрали мощный язык не отягощенный лишним синтаксисом. Никакой идеи втыкания палок в колеса студентам не было.

>К тому же десятилетие увлечения функциональщиной. В следующем десятилетии будет другой академический мейнстрим.

Какое нафиг десятилетие? Лисп в американской системе образования уже лет 25 наверное.

>Мой пойнт был в том, что компилятор Delphi наглядно показал, что код аналогичного качества можно собирать за многократно меньшее время. Выходит, технический изъян в Си с плюсам.

Главное корость разработки, а не скорость сборки. Кормить лишнего программиста дороже чем поставить выделеный сервак для найтли билдов. Неужели я должен объяснять такому опытному человеку, как Вы, прописные истины? К тому же компиляторы Ц значительно шустрее крестовых. Если Вы располагаете тестами о реальном значительном превосходстве в скорости компиляции Делфи програм перед их Цшнами аналогами будет очень интересно глянуть.

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

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

Вы так зловеще об этом говорите. Озвучте пожалуйста последствия.

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

>>Святая наивность. Например, почему на Core2Duo 2GHz полуторачасовый фильм пережимается в другой формат не за 30 секунд, а за 30 минут? Современный уровень техники, по твоим словам, уже вполне достаточен для того, чтобы не считаться с трейдофами на производительность.

>И сколько процентво приложения реально требуют такую производительность? Сколько процентов программистов занято именно в этих областях?

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

eao197 ★★★★★
()

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

Это уже следующий вопрос? Или ты думаешь, что твой вопрос совпадает с тем, который задал Absurd?

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

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

Но на твой вопрос с "бугагага" я ответил?

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

>Boost - извращенческое применение generic programming, которому в таких масштабах в низкоуровневом языке системного программирования просто не место.

Исторически boost:: - это отстойник из того что по каким-то причинам не вошло в std::. Хотя почему в std:: не вошли вещи типа shared_ptr еще в 98 году это интересный вопрос.

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

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

>Но на твой вопрос с "бугагага" я ответил?

Множественном наследование - это не краеугольный камень Qt, как можно видеть по ftp://ftp.trolltech.com/qt/pdf/3.0/qt30-class-chart.pdf. И множественное наследование - это не киллер фича. И это был не вопрос.

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

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

Вот ты мне скажи: ты не устал так лажаться? Или проводишь исследование на тему "сколько раз нужно лажануться, чтобы тебе перестали отвечать всерьёз"?

Вот ты говоришь "никто не пользуется", да? Хорошо. Сходи по ссылке http://doc.trolltech.com/4.2/qwidget.html , перейди в раздел "Protected functions" и узри

virtual void mouseMoveEvent ( QMouseEvent * event ) virtual void mousePressEvent ( QMouseEvent * event ) virtual void mouseReleaseEvent ( QMouseEvent * event ) virtual void paintEvent ( QPaintEvent * event )

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

Или тебе, как ветерану Микрософт Вижуал Сиплюсплюса, нужно чтобы было _именно_ "onPaint" и "onMouseMove"?

Я пытаюсь подобрать слова для того, чтобы сказать тебе, что я о тебе думаю и при этом не сильно обидеть --- и не получается. Лучше промолчу, тут и так всё понятно.

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

>Использовать void(*)(...) либо тащить еще несколько десятков килобайт буста. Зашибись альтернативы.

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

Если тебе знакомо ключевое слово "грань" (facet), то тут тебе самое место выбрать этот самый третий вариант. А если не знакомо --- пойти учить матчасть.

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

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

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

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

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

Sidrian (*) (10.09.2008 19:21:03)

А вот и не факт. При увеличении мощности вычисительной техники растет и объем вычислений.

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

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

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

Ты бы бложек хотя бы с краткими примерами и ссылочками завел что-ли по поводу недостатков плюсов... а я бы читал :-)

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

>На C++ я бы либо передал указатель на функцию, либо завел интерфейс с нужным виртуальным методом и передавал ссылку на него, либо же передавал ссылку на объект и указатель на метод этого объекта. Ну, если бы в проекте уже использовался Boost, то можно было бы попробовать и boost::function.

eao197 (*) (10.09.2008 16:53:22)

Да нет, никакого смысла не имеет шаблоны использовать, можно точно так же как и в чистом с передать указатель void (*)(void* handback, int percentDone), можно ссылку на функцию: void (&)(void* handback, int percentDone), Вы просто с++ не знаете. Только с++ объектно-ориентированный язык, соответственно и ситуаций с необходимостью передавать callback'и для перерисовки чего-либо должно быть меньше.

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

>Так я вроде не абстрактным эмбедом в вакууме занимаюсь. Вижу кто чем занят у меня на работе и слышу от людей чем занимаются в "конкурирующих фирмах". Да и бывал на собеседованиях, где речь шла о работниках, которые будут писать софт под девайсы где вообще ОС нету. Угадай с 3х раз какой язык там предполагалось использовать и куда бы там тебе предложили засунуть кресты?

Sidrian (*) (10.09.2008 17:33:10)

Это только от того что Вы элементарных вещей не понимаете, считаете, что c++ использоваться не может и от непонимания тех кто проводит собеседование. Даже на мобильниках со 100 кб памяти используется джава с ооп. Говорит о том что Вы: 1 не понимаете ооп, его назначение, 2 не знаете с++, его отичие от с, 3 не понимаете принцип работы компилятора и линкера.

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