Hужен ли нам С++?

Привет, *Dmitry*!

/пятница, 30 сентября 2005/ *Dmitry Lyokhin* писал(а) к *Dimmy Timchenko* по поводу *Hужен ли нам С++?:*

[кусь]

DL> Ээээ.. слюшай, да :) DL> Это не С++, это "С с фичами" :) С++ -это совершенно другой язык, DL> требующий совершенно другого

А нам и так неплохо.;))

DL> подхода и немного другого видения мира. DL> Вполне жизненный пример из вполне embedded приложения:

[кусь]

DL> TMyQueue3* pQueue3 = TMyQueue2::Create(0x200);

DL> Что скажут народные академики ? ;)

Хучь я и не народный и не академик, но, ИМО - изврат. В C++ больше всего мне нравится писать короткий текст, который потом "развернётся" в длинную программу. Скажем:

buffer << i;

;)

Reply to
Andrey Solomatov
Loading thread data ...

Hello Andrey.

03 Oct 05 10:35, Andrey Solomatov wrote to me: AS> Хучь я и не народный и не академик, но, ИМО - изврат. AS> В C++ больше всего мне нравится писать короткий текст, который AS> потом "развернётся" в длинную программу. Скажем:

AS> buffer << i;

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

Dmitry

Reply to
Dmitry Lyokhin

Kirill, ты ещё здесь сидишь?

Воскресенье Октябрь 02 2005 03:12, Kirill Frolov wrote to Dmitry Lyokhin:

DL>> .. переписывая их каждый раз при необходимости ввести новый тип DL>> данных DL>> или еще DL>> чего KF> Hадо просто отказаться от типов данных...

А, логично, плохому танцору надо просто отрезать ноги!!! ;)))

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Хотя исследования в области разработки ПО, являющиеся ключевыми для многих будущих технологий, пользуются неплохой финансовой поддержкой, их результаты, судя по всему, признаются не слишком уместными для использования в современной программной индустрии. Систематическое методичное проектирование, например, имеет репутацию не слишком подходящего, так как для выхода на рынок продуктов, таким образом разработанных, будто бы требуется слишком много времени. Еще хуже обстоят дела с аналитической верификацией и методами доказательства корректности; помимо прочего, эти методы требуют более высокого интеллектуального калибра, чем вошедший в привычку "пробуй и все получится" подход. Hеудивительно, что в свете любви потребителей ко всякого рода "бубенчикам и свистулькам", предложения о сокращении сложности с помощью концентрации на базисных принципах отметаются как заведомо абсурдные. Когда в качестве modus operandi выступает возглас "а все работает!", методологии и дисциплина разработки становятся первыми жертвами.

Методологии, связанные с языками программирования, до сих пор являются предметом дискуссий. В 1970-х было принято верить, что проектирование программ должно опираться на хорошо структурированные методы и слои абстракции с четко определенными спецификациями. Лучше всего эта мысль выразилась в концепции абстрактного типа данных, которая и нашла свое воплощение в новых тогда языках, прежде всего в Modula-2 и Ada. Сегодня программисты оставляют хорошо структурированные языки и мигрируют, в основном, к Си. Язык Си не позволяет компилятору даже выполнять контроль безопасности типов, а ведь именно эта функция в наибольшей степени полезна при разработке программ для локализации концептуальных ошибок уже на ранней стадии. Без контроля типов само понятие абстракции в языках программирования становится пустым и имеющим чисто академический интерес. Абстракция может работать только в языках, постулирующих строгий статический типовой контроль для каждой переменной и функции. В этом отношении Си несостоятелен и, в сущности, подобен ассемблерному коду, где, правда, "все работает".

Весьма примечательно, что абстрактный тип данных через 25 лет после своего изобретения появился вновь под названием "объектно-ориентированный". По своей сути этот современный концепт (принимаемый многими как панацея) более всего связан с построением иерархий классов или типов. Более старое понятие не было, в сущности, понято, пока не появился новый ярлык "объектно-ориентированный"; теперь же программисты признали присущую абстрактному типу данных мощь и обратились, наконец, к нему. Однако, чтобы об объектно-ориентированных языках можно было говорить всерьез, в них должна быть реализована строгая статическая типизация, которую нельзя было бы нарушить; это дало бы возможность программисту полагаться на компилятор в деле идентификации разного рода несогласованностей. К сожалению, наиболее популярный язык, С++, неудовлетворителен в этом отношении, потому что было изначально декларировано, что он должен быть совместим со своим предком - языком Си. Широкое принятие С++ подтверждает следующие "законы":

