Разговор о разном в науке и технике

[kichrot]

Не важно, как пишет CASTRO. Важно, что в общем случае Ваше утверждение "- в программах на ассемблере каждый байт функционален в рамках задач программы." - неверно.

А доказательство моей неверности где???  
А нету.  

Несомненно.

Здесь, уважаемый СASTRO СОГЛАСИЛСЯ, что при компиляции программ, написанных с использованием объектно ориентированных языков программирования, всегда присутствует программный мусор, который ни когда не используется в процессе функционирования программы.

Смотрим, что дальше:

Только это не делает осмысленным Ваше утверждение: "- в программах на объектно ориентированных языках больше половины строк кода, если развернуть встроенные процедуры и функции описывающие классы и объекты, присутствуют в программе мертвым грузом, ни когда не используясь."

Так что пальчики загните.

А вот здесь, уважаемый СASTRO НЕ СОГЛАСИЛСЯ, что при компиляции программ, написанных с использованием объектно ориентированных языков программирования, всегда присутствует программный мусор, который ни когда не используется в процессе функционирования программы.

Уважаемый CASTRO, Вы уж, как нибудь, определитесь со своим мнением, по одному и тому же вопросу.  

[BJIaquMup]

Запросто. Когда человек делает утверждения, несоответствующие действительности. Этим самым он автоматически опровергает реальность 

Ну, вот вы на моём примере и покажите.

[kichrot]

Ну, вот вы на моём примере и покажите.

Зачем Ваш пример?
Alexpo с успехом показывает на своем примере. 

[CASTRO]

А доказательство моей неверности где???  
А нету.  

Здесь, уважаемый СASTRO СОГЛАСИЛСЯ, что при компиляции программ, написанных с использованием объектно ориентированных языков программирования, всегда присутствует программный мусор, который ни когда не используется в процессе функционирования программы.

Смотрим, что дальше:

А вот здесь, уважаемый СASTRO НЕ СОГЛАСИЛСЯ, что при компиляции программ, написанных с использованием объектно ориентированных языков программирования, всегда присутствует программный мусор, который ни когда не используется в процессе функционирования программы.

Уважаемый CASTRO, Вы уж, как нибудь, определитесь со своим мнением, по одному и тому же вопросу.  

1) Если Вы под нефункциональностью называете "неиспользуемые" байты в исполняемом файле, то они - следствие использоания библиотек. Такая ситуация присутствует в любых языках, а не только в объектно-ориентированных. Она и в ассемблере есть.

2) Современные компилляторы выдают машинный код, близкий к оптимальному. Настолько близкий, что среднестатистический программист на ассемблере создаёт код более громоздкий. И дело тут не в мастерстве программиста.

3) Кроме того, распространённое заблуждение состоит в том, что чем компактнее исполняемый файл - тем лучше соптимизирована программа. Это далеко не всегда верно. Часто наоборот: ускорение работы увеличивает экзешник.

4) С исходниками то же самое: число "неиспользуемых" строк кода зависит не от того, объектно-ориентированный язык или нет, а от того, сколько и каких библиотек Вы прицепили к программе, которые будут обработаны на уровне препроцессора.

[alexand]

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

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

[CASTRO]

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

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

Системное программирование на ассемблере? Ню-ню. Жёстко.
На самом деле, конечно, сейчас всё делается на языках высокого уровня и, прежде всего, на C/C++

[Петр Иванович]

Различная электроника, в том числе релятивистская. Генераторы разные, я о них в теме про СУРУ рассказывал. Кстати релятивистская электроника - это еще одно из экспериментальных обоснований СТО - работает в соответствии с ней...

Что за чушь ты несешь, дорогой?

Задайте конкретный вопрос, попробую ответить.

Что такое "релятивистская электроника" ?

[Петр Иванович]

Я уж молу, что между ассемблером и машинними кодами - колоссальная пропасть.

Неужто?
 
И в чём заключается эта пропасть?

[alexand]

Да, при современных объемах памяти и быстродействии
не нужно очень экономить.

Но, как упоминал и тов Алекспо,
для программирования ОС небольших контроллеров,
с небольшой памятью, применяют чистый Ассемблер.

[Петр Иванович]

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

По сути, программирование на ассемблере ничем не отличается от программирования в машинных кодах.
Единственное отличие - оно нагляднее ля человека, мнемонически понятнее...
Разумеется, всегда проще написать и потом понять MOV AX,0123 чем B82301 (еще "понятнее" это выглядит в двоичном виде)
Но на этом вся разница между машинными кодами и ассемблером заканчивается.
---
Забавно видеть, как о программировании рассуждают наши метные "великие физико-теоретики" - два Алексея.
 

[kichrot]

1) Если Вы под нефункциональностью называете "неиспользуемые" байты в исполняемом файле, то они - следствие использоания библиотек. Такая ситуация присутствует в любых языках, а не только в объектно-ориентированных. Она и в ассемблере есть.

Альтизм высшей меры, проявляете уважаемый CASTRO.

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

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

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

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

2) Современные компилляторы выдают машинный код, близкий к оптимальному. Настолько близкий, что среднестатистический программист на ассемблере создаёт код более громоздкий. И дело тут не в мастерстве программиста.

Чушь.  

3) Кроме того, распространённое заблуждение состоит в том, что чем компактнее исполняемый файл - тем лучше соптимизирована программа. Это далеко не всегда верно. Часто наоборот: ускорение работы увеличивает экзешник.

А я про быстродействие и не писал. С точки зрения скорости исполнения программы необходимо прежде всего говорить об оптимальных быстрых алгоритмах.
Но даже здесь, при прочих равных, по объему программ с одинаковым функционалом, можно косвенно судить и о качестве программирования и о скорости выполнения. Практика показывает, что такая зависимость прослеживается.

