OberonCore

Нет. Все аналоги дельфовских-сишных пойнтеров объявляются как POINTER TO RECORD [untagged]... или POINTER TO ARRAY [untagged] - а дальше воротите, чего хотите, компилятор за Вас не отвечает. Вы сами отвечаете за то, куда это будет указывать и какова структура памяти.

SYSTEM.PTR использовать не нужно. Это особый (недокументированный) тип, который позволяет хранить-принимать любой КП-шный (т.е. безопасный, управляемый сборщиком мусора и распределённый через NEW) указатель. Вы с ним ничего сделать не сможете и незачем. С ним работают, зная структуру памяти ББ и структуры ядра. Тогда можно проанализировать что-то и аккуратно что-то сделать.

(Кстати, документация на ядро ББ - http://oberoncore.ru/wiki/blackbox/kernel)

Насчет конкретно дельфи - не знаю. Но вообще size_t обычно берут равным (по битности) указательному типу потому что он используется как размер/индекс/смещение и поэтому, согласно сишной адресной арифметике, должен уметь "адресовать" не меньший диапазон, чем сам указатель. Кроме того, в сишном коде любят кастать указательный тип в целочисленный и обратно
Так, например, для Win64 и VC: int = 32, size_t = 64, void* = 64.

Конкретно в данном случае она пошла исключительно из желания обеспечить обратную совместимость. Чего бывает, когда обратную совместимость ломают, можно посмотреть на примере другого продукта той же самой фирмы - Itanic называется

Ох Вы представляете, что такое поменять WORD на WORD16 или WORD32 или оставить WORD в гигабайтах исходного кода? А потом проверить, что все это работает? Нет? Ну так попробуйте поменять хотя бы в BB SHORT CHAR на CHAR в тех меcтах, где это надо для юникода

Спасибо, за ответы, если честно понимаю не все (предупреждал уже что в С я ноль , но тем не менее.
1) Не понятен термин "кастать"
2) не посоветуете, чего почитать по основам Си (буквально хотелось бы определиться с терминами, немного с типами, структурами, структура модуля (или какой там аналог в Си) вот пожалуй достаточно, ну или чего там еще в основах си имеется), чтоб моск не взорвался от обилия инфы ? А тот тут и по КП хватает чего изучать . А то на вышепреведенной ВИКИ глянул статью по Паскалю, все как-то в одном месте и все понятно, там же попытался по Си посмотреть, но все в разброд, непонятно с чего начать.

Представляю. Что-то мешало сразу обозначить 16-ти разрядность словом WORD16? Вероятно, посчитали, что 16 разрядов - это на тыщу лет вперёд. Или наоборот - конкретный смысл обобщённого понятия задаётся платформой, а это тот самый vendor-lock. Хотя вряд ли такие сложности обдумывали в те времена, скорее - просто отсутствие перспективного зрения + крайняя самоуверенность.

Я думаю все намного проще. Возможно, что изначально преполагалось, что WORD - это машинное слово. Но криворукие виндовые программеры (у которых "экспериментальное" знание "WORD = 16 бит" - есть, а вот знания о том, что такое "машинное слово" и прочей перспективы - уже нет) стали использовать этот WORD как синоним WORD16. Ну а дальше - понятно. Попробуйте представить, что у вас отвалится, если в версии BB 1.7 размер SHORT CHAR станет равным CHAR. Нет, если все правильно написано, то ничего не отвалится. Но вы все равно попробуйте

P.S. У меня был проектик (не очень большой), который я переводил на Win64 и который заработал сразу после перекомпиляции. И который с 95% вероятностью заработал бы даже если int на Win64 стал 64-битным. Этот же проектик до этого был переведен на юникод с несколькими багами. Но я знаю другой проектик примерно такого же размера, который никогда не заработает на Win64, который никогда не будет скомпилен как юникодный и у которого даже опции компиляции лучше не трогать И не потому, что он жуткий системный драйвер на ассемблере или еще чего в таком духе. Нет, оба проектика примерно из одной области, разрабатывались примерно в одно время (задолго до появления Win64), только код написан разными людьми Причем если смотреть в целом по области - проектов второго типа сильно больше

Приводить тип.




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

Может, и так было.

Вот читаю я сугубо техническую ветку, и дивлюсь...
Коллеги, вы себя со стороны то видите?

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

А ведь 32-разрядная техника появилась совсем недавно. И машинное слово на всей доступной технике было 16-разрядным большую часть времени. И это слово было во всю ширину шины. Т.е. программист практически проводки дергал, записывая 16-разрядное слово в переменную типа WORD.
Так что не надо говорить про "перспективного зрения + крайнюю самоуверенность". Давайте как-то более уважительно к труду предыдущих поколений, однако, относиться.
И про шизофрению я бы тоже попросил не упоминать, поскольку это очень серьезное психическое заболевание.
Я прекрасно помню и программирование на ассемблере для ZX-Spectrum, и первые XT, и PIC, где биты считаешь.

В любой деятельности нужны какие-то незыблемые вещи, что-то, от чего можно оттолкнуться (и не надо тут напоминать мне про законы Мерфи). Байт - 8 бит (где это не так, об этом все знают), слово - 16 бит (где это не так, об этом все знают), двойное слово - 32 бита (где это не так, об этом все знают).

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

