Проект на чистом Си

Кстати, паровозостроение живо:

Dampflokwerk Meiningen is the only facility in Europe capable of constructing new locomotive boilers up to modern standards of construction, performance, and safety. The newly built British steam locomotive 60163 Tornado that was delivered in 2008 had her all-steel, high-performance boiler made at Meiningen; the only part that could not be made in Britain

Ваш прекрасный char* крайне небезопасен

Язык системного программирования и не может быть сильно безопасным - иначе на нем будет не написать всякие железозависимые вещи. Предполагается что использующий этот язык достаточно грамотен чтобы не слишком часто стрелять себе в ногу.

А как на лично мой взгляд - куда более неприятно обрезание разрядности при сложении вида long = int + int. Казалось бы программист предусмотрел возможность «невлезания» результата и выделил более длинный тип. Но нет - компилятор всё равно тупо обрезает результат перед присваиванием. Хотя мог бы и догадаться сделать разумное приведение типов. В других-то случаях много где делает.

и даже не умеет конкатенацию по плюсу.

Вот это пожалуй единственный недостаток. Но чтобы его обойти - пришлось бы делать неявное выделение памяти под результат такой конкатенации. А это в системном программировании неприемлимо.

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

Лишь чуть менее неявное, чем strcat

Ты конечно прав. Мне изначально стоило сказать, что их очень легко игнорировать. Вроде и стоит обратить внимание, но здесь и сейчас не обязательно, можно отложить. А что делает человеческое внимание с вещами которые можно откладывать… Это вообще персонально.

Я выше начал было писать, что с удовольствием послушал бы аргументы >авторов 0-terminated строки, почему они заюзали такую неудобную дичь >вместо length в первых байтах.

Реализация строки с длинной в первом байте существует для Си как минимум с 90х годов - я тогда программистом работал и уже её видел. У обеих реализаций строк есть и свои достоинства и свои недостатки.

задумался, какой длины должно быть поле length Я так думаю длина должна быть такой, с которой могут оперировать процессорные команды сложения/вычитания/умножения. У нас же язык системного программирования. Авторы вышеупомянутой виденной мной реализации были с этим согласны и там было 16 bit потому что писалось под процессор 80286,самый массовый в России на момент написания.

Например, path - строка; strerr() или как его там – строка.

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

дык path конкатенировать Дык stradd() пишем. Ровно также как можно сделать свой вариант функции конкатенации для своей реализации строк. Ну будет какой-нибудь addstr() или там concat() - не вижу разницы.

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

Керниган и Ричи делали и язык, и систему. Полагаю, у них было достаточно свободы.

Надо было выбрать самую современную реализацию - и стандартизировать её.

А «самая современная» - это какая?

конкатенировать их через +, как в нормальных языках, а не через дурацкий >strcat.

Не вижу особо принципиальной разницы. Дело привычки скорее. К тому же если делать конкатенацию плюсом то придется неявно выделять память под результат так как его длина заранее неизвестна в выражениях типа

str = str + «текст»;

А это тянет за собой опять же неявную обработку ошибки переполнения. Куда это всё пихать например в микроконтроллерах? Да и так в языке системного программирования неявная работа с памятью это плохо.

А как на лично мой взгляд - куда более неприятно обрезание разрядности при сложении вида long = int + int. Казалось бы программист предусмотрел возможность «невлезания» результата и выделил более длинный тип.

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

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

надо было сделать в си как в питонах

Как потом на этом писать для всяких встроенных систем где типичную для десктопа «кучу»(heap) не сделать? Должен же быть какой-то язык в роли «переносимого ассемблера» - вот Си таким и является. Кому надо больше удобств - не пишите на ассемблере,пусть и переносимом. Кто жалуется на неудобство классических сишных строк - просто используют язык не по назначению. А так-то я в начале 90х видел программу складского учета в спортивном магазине,реально написанную на самом настоящем асме x86. Но это не значит что так надо делать.

