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

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

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

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

подозреваю, что return в_другую_точку_если_произшло_исключение будет быстрее

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

нет, не сам виноват -- смысл именно в том, чтобы компилятор это не допускал

> 1,2,3. Идея с «гарантиями», которые энфорсятся компилятором и/или разъезжаются по графу вызовов, (а) потенциально продуктивна, (б) во всю используется и исследуется, (в) уже довольно давно.

в каком языке я могу не патча компилятор написать свою гарантию и заставить его ее энфорсить?

> Но вопрос о том, как это синтаксически воткнуть в C++ (или в любой другой язык), тут не на первом и даже не на десятом месте.

я не верю в синтаксис плюсов -- им нужна ресинтаксификация

> Но если уж вас заинтересовал именно этот аспект — для таких экспериментов C++ уж точно не лучший выбор.

кхе-кхе... а что лучше?

> 1,2,3. Идея с «гарантиями», которые энфорсятся компилятором и/или разъезжаются по графу вызовов, (а) потенциально продуктивна, (б) во всю используется и исследуется, (в) уже довольно давно.

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

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

Так покажите, что такое «статические исключения». Нечто вроде break из именованного блока (несколькими уровнями выше)? Так это ни хрена не замена исключениям. Что-то ещё совсем другое? Покажите же. Я имел дело с исключениями в довольно-таки разных языках, но не grok'нул, что вы имеете в виду. Думаете, я один такой тупой?

> подозреваю, что return в_другую_точку_если_произшло_исключение будет быстрее

Так это сейчас почти так и есть. С мааленьким исключением :), что нужно для каждого применения RAII между уровнями всё открутить назад (деструкторы вызвать).

> Вы не понимаете сущности плюсиста как биологического вида.

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

> Им нравится, что Something b=1; может вызвать любые вычисления, в том числе и очень долгие

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

однако не понял, чем плоха возможность сказать "а вот тут у нас POD!"

> и *it; тоже может

> Кому нужен C++ без таких вещей? Мне точно не нужен.

Очень тяжело писать Something b(1) вместо Something b=1 ? сочувствую... (хотя синтаксис плюсов я юзаю только для общепонятно примера -- он должен быть другой)

> и *it тоже может

и указатели тоже надо раскидать по категориям:

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

> Так это сейчас почти так и есть. С мааленьким исключением :), что нужно для каждого применения RAII между уровнями всё открутить назад (деструкторы вызвать).

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

> Так покажите, что такое «статические исключения». Нечто вроде break из именованного блока (несколькими уровнями выше)? Так это ни хрена не замена исключениям.

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

на полную замену я пока не претендую

Я же привёл C# в качестве примера (правда, только потому, что про лиспы да хаскелли без меня расскажут). Там можно прилепить атрибут на функцию (любой, который вы придумаете, хоть MyLib.НеЛезетВИнтернет), можно её код проверить (например, что [MyLib.НеЛезетВИнтернет] вызывает только то, что тоже объявлено как [MyLib.НеЛезетВИнтернет]), ну и PROFIT. Я сам, правда, не пробовал, просто наблюдал краем глаза, как подобное бывает (и вообще в C# я не настоящий сварщик).

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

(require-finite-execution-time 
  ...; тут ваши килобайтики кода
  ...)

Дальше остаются проблемы доказательства, т.е. собственно реализации проверки. И это самое интересное :)

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

А я вот вообще занимаюсь статическими проверками в TCL (с помощью вспомогательного макропакета sugar), получается легче, чем должно бы быть в C#, и чуть труднее, чем в лиспах.

я не верю в синтаксис плюсов — им нужна ресинтаксификация

Так-так. С ресемантизации вы начали, ресинтаксификация тоже нужна, ну и реимплементация и рестандартизация, куда же без. Вопрос только, при чём в этой замечательной каше из топора собственно C++? Конечно, пипл гораздо охотнее хавает языки, которые раскрашены под «синтаксис в стиле C», но так раскрасить можно почти что угодно и довольно быстро (think ECMAScript).

