LINUX.ORG.RU

Что нужно добавить в C?

 


0

5

Расскажите, что бы вы хотели добавить в си? Только то, что реально можно добавить, не делая при этом новый язык. Просто фичи, которых не хватает.

Или покритикуйте мой список.

  • Константы. #define - препроцессор, const не работает полноценно в compile-time, enum только для целых и вообще для другого .
  • Лямбды (анонимные функции) - для удобства коллбеков. Можно без замыканий, т. к. они много скрывают.
  • Модули, если возможно. Для изоляции единиц трансляции.
  • Интроспекция (typeof, хотя бы) - для обобщенного программирования.
  • Более развитая макросистема - для того же. Например, возможность макросы раскрывать в директивы препроцессора.
  • Пространства имен, чистые функции, switch по составным типам, case с диапазоном - для сокращения кода.
  • Аналоги volatile и restrict с более точным контролем - для микрооптимизации.
  • Доступ к стеку вызовов, goto между функциями - для трюков типа трамплинов.
  • В стандартной библиотеке - строки, контейнеры, foreach, большие числа. Возможно, сокеты.
★★★★
Ответ на: комментарий от unsigned

Модулей

Там есть классы, что гораздо гибче. И кстати, модули есть даже в Си.

интроспекции

Динамическая чушь. Кому надо, может запилить руками или взять Qt. Любители чистого Си могут взять glib.

макросов

Там есть шаблоны - те же яйца, вид сбоку.

чистых функций

Не понял что имеется в виду. В чем проблема писать на Си чистые функции?

switch, case

Сахарок. If else if else ничем не хуже. switch по целому типу имеет то преимущество, что может лучше оптимизироваться и можно реализовать в виде таблицы переходов, т.е. без применения сравнения вообще.

стека, goto

setjmp, longjmp есть даже в Си. В крестах есть сахарок в виде throw.

volatile, restrict

Вот непонял какой тебе нужен контроль. Классы + volatile недостаточный контроль?

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Модулей

Там есть классы, что гораздо гибче. И кстати, модули есть даже в Си.

В си есть единицы трансляции, а в модуле есть ещё метаданные о его содержимом, доступные самому языку. Как в java, python, pascal... Короче, практически везде. И модули предложены в стандарт C++, ведется их реализация в clang/llvm.

интроспекции

Динамическая чушь. Кому надо, может запилить руками или взять Qt. Любители чистого Си могут взять glib.

Речь о статической интроспекции. typeof, __func__ - примеры её огрызков, что есть в (гну) си.

макросов

Там есть шаблоны - те же яйца, вид сбоку.

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

чистых функций

Не понял что имеется в виду. В чем проблема писать на Си чистые функции?

Проблема сказать компилятору, что функция чистая. См. attribute((pure)) (и attribute((const))).

switch, case

Сахарок

Разумеется, сахар, как и foreach. Нужно для сокращения и читаемости кода.

стека, goto

setjmp, longjmp есть даже в Си. В крестах есть сахарок в виде throw.

Вот throw как раз не сахар, а новая часть семантики языка. Только вся эта компания не дает ни доступа к стеку, ни перехода в новую функцию (Что нужно добавить в C? (комментарий)).

volatile, restrict

Вот непонял какой тебе нужен контроль. Классы + volatile недостаточный контроль?

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

unsigned ★★★★
() автор топика
Ответ на: комментарий от no-such-file

Там есть шаблоны - те же яйца, вид сбоку.

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

anonymous
()
Ответ на: комментарий от unsigned

Как в java, python, pascal...

Ах как в паскале... Спасибо, не надо.

Речь о статической интроспекции

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

Макросы легко читаются, легко реализуются, отлаживаются

Какие именно макросы? Сишные макросы вообще никак не отлаживаются и о легкости реализации речи не идет. Если ты имеешь в виду макросы как в лиспе, то их простота и т.п. это не особенность макросов, а особенность лиспа как языка. Шаблоны в крестах - вполне адекватный подход.