4) С исходниками то же самое: число "неиспользуемых" строк кода зависит не от того, объектно-ориентированный язык или нет, а от того, сколько и каких библиотек Вы прицепили к программе, которые будут обработаны на уровне препроцессора.

Только тупые программеры цепляют к программе модули которые или не используют (по принципу хай буде, вдруг пригодится), или используются в малой мере.
Нормальный программист, всегда, если процент использования стандартного модуля мал, выдернет из стандартного модуля необходимую процедуру или функцию и включит в свой, используемый на 100 процентов модуль.

Но так не получится с классами.

Уважаемый CASTRO, не спорьте, ради спора там, где Вы альт.

[alexand]

Наверное, дядь Петь, релятивистская электроника -
та, где есть релятивистские электроны.

А еще, говорят, могут быть релятивистские тяжелые атомы.
Вроде они еще не получены в эксперименте.

[kichrot]

Системное программирование на ассемблере? ...

Примеры есть, Вы сами знаете. 

[evilimp]

1) Если Вы под нефункциональностью называете "неиспользуемые" байты в исполняемом файле, то они - следствие использоания библиотек. Такая ситуация присутствует в любых языках, а не только в объектно-ориентированных. Она и в ассемблере есть.

Это не так. В ассемблере для этого надо очень постараться. ООП порождает много мертвого груза в бинарниках.

2) Современные компилляторы выдают машинный код, близкий к оптимальному. Настолько близкий, что среднестатистический программист на ассемблере создаёт код более громоздкий. И дело тут не в мастерстве программиста.

Да

3) Кроме того, распространённое заблуждение состоит в том, что чем компактнее исполняемый файл - тем лучше соптимизирована программа. Это далеко не всегда верно. Часто наоборот: ускорение работы увеличивает экзешник.

Обычно да

4) С исходниками то же самое: число "неиспользуемых" строк кода зависит не от того, объектно-ориентированный язык или нет, а от того, сколько и каких библиотек Вы прицепили к программе, которые будут обработаны на уровне препроцессора.

Это не так. Например, в С++ предполагается раздельная компиляция.
В этом случае выяснить какие функции никогда не вызываются является совершенно нетривиальной и не всегда решаемой задачей.
Соответственно они будут присутствовать в исполняемом файле.
Кроме того, именно для ООП требуется специфическая поддержка времени выполнения, которая увеличивает мертвый груз.

Что до препроцессора, то он вообще не работает с библиотеками. Сколько их не прицепляй.

[evilimp]

Но, как упоминал и тов Алекспо,
для программирования ОС небольших контроллеров,
с небольшой памятью, применяют чистый Ассемблер.

При программировании "небольших контроллеров с небольшой памятью" ОС вообще не используют за ненадобностью.
На ассемблере пишут в случае крайней нужды обработчики прерываний.

[evilimp]

По сути, программирование на ассемблере ничем не отличается от программирования в машинных кодах.
Единственное отличие - оно нагляднее ля человека, мнемонически понятнее...
Разумеется, всегда проще написать и потом понять MOV AX,0123 чем B82301 (еще "понятнее" это выглядит в двоичном виде)
Но на этом вся разница между машинными кодами и ассемблером заканчивается.

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

[Петр Иванович]

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

Интересно узнать, что значит "профессионально написанной" ?
Видишь ли, есть несколько совершенно разных школ программирования...
Есть несколько совершенно различных языков программирования, которые используют разные приёмы компиляции и линкования...
Да чего там долго ходить - самый широко используемый компилятор gss (это для -NIX систем) постоянно совершенствуется...
Как-то лет этак 8 назад я писал программулю на QT3 для управления 100КВт антенными коммутатороми под ОС МСВС 3.0... и разумеется, компилил её тем, что было в комплекте МСВС... а потом ради интереса откомпилил под Мандривой 2006 с более новой версией gss... Размер исполняемого файла сократился примерно в полтора раза... при этом пропал некий геморрой, который иногда приводил к неприятному подвисанию при обмене коммутаторами между собой - так как соседние коммутаторы связаны между собой одним входом и выходом... а переключать их, когда Пурга давит в эфир всю сотню, да даже если обычный ПКМ-20 работает на половину мощности, нельзя... ячейку можно будет выбрасывать - возможно и не одну...
Я пару месяцев ломал себе голову, что же я написал в коде не так - но так и не нашёл ошибки...
Проблема была именно в компиляторе.
Коммутаторы работают нормально до сих пор.
Вот так-то...
Кстати, сейчас, недавно, 22 апреля вышел уже новый релиз gss - 5.1
---
Тебя убедил мой пример?

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

Моя племянница сейчас профессионально занимается проверкой различных ОСей и другого программного обеспечения для их использования в госструктурах, где ходят документы с грифом 00...
Рассказывает много интересного про разные "затычки", "хвосты" и т.д... написанные и оставленные различными "профессиональными программистами"... в т.ч. и теми, что работают на мелкомягких...

 

[Петр Иванович]

Альтизм высшей меры, проявляете уважаемый CASTRO.
...
Уважаемый CASTRO, не спорьте, ради спора там, где Вы альт.

Не правильно...
Вот как надо:
CASTRO, не спорьте, ради спора там, где Вы полный лох.
 

[Петр Иванович]

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

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

[alexand]

При программировании "небольших контроллеров с небольшой памятью" ОС вообще не используют за ненадобностью.
На ассемблере пишут в случае крайней нужды обработчики прерываний.

Генияльна!

А для станка с ЧПУ или робо-пылесоса не нужны небольшие ОС?

Ну, мудро назовите их УПами, тов Евилимпус.