Если что-то в Си++ вам нравится, имеет смысл сформулировать именно это, в виде закрытого списка. Т.е. начинать не с претензий, а с комплиментов :) Тогда, во-первых, может что-то найтись подходящее по этим критериям; во-вторых, если не найдётся — вам хотя бы будет понятно, что именно нужно создавать. И наверняка среди имевших место экспериментов в языкостроительстве найдётся что-то хотя бы частично подходящее, на чём можно основываться (и по фигу, кто его сделал, дохлое оно или не очень, эффективно оно или тормозит и ничего не умеет — заимствовать решения это ничуть не мешает).

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

Идея иметь 2 языка мне не нравится.

Дело в том, что противоречия между наличием 1. абстракций и 2. наличием контроля байтов и тактов нет никакого (в связи с чем желательно было бы запретить термин "язык низкого уровня").

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

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

> Я же привёл C# в качестве примера (правда, только потому, что про лиспы да хаскелли без меня расскажут). Там можно прилепить атрибут на функцию (любой, который вы придумаете, хоть MyLib.НеЛезетВИнтернет), можно её код проверить (например, что [MyLib.НеЛезетВИнтернет] вызывает только то, что тоже объявлено как [MyLib.НеЛезетВИнтернет]), ну и PROFIT. Я сам, правда, не пробовал, просто наблюдал краем глаза, как подобное бывает (и вообще в C# я не настоящий сварщик).

C# еще плохо знаю. Но вызывает некоторое подозрение "можно её код проверить".

В яве есть аннотации, которые можно прочитать в рантайме при рефлексии.

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

> Так-так. С ресемантизации вы начали,

a.[i] слишком жирно называть ресемантизацией, а вот a["asdf"] имеет такую же семантику, как и в плюсах

так что я надеюсь, что Qt можно будет дергать (насчет буста -- хмм...)

> ну и реимплементация и рестандартизация

а тут просто имплементация и стандартизация

> Если что-то в Си++ вам нравится, имеет смысл сформулировать именно это, в виде закрытого списка.

тут в треде было это в 4 пункта (если совсем кратко -- это байты и абстрации) поэтому я опять перейду к ругани: в принципе, с++ достаточно близок к байтам, но и у него есть завороты, типа невозможности программеру самому строить vtbl

Отвечаю сразу на пару сообщений:

однако не понял, чем плоха возможность сказать «а вот тут у нас POD!»

Ну кто же сказал, что она плоха? Совершенно замечательная вещь, только вот непонятно, при чём тут C++.

Например, в D структуры отличаются от классов именно таким образом. Но это именно свойство типа, т.е. автор Something'а решает, каким оно будет. Мы не можем решить, что какой-нибудь класс, написанный кем-то другим, у нас ВНЕЗАПНО стал POD.

И, пожалуй, это всё-таки правильно, что не можем (разумеется, в D можно сделать static assert и проверить в compile-time, что это структура, а не класс).

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

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

Кстати, компромиссный вариант обработки исключений, который таки звучит похоже на ваше предложение: для каждой бросающей функции компилировать два тела с разными abi, одно с нелокальным переходом (для вызова, вокруг которого не стоит перехват), другое со скрытым кодом возврата (как раз для случая try { func(); } catch (...), когда откручивать нечего). Это опять же была бы особенность реализации, не влияющая на язык — но так никто не делает. Почему бы? Да потому, что try { func_которая_сама_и_содержит_throw(); } это не большинство случаев, и, боюсь, даже не 1%. Исключения ведь именно для того, чтобы избежать проверок в точке возврата, а не для того, чтобы их обернуть новым «замечательным» синтаксисом. Да любой плюсист вам скажет, что try {} всего на уровень выше throw — признак говнокода, и кто так пишет, не умеет пользоваться исключениями.

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

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

> любой плюсист вам скажет, что try {} всего на уровень выше throw — признак говнокода

Не любой.