Проблема сказать компилятору, что функция чистая

Во-первых если компилятор не дурак, то может сам догадаться, а во вторых, есть как ты сказал атрибуты. Жаль, конечно, что на уровне стандарта тут ничего не предпринято. Кстати, я не в курсе, а яве, паскале и т.п. есть возможность сказать что ф-ця чистая?

Разумеется, сахар, как и foreach. Нужно для сокращения и читаемости кода

Я, лично не вижу где switch/case короче чем if else if else.

switch (a) {
   case 1: do1(); break;
   case 2: do2(); break;
   case 3: do3(); break;
}

if (a==1) do1();  
else if (a==2) do2(); 
else if (a==3) do3();

По-моему if-else-if-else даже короче. И понятнее, плюс нет возможности пропустить break;

Только вся эта компания не дает ни доступа к стеку, ни перехода в новую функцию

В какую новую? По стеку можно перемещаться, да собственно в этом суть longjmp/throw. Если ты имеешь в виду просто переход на метку внутри произвольной функции, то такого бреда нет ни в одном языке, где есть функции. ЕМНИП.

тут синхронизируй абстрактное значение переменной с реальным, а там кешируй как хочешь

А зачем это нужно? Навскидку - используй две переменных, одну volatile, другую обычную, кэширующую первую. Для доступа к переменным испольуй 2 геттера волатильный и простой (кэширующий). Зачем тянуть это в язык?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Что есть полноценные макросы?

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

anonymous
()
Ответ на: комментарий от no-such-file

switch, case

Сахарок. If else if else ничем не хуже

Так можно договориться до того, что while и for - это просто сахарок поверх goto.

tailgunner ★★★★★
()
Ответ на: комментарий от no-such-file

Ах как в паскале... Спасибо, не надо.

Я вообще не припомню навскидку другого популярного языка, где нет модулей. Что по-твоему с ними не так?

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

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

Какие именно макросы? Сишные макросы вообще никак не отлаживаются и о легкости реализации речи не идет.

Сишные. Реализуются препроцессором, отлаживаются им же (т. е. можно посмотреть, во что раскрываются).

Шаблоны в крестах - вполне адекватный подход.

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

Во-первых если компилятор не дурак, то может сам догадаться

Да, если видит функцию.

Кстати, я не в курсе, а яве, паскале и т.п. есть возможность сказать что ф-ця чистая?

Нет, афаик.

По-моему if-else-if-else даже короче. И понятнее, плюс нет возможности пропустить break;

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

switch(msg) {
  case { .type == T1, .cmd == C2 }:
  case { .type == T2, .cmd == C5 }:  return foo();
  case { T2, C2 }:                   return 0;
  case { .type == T1 }: return error();
}

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

Примерно это, да. Такие трюки всё равно делают, только на ассемблере. Имхо, си должен (и может) это покрывать.

используй две переменных, одну volatile, другую обычную, кэширующую первую. Для доступа к переменным испольуй 2 геттера волатильный и простой (кэширующий). Зачем тянуть это в язык?

Читаемость похуже (а почему это тут две переменные?). А вообще вопрос больше принципиальный: раз уж ввели понятие абстрактной семантики, но абстракции при этом текут (а усложнять нельзя, потому что си) - дайте тогда уж механизм точечного отключения этих абстракций. Это предотвратило бы многие баги, вылезающие от того, что оптимизатор оказался умнее кодера - сейчас даже занулить пароль в памяти оказывается проблемой. Скажем, можно было бы распространить volatile для блоков кода (сейчас это по сути volatile asm). Можно было бы ввести барьеры, на которых происходит синхронизация (например, это нужно для setjmp). Тут лучше ядерщиков спрашивать, у них много таких приколов. И решается это только на уровне языка (сейчас решают другим языком, ассемблером).

unsigned ★★★★
() автор топика
Ответ на: комментарий от unsigned

Что по-твоему с ними не так?

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

Например, на них не напишешь обобщенную функцию сериализации. Разве что всю программу писать в шаблонах, но про это можно и не говорить.

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

