\Добавь снизу, что чистые классы не содержат полей данных и все будет как надо
А это уже есть
"No Attributes".
\чистый виртуальный метод не имплементируется в чистых классах...
Ну вот этого я и не заметил, если оно было написано.
\... и его вызов дает отслеживаемую ошибку
Может ты имел в виду имплементация?
\Ну наконец-то... :) Используя С++ - никак. Для Сей - дополнительное поле таблице виртуальных функций и проверка поля перед "выбросом исключения"
Ты наверное имеешь в виду признак чистой абстракной функции, а я имел в виду как определить, что функция не имплементирует ничего полезного.
\В купе с чистыми классами - для редуцирования ошибок в архитектуре классов.
Либо лишней головной болью если ими неправильно пользоваться.
Получается, что ошибки архитектуры ты хочешь отлавливать на этапе выполнения? Хотя так часто и получается, но я бы предпочел данные ошибки отлавливать еще на этапе разработки.
Хотя , если честно, я так до сих пор и не проникся данным концептом.
\но Я буду утверждать, что С++-концепт не есть наипоследнее и совершенное творение,
Я такого тоже не буду утверждать, но стоя перед выбором С или С++ я склоняюсь больше в пользу последнего.
\и что есть необходимость анализировать задачу и разрабатывать концепт под задачу до выбора средства имплементации.
Часто средство имплементации уже задано.
\Ну а С++ реализация чистого виртуального метада как определено в концепте что даст?
тот же бардак.
\Ну а меня все же научили. Итого: вторая производная пути есть ускорение...
\Аналогично - объем шара - поверхностный (двойной) интеграл...
а зачем усложнять там где это не нужно. Если мне нужно подсчитать конкретное ускорение, то я не собираюсь вычислять производные.
Только я не хочу утверждать, что твой метод не оптимальный. Каждый делает так как ему удобней и привычней.
\последний раз понятие третьей производной использовал на этой неделе
А я уже и не упомню когда я в последний раз использовал бумажку с этими понятиями Но если они мне понадобятся, то думаю разобраться в этом можно будет.

\... и его вызов дает отслеживаемую ошибку
Может ты имел в виду имплементация?
-----
Нет, имелась в виду именно отслеживаемая в ран-тайм ошибка попытки вызова.
а я имел в виду как определить, что функция не имплементирует ничего полезного.
-----
Опять смотри концепт - не производит ничего полезного, кроме выброса исключения или вызова базового метода. Можно, конечно, написать какие-нибудь глупости вида ++i, но это как раз пустой код.
Либо лишней головной болью если ими неправильно пользоваться.
-----
Ну так и С++ дают весьма-весьма сильную головную боль, при необходимости вызвать приватный метод из вне клосса...
Получается, что ошибки архитектуры ты хочешь отлавливать на этапе выполнения?
-----
Да нет, Я хочу наложить требования, выполнение которых обеспечивает корректность архитектуры, плюс, встроить механизм, который позволяет отслеживать некорректности.
тот же бардак.
-----
Вообще-то, именно это Я и утверждал изначально... :) У Плюсов есть преимущества... пока задача укладывается в концепт Плюсов... дальше - равнозатратные имплементации...
Если мне нужно подсчитать конкретное ускорение, то я не собираюсь вычислять производные.
-----
Гхмм... ну и что же ты посчитаешь, при условии, что ускорение само по себе не то, что не константно, а даже нелинейно? Т.е. если Путь описывается не тремя элементами, по меньшей мере пятью...
что твой метод не оптимальный.
-----
Он не оптимальный. Он просто позволяет редуцировать избыточную информацию, заменяя ее применением одной стандартной методики. Самое сложное - требуется понимать методику и условия ее применения, вместо простого запоминания большого объема информации.
Но если они мне понадобятся, то думаю разобраться в этом можно будет.
-----
Ты - возможно разберешься. Но вот мне весьма часто попадаются люди, которые не смогут разобраться... потому как их, в свое время, не обучили даже составлению и решению линейных уравнений... не систем, просто отдельных уравнений... Эээ... мягко говоря, их учителя схалтурили и не сделали перевод с использования контретных понятий на абстрактные...

