LINUX.ORG.RU

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)


0

0

Если бы вы изобретали С++ с чистого листа, то как бы вы...?

___

Чтобы тема была чуть определеннее, приведу несколько обычных притензий к С++, и мои предложения как это исправить:

1. Вроде-как-объявление переменной Something s=1; может вызвать сколь угодно длинное вычисление

Решение: разный синтаксис:

Something s=1; означает, что конструктор s завершается за заранее известное число таков (и деструктора нет?)

Something s(1); означает... что ожидать можно что угодно.

2. С++ поддерживает перегрузку оператора [] -- и это значит, что a["asdf"] может обращаться за значением к серверу на другой стороне Земли, не говоря уж о произвольном таймауте и возможном выбросе исключения. В то же время абстрактная запись типа a["asdf"] для языка высокого уровня *НУЖНА*. Поэтомо, возможно, следует *на уровне синтаксиса* различать абстрактное и гарантированно-себя-хорошо-ведущее.

Решение: разный синтаксис:

a.[i] означает, что компилятор гарантирует, что i не выйдет за пределы границ массива а, операция завершается за заранее известное число таков, и проверка в ран-тайме *не нужна*, как например в случае for(int i=0; i<sizeof(a)/sizeof(a.[0]); i++) do_something(a.[i]);

a.at(i) (или a.at[i]?) означает, что проверка диапазона (или наличия значения в хэше, или ... ) производится, операция завершается за заранее известное число тактов; выход за границы -- это критическая ошибка логики программы, и при ее наличии программа должна gracefully завершиться.

a[i] означает... что ожидать можно что угодно.

3. Исключительно тормозные плюсовые исключения (на десятичные порядки) http://www.linux.org.ru/view-message.jsp?msgid=3856841

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

(Понятно, что все это требует более умного компилятора)

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

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

почитайте "дизайн и эволюцию"

gavv ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> Если бы вы изобретали С++ с чистого листа,

Страуструп с самого начала установил условия, что:

1. Чем не пользуешься, за то не платишь.

2. Совместимость с C.

Поэтому, с твоим подходом получиться альтернатива плюсам и очень непохожая.

Liosha_Syrnikov ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>Something s=1; означает, что конструктор s завершается за заранее известное число таков (и деструктора нет?)

Ты путаешь с++ с чемто другим:)

golodranez ★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> почитайте "дизайн и эволюцию"

мне хотелось бы ответов по существу

написав, например, a.[i] я утверждаю, что это будет быстро, и компилятор подтверждает это (а не просто умывает руки)

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> Ты путаешь с++ с чемто другим:)

прочти мой пост еще раз и внимательно

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>написав, например, a.[i] я утверждаю
как ни странно, автор с++ и люди из комитета стандартизации тоже задумывались по этому поводу, и все это уже обсуждалось и об этом писалось

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

зашивать в синтаксис гарантию скорости работы произвольной функции - странно

gavv ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

хорошие предложения, можно будет вывешивать новый слоган "еще больше способов выстрелить себе в ногу!" и намного легче...

ott ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> 1. Чем не пользуешься, за то не платишь.

да, это надо

> 2. Совместимость с C.

даже и сейчас у с++ синтаксически совместимость с С не полная

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

> Поэтому, с твоим подходом получиться альтернатива плюсам и очень непохожая.

доктор, это плохо?

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> Something s=1; означает, что конструктор s завершается за заранее известное число таков

Чего ты хочешь этим добится?

anonymous ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> хорошие предложения, можно будет вывешивать новый слоган "еще больше способов выстрелить себе в ногу!" и намного легче...

вежливо: раскройте, пожалуста, тему

не вежливо: бред.

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>> Something s=1; означает, что конструктор s завершается за заранее известное число таков

> Чего ты хочешь этим добится?

Пресказуемости, за отсутствие которой сишники ругают плюсы.

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>Чего ты хочешь этим добится?
человек хочет, чтобы посмотрев на код, можно было понять, что он делает на самом деле.

но есть причины, по которым с++ при таком раскладе будет либо си, либо будет иметь балласт

gavv ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

Си это честный язык задействующий все возможности юниксовых тулчейнов родом из 70-х. Добавление в Си чего-то нового без изменения всей платформы это нечестное пичкание здорового организма стероидами.

Absurd ★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>Если бы вы изобретали С++ с чистого листа?

То мы (sic!) бы не стали изобретать С++ совсем.

zfsed ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> зашивать в синтаксис гарантию скорости работы произвольной функции - странно