Qt, кстати, очень неплохое упражнение на тему «как я постриг ёжика» (продолжая боянную метафору про Страуструпа и Александреску). Но именно поэтому хороший биндинг к Qt — задача и осмысленная, и разрешимая, вовсе не только для C++ и ему подобных.

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

в математике принято наоборот :) слабая абстракция (weak abstraction) - та, под которую подпадает больше объектов. категория, например, очень слабая абстракция; топос (частный случай категории, специализация исходной абстракции) - более сильная абстракция. вырожденный случай - абстракция, имеющая всего одну специализацию - полное упорядоченное поле, например (под определение подпадает только поле вещественных чисел). итого смысл противоположный тому, что используешь ты

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

беда в том, что под определение абстракции (что твоё, что SICP'овское) подпадает очень много вещей. асбстракция абстракции, скажем так, очень слабая :)

Да любой плюсист вам скажет, что try {} всего на уровень выше throw — признак говнокода, и кто так пишет, не умеет пользоваться исключениями.

мы хотим посчтитать общее количество байт в трафике из лог-файла

int amount=0, invalid=0;
while( line=get_line() )
{
  try{
    amount+=traffic(line);
  }catch(....){
    invalid++;
  }
}

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

> Да любой плюсист вам скажет

я, вообще говоря, тут пытаюсь точку зрения сишников понять

> Да любой плюсист вам скажет, что try {} всего на уровень выше throw — признак говнокода, и кто так пишет, не умеет пользоваться исключениями.

try {} может быть существенно throw, но необходимо, чтобы компилятор мог статически определить, где исключение перехватится

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

> в математике принято наоборот :)

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

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

Где?

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

спасибо что поделился столь ценной информацией о твоих планах :)

В Эль-76 :)

> В Эль-76 :)

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

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

фрейм-с-перехватом-исключения

несколько-промежуточных-фреймов

фрейм-вызывающий-исключение

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

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

при наличии статических исключений именно так и надо выходить из цикла

*особенно*, если при выходе из цикла надо вынести из него какое-то значение -- выностить будет исключение

> try {} может быть существенно throw, но необходимо, чтобы компилятор мог статически определить, где исключение перехватится

Ну он и сейчас иногда может. Допустим, у нас whole program optimization, всё заинлайнилось до полного неприличия, ну и понятно, что каждый throw превращается в вызов деструкторов + локальный переход, или просто в локальный переход. Но где тут существенный профит запрятан? Нету тут его. На одного идиота, который исключениями выходит из вложенных for(), приходится куча случаев нормального использования, когда возня с деструкторами перекроет все остальные затраты.

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

> Где?

А тут я прозреваю Java или ещё что-нибудь с GC или JIT или обоими. К вашим задумкам ни то, ни другое отношения не имеет (GC ведь «далеко от байтов», да?). В таких местах «исключенческая» проблематика [b]совсем[/b] другая.

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

Сейчас для каждой хрени, которую компилятор обязан доказывать, специфицировано и то, как её должен обеспечивать программист. Все знают, что return 0+int_func(); не является хвостовым вызовом в смысле обязанности это оптимизировать (это не про Си[++], где её и так нет, но неважно), что const-функции-члены класса не трогают поля данных (кроме mutable) и не вызывают не-const-члены, ну и так далее. У вас же ни слова о том, как результат компиляторных раздумий зависит от входного кода. «Должен гарантировать» и баста. Вот был на сборочной машине 1Гб памяти, компилятор поковырялся с data flow и решил, что всё хорошо. А стало 512Мб, компилятор поймал out_of_memory, но решил вместо того, чтобы вывалиться, снизить тщательность анализа — и оп-па, «скорость кода не доказана». Утрирую, конечно (не ведут себя так компиляторы), и наверняка у вас идеи по требованиям к коду есть, но про них бы сразу надо хоть намекнуть немного :)

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

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

Из цикла надо выходить return-from имя блока (и значение им же возвращать), а если в некоем язычке этого нет — goto и не выёживаться. С сишным goto хотя бы понятно, что он локален.

