Я, конечно, не программер. Но, по-моему, из приведённого выражения следует только то, что int не может быть больше long, а short - не больше int. Т.е. int может быть 4 байта, а long 2 байта - НЕТ.Цитата:
Сообщение от andreyu
Вид для печати
Я, конечно, не программер. Но, по-моему, из приведённого выражения следует только то, что int не может быть больше long, а short - не больше int. Т.е. int может быть 4 байта, а long 2 байта - НЕТ.Цитата:
Сообщение от andreyu
Массив байт - для арифметики как-то не очень.
Современные каноны программирования на C, особенно для встраиваемых систем, отказываются от традиционных типов int, short и long, и рекомендуют использовать только заданные точно типы: int8_t, int16_t, int32_t, int64_t и их беззнаковые аналоги. Так что нет смысла здесь копья ломать. Пишите так, чтобы программа не зависела от ширины int, short и long на конкретной платформе.
Собственно, откуда взялась эта идущая родом из истоков языка C неточная спецификация на ширину целых чисел? В те времена считалось, что пусть программист укажет, что желает работать с таким целым типом, который наиболее удобно представим на целевой платформе. Компилятор же решит, какая у этого типа будет ширина. Но на практике оказалось, что программисты пишут программы исходя не из наихудшего случая (т.е., к примеру, не допускать, чтобы переменные int выходили за диапазон -32768...32767, так как на некоторых компьютерах int могут иметь ширину 16 бит), а из той ширины типов, которая принята на платформе, под которой работает программист. И в конце концов вместо улучшения портируемости программ произошло ее ухудшение.
В самом деле, пусть уж лучше портированная программа работает медленно, но правильно, чем сбивается или того хуже - чтобы в ней из-за переполнений образовывались дыры безопасности.
Ситуация усугублялась несовместимостью библиотек и причудами компиляторов. В начале 2000х я пытался писать программы на C и C++ исходя из "наихудшего случая - 16 бит на int". Там, где были нужны 32-битовые переменные - использовал long. Но однажды мне пришлось компилировать свои программы на другой платформе, а там был принят стандарт: long = 64 бита. В результате съехали все размеры структур, и программа не смогла работать с двоичными файлами, с которыми она должна была работать. Так что даже программирование под "наихудший случай" не позволяет избегать проблем с портируемостью кода на С; более того, в данном конкретном случае мои усилия оказались даже вредными. Использовал бы int - все работало бы нормально.
Так что теперь я перешел на типы фиксированной длины, разве что, кроме случаев, когда какая-нибудь библиотека или API требует старого традиционного типа. Чего и остальным советую.
Записываю сюда чтобы не забылось:
В последней версии Rust (1.11) добавлена поддержка 16-битных указателей: https://github.com/rust-lang/rust/bl...110-2016-08-18
(имеет отношение к теме; rust - "низкоуровневый" язык использующий LLVM для компиляции)Цитата:
Не взлетит. Только на одн... Держится. Без мотивации
Вот тут пишут, что есть работоспособная реализация LLVM для Z80, поддерживается в том числе и 32bit int. Статья с примерами компиляции (используют clang):Цитата:
Сообщение от mastermind
С-систаксис: https://olduino.wordpress.com/2014/1...f-inspiration/
С++: https://olduino.wordpress.com/2015/0...llvm-compiler/
Это кто то из наших таки добил гадину? И вообще, пробовал ли кто-то с помощью этого варианта LLVM собрать что-то приличное?
Судя по нику топикстартера - по ссылке это как раз его наработки. Просто здесь движуха отсутствует напрочь.
Выглядит похоже. Хоть бы автор отписался что да как, съэкономил нам время на исследования методом проб и ошибок. :)Цитата:
Сообщение от shurik-ua
У EARL последний коммит в 2013 году, о чем вы говорите.
- - - Добавлено - - -
А так вообще вот чувак более живой, пилит что-то: https://github.com/jacobly0/llvm-z80
Я так и не доделал все до конца в связи с отсутствием времени и некоторыми проблемами в понимании как реализовать нужные мне вещи в LLVM. Примеры по ссылкам выдают как раз тот код, который и у меня был, т.е. вряд ли там кто-то что-то еще допиливал. Могу заверить, что некоторые конструкции просто не скомпилируются и поэтому проект неработоспособный.Цитата:
Сообщение от Error404
Да, у этого человека в настоящий момент идет понемногу движуха, но я не пробовал тестировать его код.Цитата:
Сообщение от Shadow Maker