Реализуются препроцессором, отлаживаются им же (т. е. можно посмотреть, во что раскрываются).

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

На замену макросам пойдет с натяжкой - если поступиться простотой.

Каким именно макросам? Сферическим в вакууме?

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

Из твоего примера неочевидно, что именно там происходит. А если написать тоже с использованием if else if else, то понять сможет даже паскалист.

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

Такие трюки всё равно делают, только на ассемблере. Имхо, си должен (и может) это покрывать

Кто и где это делает? На асме так делают, но там и нет функции как языковой единицы, а весь код виден как он есть, т.е. можно определить все эффекты от такого кульбита. В Си ты не видишь ассемблерный код и не можешь знать какие будут эффекты, не говоря уж о том, что не известно как это отразиться на стеке. В Си стек чистит вызывающая сторона, и если зайти в функцию через jmp то на стеке не будет параметров и после возврата будет жопа. Я ещё не вспоминаю о том, как отследить переменные выделенные на стеке в самой функции.

Читаемость похуже (а почему это тут две переменные?).

Я тебе русским языком сказал, что доступ через геттеры. getVolatileValue, getCachedValue, по-моему все просто и понятно.

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

И чтобы этот volatile делал бы? Отключал оптимизацию? Для этого нужно просто вынести код в отдельный модуль и собрать его без оптимизации. Делов-то.

Можно было бы ввести барьеры, на которых происходит синхронизация

Синхронизация чего?

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

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

no-such-file ★★★★★
()
Ответ на: комментарий от tailgunner

Так можно договориться до того, что while и for - это просто сахарок поверх goto.

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

А теперь скажи мне, чем обобщенный switch лучше if else if else? Switch по целому типу, как я уже сказал - особый случай, который можно соптимизировать, а вот switch , как обобщенный оператор нафиг не нужен, т.к. технически ничего не дает, но взамен требует усложнения компилятора и увеличения времени компиляции.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

А теперь скажи мне, чем обобщенный switch лучше if else if else?

У switch (как он реализован в Си и Си++) семантика другая - не проверка шашлыка условий, а _исчерпывающий_ выбор варианта действия в зависимости от значения _одной_ переменной.

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

Какая трогательная забота о компиляторах. Не стоит - они в своем деле давно уже умнее 99% программистов.

switch , как обобщенный оператор нафиг не нужен

Кстати, если ты не заметил... unsigned называет «обобщенным switch» нечто, очень похожее на pattern matching. Если pattern matching тебе не нужен - окей, оставайся в 70-х.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от no-such-file

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

это далеко не так - у Била Джоя ( это который vi и Sun ) есть буклет про Паскаль - и там с интеграцией модулей Паскаля с окружающим bsd? всё хорошо.

qulinxao ★★☆
()
Ответ на: комментарий от tailgunner

нечто, очень похожее на pattern matching

Но не паттерн матчинг. А тупо if-else записаный по-другому.

Не стоит - они в своем деле давно уже умнее 99% программистов.

Да именно это я и сказал. Но тебе лишь бы вякнуть.

У switch (как он реализован в Си и Си++) семантика другая

Да именно это я и сказал. Но тебе лишь бы вякнуть ещё раз.

no-such-file ★★★★★
()
Ответ на: комментарий от qulinxao

там с интеграцией модулей Паскаля с окружающим bsd? всё хорошо

Дай почитать.

Вообще моя претензия к модулям как в паскале или яве в том, что они не переносимы в том смысле, что формируют вместе с языком некоторую закрытую платформу, язык+модули. Си сейчас можно использовать безотносительно платформы, как метаассемблер. Если в стандарт внести модули, то это сильно сузит применимость языка и вызовет необходимость его дробления на версии. В итоге мы будем иметь 100500 разных вариантов си с той или иной глубиной поддержки модулей, в зависимости от платформы. Зачем? Только потому, что кому-то показалось хорошей идеей объединить объектные и заголовочные файлы в один «модуль»? В сегодняшнем положении вещей с модулями в си нет никакой технической проблемы, только организационная, которая решается сейчас уровнем выше - не языковым, а системным. И правильно, т.к. это системоспецифичная область.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

