Вы хотите сказать, что очередь на основе void* ничем не хуже очереди на основе TypeName*? С точки зрения удобства и безопасности использования.

Я хочу сказать, что TypeName* ничем не лучше и делать нечто самодельное похожее на очередь ВМЕСТО механизма очередей системы, по причине того, что очередь с void* есть глупость.

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

для "защиты" и создания лишней "своей" очереди я могу и на 'C', только находясь в здравом уме делать такого не буду, а уж тем более изготавливать костыли с TypeName* ВМЕСТО штатной очереди.

Ничего личного, но сразу видно отличие Сишного стиля мышления от Сиплюсового.
В шаблонную очередь (пример выше) мы можем класть не только объектры ELEMENT, но и наследников от него. Это про "разные сообщения"
Далее - насчет "запихнуть не то - невозвожно". Да леко!
Я кончено понимаю, что специалист Вашего уровня никогда не ошибается, но у меня могут быть промашки - при 10 очередях и 20 типах объектов, которые "гуляют" по ним. И любые средства языка, которые хоть немного могут это предотвратить, я очень приветствую.

А, блин, при выемке распознавать святым духом.... Зачем мелкие дежурные "мероприятия".

Разница много больше проявляется в отсутствии/наличии мышления.

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

если всю программу принципиально писать в стиле си++, то ваш подход корректен. если же плюсы избыточны для данной задачи, то и не надо парить моск с обертками. тем более что если вы точно знаете, что в очереди указатель на ELEMENT или производный от него, то при передаче приведите его к void*, а при получении к ELEMENT*. и никаких проблем. никакого лишнего кода.

Гм... Зачем тут void *? Почему бы не приводить к ELEMENT * сразу при передаче? И зачем тут вообще приведение? Если исходный имеет тип ELEMENT * или производный от него, приведение будет выполнено неявно. Если тип совсем другой - то какой смысл его класть в эту очередь, ведь при извлечении получим ELEMENT*, как мы узнаем, что тип был совсем другой?

Лучше принципиально. Наличием четкого статического контроля типов.


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


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


Ну, не все же такие "укротители кода", большинству людей свойствено ошибаться. И код пишется часто не только для себя. И цель - так спроектировать программу, чтобы в ней в идеале не было ни одного ручного преобразования типов (что, к сожалению, не всегда удается, но реально оправданные случаи - это, как правило, стыковка с "железом" - например, преобазование целого в адрес (указатель)). И не зря не последние люди в Computer Science говорят, что ручное преобразование типа чаще всего указывает на ошибку проектирования.


Да, на С ничего, кроме костылей не получается. Именно поэтому и появился С++ - именно как средство устранения горбатостей предка, с сохранением совместимости, но без костылей. И сегодня уже достаточно все это развито и доступно. Нет ни одной причины не использовать. И уж если некогда/не хочется/лень/т.п. в плане использования - это личное дело, но и обосновывать эту позицию тоже ни к чему - за этим ничего, кроме личного субъективизма нет.

P.S. Знаю вас как сложившегося, квалифицированного специалиста, ни разу не сомневаюсь, что все вышеприведенное вас ни в чем не убедило. Т.ч. это скорее не к вам пост, а просто как флаг того, что есть и другое мнение по этому вопросу. Для сомневающихся, так сказать.

если функция отправки в очередь принимает только void*, то при ее вызове надо все приводить к void* это избавит от варнингов в различных компиляторах.

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

Тут вы глубоко ошибаетесь. К void* любой не-cv (не const и не volaile) указатель приводится неявно, о чем ясно написано в стандарте. Если компилятор на это выдает предупреждение - надо писать его разработчикам используя примерно такие идиомы: Вы ведь не приводите к void * при вызове memcpy(), memset()?


грамотно написанная обертка работает на этапе компиляции. Не отнимая ни байта, ни такта на этапе выполнения.

Видимо, я не совсем понятно выразился . Говоря об ОДНОМ указателе я имел в виду именно указатель, который процесс команд помещает в очередь и который является "независимым" от очереди. Естественно, процесс передачи будет работать с другим указателем, который он возьмет из очереди.

да нет же, я просто немного попутал


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

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

Вы похоже потеряли то, с чего собственно начались мои возражения . Напомню.
Было предложено при имеющейся системе "сделать свою очередь" . На мое возражение, что в таком случае городить самодельные очереди не надо, было отвечено "Мне большей частью удобнее НЕ использовать системные очереди. Исключительно из-за их "сишной" природы". И так далее..... до
"сразу видно отличие Сишного стиля мышления от Сиплюсового"

Никто нить не терял . Здесь я своего мнения не изменю - если в качестве языка выбран С++, нужно использовать его возможности. Например - типизацию элемента очереди. Зачем мне системные очереди, которые все приводят к void* ?



Если это Вас задело - извиняюсь. Я вкладывал в эту фразу следующий смысл
"Сишник работает с данными, как с куском памяти. Плюсовик - как с объектом"

А должно было ? Самые главные плюсы плюсов, и это неизбежно, связаны с накладными расходами (и благодаря системному подходу эти расходы чаще всего МЕНЬШЕ, нежели неумелые реализации подобного на 'C' ), но именно в этом сила. Использование С++ только из-за того,что-бы местами в частных случаях избавится от какого-нибудь void * притянуто за уши .

Мне тоже - много и жестоко, только я точно могу сказать, что в 99% моих ошибок выявляющихся в процессе компиляции и легкой отладки и 99,999% ошибок выявляющихся в процессе эксплуатации используемый язык написания совсем не виноват .
P.S.
В 90x мне пришлось столкнуться с ADA - был один телекоммуникационный проект на западников. Вот уж язык,который старались создавать,как безошибочный, но доведенный до абсурда в том числе и с заветной целью военных взять военных специалистов и они все безошибочно напишут все, что и как нужно военным. Так вот, человек,который руководил поминаемым мной проектом, будучи и оставаясь ярым ADA-вцем буквально сбежал разорвав контракт с большими для себя потерями, когда в его предыдущий военный проект начали прикомандировывать военных специалистов прошедших курс обучения языку ADA. Им, и это совершенно естественно, легко удавалось делать умопомрачительное количество ошибок.

Вы НИЧЕГО не знаете о программировании. Совсем Не путайте дурное "программирование", с Программированием.