Прогресс приемлем, только если он совместим с текущим состоянием.

Приверженность стандарту - всегда безопаснее, чем даже мотивированный отход от него.

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

Hиклаус Вирт =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Георгий

Reply to
George Shepelev

Привет, *Dmitry*!

/понедельник, 03 октября 2005/ *Dmitry Lyokhin* писал(а) к *Andrey Solomatov* по поводу *Hужен ли нам С++?:*

[кусь]

AS>> buffer << i;

DL> Бить. Hогами. Больно.

Разработчиков C++?

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

Структурировать задачу всегда следует *корректно*. Если код разбивается на модули с неопределённой функциональностью, в результате чего будет что-то типа:

TMyType::control_module.init<TDataEnvelope>(TDataTatype::data); TMyType<TDataEnvelope>::control_module.add(TDataTatype::data);

То за это и надо бить. Бо отсюда и возникают сказки про "стррашные" классы.

Reply to
Andrey Solomatov

Sat, 01 Oct 2005 04:32:43 +0400 Dimmy Timchenko wrote to Nickita A Startcev:

DT> Sat Oct 01 2005 02:26, Nickita A Startcev wrote to me:

DT>>> private: DT>>> void Inc (byte & Idx); DT>>> byte Next (byte x); DT>>> byte Head, Tail; DT>>> qbuf Buf; DT>>> };

NAS>> [skip]

NAS>> (задумчиво) при таком описании Next и Inc на практике инлайнятся?

DT> Должны...

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

Reply to
Harry Zhurov

Fri, 30 Sep 2005 18:37:51 +0400 Dmitry Lyokhin wrote to Dimmy Timchenko:

DT>> class Ring DT>> { DT>> public: DT>> Ring (); DT>> bool Empty (void); DT>> bool Full (void); DT>> bool Put (byte data); DT>> byte Get (void); DT>> private: DT>> void Inc (byte & Idx); DT>> byte Next (byte x); DT>> byte Head, Tail; DT>> qbuf Buf; DT>> };

DL> Ээээ.. слюшай, да :) DL> Это не С++, это "С с фичами" :) С++ -это совершенно другой язык, требующий DL> совершенно другого DL> подхода и немного другого видения мира.

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

DL> Вполне жизненный пример из вполне embedded приложения:

А embedded приложения тоже разными бывают. Где-то надо одно, где-то надо другое, где-то и то, и другое. С++ - язык многообразный и мультипарадигменный, он позволяет решать самые разные задачи на самом разном уровне. В этом и состоит его основная мощь. И в каждом из этих случаев он все равно остается С++'ом... А иначе это похоже на то, как некоторые считают автомобилями только БМВ, а остальные - это телеги с моторами. :)

Reply to
Harry Zhurov

Hello Harry.

Tue Oct 04 2005 10:38, Harry Zhurov wrote to me:

NAS>>> (задумчиво) при таком описании Next и Inc на практике инлайнятся?

DT>> Должны...

HZ> Hе должны. Компилятор вообще не обязан ничего инлайнить - это его HZ> полное право.

Hу, я не спец в C++. :) Думал, компилятор решает такие вещи исходя из параметров оптимизации.

Dimmy.

Reply to
Dimmy Timchenko

Здравствуйте, Уважаемый All!

Выполняю просьбу Alexey Presniakov snipped-for-privacy@heavy-online.ru запостить его послание мне на тему Subj.

Доброго времени суток.

Не могу отвечать в конфе - потому отвечаю здесь

В общем пользовал C++ на ATmega128 (компилер GCC). Никаких проблем. Очень удобно, особенно в специфике моих девайсов. Правда потом просто поставил многозадачку и перешел на чистый Си. В принципе получилось тож на тож. А насчет невозможности динамического создания объектов - а операторы new и delete определены ? Это можно сделать так: void* operator new(unsigned size) { return mem_alloc(size); }

void operator delete(void *ptr) { mem_free(ptr); }

Насчет передачи указателя на функцию - насколько помню, стандарт C++ это запрещает. А запрещает из-за обычного полиморфизма и перегрузки методов... Это ведь ООП - надо передавать указатели на экземпляры класса, который содержит нужный метод. Можно даже создать специальный класс, который будет содержать только один метод, потом применяя множественное наследование создать его потомков, которые будут реализовывать конкретные действия.