нечто, очень похожее на pattern matching

Но не паттерн матчинг

Деталей семантики он не привел. Впрочем, switch по целому числу - это такой очень ограниченный pattern matching.

чем обобщенный switch лучше if else if else?

У switch (как он реализован в Си и Си++) семантика другая

Да именно это я и сказал.

Забавно. Я даже не говорил, чем «switch лучше».

тебе лишь бы вякнуть ещё раз.

Мог бы просто попросить «защитай мне слив».

tailgunner ★★★★★
()
Ответ на: комментарий от no-such-file

Joy W.N. UNIX Pascal user's manual

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

у Си нет модулей у Си есть линковка как отдельная общая для обьектников вне зависимости от фортран это , асм это или сам его величество С-обьектник.

кури историю. формат исходных С-обьектников в который сс переводил забавные скобки это был формат бинарных обьектников местного ассемблера.

qulinxao ★★☆
()
Ответ на: комментарий от no-such-file

ну а про реальную модульность - очень хорошо у Оберона где можно на горячую заменять модули и даже расширят их интерфейсы.

а даже у жабки на эту тему есть интерестности.

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

у Си нет модулей

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

у Си есть линковка как отдельная общая для обьектников вне зависимости от фортран это , асм это или сам его величество С-обьектник.

В том то и дело, что это не относится к си как к таковому, организация линковки - дело операционной системы, ну или среды разработки в недоОС. А вот введение модулей в язык, делает всю эту кухню проблемой языка. Зачем тащить дела ОС в язык? Я понимаю, что в бородатые времена, когда ОС и средства разработки были слабо развиты, такой подход был популярен. На первых персоналках вообще, встроенный язык выполнял роль ОС, но зачем тащить это сейчас в язык. Независимость от ОС я считаю прорывом си. Именно это позволило прозрачно перейти к динамическим библиотекам без какого-то изменения языка.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

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

вот тот же Unix&C по факту ОС это сборщик муссора в том числе ,а С- программа даже не обязана ( и у патриархов сплош и рядом так код и написан) free-шеть mallocнутую память С- программе достаточно свялится , а ОС похоронит трупик и вернёт всё в биогеоценоз.

поэтому как и модулю а сей нет штатного сборщика муссора.

а теперь вопрос:

а почему в С есть автоматические переменые и стек встроин в язык - это ведь излишество?

qulinxao ★★☆
()
Ответ на: комментарий от no-such-file

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

ща как раз есть проблема когда на уровень языка тащат всё

однако посмотри на эволюцию С-->golang - так как оба языка предназначенны в том числе для исполнения на голом железе замечательно почему в golang добавили то чего не было 40 лет назад в С ( хотя и тогда всё что добавли в golang уже было известно среди многих включая и BellLabs)

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

а почему в С есть автоматические переменые и стек встроин в язык - это ведь излишество?

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

no-such-file ★★★★★
()
Ответ на: комментарий от qulinxao

которым был обычно бэйскик и был её осью

Так в том то и дело. И не на персоналках тоже. Был такой подход ввиду тормознутости железа. Собственно бейсик для того и был изобретен, чтобы предоставить интерактивную среду программирования в которой есть всё в себе. Прото-IDE из 60-х. Отсюда и растут ноги у всех этих модулей в языке, файлов в языке, сетевых интерфейсов в языке и прочего хлама, который в языке как таковом не нужен, а должен быть отдан на откуп ОС и/или среды разработки.

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

Go на голом железе? Со сборщиком мусора и многопоточностью в языке? Да ты наверное бредишь. Нет, я понимаю, что можно реализовать концепт в виде среды исполнения для Go на голом железе без ОС (такое микроядро для Go-сервисов), но это тот-же бейсик-ОС родом из 70-х.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Go на голом железе? Со сборщиком мусора и многопоточностью в языке? Да ты наверное бредишь. Нет, я понимаю, что можно реализовать концепт в виде среды исполнения для Go на голом железе без ОС (такое микроядро для Go-сервисов), но это тот-же бейсик-ОС родом из 70-х.

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