с точки зрения абстракций и языка высокого уровня это может выглядеть странно, впрочем, даже сейчас в stl нет оператора [i] у списка, так как его скорость будет О(i)

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

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

Си++ невозможно изобрести заново: провальна сама идея автоматически вызываемых деструкторв и конструкторов копирования. Развитие шаблонов в Си++ должно было остановиться на уровне второй редакции книги Страуструпа; множественного и виртуального наследования вообще не должно было быть (сигнатуры вместо него). И, конечно, обработка исключений должна быть не более, чем в 2-3 раза медленнее возврата из функции.

Новый Си++ не нужен. Нужен улучшенный Си, а еще лучше - новый Си. Вот в соседней ветке проскочила ссылка на L - что-то в этом роде (хотя сам L уродлив).

tailgunner ★★★★★ ()

Re: Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> Пресказуемости, за отсутствие которой сишники ругают плюсы.

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

anonymous ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> но есть причины, по которым с++ при таком раскладе будет либо си, либо будет иметь балласт

(не верю) расскажи подробнее.

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> a["asdf"] может обращаться за значением к серверу на другой стороне Земли

Вообще-то, в сях обращение к памяти может привести к обращению к свопу, который лежит на другой стороне Земли... Если нужен реалтайм, то всё равно надо думать над _каждым_ действием в программе.

const86 ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> То мы (sic!) бы не стали изобретать С++ совсем.

Прекрасно. Тогда расскажите принципы дизайна языка, который имел бы

1. абстракции достаточно высокого уровня

2. способы эффективной реализации частных случаев этих абстракций (по этому пункту пролетают практически все)

3. хорошие возможности дергать сишные либи

4. и желательно хорошие возможности дергать плюсовые либи, типа Qt

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

Python же :-)

> 1. абстракции достаточно высокого уровня

Уровня як у лиспе?

> 2. способы эффективной реализации частных случаев этих абстракций (по этому пункту пролетают практически все)

Более конкретно желательно описать

> 3. хорошие возможности дергать сишные либи > 4. и желательно хорошие возможности дергать плюсовые либи, типа Qt

О_О

zfsed ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> Вообще-то, в сях обращение к памяти может привести к обращению к свопу, который лежит на другой стороне Земли... Если нужен реалтайм, то всё равно надо думать над _каждым_ действием в программе.

извините, а кто *так* пишет проги для реалтайма?

так = "вот эти указатели окажутся в свопу, который лежит на другой стороне Земли, а вот эти нет, следовательно ..."

_______________________________________________

не RT, но: обращение к безобидному swap(a,b) может иметь результатом page fault объектой базы данных

выход в двух-(трех-)уровневой модели исключительных ситуаций, типа (un)checked exceptions

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>расскажи подробнее
если не читали книгу, все же почитайте. у меня это получится намного хуже

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

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

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

gavv ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

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

а) эти инструменты и
б) си

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

gavv ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

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

gavv ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

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

> скрывая это.

речь идет именно о тех случаях, где с++ скрывает лишнего.

> вы уберете пару проблем, введя новые синтаксические соглашения, но останется много других из-за идеологии с++

собственно об этих "многих других" я и справшиваю в топике

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

и чем это плохо?

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> извините, а кто *так* пишет проги для реалтайма?

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

const86 ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

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

ничего не знаю на эту тему, где почитать мнения?

> Развитие шаблонов в Си++ должно было остановиться на уровне второй редакции книги Страуструпа;

то, что шаблоны часто misused, это точно, насчет уровня второй редакции книги Страуструпа -- это вопрос

> множественного и виртуального наследования вообще не должно было быть (сигнатуры вместо него).

"запретить" выглядит совсем подозрительно

кто считает сложным или не подходящим, те и не юзают

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

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

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

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

gavv ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> вы выбираете с++, когда вам нужен си,но хочется в придачу мощные инструменты (классы и шаблоны)

я скажу кратко, что мне хочется: еще более высокого уровня абстракций, чем в с++, и большего контроля низкого уроня (байтов), чем в с++

(надеюсь, что все понимают, что шаблоны являются абстракциями)

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>еще более высокого уровня абстракций, чем в с++, и большего контроля низкого уроня (байтов), чем в с++

если это все, что вам нужно, то комбинируйте ассемблер и лисп :)

gavv ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> хорошие предложения, можно будет вывешивать новый слоган "еще больше способов выстрелить себе в ногу!" и намного легче...

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

www_linux_org_ru ★★★★★ ()

Re: Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

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