А «самая современная» - это какая?

Комитет по стандартизации начал свою работу в 1983. Вот, какая была на момент 1983 самая современная - ту и взять, чо б нет. Языкостроение высокого уровня уж почти 20 лет развивалось, были достаточно совершенные концепции.

Куда это всё пихать например в микроконтроллерах?

Куда-то же пихали в ZX-80

Sinclair BASIC Изначально разработан в 1979 году для размещения в 4 килобайтах ПЗУ

Да и так в языке системного программирования неявная работа с памятью это плохо.

Ничуть не хуже абстракции а=b+c. Вы сами пишете, что всё зависит от размеров типов a, b и с - а язык и компилятор от вас эту кухню скрывают!

Короче, кошмарно-непонятная и мутная эта штука – строка.

Это вы еще не сталкивались с реализациями комплексных чисел и операциями с ними. Там и мнимая -1 бывает. И физикам она нужна. Поэтому они по сей день используют «морально устаревший» Фортран где это более-менее стандартизовано. На Си - тоже можно, но уровень комфорта будет примерно такой же как strcat вместо «плюсика». Но и это тоже не недостаток Си,а просто следствие непредназначености Си для высшей математики. Помянутый ранее системный драйвер мыши тоже неудобно писать на Фортране. Но никто и не пытается. А тащить Си в те задачи для которых он не предназначен - почему-то пытаются регулярно. Потом жалуются на неудобства.

мало языков со стандартом, Фортран ещё

Самый полный и точный стандарт у ADA. Но он весьма объемный и изучать его большинству Лень. Вот и пихают Си не по назначению в чисто прикладные проекты. Уж лучше бы прикладной софт на паскале писали - там всё-таки существенно более строгий компилятор, не пропускающий глупые ошибки.

поддержки от ИДЕ нет

Вообще-то совсем недавно вышел очередной Lazarus и у него таки есть IDE. Как раз недавно в новостях было и там же была картинка внешнего вида этого IDE.

https://www.opennet.ru/opennews/art.shtml?num=60333

в ВУЗах не преподают

По сей день преподают,хотя и не так массово как раньше. Особенно там где программирование это не профильный предмет,электронщикам например.

вакансий нет

Есть. Не у нас конечно. Так и кремниевая долина не в РФ находится. А там есть вакансии и на более специфические языки типа ADA и даже COBOL.

средство решения промышленных задач

В «промышленных задачах» и куда более редкие языки попадаются Например те что входят в стандарт МЭК 61131-3, их там аж пять штук.

А вот в деревне Золупино до сих пор работает паровоз. Паровозостроение >живо!

Ну с некоторой точки зрения,например в сравнении с размерами России, Европа это большая деревня. И там таки весьма много паровых поездов,используемых для туристических целей. Да и у нас РЖД довольно успешно занимается развитием этого направления туризма.

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

В России последняя лицензия на предоставление пейджинговой связи неограниченному кругу лиц закончилась только в прошлом году. Ведомственные системы вполне себе работают,например на некоторых АЭС так сделано оповещение персонала. В мире тоже такого хватает,например спасатели в Великобритании. Просто этот вид связи занял своё место там где он имеет преимущества, в первую очередь полную независимость от сложной инфраструктуры сотовых операторов,уязвимой при всяких черезвычайных ситуациях. Так что пример неудачный,в отличие от кремневых мушкетов.

В России последняя лицензия на предоставление пейджинговой…

Ну и зачем ты все это пишишь то? Что ты сказать хочешь? Что та же пейджинговая связь жива? Ну пусть это так будет в твоем мире, пускай. Мне все равно, как и остальным жителям Земного шара, половина из которых никогда в глаза не видели пейджер, а 99.99999% никогда больше не увидят. Но ты раскопал, нашёл, нагуглил, что где-то там в Британии спасатели… Ты победил! Задавил душными фактами. Доказал, что мой пример про пейджер - гавно, и про паравоз - гавно. И про кремневое ружье тоже гавно. Ты молодец, а я нет. Всё, ты имеешь стопроцентное преимущество в холиварах про Си, потому что в Британии еще используют пейджер, и ты нагуглил.

