В каком случае встроенные компиляторы C ++ не поддерживают множественное наследование?

Question

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

Существуют ли случаи, когда компилятор на текущей встроенной платформе (то есть не более нескольких лет) абсолютно не поддерживает множественное наследование?

Я не хочу делать множественное наследование в том смысле, что у меня есть ребенок с двумя полными реализациями класса. Больше всего меня интересует наследование от одной реализации класса, а затем наследование одного или нескольких чистых виртуальных классов только в качестве интерфейсов. Это примерно эквивалентно Java / .Net, где я могу расширить только один класс, но реализовать столько интерфейсов, сколько мне нужно. В C ++ все это делается через множественное наследование, вместо того, чтобы иметь возможность специально определять интерфейс и объявлять, что класс реализует его.

Обновление:

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

Моя точка зрения такова: я хочу знать, существуют ли текущие встраиваемые платформы, которые для целей разработки предоставляют собственный компилятор C ++ (т.е. я не могу использовать GCC или MSVC), который НЕ поддерживает множественное наследование. Моя цель в упоминании встроенного стандарта C ++ состояла в том, чтобы дать справочную информацию только по этому вопросу.

Answer 1

Если вы имеете в виду «Embedded C ++», то я пока не знаю ни одной коммерческой реализации. Честно говоря, если вы посмотрите на цели проекта, то это просто поражение C ++ до такой степени, что, как указывает г-н Барбер, его нельзя считать C ++.

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

Answer 2

Если он не поддерживает MI, то это не C ++.

Answer 3

Многие ограничения, наложенные в подмножестве EC ++, были сделаны, чтобы позволить широкую поддержку компилятора для небольших 16- и 32-битных целей в то время, когда не все компиляторы C ++ поддерживали все появляющиеся функции (например, GCC не поддерживал пространства имен до версии 3. x и EC ++ опускает поддержку пространства имен). Это было до стандартизации ISO C ++, и стандартизация любого рода важна для многих встроенных проектов. Таким образом, его цель состояла в том, чтобы способствовать принятию C ++ во встроенных системах до необходимой стандартизации.

Однако его время прошло, и это в значительной степени не имеет значения. В нем есть несколько вещей, которые можно сказать о «дорогих» и «недетерминированных» элементах C ++, которые все еще актуальны, но большая часть этого была нацелена на совместимость.

Обратите внимание, что EC ++ является истинным подмножеством C ++, и что любая программа EC ++ также является допустимой программой C ++. На самом деле это определяется исключительно с точки зрения того, что он пропускает, а не полное определение языка.

Green Hills, IAR и Keil производят компиляторы с переключателями для обеспечения подмножества EC ++, но, поскольку это во многом вопрос переносимости, это совершенно бессмысленно, поскольку все эти компиляторы также поддерживают ISO C ++. По большей части те части спецификации EC ++, которые вы, возможно, захотите придерживаться, можно сделать, просто не используя эти функции в полнофункциональном компиляторе.

Существуют компиляторы C ++ для очень ограниченных систем, которые не являются ни полностью ISO C ++, ни EC ++.

Answer 4

Извините за старый ответ, но невероятно актуальный по состоянию на выпуск 2014 года:

Apple OS X, драйверы набора ввода-вывода уровня ядра XNU (libkern) не поддерживают множественное наследование.

Из библиотеки разработчика Mac:

Набор I / O построен поверх библиотеки libkern C ++, которая написана в подмножестве C ++, подходящем для использования в загружаемых модулях ядра. В частности, среда libkern C ++ не поддерживает множественное наследование, шаблоны, средства обработки исключений C ++ и информацию о типах среды выполнения (RTTI). Средство RT ++ в C ++ опущено, поскольку оно не поддерживает динамическое распределение классов по имени, что необходимо для загрузки расширений ядра. RTTI также широко использует исключения. Однако среда libkern C ++ определяет собственную систему типизации во время выполнения, которая поддерживает динамическую загрузку.

Исключения в ядре запрещены по причинам как стоимости, так и стабильности. Они увеличивают размер кода, тем самым потребляя драгоценную память ядра, и создают непредсказуемые задержки. Кроме того, поскольку код набора ввода-вывода может вызываться многими клиентскими потоками, невозможно гарантировать, что исключение будет перехвачено. Использование try, throw или catch в любом расширении ядра не поддерживается и приведет к ошибке компиляции. Хотя вы не можете использовать исключения в драйвере I / O Kit, ваш драйвер всегда должен проверять коды возврата, где это уместно.

Apple настоятельно рекомендует основывать весь код ядра C ++, включая код для драйверов устройств, на базовых классах libkern, OSObject и OSMetaClass и соблюдать соглашения, предписанные этими классами

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

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

Answer 5

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

Answer 6

Я хочу знать, существуют ли текущие встроенные платформы, которые для целей разработки предоставляют собственный компилятор C ++ (т.е. я не могу использовать GCC или MSVC), который НЕ поддерживает множественное наследование

Нет, не то, чтобы я знал. Любая встроенная платформа, которая считала, что MI был плохим, вероятно, просто думает, что накладные расходы на ООП вообще плохи, и не дала бы ничего, кроме C