Вы ведь так и не раскололись — return-from лиспового образца это то самое, что вы понимаете под статическими исключениями, или другое? Если то самое, то я соглашусь, что им надо выходить из цикла, но он не заменяет кодов возврата и _тем более_ не заменяет «динамических» (настоящих) исключений. Ну а если не то же самое, тогда им из цикла выходить _не надо_.

> GC ведь «далеко от байтов», да?

ЖЦ близок, а вот язычки, которые его юзают, обычно далеки. Хотя D довольно близок.

> Все знают, что return 0+int_func(); не является хвостовым вызовом в смысле обязанности это оптимизировать (это не про Си[++], где её и так нет, но неважно)

gcc умеет такое оптимизировать

> Допустим, у нас whole program optimization, всё заинлайнилось до полного неприличия, ну и понятно, что каждый throw превращается в вызов деструкторов + локальный переход, или просто в локальный переход. Но где тут существенный профит запрятан? Нету тут его.

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

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

а не "ну и понятно", а под капотом -- ну не смогла я, не смогла :-)

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

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

если же у компилятора это не получается (т.е. abstraction_penalty!=0) то компилятор обязан вывалиться с ошибкой

что не мешает писать и использовать код с abstraction_penalty!=0

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

хм

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

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

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

Всем недовольным C++ советую посмотреть в сторону D.

>Всем недовольным C++ советую посмотреть в сторону D, проблеваться и больше не возбухать.

fixed.

А конструктивного сказать ничего не можете?

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

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

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

>А конструктивного сказать ничего не можете?

Полноценной свободной реализации нет, так что не скажу.

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

Можно было бы согласиться, но есть одно "но": архитектура PC принципиально не изменилась с тех самых дремучих времен, поэтому нет смысла перекраивать "кроссплатформенный ассемблер".

>что значит - оставаясь в рамках C?
возможность писать код не медленнее аналогичного на си. то есть все новые возможности - "локальны" и не меняют весь язык. "не платим, за то, что не используем". ну итд

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

А куда она девалась?

>то есть все новые возможности - "локальны" и не меняют весь язык

ну, ABI поменялся; правила разрешения имён - тоже. вообще, "оставаясь в рамках C" - это несколько идеализированная позиция

Кастую Objective-C в тред

>несколько идеализированная позиция
не спорю

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

Разумеется, этот студентческий говнокод просто КРИЧИТ "перепешите меня!".

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

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

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

>Разумеется, этот студентческий говнокод просто КРИЧИТ "перепешите меня!".

Код вполне как в жаве - либо валидный результат либо exception. Только в жаве для ожидаемых ошибок кидают checked exception.

> P.S. и вообще, ниша С++ уже достаточно сильно пострадала от других языков, оставьте этот язык в покое, пусть помрет неспешно...

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

Да даже на яве, где исключения гораздо естественней, такой код пахнет очень дурно и допустим только при условии, что контракт traffic() был задан извне и прибит гвоздями. Если задача изначально стоит - посчитать трафик _и_ количество ошибочных строк, а traffic() был реализован самим программистом, что подразумевается примером, то нужно делать честное управление, а не эмулировать его исключениями.
Единственное назначение исключений - возврат в состояние до входа в эту ветвь вызовов и, соответственно, в catch {} я ожидаю код очистки. Достаточно прикинуть, как будет выглядеть такой код, если в catch {} вместо foo++ будет более развесистый код или вообще основной поток управления.

Exception для учёта/обработки _ожидаемого_ т.е. штатного события - моветон.

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

я не понял такую постановку вопроса

мое предложение заключается в том, что не-POD-объекты не могут инициализироваться вот так NotPOD something_complex=1; а могут только так: NotPOD something_complex(1);

если же программист попытается написать NotPOD something_complex=1; то компилятор выдаст ошибку

______________________________________________________

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

Решать эту проблему должно IDE и/или (что может быть непривычным) хранение программы в некоторой нетекстовой форме.