Вам или ассемблер, или шашечки.

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

Но я о том, что возможность работы со строками - должна быть из коробки.

Само понятие «коробка» восходит к временам,когда дистрибутивы продавались на дискетах и сидюках. Что купил(или унёс у знакомых) - тем и пользуешься. Потому что добыть что-то еще можно было только сходив ногами к тому,у кого оно есть. Лично я однажды в начале 90х за нужным мне дистрибутивом библиотеки ездил из Питера в город Тверь, покупал его там в каком-то местном кооперативе. Сейчас и компиляторы и библиотеки распространяются через интернет. И нет разницы - одну библиотеку качать,две или вообще несколько. Поэтому понятие «из коробки» к библиотека уже не применимо. Его еще можно как-то притянуть к поддержке строк,встроенной в сам компилятор,как writeln в Паскале. Но учитывая основное назначение Си как переносимого ассемблера - такое принудительное встраивание будет скорее во вред чем на пользу.

недостроки есть даже в ассемблере (внезапно!)

Далеко не в каждом (где они в AVR?). А там где есть,типа интеловских команд movsb,scasb - это скорее массивы,а не строки,как,собственно и в переносимом ассеблере (Си).

А её ведь хватает в 90% случаев.

Можно и вообще всё на ассемблере писать - технически его гарантированно хватит для 100% случаев. И я выше уже говорил,что реально когда-то видел в продакшене складской учет,написанный на асме. Потому что там была задача впихнуть его на болгарский клон PC XT c 512K памяти,который стоил в те времена как примерно полторы «Волги». Там кстати была использована весьма высокоэффективная СУБД «MDBS III». Но тогда труд программиста стоил копейки,а компы - очень дорого. Сейчас писать прикладной софт на асме нет никакого экономического смысла.

А можно какую-либо ссылку на K&R где бы подобное утверждалось?

Общеизвестно, что K&R использовали Си для написания операционной системы для машины PDP,именно как замену обычно применявшегося для этих целей в то время ассемблера.

Си от ассемблера столь же далек, как и любой другой язык того времени.

Классический Си без плюсов куда ближе к ассемблеру чем даже Паскаль или PL/1,не говоря уже о Явах и Питонах.

Классический Си без плюсов куда ближе к ассемблеру чем даже Паскаль

Только из-за побитовых операций и сдвигов (в Паскале же нет сдвигов из коробки, я не путаю?).

Само понятие «коробка» восходит к временам,когда дистрибутивы продавались на дискетах и сидюках. Что купил(или унёс у знакомых) - тем и пользуешься. Потому что добыть что-то еще можно было только сходив ногами к тому,у кого оно есть. Лично я однажды в начале 90х за нужным мне дистрибутивом

Скачать и один раз подключить я готов. Я не готов каждый раз писать соответствующий #include в заголовке. Реально бесит. Строки мне нужны практически всегда.

в Паскале же нет сдвигов из коробки, я не путаю?

Путаете.

в паскале есть и битовые операции и сдвиги.

Строки мне нужны практически всегда.

лев толстой.

Керниган и Ричи делали и язык, и систему. Полагаю, у них было достаточно >свободы.

В то время свобода была ограничена железом. Я писал для отечественного клона PDP называвшегося СМ1600.05, памяти там было 256К если правильно помню,причем не более 64К на один процесс. Система кстати была юниксоподобная ДЕМОС, вроде бы это какой-то клон клона BSD UNIX. (именно поэтому как только я в 90х смог купить себе комп с 8 МБ памяти то я на него сразу поставил один из первых линуксов,а не входившие тогда в моду винды). Так вот, у K&R в их варианте машины PDP - памяти было еще меньше,как бы не всего 64К. Так что встраивать в язык сложную и ресурсоемкую реализацию строк они не могли себе позволить.