> ничего не знаю на эту тему, где почитать мнения?

ХЗ. Это мой опыт работы на Си++. Взаиможействие конструкторов копирования с механизмом передачи параметров, возврата значений и обработки исключений - это поле, усеянное граблями как для прогера на Си++, так и для реализатора компилятора/рантайма.

>> множественного и виртуального наследования вообще не должно было быть (сигнатуры вместо него).

> "запретить" выглядит совсем подозрительно

Я не сказал "запретить". Их не должно было быть изначально.

> кто считает сложным или не подходящим, те и не юзают

Заблуждение. Во-первых, разработчики компиляторов платят за всё; во-вторых, редко есть возможность выбирать (хинт: библиотеки).

> чем публичное множественное наследование принципиально отличается от взятия указателя на член объекта

Вопрос неправильно поставлен. Но можно ответить и на такой вопрос - например, ромбовидным наследованием. Нужно объяснять, чем оно плохо?

tailgunner ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> если это все, что вам нужно, то комбинируйте ассемблер и лисп :)

спасибо, не надо

макросы на основе ковыряния AST -- это порочный подход, кроме того, лисп спроектирован изначально под динамическую типизацию, и сейчас это не исправить

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>> если это все, что вам нужно
>макросы на основе ковыряния AST -- это порочный подход

ирония. я имел в виду - преимущества с++ в другом

gavv ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>все дополнения с++ - это скрытие более сложной работы за простыми конструкциями, но всегда оставаясь в рамках си

что значит - оставаясь в рамках C?

jtootf ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>макросы на основе ковыряния AST -- это порочный подход

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

Absurd ★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

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

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

jtootf ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> Нужен улучшенный Си, а еще лучше - новый Си.

тут должен быть список недостатков дизайна С

я бы предложил: "делаем быстро, а не надежно"

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

- границы массива не проверяются, только если компилятор уверен в этом, или ему отдельно сказано не проверять *здесь*

- нулевые указатели не проверяются, только если компилятор уверен в этом, или ему отдельно сказано не проверять *здесь*

- void* имеет размер 12 байт -- указыватель на данные+тайптег, тайптег проверяется всегда (кстати, стандарт С вроде не мешает void* иметь другой размер, чем остальные?)

> Вот в соседней ветке проскочила ссылка на L - что-то в этом роде (хотя сам L уродлив).

там хоть нормально сделали объявление типов (в одну сторону, а не вправо-влево как в С). хотя язык сильно недопилен.

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

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

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

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>- границы массива не проверяются, только если компилятор уверен в этом, или ему отдельно сказано не проверять *здесь*

>- нулевые указатели не проверяются, только если компилятор уверен в этом, или ему отдельно сказано не проверять *здесь*

это уже было в Cyclone

jtootf ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

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

>Абстрактное понятие — высшая форма абстракции, но связанная с примитивной чувственной абстракцией

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

jtootf ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> ХЗ. Это мой опыт работы на Си++. Взаиможействие конструкторов копирования с механизмом передачи параметров, возврата значений и обработки исключений - это поле, усеянное граблями как для прогера на Си++, так и для реализатора компилятора/рантайма.

надо тебя об этом расспросить

> Заблуждение. Во-первых, разработчики компиляторов платят за всё; во-вторых, редко есть возможность выбирать (хинт: библиотеки). ... Вопрос неправильно поставлен. Но можно ответить и на такой вопрос - например, ромбовидным наследованием. Нужно объяснять, чем оно плохо?

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

Что касается разработчиков компилятора -- это их работа. Фичи требуют труда.

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

> это уже было в Cyclone

ага, с него я и писал :-)

циклон интересен этим своим подходом

однако void* там динамически вроде не проверяется?

www_linux_org_ru ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>однако void* там динамически вроде не проверяется?

нет

jtootf ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

>> Нужен улучшенный Си, а еще лучше - новый Си.

> тут должен быть список недостатков дизайна С

Си скоро 40 лет, какие еще недостатки дизайна? Речь о том, что Си должен воспринять из того, чему за эти 40 лет люди научились.

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

> - границы массива не проверяются, только если компилятор уверен в этом

> - нулевые указатели не проверяются, только если компилятор уверен в этом

Это дорога в никуда. Проще иметь 2 языка и нормальный ABI.

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

>> Вот в соседней ветке проскочила ссылка на L - что-то в этом роде (хотя сам L уродлив).

> там хоть нормально сделали объявление типов

Ыы... какое уродство.

tailgunner ★★★★★ ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