Deleted
()
Ответ на: комментарий от Deleted

Программа компилировалась со спец флагом (минимальынй рантайм прикручивался) и запускалась на голом железе.

Дай, что ли, почитать.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

ну зачем же так грубо то?

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

qulinxao ★★☆
()
Ответ на: комментарий от no-such-file

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

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

голэнг спроектирован ровно так же как С(для того времени) - использая некоторый идеализированный СОВРЕМЕННОЙ(созданию) многопотоковый проц(с комуникацией через сеть с другими узлами) как идеализированную машину исполнения

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

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

Это, конечно, сарказм.

Deleted
()
Ответ на: комментарий от Deleted

не уже ли?

фортран с коммон блоками и вызовом процедуры(без ПАРАМЕТРОВ!!!) с сохранением адресса возврата в специальной (затираемой ежель ...) переменной - вот оно самое.

зы. за линк на блог благодарю , очень полезный.

qulinxao ★★☆
()
Ответ на: комментарий от Deleted

а если серьёзно , то как давно заметил тот же Оруэл ( а он видимо просто был в курсе мыслей приведшей к гипотезе Уорфа-Спарфа?) язык определяет сознание.

вот такаая рефлексия : давно когда учился и нас ознакамливали с рекурсией , я был несколько удивлён от чего соученики(сокурсники) буксуют - и тут достаточно не давно повторно наткнулся на двухтомник

Ф. Л. Бауэр, Г. Гооз - Информатика. Вводный курс. Часть 1 и 2

а так получилось , что не очень понимая но я его пролистал/прочитал в возрасте 12-14 лет.

может поэтому потом когда в c#(это было 3 или даже 2.5ой дотнет 2005-2006 года когда вроде анонимные функции уже были , а линка и прочих асинков ещё нет) опытным путём сотворил замыкания - достаточно долго не мог понять механику(т.е как непосредственно работает рантайм) стоящую за наблюдаемым поведением - пока не увидел описание чикен-схема где расказано про стек-кактус

а вот затем наткнулся на вот такое археологическое : http://funcall.blogspot.ru/2011/02/no-stack-no-problem.html

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

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

поддержка языком рекурсивных вызовов функций

Не обязательно через стек.

что согласись излишество и баловство

Дело вкуса.

no-such-file ★★★★★
()
Ответ на: комментарий от qulinxao

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

Ой ой, где-то я уже это слышал, ах да, ява и ява-процессоры.

что бы рантайм на современных машинах у голэнга был так же минимален(почти остутсвует) как и С-изначального

У си изначального, да и у неизначального райнтайм вообще может отсутствовать. Плюшки типа автолинковки пролога/эпилога, libc и прочая можно отключить, кому они не нужны. Си компилятор может выдавать код для запуска as is, голанг может? - хренушки. Это всё тот же бейсик-все-включено, на современный лад да, с потоками, сборщиком мусора и другими модными батарейками.

PS: я понимаю, это такой фирменный стиль, но все же твои посты выглядят как перевод гуглом с китайского.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

да , ибо Pcode который стал общеизвестен в java-ипостаси реализован был уже в середине 70ых и цель была как раз получить окружение малозависимое от конкретной железки , а задача распределённых вычислений и вариант акторов и варинат cspХоара и работы с препрепредшествениками plan9(inferno(в котором опять Limbo и Dis)) т.е задача получение многомашиной системы где отдельномашиность универсализированно через обёртку либо в виртуальную машину либо унивефецирующий рантайм идеи уже более 40 лет.

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

вот тот же Unix&C по факту ОС это сборщик муссора в том числе ,а С- программа даже не обязана ( и у патриархов сплош и рядом так код и написан) free-шеть mallocнутую память С- программе достаточно свялится , а ОС похоронит трупик и вернёт всё в биогеоценоз.