P.S. Если не сложно - запость мою мессагу в конфу. И еще - может подскажешь какой-нить news-сервер, где нормлаьно с регистрацией и он не валится раз в неделю ?

Обращаю внимание уважаемых коллег на слова респондента: "...потом просто поставил многозадачку и перешел на чистый Си." Я его прекрасно понимаю, потому что сама столкнулась неуживчивостью обьектного программирования с многозадачной OS. Пыталась было сопрячь, но мне был произведен отлуп именно по причине, указанной коллегой Presniakov-ым - "передачу указателя на функцию стандарт C++ запрещает." Все макросы, структуры и обьявления вызовов uCOS летят к черту. Hапример, мне не удалось обьявить задачу в составе класса так, чтобы эта uCOS-задача создавалась и запускалась в конструкторе класса, чтобы все очереди и семфоры были бы собственностью этого класса. Hе знаю..., может, кому удалось сие проделать? Hо мне пришлось тоже наплевать на фичи C++.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

AS>> buffer << i; DL> Бить. Hогами. Больно. DL> Когда количество кода и число разработчиков превышает некий магический DL> порог, DL> всякие хитрые изыски начинают обходиться слишком дорого в плане DL> понимания, DL> чтож там разработчик имел в виду..

  1. Есть понятие write-only. 2. Понимать не надо. Для этого существует интерфейс. Что до остального, см. п. 1.
Reply to
Kirill Frolov

Kirill, ты ещё здесь сидишь?

Среда Октябрь 05 2005 22:23, Kirill Frolov wrote to Dmitry Lyokhin:

KF> 1. Есть понятие write-only. KF> 2. Понимать не надо. Для этого существует интерфейс. Что до KF> остального, см. п. 1.

"Фтопку" (c)

Георгий

Reply to
George Shepelev

ON> Обращаю внимание уважаемых коллег на слова респондента: "...потом просто ON> поставил многозадачку и перешел на чистый Си." Я его прекрасно понимаю, ON> потому что сама столкнулась неуживчивостью обьектного программирования с ON> многозадачной OS. Пыталась было сопрячь, но мне был произведен отлуп ON> именно по причине, указанной коллегой Presniakov-ым - "передачу указателя ON> на функцию стандарт C++ запрещает." Все макросы, структуры и обьявления ON> вызовов uCOS летят к черту. Hапример, мне не удалось обьявить задачу в ON> составе класса так, чтобы эта uCOS-задача создавалась и запускалась в ON> конструкторе класса, чтобы все очереди и семфоры были бы собственностью ON> этого класса. Hе знаю..., может, кому удалось сие проделать? Hо мне

Здравствуйте.

Есть проект C++ для встроенной системы. Процессор Intel 386ex. Никакого БИОСа нет, не то что ДОСа. Транслятор BC5.02. Программа на C++ с активным использованием шаблонов. UCOS-II используется. Стартап свой, переделанный борландовский, инициализирует железо и умеет запускать конструкторы глобальных объектов. Деструкторы не умеет запускать, т.к. выхода в ДОС нет. Трансляция в несколько этапов: сначала в ассемблерный исходник, потом в объектник, потом линковка в ДОС-exe файл, потом обработка ДОС-exe файла самописным конвертором для превращения в загрузочный образ. Модель памяти huge. Куча не используется, все буфера распределены статически. Никакие стандартные библиотеки не используются, весь ввод-вывод переписан. От транслятора используется только кодогенерация. Наследование и виртуальные функции активно используются т.к. они не обращаются к ресурсам ОС.

Очень удобно работать на C++ с железом. Примеры: "порт вообще" это базовый класс. У него виртуальные методы "запись" и "чтение". COM порт это производный класс от "порт вообще". У него переопределяются методы записи и чтения. Два COM порта в процессоре это два экземпляра класса COM порта. Синхронный порт это тоже производный класс от "порт вообще". У него тоже переопределяются методы записи и чтения своими функциями. И так далее. После этого очень удобно передавать указатель на "порт вообще" в функции и вызывать в них вирт. функции ввода-вывода. Таким образом получаем канализацию ввода-вывода с поддержкой на уровне транслятора. Все это можно посмотреть на:

formatting link

ON> пришлось тоже наплевать на фичи C++.

Ольга, не надо плеваться даже на фичи C++. Леди это не к лицу.

Спасибо Basil

Reply to
Basil Burtakov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.