До 16-ти разрядных были восьми-разрядные. И я прекрасно помню программирование под сегменты памяти под DOS, и помню времена, когда под символы отводилась табличка из 256 значений.

Проблема в том, что "незыблемым" в ИТ почему-то считается только то, что есть здесь и сейчас. А возможности техники в своё время росли быстрее, чем человек нащупывал эту самую незыблемость.

"Расщепление ума" возникает в момент, когда читаешь про "машинное слово" и тут же понимаешь, что тип WORD, хотя вроде про это, но не совсем. Отсюда и вопросы у людей - как сопоставить все эти названия, ведь кроме базовых понятий, надо ещё знать про некие преходящие традиции.

И причём здесь оберон, не совсем понимаю. Это просто размышления на тему.

P.S. Заглянул тут в историю x86-й архитектуры: http://jriddell.org/programs/essays/x86-essay.html
Интересно, что 8086 процессор (16-ти разрядный) появился в 1978 году. А уже в 1985 появился 32-разрядный 386-й. Промежуток в 7 лет. И 16-разрядный код уже стал legacy. Это я и имел в виду, говоря об отсутствии перспективного зрения. Горизонт - в несколько считанных лет, всего лишь.

В том то и дело, что традиции надо знать.
Это свойство человека, свойство психики (тут info21 чего-нибудь скажет про приматов) - иметь традиции. Мы живем в мире, где опыт живших даже 10 лет назад часто оказывается неприменимым.
То, что представляло ценность для моего деда сейчас для меня бессмысленно, поскольку неприменимо. Но это не значит, что ценности моих предков плохи или шизофреничны.

Точно также и здесь.
Страничная сегментация была данностью на таком кол-ве аппаратуры, что на принятии этого факта выросла целая армия программистов, я в том числе. И сейчас, когда мы находимся совсем в других условиях, показывать пальцем и говорить о том, что "word" и "машинное слово" - не одно и тоже, на мой взгляд является чтопроявлением высокомерия, а значит неразумно.
Неразумно потому, что:
- из спора "профессионалов" новый пользователь не вынесет ровным счетом ничего;
- те, кто в курсе, увидят, что на этом форуме могут облить грязью ни за что;
- нарушается историческая связь между поколениями, как бы пафосно мои слова не звучали.
Гораздо разумнее было бы сказать, что "принято считать WORD равным 16 битам, а DWORD - 32 битам, что соответствует SHORTINT и INTEGER". Почему - смотри учебник по С. А не объявлять о шизофреничности ИТ.
Знаете, мне в целом не очень нравиться поговорка "сто миллионов американцев не могут ошибаться", но что-то в этом есть...
PS. Оберон есть в названии сайта

Умалчивать о том, что традиция x86 довлеет над смыслом типа WORD тоже не стоит, я думаю.

Важно не то, какая традиция, важно то, как мы к ней относимся.

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

Считаю эмоциональную составляющую темы закрытой.
Если остались еще вопросы по портированию (и осталось еще желание обсуждать, см. предыдущие сообщения), можем обсудить.

Немного уточню (резюмирую).

Трактовка машинного слова относится к конкретной архитектуре. Так в текущей нотации Интел (как наиболее распространённой в массах, исчисляем от процессора Pentium) размер машинного слова составляет 32 бита. Соответственно есть ещё полуслово в 16 бит, двойное слово 64 бита и квадрослово 128 бит.

Обозначения WORD, DWORD и QWORD и соответствие им 16, 32 и 64 имеет исторический характер и просто устоялось в умах. Нарваться на другую размерность этих обозначений, я думаю, можно в ассемблерах для разных процессоров. Также, на сколько я помню, этих обозначений нет в стандарте Си, а наиболее широкоиспользуемый там тип int является машинно-(компиляторо-)зависимым.

Совершенно правильное общее замечание. Тем более учитывая, что форум теперь индексируется поисковиками.

Значит, я был неправ, и обозначение WORD на платформе x86 не имеет прямого отношения к машинному слову.

P.S. Слово "шизофрения" по отношению к некоторым аспектам ИТ я употребил не в клиническом смысле (странно было предположить обратное, я ж не психиатр), а скорее, в философском, близком к этому: (http://ec-dejavu.net/s-2/Schizophrenia.html).

И уж тем более, глупо с моей стороны было бы поливать отрасль, в которой тружусь сам и которая меня кормит. Согласен, что критические выпады лучше было бы выкладывать в другой теме. А с другой стороны, без этого не произошло бы копания в истории, которое связывает прошлое (из которого нам прилетел привет в виде DWORD - кстати, DWORD является частью спецификации Windows API, которую можно легко найти на msdn.microsoft.com) и настоящее (типы данных КП).

Задумывайтесь о чем пишите, Иван. Кто ещё предлагал подобное?

Ага, вот Блэкбокс -- что же сразу не сделали поддержку Юникода, не думали об перспективе? Да и, судя по форуму, с совместимостью между 1.5 и 1.6 тоже не всё гладко...