Лично я стараюсь по возможности мёртвых страусов не насиловать, но если говорить о ваших конкретных претензиях, то:

3. Ни в какую спецификацию языка C++ не входит конкретный способ передачи исключений, а также тот факт, что они должны тормозить при выбрасывании. Вот и реализовали бы в своём компиляторе исключения через скрытые коды возврата и автоматическую их проверку. Тогда тормозить из-за этих проверок станут уже «неисключительные» execution paths, и угадайте, как типичный плюсист будет смотреть на такой компилятор.

Это написано, имея в виду первую часть решения 3 («ввести быстрые статические исключения»). Если посмотреть на вторую часть («при этом компилятор должен проверять то, что все варианты кода возврата проверены») — при чём тут тогда вообще исключения? Семантика исключений, а также вся их возможная польза — в том, чтобы не проверять результат в точке возврата. Если всегда нужны проверки в точке возврата, то и пользуйтесь кодами возврата (их никто не отменял). Что-нибудь типа __attribute__((warn_unused_result)) поможет компилятору «гарантировать», хоть и непонятно что:

 #define USE_RESULT(expr) do {} while ((expr)<0)
 USE_RESULT(fd=open(name,flags)) // avoid warning with f..king www_linux_org_ru's compiler

2. Перегружать-то свои роскошные операторы вы разрешите или нет? Если не разрешите, понятно, с чем вас съедят плюсисты. А если разрешите, но потребуете от компилятора доказывать соблюдение «гарантированных» вещей... Ну, в общем, сами подумайте. А ещё можно во «встроенном» варианте (для массива и, может быть, для std::vector) дать гарантии, а если кто перегрузил [], .[] или .at — то сам виноват. Но сейчас и так почти так и есть :)

1. Те же проблемы с гарантиями и тем, кто и как их будет обеспечивать. Прозреваю самую популярную конструкцию будущего wwwLORc+++++c:

 unsafe(быстрый_код,я_гарантирую_это) {
   ... килобайтики кода...   
 }
Вы могли бы ещё выделить не-тьюринг-полное подмножество в вашем языке, про которое компилятор может что-то гарантировать, и потребовать всё «гарантированное» писать на нём. Но для кого всё это?

Вы не понимаете сущности плюсиста как биологического вида. Им нравится, что Something b=1; может вызвать любые вычисления, в том числе и очень долгие (и Something b; без всего — тоже может, и *it; тоже может, и так далее). Это называется «мощность» и «гибкость». Кому нужен C++ без таких вещей? Мне точно не нужен. Когда я имею дело с большим объемом кода, который уже на C++, у меня хватает других занятий, нежели портирование на «гарантированный» wwwLORc+++++c. А если уж всё равно придётся переписывать половину кода, можно сделать это и не на C++.

Плюсисту, который решается писать новые проекты на C++, тоже не нужен. Раз уж он никуда не слез до сих пор, не вперлась ему эта ваша гарантированность, и не вопрётся никогда. Гибкость и мощность forever.

1,2,3. Идея с «гарантиями», которые энфорсятся компилятором и/или разъезжаются по графу вызовов, (а) потенциально продуктивна, (б) во всю используется и исследуется, (в) уже довольно давно. Но вопрос о том, как это синтаксически воткнуть в C++ (или в любой другой язык), тут не на первом и даже не на десятом месте. Но если уж вас заинтересовал именно этот аспект — для таких экспериментов C++ уж точно не лучший выбор. Если даже опустить альтернативы, которые приводятся в любом местном плюсосраче, останется ещё, например, C# (там есть CodeDom и атрибуты функций, на них подобные вещи делаются).

А плюсы сами очень быстро подтянутся, стоит только придумать что-то полезное: всего лишь лет через пять в компиляторах появится кривая и недоделанная поддержка ваших семантических идей, ещё через три года какой-нибудь boost::contract, с которым этим можно будет пользоваться, ещё года три — и привет, проект стандарта, ещё пару лет — и это уже std::, ну и ещё года через полтора в основных распространённых компиляторах допилят.

LeninGad ()

Несколько вопросов: языки высокого уровня и С++ с точки зрения программистов на С (kernel, embedded, realtime, ...)

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

Блин. Раньше там намного лучше было определение. Ладно дам свое, на вскидку.

Абстракция (процесс) -- исключение из рассмотрения каких-либо свойств, качеств, связей предмета рассмотрения (или математической модели).

Абстракция (результат) -- результат абстракции-процесса, характеризуется некоторой замкнутостью.

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

www_linux_org_ru ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.