Ну, тем более. Значит, Классический Си без плюсов ничуть не ближе к ассемблеру чем Паскаль

Держи пять! Есть такое.

Я не про времена создания сей Керниганом и Ричи, а про 80-е. Уж 10 лет с тех пор прошло, и компы с 256К памяти были обыденностью.

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

Как раз именно говорит и весьма однозначно. Я плохо себе представляю случай,где обрезка результата перед присваиванием может быть полезна на практике. Так что поведение компилятора весьма неудобное. Но оно как раз следствие близости Си к ассемблеру потому что такое сложение транслируется в одну машинную команду add.

Кстати, в Паскале (как минимум от Borland) эта особенность поведения тоже есть. И тоже,блин,без предупреждений при компиляции.

А вот компилятор ADA «додумывает» в этом случае правильно.

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

Вброшу немного.

Для Python это не проблема.

В принципе логично.

Куда это всё пихать например в микроконтроллерах? Куда-то же пихали в ZX-80

Микроконтроллеры - это не только STM32, но и Attiny13. Но даже если не брать столь экстремальный пример минимализма, то и у Atmega8 всего один килобайт памяти ОЗУ и 8К ПЗУ. Если занять его работой с продвинутой реализацией строк то может и не хватить под что-то более полезное. При сборке проектов под мелкие AVR с помощью avr-gcc для экономии программной памяти по умолчанию не линкуются даже процедуры для работы с числами с плавающей точкой пока явно это не укажешь. Хотя плавающая точка нужна существенно чаще чем продвинутые строки. Не такое уж редкое явление когда от лени писать своё натаскаешь готовых библиотек для работы с экраном, для работы с I2C датчиками,для работы с usb,еще что-нибудь,соберешь и оказывается что свой код из-за которого всё это затевалось - писать уже и некуда. Библиотеки-то ведь универсальные под все случаи жизни. И начинаешь из них нужные именно в данном применении куски кода вытаскивать.

Доказал, что мой пример про пейджер - гавно, и про паравоз - гавно. И про >кремневое ружье тоже гавно.

Невнимательно читаете. Я написал что пример про ружье - правильный. В отличие от пейджеров и паскаля вместе со всеми узкоспецивичными языками программирования.

Мне все равно, как и остальным жителям Земного шара, половина из которых >никогда в глаза не видели пейджер,

Я так думаю что очень значительно больше половины жителей не видели и языков из стандарта МЭК 61131-3. Но это не значит что они «мертвы». Просто они,как и пейджеры, и COBOL и FORTRAN имеют свою область применения.

Ну и зачем ты все это пишишь то?

Для восстановления объективности и строгости изложения. Мы же тут программисты,а не гуманитарии.

Что ты сказать хочешь?

Я сказал что ваше утверждение «язык Паскаль мёртв» == FALSE и привел доказательства.

Общеизвестно, что K&R использовали Си для написания операционной системы для машины PDP

да, это факт

именно как замену обычно применявшегося для этих целей в то время ассемблера.

ну, допустим. Как из этого вытекает утверждение «Си близок к ассемблеру». Назовите хоть одну концепцию языка Си, которая делает его ассемблером на стероидах. Вы же просто цитируете википедию, которую какой-то дебил писал.

Вот ту же самую википедию читаем:

Си создан на замену Би, который является прямым потомком BCPL, который создан на основе CPL, который создавался под влиянием Алгола и работал на машинах Титан и Атлас и его код выглядит вот так

Max(Items, ValueFunction) = value of
§ (Best, BestVal) = (NIL, -∞)
while Items do §
(Item, Val) = (Head(Items), ValueFunction(Head(Items)))
if Val > BestVal then (Best, BestVal) := (Item, Val)
Items := Rest(Items) §⃒
result is Best §⃒