qulinxao бесподобен.

anonymous
()
Ответ на: комментарий от qulinxao

вот тот же Unix&C по факту ОС это сборщик муссора в том числе ,а С- программа даже не обязана ( и у патриархов сплош и рядом так код и написан) free-шеть mallocнутую память С- программе достаточно свялится , а ОС похоронит трупик и вернёт всё в биогеоценоз.

дык это везде так.

emulek
()
Ответ на: комментарий от qulinxao

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

Ээээ... А подробнее?

anonymous
()
Ответ на: комментарий от qulinxao

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

anonymous
()
Ответ на: комментарий от qulinxao

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

эээ... а поцчему энто ты считаешь «самоописывающися протокол мечтой Кея и прочих фонтастов» ?

вот ты лекцию его читал, «контуперная рейволюция исчо не и не начиналась как следует» (транскрипт) ?

там он приводит такой пример:

So here's a couple of knocks on the head I had over the years. I just want to tell them to you quickly. This one I think you'll find interesting because it is the earliest known form of what we call data abstraction. I was in the Air Force in 1961, and I saw it in 1961, and it probably goes back one year before. Back then, they really didn't have operating systems. Air training command had to send tapes of many kinds of records around from Air Force base to Air Force base. There was a question on how can you deal with all of these things that used to be card images, because tape had come in, [there] were starting to be more and more complicated formats, and somebody—almost certainly an enlisted man, because officers didn't program back then—came up with the following idea. This person said, on the third part of the record on this tape we'll put all of the records of this particular type. On the second part—the middle part—we'll put all of the procedures that know how to deal with the formats on this third part of the tape. In the first part we'll put pointers into the procedures, and in fact, let's make the first ten or so pointers standard, like reading and writing fields, and trying to print; let's have a standard vocabulary for the first ten of these, and then we can have idiosyncratic ones later on. All you had to do [to] read a tape back in 1961, was to read the front part of a record—one of these big records—into core storage, and start jumping indirect through the pointers, and the procedures were there.

I really would like you to contrast that with what you have to do with HTML on the Internet. Think about it. HTML on the Internet has gone back to the dark ages because it presupposes that there should be a browser that should understand its formats. This has to be one of the worst ideas since MS-DOS. [Laughter] This is really a shame. It's maybe what happens when physicists decide to play with computers, I'm not sure. [Laughter] In fact, we can see what's happend to the Internet now, is that it is gradually getting—There are two wars going on. There's a set of browser wars which are 100 percent irrelevant. They're basically an attempt, either at demonstrating a non-understanding of how to build complex systems, or an even cruder attempt simply to gather territory. I suspect Microsoft is in the latter camp here. You don't need a browser, if you followed what this Staff Sergeant in the Air Force knew how to do in 1961. You just read it in. It should travel with all the things that it needs, and you don't need anything more complex than something like X Windows. Hopefully better. But basically, you want to be able to distribute all of the knowledge of all the things that are there, and in fact, the Internet is starting to move in that direction as people discover ever more complex HTML formats, ever more intractable. This is one of these mistakes that has been recapitulated every generation. It's just simply not the way to do it.

anonymous
()
Ответ на: комментарий от anonymous

опять же, есть такая тема, как программно-задаваемое радио (SDR)

опять же, есть такая тема, как ООСУБД, например GOODS на MOP на C++, через костыли макросами для рефлексии. можно только гадать, как эта штука упростилась бы, если бы взять язык, где рефлексия и интроспекция нативная, «из коробки» — или, например, объектная система COS, CLOS для C (с мультиметодами, метаклассами, комбинаторами методов, МОП).

опять же, Алан Кей по натуре биоинформатик — он взял просто идею биологической клетки, которая масштабируется черезвычайно хорошо, и переложил её на компьютёры, получились объекты (подробнее об этом в лекции)

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

я к тому, что эти «фантазии» в природе-то вполне себе работают (гено информация и иммунитет, митохондриальное что-то там, и т.п.)

