Большинство современных программ в здравом уме сейчас на 16-битных процессорах запускать не будет. К тому же размеры целых типов - не единственная проблема. На таких процессорах кардинально другая система управления памятью с сегментами и дескрипторами.
Нет. Ты ведь, надеюсь, не исключительно x86 под 16ти битами подразумеваешь?
Скажем у msp430 плоская модель памяти. Никаких сегментов вообще.
Кстати, а какая разница с точки зрения языка, какая там модель памяти у машинки внизу? Вроде бы в сообщении о языке ничего об этом не говорится.
Указывать диапазоны это конечно выглядит правильно, но довольно неприятно для всякой переменной указывать размер. Пусть лучше будет 4 байта, всё равно новый врятли будут запускать на 8-и и 16-ти битной машине. К тому же вероятно для таких машин могут потребоваться и другие изменения.
Не для всякой переменной, а создавая свои типы. Переменных одного типа, как понимаешь, может быть множество.
Подход Си в неопределённости размеров целых чисел неудачен, т. к. может нарушить логику работы программы на разных процессорах.
У Си, равно как и у С++, давно уже
другой подход. И он лучше чем в КП, и тем более чем в Oberon-07/11.
Таким образом КП-программа оказывается эффективной только на 32битной машине. Работа с 32битами не эффективна на машинах с меньшей битностью, и на ряде машин с бОльшей битностью.
В чём проблема с 4-х байтными целыми на AMD64?
Затрудняюсь ответить (то есть прямо сейчас по полочкам не разложу). Но в принципе, могу сказать какие проблемы бывают на АРМе с 16тью битами - выравнивание. Данные должны быть выровнены, и доступ к 16ти битной переменной идет медленней чем к 32битной. Соответственно на 64битах относительно 32бит может быть то же самое.
Кстати, вот, нашел. На самом деле выравнивание хорошо бы иметь 128битное (
http://en.wikipedia.org/wiki/Data_structure_alignment#x86):
While the x86 architecture originally did not require aligned memory access and still works without it, SSE2 instructions on x86 CPUs do require the data to be 128-bit (16-byte) aligned and there can be substantial performance advantages from using aligned data on these architectures. However, there are also instructions for unaligned access such as MOVDQU.
Ну и советую посмотреть что там с RISC'ами.
Это есть и в java и в С++. Подозреваю, что в C# тоже есть.
В них можно получать полный доступ ко всем переменным внутри модуля (безо всяких friend и прочих костылей)?
Доступ кого к кому? И какое отношение это имеет к обсуждаемому ограничению на наследование?
В них можно объявить класс, который может создать только модуль, который его объявил (безо всяких костылей типа объявления пустого класса и его расширения неэкспортированным классом).
Да, коенчно.
В С++ модульности вообще нет. Экспортируется всё. Инкапсуляция только на уровне классов.
Нет. То есть модулей конечно же нет в явном виде. Но попробуй, пожалуйста, получить вот в данной программе из другой единицы компиляции к переменной foo:
// Foo.c
static int foo = 42;
Замечу, что это даже не С++, а просто Си.
Также в Component Pascal'е очень удобно, то, что не надо писать никаких definition'ов и header'ов. Компилятор это делает автоматически. Некоторые почему-то видят в этом недостаток, не знаю почему.
Потому, что становится невозможным specification driven development. Что бывает очень полезно. Особенно в больших проектах. Да и библиотеки которые написаны в таком стиле читать/разбираться намного приятней.
Побыстрому что-то накидать конечно удобней в стиле без спецификации отдельно.
Впрочем, этим грешат многие (чуть ли не все) новоделы. Та же java например, с#, go, D и так далее. Свет в окошке только Ада да Haskell.
Но в java,c# и Go это все частично компенсируется IDE, а вот в КП и D - нет. Увы-с. С таким работать не приятно.
Удобен метод экспортирования символов - просто ставишь "*" и всё. и никаких длинных слов вроде "public".
А потом высматривай эти звездочки, ога. Причем по всему тексту. То есть для пишущего это конечно удобно, для читающего - нет. А читатель в плане программирования имеет бОльший приоритет чем писатель.
Да, к тому же, длинное слово вроде public в С++ не требуется писать перед КАЖДОЙ сущность в структуре/классе. Таким образом, если у нас есть группа экспортируемых сущностей числом больше шести, то по лаконичности С++ начинает выигрывать. А по наглядности он выигрывает сразу.
Ещё Java не умеет работать с неуказательныим классами, там они все только POINTER TO RECORD. Это повышает нагрузку на сборщик мусора и снижает эффективность работы. Для Component Pascal'я сборщик мусора с поколениями не нужен, поэтому память работает быстрее.
Оно бы нагружало сборщик мусора, если бы реализация была бы наивной. Но она не такова, и в ряде случаев "объекты" будут на стеке. А сборщик мусора c поколениями в КП настолько не нужен, что народ аж переходит на ручное управление памятью :-) Как раз вот свеженькая темка в тему:
http://forum.oberoncore.ru/viewtopic.php?f=23&p=77104Которое повышает вероятность утечек, ведь это не С++ и умный указатель тут не сделаешь.
Для микроконтроллеров вполне себе может стать. Высокая эффективность проверки типа позволяет использовать RTTI даже на микроконтроллерах.
Наврятли. На микроконтроллерах обычно тормозит например умножение и работа с плавающей точкой. А RTTI там противопоказан не из соображений производительности обычно, а из соображений экономии ОЗУ. На минуточку - у тебя 8 КБ на ВСЁ. Вообще все! Причем 8 Кб ОЗУ - это достаточно жирный микроконтроллер.
Я гонял приложение на c++11 (с лямбдами и прочим) на микроконтроллере с 512
байтами ОЗУ.
А скажи пожалуйста, чем микроконтроллер на MSP430 с ОЗУ в 18 Кб менее полноценен, чем ARM (ARM7TDMI) с 8 Кб ОЗУ?
Если и там и там можно динамически загрузить модуль в ОЗУ и исполнить его оттуда, то ничем. Для меня загрузка модулей - один из основных критериев "полноценности" процессора.
Если ты имеешь ввиду гарвард там или фоннейман, то там да, фоннейман.
Какие преимущества у Oberon-07/11 перед C/C++ кроме идеологии и простоты построения компилятора? Си же вроде для любого микроконтроллера есть...
Oberon-07/11 хорош для системного программиста. То есть не для того, который битиками оперирует - битиками и прерываниями оперирует все же прикладной программист, а тот который создает инструментарий для прикладного программиста. В этом плане у Oberon-07/11 пожалуй конкурентов мало. На базе него можно много быстрее и качественнее сделать нужный инструмент. Другое дело, что, вполне вероятно, на выходе будет уже не Oberon-07/11.
Ну, например для Oberon-07/11 (даже если не менять язык) намного проще построить вменяемую IDE чем для C++ или даже Си.
Ну и начинающий программист (но матерый электронщик) Оберон пожалуй быстрее освоит. Да, и мое IMHO, что народ учить программировать следует на базе именно микроконтроллеров, а не больших персоналок. Во первых это фан, ибо робототехника и вообще реальное взаимодействие с окружающим миром. Во-вторых если взять кошерный микроконтроллер (например msp430), то система команд и устройство памяти там очень-очень простое (проще чем у Виртовского недоАРМа из книжки) + вся память (все 512 байт скажем) будут на виду (на одном экране поместится вся карта памяти).
Смотрю я код BlackBox'а и думаю: видимо это идеология оберона такая писать контейнеры каждый раз свои для каждого объекта. Принципе это не сложно организовывать связные списки и т.п..
А что-то хитрее тоже не сложно организовать? Скажем B-tree?
И да, это не идеалогия такая, это вынужденая мера такая, потому что с таким языком иначе не получится вообще никак.
К тому же это позволяет адаптировать контейнеры под применение объектов и повысить эффективность.
А также насажать ошибок либо при копипасте, либо при ручной реализации велосипеда. А поскольку велосипеды приходится реализовывать постоянно, и нужно быстрее, то на вылизывание производительности, сколь-нибудь не тривиальные оптимизации и алгоритмы времени уже не хватает. Абы работало.
При использовании шаблонов можно запросто написать крайне неэффективный код, не зная особенностей реализации (например один раз открывал большой RTF в Haiku и так и не дождался пока он откроется; оказывается там строковой буфер очищался удалением каждого символа с начала; у себя локально исправил проблему).
Какое отношение приведенный пример имеет к шаблонам? По моему - никакого.