с какой жопы Си стал ассемблером для PDP-11, господь его ведает, в голове у кото-то зашумело

Только из-за побитовых операций и сдвигов

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

в Паскале же нет сдвигов из коробки, я не путаю? В том,который действительно продавался в физических коробках с дискетами (Borland) - битовые операции есть. Да, я читал про очень старые компиляторы Паскаля,которые сам не застал, что там битовых операций действительно небыло. Так и в Си тех времен тоже много чего небыло что мы вполне привычным считаем(volatile,long double).

Я не готов каждый раз писать соответствующий #include в заголовке. >Строки мне нужны практически всегда. Так ведь и для использования обычных сишных строковых функций надо включать string.h

Берешь Quakespasm или любой форк, наворачиваешь новомодные шейдеры, фичи, создаешь убиицу анрылов, юнитей и прочих годотов. А ну и это добро портируй на Playstation 2, будь добр.

А серьезно, можно почитать какие есть проектики для вдохновения:

https://github.com/oz123/awesome-c

Для Python это не проблема.

Я честно скажу что толком Питон не знаю,разве что на уровне поправить какую-то мелочь в чужом небольшом куске кода. И в процессе таких правок мне не понравилась нестрогость Питона в отношении типов переменных. В чужих исходниках часто попадается просто присваивание начального значения переменной без указания типа. По принципу «что присвоили,такая и будет». Может дело в программистской лени,а может сам Питон не позволяет явно указать тип. Впрочем, я понимаю что мое мнение субъективно так как встречал программистов,которым наоборот такие вольности с типами нравились. Наверно им Питон хорошо подходит.

Но даже если не брать столь экстремальный пример минимализма, то и у Atmega8 всего один килобайт памяти ОЗУ и 8К ПЗУ.

Вы не поверите, но в ZX-80/81 был

1 КБ статического ОЗУ и 4 КБ ПЗУ.

и Sinclair BASIC, поддерживающий строки.

Еще и потому что для кода на Си опытный программист,даже любитель, более-менее представляет во что написанное им скомпилируется

М-м-м, с учётом оптимизаций компилятора - ни хрена там не то будет. Сколько раз смотрели, что там воротит компилятор Borland C++ - этожжжесть, даже для чистого С. Не, разобраться в итоге можно, но придётся попотеть. А самое главное, смысла в этом разбирательстве мало.

Назовите хоть одну концепцию языка Си, которая делает его ассемблером на > стероидах.

Я даже погуглил что может означать словосочетание «концепция языка». Ничего достаточно внятного не нашел, особенно применительно к языкам программирования. Околофилософские статьи на тему «человеческой» лингвистики не в счет.

А на мой взгляд (возможно что и неправильный), ассемблером на стероидах делает возможность структурного программирования в человекочитаемом виде,но с сохранением достаточно однозначного понимания во что это скомпилируется. Особенно актуально в написании всяких системных и близких к железу вещей - потому и аналогия с ассемблером.

Вы же просто цитируете википедию

Я «цитирую» книжки,написанные лет за двадцать до появления википедии и примерно тогда же мной прочитанные.

Си создан на замену Би

А можно уточняющий вопрос - на какой машине работал Би и заменил ли его Си на этой машине? Или всё же его под PDP сразу делали и прицелом систему на нем писать? Как-то вот про PDP+Си все знаем,а где был Би - умалчивается.

потому что выражение

long1 = int1 + int2;

транслируется в

mov reg_int, int1
add reg_int, int2
mov long1, reg_int

а вот выражение

long1 = (long)int1 + int2;

в

mov reg_long, int1
add reg_long, int2
mov long1, reg_long

выбор разрядности делается по типу операндов. а не по типу результата.

пример - длинное сложное выражение навроде

long = (int + int*(short / short) * int) / int...

по вашей логике поскольку результат - long - то все выражение надо считать в long?… это логика неправильная. длина и сложность выражения ничем не ограничена. и считается оно в текущей разрядности операндов(самого длинного в данной бинарной операции ).

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