почему бы этим фантазиям (или, видЕнию) — не работать в искусственной системе, вместо того чтобы лепить костыль на костыль чудеса enterprisely?

anonymous
()
Ответ на: комментарий от anonymous

Самый лучший вариант рефлексии был в Delphi - там была секция published у классов. Если надо динамическое изменение как в Smalltalk/Objective-C - делаем рефлексию, если не надо - не делаем и не расходуем зря память.

Den_Zurin
()
Ответ на: комментарий от no-such-file

Вообще моя претензия к модулям как в паскале или яве в том, что они не переносимы в том смысле, что формируют вместе с языком некоторую закрытую платформу, язык+модули.

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

вообще Н. Вирт в «так получилось» пишет, что идея про модули была стянута ещё с Алгола (то есть, одна и та же идея АДТ, типа данных, модуля и класса обыгрывалась три раза как три различных реализации).

Gillad Bracha в newspeak пилит свой тёплый ламповый смоллток, в котором модуль — это объект, и объекты разных «систем» живут в разных мирах. а объекты умеют в рефлексию и интроспекцию и метаклассы.

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

с одной стороны, в этой унифицированности есть смысл: в линкере же есть linker scripts, который говорит тебе, как собирать конкретные секции в бинарник исполняемый. то есть, что-то подобное нужно и для систем: описать, как собирать модули в бинарник.

разделение ролей: есть модули и есть «физические пакеты», как в UML диаграмме развёртывания. и одно отображается на другое, но не совсем 1:1

вообще, модули не обязаны организовывать «закрытую систему» (и свой велосипедистый линкер «внутри системы», как в том же BBCP). например, в kencc библиотеки были через #pragma lib «modulename», и в .o появлялась секция про модули, которую «умный линкер» мог понимать и использовать (ЕМПИП, в go сейчас что-то похожее с дополнительной секцией в ELF).

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

то есть, тезис в том, что «статический линкер» ld и динамический ld.so довольно тупые, но для Си это нормально, и эта тупизна не существенна.

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

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

то есть, вместо того чтобы велосипедить «генератор образа системы» в BBCP, например, лучше бы выставили наружу API и дёргали тот же ненаписанный ещё «умный линкер» LLVM (а система на каком-нибудь D тожё дёргала бы это API линкера, и получилась бы системка, у которой два рантайма (оберон и Ди), но модули в унифицированном виде : нейтральном от рантайма, в API общего модульного линкера, где часть модулей на Ди, часть на обероне, например).

то есть, этот «модульный линкер» интересен в основном только метаданными, интерфейсами, стандартизацией формата модулей под ООП/компонетное ООП модулей особенности. а не тем, «внутри системы» он реализован или снаружи.

anonymous
()
Ответ на: комментарий от anonymous

то есть, тезис в том, что «статический линкер» ld и динамический ld.so довольно тупые, но для Си это нормально, и эта тупизна не существенна.

Их тупизна нормальна не для Си, а вообще, т.к. они работают не для Си, а вообще. Без привязки к какому либо языку.

для таких вещей как в обероне

Получится система закрытая на Оберон. Т.е. если ОС в целом писать на Обероне и этим ограничиться, то всё ОК. Но если вы захотите прикрутить к этой системе Яву, или там, Хаскель, то модульный линкер Оберона вам ничем не поможет, т.к. там модули совсем другие и все они друг с другом никак не совметимы. В итоге те же яйца - вид сбоку.

лучше бы выставили наружу API и дёргали тот же ненаписанный ещё «умный линкер» LLVM (а система на каком-нибудь D тожё дёргала бы это API линкера, и получилась бы системка, у которой два рантайма (оберон и Ди), но модули в унифицированном виде

Если бы, да кабы... Но и при этом остается проблема переносимости на другие системы, где такого умного линкера нет - мой аргумент о неприменимости идеи модулей для Си, как кроссплатформенного метаассемблера, это никак не отменяет.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.