Я это понял.

Все в этом хорошо кроме двух существенных недостатков - в конструкторах нельзя использовать сервисы ОС, ибо ос запускается из main() и второй - не гарантирован порядок вызова конструкторов. И если один объект использует при инициализации данные другого - возможны три варианта:
1) повезет и порядок случайно окажется нужным
2а) не повезет, и работать не будет,
2б) не повезет, но работать будет
3) завести в каждом классе init() и вызвать его в нужном порядке из main(), а конструктор не нужен.

Как решать такие ситуации? Объясню на двух простых примерах:
1) scmRTOS. Каждый поток в своем конструкторе прописывает себя в таблице объекта Kernel. Чаще всего объект Kernel еще не существует и спасает лишь то, что он глобальный, и его адрес известен компилятору. Потоки складывают данные туда, где потом разместится Kernel. Это случай типа 2б и спасает лишь то, что конструктор TKernel фактически разбит на две части - сначала при обнулении неинициализированных глобальных переменных обнуляется и память на месте размещения Kernel, а потом, при конструировании объекта заполняются своими значениями ненулевые члены. Здесь процесс борьбы вроде бы очевиден - поскольку ядро может быть лишь одно, то его можно сделать виртуальным базовым классом для потоков или все его(ядра) члены - статическими. Второй способ менее элегантен, ибо придется где-то отдельно перечислять инициализацию каждого члена.

2) Микросхема Wiznet. Имеет 4 сокета (каждый со своим набором регистров) и набор общих настроек. Описана классом TWiznet, который имеет членами массив из четырех TSocket. Вроде все логично.
Есть объекты (Ttelnet, Ttftp), которые используют сокеты и которые по хорошему в конструкторах должны делать настройку сокетов, но проблема в том, что на момент вызова конструкторов этих объектов объекты сокетов еще не созданы. Тупик, приводящий к варианту 3.


Для Непомнящий Евгений: Посмотрел ваш исходник, есть вопрос. Почему вы в конструкторе используете конструкцию { this->member = initvalue; } вместо рекомендуемой Страуструпом (правда он тоже не всегда ее придерживается) : member1(initvalue1) {}?

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


Есть честный обходной путь. Размещай объявления объектов в одной единице компиляции и порядок вызова конструкторов будет гарантирован. На уровне проекта это вполне нормальное и устойчивое решение.

[quote name='Сергей Борщ' date='Sep 28 2007, 11:49' post='300070']
И если один объект использует при инициализации данные другого - возможны три варианта:
1) повезет и порядок случайно окажется нужным
2а) не повезет, и работать не будет,
2б) не повезет, но работать будет
3) завести в каждом классе init() и вызвать его в нужном порядке из main(), а конструктор не нужен.
quote]
Проблема понятная.
Возможные решения.
1. Если логично, использовать наследование (тогда порядок вызова конструкторов однозначный).
2. Использование наследования виртуальных классов.
3. В main сразу всех родить.
4. Нехороший вариант. Проверять есть ли данный класс.

По поводу scmRTOS лучше ответит Гари (я его видел мельком).
PS. Пока я ходил обедать, он уже ответил.

Сообщение отредактировал alexander55 - Sep 28 2007, 09:12

У меня имя члена совпадает с именем аргумента, и я как-то не пробовал что получится при записи
: member1(member1) {}

Ну и как-то привычнее . Я списки инициализации использую для конструкторов предков, объектов-членов и констант, а все остальное обычно размещаю в теле конструктора.

Сообщение отредактировал Непомнящий Евгений - Sep 28 2007, 09:48

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


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

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

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

[quote name='dxp' post='299963' date='Sep 28 2007, 08:31']
Ну, собсно, тут на плюсах особенно не развернуться, чтобы показаться во всей красе ,

Должно слегка помочь
И это исчо без применения асм и всяких хаков

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

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





Так я ж вроде бы и сказал, что для инициализации объектов - членов, предков и констант использую список инициализации.
Члены встроенных типов я инициализирую в теле конструктора по привычке; может стоит от нее отказаться.

Счас проверил, запись вида : member1(member1) действительно работает правильно.

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


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

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


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

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


Он вообще к ООПу никакого отношения не имеет.


Почти так. Меня попросили реализацию фрагмента на С++, я ее сделал. Вы не это просили разве?


Не понял, что вы тут имели в виду. И про какой оверхед речь?


За счет чего? И причем тут уже ++?

Дык ответ то прост и банален, потому что джиттера не будет при чтении портов например...

dxp, я надеюсь что Вы сами то понимаете что слегка лукавите ?
Вариант классы ради классов я все-таки не рассматривал.
Вы будете меня убеждать что класс подобный описанному Вами будет когда-либо присутствовать
в Вашей программе ? (лучше соврите если это правда )
И эта функциональность бывает иногда(часто) излишней для конкретного проекта.
Заметим сразу же что если какая-то функция реализованна в классе, то линкер не
имеет возможности выкинуть эту функцию из конечного бинарника(или имеет такое право...,
засомневался, кто знает просветите...)
Повторюсь еще раз, классы ради классов...
Все очень просто,
Вы создаете реальный(похожий на реальность) класс под названием типа TPort.
Этот объект будет включать в себя переменную указывающую на адрес
регистра PINx(в общем случае там таких переменных будет 3 (pin, port и ddr), хотя
в частных реализациях можно обойтись и одним адресом).
Так же в этом классе будет реализован доступ к этому порту в разных вариантах,
типа считать, записать, считать с маской, записать с маской, и т.д.
ну и конечно конструктор с привязкой к конкретному порту.
Про оверхед нужно объяснять или сами все поняли ?
С++ здесь уже действительно не при чем.
Ну это вроде очивидно,
за счет исключения лишнего считывания adcsra из памяти.

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


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


Классы ради удобства логического представления.



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


См выше. Кроме того, оверхед зависит от целевого процессора. Например, на MSP430 оверхеда не будет.


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

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

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

С этой точки зрения, как мне кажется, дискуссия была очень полезна.