в ZX-80/81 был 1 КБ статического ОЗУ и 4 КБ ПЗУ. и Sinclair BASIC, поддерживающий строки.

Вопрос лишь в том,сколько тех строк в этот килобайт влезало и что там с ними можно было делать.

Это как ядро линукса загрузить на машине с совсем маленькой памятью. Ядро влезет,приглашение bash выдаст и всё - ничего хоть сколько-нибудь полезного уже не запустить.

Я так думаю именно поэтому у Синклера быстро стало 16К ОЗУ.

Не, разобраться в итоге можно, но придётся попотеть.

Вот именно что можно. Для более высокоуровневых языков уже не реально.

А самое главное, >смысла в этом разбирательстве мало.

Наличие смысла зависит от задачи. я например на Microsoft C 5.10 немало писал под малосерийные/штучные железки. И требовалось сочетать Си с Ассемблером. Поэтому разобраться пришлось. Потом даже под PharLap DOS Extender писал (защищенный режим 80826) - тоже получалось. А там чуть не туда обратился и всё, аппаратный exception. Там не так как сейчас в линуксе весь свой код грузится в один кусок памяти и твори там что хочешь,а защита работала даже внутри программы. Сделать call куда попало нельзя - только на точку входа объявленной функции. Можно было массив в отдельный сегмент поместить и исключение вылетало при попытке обратиться за его границу. Ну и так далее. Было интересно. Жаль что всё это потом было похерено Микрософтом и Интелом.

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

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

Логика не моя,а создателей стандарта и компилятора языка ADA. Там этой глюкофичи нет. А то что лично мне поведение Ады в этом случае нравится больше чем поведение Си (и борландовского паскаля тоже) - это уже конечно мои личные предпочтения.

Я так думаю именно поэтому у Синклера быстро стало 16К ОЗУ.

Да. Тем не менее, накладные расходы на обработку строк мизерные, 4К ПЗУ и 1К ОЗУ достаточно.

PharLap DOS Extender - да, кровушки попил изрядно. Так я его и забросил.

а причем тут ада?

разрядность приемника может быть обусловлена лишь совместимостью с неким типом.

пример.

void ff(long* p);

...
long ll = int1 + int2;
ff(&ll);

есть функция требующая long*. но пусть в данном конкретном вызове int1 и int2 не могут дать переполнения, и потому длинная операция избыточна.

по логике си и прочих - тут и не будет длинной операции. по логике ада - будет. но она избыточна.

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

ассемблером на стероидах Си делает возможность структурного программирования в человекочитаемом виде

Забористо!

Или всё же его под PDP сразу делали и прицелом систему на нем писать?

Уважаемый watchcat382, вот вам архитектура PDP https://en.wikipedia.org/wiki/PDP-11_architecture, будьте добры, облейте меня мудростью и утопите в величии вашего интеллекта ответив на вопрос, что конкретно из этой архитектуры нашло отражение в систаксисе языка Си, и каким бы получился Си если бы его писали с прицелом на архитектуру, скажем, Z-80. Спасибо

а причем тут ада?

При ее удобстве для прикладных проектов значительного размера. Язык сильно недооценен народными массами из-за его малой распространенности в «общегражданском» программировании. На нем пишут в во всяких промышленных применениях с особыми требованиями. Там где тяп-ляп и в продакшн не прокатывает.

по логике си и прочих - тут и не будет длинной операции. по логике ада - >будет. но она избыточна.

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

У Ады вообще всё с типами и их приведением очень хорошо. Там типы - это именно что строго определенные сущности. Создал два разных типа производных от целого - да, физически это такие же целые,с совершенно одинаковым внутренним представлением. Но вот просто так втупую написать их сложение - нельзя,компилятор ругнется. И это избавляет от всевозможных вариантов сложения метров с килограммами.

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