\Нет, имелась в виду именно отслеживаемая в ран-тайм ошибка попытки вызова.
Тогда мне нужна четкая привязка функция-класс. Ето мне ее гарантированно даст?
\а я имел в виду как определить, что функция не имплементирует ничего полезного.
\-----
\Опять смотри концепт - не производит ничего полезного, ...
Да, в принципе однинакого, как для меня. Надо на этапе выполнения анализировать код функции, а это уже попахивает жесткой привязкой к системе.
\Ну так и С++ дают весьма-весьма сильную головную боль, при необходимости вызвать приватный метод из вне клосса
так это как раз именно :"...если ими неправильно пользоваться.". Хотя если исходников нету, а надо, то нужно заказывать вагон аспирина.
\Я хочу наложить требования, выполнение которых обеспечивает корректность архитектуры,
А не проще заложить это, скажем, в дизайн гайд. В любом случае архитектуру можно сделать некорректной даже при выполнении всех требований.
\Вообще-то, именно это Я и утверждал изначально
а я не собирался это оспаривать.
\У Плюсов есть преимущества... пока задача укладывается в концепт Плюсов... дальше - равнозатратные имплементации...
Не только у плюсов, думаю абсолютно везде,пока задача укладываектся в концепт имплементации, все хорошо.
\ну и что же ты посчитаешь, при условии, что ускорение само по себе не то, что не константно, а даже нелинейно?
Для начала нужно столкнутся с подобной задачей, часто требуется просто одно число +\- три попугая.
\Он не оптимальный. Он просто позволяет редуцировать избыточную информацию, заменяя ее применением одной стандартной методики.
Можно видимо назвать "системный подход". Я двумя руками за, но допустим, искать свежее доказательство теоремы Ферма меня не увлекает.
\Ты - возможно разберешься. Но вот мне весьма часто попадаются люди, которые не смогут разобраться.
Не думаю, что я какое-то исключение. Все упирается в желание и время. Просто иногда удивляют люди, которые увидев стену, не только не пытаются на нее залезть, но и просто попробовать обойти.
\потому как их, в свое время, не обучили даже составлению и решению линейных уравнений...
Знаешь, меня тоже пытались этому научить, толку не было до тех пор пока не понадобилось сделать это самому.
Можно сказать, что это была моя первая "большая" программа. Ну и что, сейчас я только помню, что метод назывался "Ньютона-Рафсона".
Но это я к тому, что иногда полезно выбрасыать из комнаты все лишнее.
А методы преподавания это уже совсем отдельная тема.

Ето мне ее гарантированно даст?
------
В Сишной реализации? Без проблем...
Надо на этапе выполнения анализировать код функции
------
Гораздо раньше получишь функцию соответствующую определению - пустая.
думаю абсолютно везде,пока задача укладываектся в концепт имплементации
-----
Увы... есть еще сложность реализации... К примеру, все, что будет написано на любом формальном языке - определение авиомата... но не дай боже писать все тоже самое используя концепт автомата... особенно, если не ясно какой глубины контекст надо рассматривать для корректности его работы... Хотя Я частенько пишу именно так...
А не проще заложить это, скажем, в дизайн гайд.
-----
Тут разница - дизайн гайд - хорошо бы иметь, а концепт - должно быть.
но допустим, искать свежее доказательство теоремы Ферма меня не увлекает.
-----
Достаточно понимать... и понимать вполне внятно... что задача сводится и как именно сводится именно какой-то теореме - это дает "мгновенное" решение...
Все упирается в желание и время.
-----
Могу согласится, но не в том плане, в котором ты используешь "время". Дело в том, что времен - два. Первое - биологическое время особи, второе - психологическое время особи. "Человек" - это номо сапиенс, у которого нет большого разрыва между этими временами. В противном случае имется дефект... В области обучения это обозначает, что обучение должно быть своевременным - чуток ранее - не воспринимается - рано, недостаточно развит, чуток позднее - не воспринимается - поздно, уже заполнено чем-то и надо ломать...
только помню, что метод назывался "Ньютона-Рафсона".
-----
Хммм... Вот как назывался - не вспомню... но алгоритмику трех-пяти способов - или вспомню, или выведу...
Но дело не в этом... При обучении программированию решение систем линейных уравнений это задача на закрепление понятия "цикл" с самостоятельным комбинированием трех уровней вложенных циклов, после того, как на примере интегрирования (вычисления площади/объема) показано как ими пользоваться. Мне попадались люди, которые не были в состоянии перейти от задачи к матрице и соответствующей организации циклов... просто неспособные перевести конкретные сущностные значения в абстрактную форму, независимо от того, кто и как объяснял что к чему... схалтурили учителя в свое время и как не изворачивайся - бестолку... на кодинг натаскать можно, на алгоритмику - никак...

Да, я девочка (ну женского пола вернее) ... в програмировании ни бум бум . Я гуманитарий , свободно говорю, и вообще на 5 ти языках (человеческих , не компьтерных), по шабатам не работаю. Дактиль не склоняется .... Что такое SSD ? Куда присылать резюмэ ?
ЗЫ по теме: Мур мне тебя жаль но сэляви ... сколько раз уже наблюдала - иннициатива наказуема, а причин для отказа может быть множество. Вплоть до того, что человек на это место был уже намечен , но начальству нужно было создать видимость, провести пару собеседований и в конце - концов просто продвинуть своего.

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

Уговорила, не буду склонять, тем более что положение семейное не позволяет

EN,DE,IL,UA,RU ?

Эх, вот в бытность мою сисадминскую – все бы гуманитарии были бы способны
линукс самостоятельно поставить, да еще дистрибутив грамотно выбрать

Senior Software Developer

“Личка” всегда открыта. На Axapta уже трудится человек,
но расширяется отдел продаж запчастей – там надо “свободно говорю”
Пы.Сы. Линукс используем... но только на моих личных компьютерах