Здравствуйте, jazzer, Вы писали:

J>Нет, не сложно. Объясни вот только теперь, почему в приведенном адобовском коде этого не написали?
потому, что им было пофиг на обработку ошибок, так же, как и пофиг при исключениях.
Авторы приведённого кода думали, что "а, фигня, поправим, если вылезет при тестах", и те, кто якобы гарантии безопасности обеспечили, так же примерно думали, что пофиг вйона, главное манёвры...
Ergo: если у руководства проекта нет политической воли, то на корректную обработку ошибок ФАКТИЧЕСКИ ЗАБИВАЮТ.

Дальше возникает вопрос, если реально всё равно этого ничего нет, то на кой на это вообще ресурсы тратить? Для галочки?

J>И почти везде в реальности забивают на повсеместную проверку кодов возврата, если только не применяются драконовские административные меры?
И на РЕАЛЬНОЕ обеспечение гарантий тоже. Вот, например, в твоей команде, как проверяют то, что базовая гарантия безопасности реально обеспечена а не только продеклорирована?..

J>ЗЫ Статический анализатор не поможет против того адобовского кода
Зато статический анализатор + ипатьевский метод очень даже

Здравствуйте, igna, Вы писали:

I>Структурного.
Не важно как назвать. Важно, что получим ужос-ужос...

Здравствуйте, SkyDance, Вы писали:

Не знаю про Tizen (не смотрел его ещё), но вот про MeeGo не надо. Это была вполне хорошая система как для пользователей (см. отзывы на N9), так и для разработчиков.

Здравствуйте, Erop, Вы писали:

E>Не важно как назвать.

Да просто иногда под процедурным понимают императивное.

Здравствуйте, igna, Вы писали:

I>Да просто иногда под процедурным понимают императивное.
Ну Дейкстра вроде так обзывал, но это правда всё равно.
Джаззер как бы показал, что код на исключениях эквивалентен полнейшему ужасу. Странно, что он считает это аргументом в защиту исключений...

Здравствуйте, Vzhyk, Вы писали:

V>Индустрия программирования все, что делает — это выполняет различные
V>заказы по программированию и совсем не заниматся стремлениями.

Ну это как-то однобоко. Даже MOP*-программисты стремятся к своей цели.

*Money-oriented programming

Здравствуйте, jazzer, Вы писали:

_>>Я же писал уже, что замена кодов ошибок на исключения обычно приводит к небольшому увеличению объёма работы, при этом не давая вообще никаких бонусов от этого увеличения.
J>Можно твое так называемое "небольшое" озвучить в цифрах?

Сам сравни объём этого кода http://www.rsdn.ru/forum/cpp/5082655

Автор: alex_public
Дата: 26.02.13

с этим http://www.rsdn.ru/forum/cpp/5082759

Автор: Patalog
Дата: 26.02.13

плюс добавив код определения класса исключений.

J>Show me the code.
J>Пусть будет вот такой стек вызовов: read_profile -> load_files -> load_file -> read_file -> read_header -> read_field_group -> read_named_field -> read_integer.
J>И у тебя вместо циферки встретилась буковка.
J>Теперь расскажи нам про уровни и инкапсуляцию и прямую архитектуру и как тут будут рулить коды возврата.
J>И имей в виду, что read_field_group зовет 50 разных read_named_field, read_header — 20 разных read_field_group, а load_files — 10 load_file.
J>И заодно еще расскажи, как ты гарантируешь, что твой read_profile не вернет true в случае ошибки где-то в потрохах загрузки.

Так это очень просто. И так read_integer у нас ругается на букву, не важно исключением или кодом возврата. Но коду использующему функцию read_file совершенно ни к чему знать из-за какой конкретно ерунды файл не читается корректно. Поэтому read_file должна отчитываться (кодом возврата или исключением) о удачном/неудачном прочтение файлa, без лишних подробностей. Аналогично и коду использующему read_profile должно быть абсолютно пофиг какой конкретно из файлов не прочитался. Думаю понятна логика?

Соответственно у нас может быть 4 варианта:
1. Тупой проброс кодов возврата с нижнего уровня — это не модульный говнкод.
2. Автоматическая работа с исключениями с нижнего уровня — это не модульный говнкод, но чуть меньшего объёма чем вариант 1.
3. Необходимая обработка кодов возврата на своём уровне, с возвратом осмысленных значений на каждом уровне. Это нормальный код.
4. Работа через исключения с необходимой обработкой их на каждом уровне. Это нормальный код, но занимающий больший объём чем вариант 3.

_>>Вообще то речь шла о том, что исключения дают небольшое увеличение объёма кода...
J>По сравнению с чем? С ручным пробрасыванием кодов возврата? И у тебя, конечно же, есть результаты измерений?

Про тупое пробрасывание кодов возврата я уже вроде всё написал.

J>Плюс ты, наверное, говоришь только про объем бинарника, так как с полотенцами проверок кодов возврата в исходниках и так все понятно, правда?

Объём бинарника вообще никого не волнует — мы тут не про микроконтроллеры говорим как бы.

Здравствуйте, Patalog, Вы писали:

P>Нет здесь никакого противоречия.
P>Код, которой кидает исключение\код возврата обычно не может предположить насколько фатально эта ошибка для программы в целом.
P>Как вы это определите в нек. библиотеке, например? Такое возможно только в plain коде типа хелло ворлда, где все просматирвается насквозь.
P>Если в требованиях к методу есть обработка фейла открытия пресловутого файла — он ее обработает, не важно через if или try.
P>Если нет — сам кинет исключение.

Библиотеки — это отдельный разговор. Думаю что там правильнее всего реализовывать оба варианта (если это не слишком напряжно). Как во многих частях Boost например.

Здравствуйте, Patalog, Вы писали:

P>Это в любом случае лучше чем забы(и)ть про обработку кодов возврата.
P>Кроме того, подход с сильно типизированными исключениями я не пробовал в боевом применении, дальше экспериментов дело не пошло.
P>В то же время, мне сильно нравиться подход товарища zaufi, но пока все не сподоблюсь попробовать.
P>У меня (к примеру) parse_error с указанием места фейла в потоке бит никому ничего не должен, он общий для неск. уровней иерархии вазовов.
P>Возможно это нарушение инкапсуляции, но искусство ради искусства считаю не практичным.

Хыхы, а я эту новую темку пропустил как-то... Спасибо, сейчас почитаем, почитаем... )))

А модульность (и инкапсуляция как один из инструментов её реализации) как очень полезна именно на практике, а не в теории. Причём что интересно не для какого-то абстрактного повторного использования кода, а именно для качества изначального.

Здравствуйте, Vzhyk, Вы писали:

V>То есть предлагают на них организовывать логику программы? — это бред.

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

Здравствуйте, Mr.Delphist, Вы писали:

MD>Это как раз последствие нашей "разбалованности" парадигмой Win32 про виртуальное адресное пространство, массированое строительство азиатских заводов микроэлектроники и "memory is not a resource".

MD>Тут в комментариях выше уже справедливо указывали микроконтроллеры с набортной нерасширяемой памятью, щедрых 4 килобайта... И это реальность сегодняшнего дня, а не бородатые "во времена моей молодости 40 баксов за мегабайт". Да и на младшие Raspberry Pi народ ворчит, что младшие модели всё ж обделены памятью — чуть куда рыпнулся сверх плана, всё, счастье кончилось.

MD>К чему это я? А, выделение памяти без throw...

Ну да) Но у микроконтроллеров исключения тоже обычно забанены, только совсем по другим причинам. ))) Там вообще чаще чистый C. Хотя лично я всё равно предпочитаю C++ использовать, благо для моих любимых микроконтроллеров есть компилятор почти со всеми возможностями.

Здравствуйте, alex_public, Вы писали:

хъ

_>А модульность (и инкапсуляция как один из инструментов её реализации) как очень полезна именно на практике, а не в теории.
_>Причём что интересно не для какого-то абстрактного повторного использования кода, а именно для качества изначального.

Убавьте пафос, вы тут пока только больше говорите, а все просьбы показать как оно "на самом-то деле" правильно скромно скипаете.

Здравствуйте, Patalog, Вы писали:

P>Убавьте пафос, вы тут пока только больше говорите, а все просьбы показать как оно "на самом-то деле" правильно скромно скипаете.

Я несколько раз показал, как правильно. Мне каждый раз ответили, что это сферические кони в вакууме.
Думаешь стоит продолжить попытки?..

Здравствуйте, jazzer, Вы писали:

J>Show me the code.
J>Пусть будет вот такой стек вызовов: read_profile -> load_files -> load_file -> read_file -> read_header -> read_field_group -> read_named_field -> read_integer.
J>И у тебя вместо циферки встретилась буковка.

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

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

Тут вообще не булет кодов возврата в обчном понимании.
Будет такой примерно код.

xxxfile src_file;
yyyfile_header src_header;
if( !src_file.open( file_name ) ) {
   // тут какая-то обработка того, что типа нету, скажем такая:
   src_header.ResetToDefault();
   if( !src_file.create( file_name ) || !src_header.write_back( src_file ) ) {
       return fatalAccessError; 
   }
} else if( !src_header.ReadAndParse( src_file ) ) {
   // тут обработка чего там у нас не parse.
   // например, если поле необязательное, то выставляем в объекте ptofile списко варнингов о формате, но работаем дальше, если нет, то возвращаем ошибку, что типа формат существенно не тот, решаёте там сверху, чего делать.
};
   // тут так же читаем сам файл
   return success;
}

при этом не забываем, ещё, что обычно это всё не функция read_profile, а метод объекта CProfile, например конструктора. Или там read? скажем. Так что мы можем распилить его на подметоды + выставлять то, что провалилось, а что нет в самом объекте.

J>И имей в виду, что read_field_group зовет 50 разных read_named_field, read_header — 20 разных read_field_group, а load_files — 10 load_file.

ну и что? Про каждый пишем считать, и анализируем результат. За одно проверяем
1) Обязательное ли это поле, или так, мелочи, и
2) Можем ли пропустить это поле до конца.
если у нас ещё и формат профиля такой, что даже если чего-то не читается, всё равно обычно можем пропустить, то всё считаем, проанализаируем и сможем юзать.

Вызывающий код будет выглядеть так:

bool init_profile( CProfile& profile ) {.
    profile.Read();
    while( 1 ) {
        switch( profile.Status() ) {
        case CProfile::ST_Ready: {
            return true;
        }  break;   
        case CProfile::ST_ConditionalReady: {
            // тут анализаируем годится нам такие проблемы или нет.
            // если годиться, 
                 profile.ResetFieldsWithWarningsToDefault();
                 profile.DiscardWarnings();
                 return true;
            // если не годиться, то , например, спрашиваем пользователя что делать^
            //   сбросить профиль в деволт или всё отменить?
            //   в зависимости от действуем
        }  break;   
        case CProfile::ST_OccupyByOtherProcess: {
            // тут тоже что-то делаем, ждём там или проваливаемся или другой процесс выталкиваем;
        } break;   
        case CProfile::ST_FatalAccessError: {
            //  отправляем пользователя за админом
        }  break;   
        assert( false );
    }
}

А как это будет выглядеть на исключениях?..

J>И заодно еще расскажи, как ты гарантируешь, что твой read_profile не вернет true в случае ошибки где-то в потрохах загрузки.
Статическим анализатором кода...

J>>>Главное отличие исключений от кодов возврата в том, что коды возврата по умолчанию игнорируются, а исключения — наоборот.
Это не совсем так. Форсировать проверку возвратов можно довольно легко просто добавив статический анализатор при коммите, например.
мало того, если уж обсуждать, что бы было более полечно в С -- исключения, или возможность сказать про функцию, что её результат обязательно должен быть использован в месте вызова, то второе однозначно полезнее и прямее ну и очень сильно проще

Здравствуйте, jazzer, Вы писали:

J>Тогда можно, но это уже инвариант "указатель всегда указывает на память, которую можно безопасно delete"

Обычно у С++ объектов есть ещё какие-то инварианты, кроме того, что можно позвать деструктор...

J>Т.е. у которого даже деструктор позвать нельзя? Инварианты же нарушены, например, указатель может указывать хз куда, а ты ему delete. Это какой-то патологический случай.

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

J>Как я и обещал, все элементарно.
Это тут уже обсуждалось выше, или в соседней теме.
прикинь, где-то в других данных программы, могли при этом остаться, например, индексы каких-то элементов в этом массиве...

J>Э, с чего бы это вдруг?
Лямбды, как бэ, сэр...

J>Ну и лямбду я заюзал исключительно для краткости. То же самое элементарно достигается локальной структурой, просто писанины _чуть_ больше будет.

Ага, ещё *чуть* больше... Так вот курочка по зёрнышку...

J>ОК, я добавил там комментариев и по просьбам трудящихся избивался от лямбды и scope_exit.
Я понял всё, что там написано. Просто это довольно сложный код.
Скажем так, уровень программиста, который адекватно там всё поймёт и в случае чего найдёт и ВЕРНО поправит багу довольно высокий...

J>Можно было бы вообще все прибить, но оставить то, что можно оставить, мне кажется полезнее.
Почему полезнее?.. Для чего полезнее? В каком сценарии это принесёт пользу и какую?..

J>Что такое параллельные массивы? Ты уже второй раз их упоминаешь.
В одном лежат коды букв в редакторе, а в другом из цвета. Синхронизация по индексу.

J>Где ж проще?
проще, потому, что везде всё последовательно. Любой нормальный студент разберётся в этом коде за десять минут досканально...

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

J>Удалять с конца абсолютно бессмысленно, ибо нигде не сказано, что объекты вставлялись в вектор по порядку или что потом на них не было напущен sort.
J>Так что "больше всяких мелочей" никакой рояли не играют в данном случае.

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

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

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

J>Ну то есть мой OnScopeExit выше. Да, если писать реальный класс вектора, то многое уйдет во вспомогательные функции и все будет еще лаконичнее и у тебя, и у меня.

Ну да. И у меня останется вообще просто такой довольно код, типа

if( !сделать_то_то() )
    подчистить_так_то()

.
А у тебя в чём-то эквивалентный, но со скоупгардами или с try|catch...

J>Зачем, если можно проще? Правда, для тебя это внезапно оказалось "мутно и сложно"
"Сложно" это очень просто. Это измеряется в долларах. Это просто минимум функции "цена минуты программиста умноденное на время, которое требуется ему, что бы разобраться", достижимый на множестве доступных программистов...

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

J>Ну и где же твое "и там и там", если ты все время хочешь сравнить код с гарантиями с кодом без гарантий?

Ну так надо сравнивать сколько будет стоить ПОЛНЫЙ цикл жизни ПО в той парадигме и в другой... А какие ещё варианты?

E>Мне кажется, тут ты не прав. Разработчик подтянется к любой ОСи, дружественной к нему или нет. Главное, чтобы ось была популярной у пользователей. Тот же win32 не слишком-то дружественен к разработчику, но тем не менее

На момент своего появления и активного развития Win32 был лучшим API. Впрочем, как и Win16. Потому что API других ОС был еще сложнее, запутаннее и с неудобными средствами разработки. Дело же не только в API, но и в средствах разработки в целом — debugger, IDE, ....

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

Узнаю Erop'а. Можно даже на ник автора не смотреть, и так ясно, кто пишет.
Конечно, это большое достоинство Симбиана, в том, что Нокиа умеет делать хорошие телефоны.

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

E>Ну да. И у меня останется вообще просто такой довольно код, типа

if( !сделать_то_то() )
E>    подчистить_так_то()

.
E>А у тебя в чём-то эквивалентный, но со скоупгардами или с try|catch...

Как мне кажется, подобное ретроградство в итоге приведет к... reinventing the wheel, то бишь, те же exceptions, но — "свои", без поддержки компилятором syntax sugar, без хороший оптимизации, да еще и с багами.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, jazzer, Вы писали:

J>>Теперь твоя душенька довольна?

I>Ну по крайней мере теперь ты видишь, что "переписать код на исключениях на код с кодами возврата" вовсе не элементарно. "Элементарно" тут скорее сделать ошибку при этом переписывании.

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

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

– Представьте себе, – говорил он, – что когда в Египте царствовал Аменготеп Четвертый из Фиванской династии, на Борелии встретились два Медлита. Один из них спросил: «Что нового?» После этого были сооружены Пирамиды, Александр Македонский покорил Азию и дошел до Тихого океана; Греция была покорена Римом; образовалась Римская империя германского народа; шли крестовые походы; ислам боролся с христианством; кипели войны Алой и Белой Розы, Тридцатилетняя война, Столетняя война… а другой Медлит все еще не отвечал, и только когда немцы победили Францию под Седаном, борелианское чудовище ответило: «Ничего нового…» Так невероятно, неслыханно медленно протекает жизнь этих поразительных созданий; я могу сказать это спокойно, ибо сам их видел и исследовал.

Тут терпение у меня иссякло.

– То, что вы рассказали, – холодно произнес я, – это низкая ложь.

Став центром всеобщего внимания, я объяснил:

– Александр Великий никогда не доходил до Тихого океана, ибо, как хорошо известно, вернулся с пути в 325 году до нашей эры.

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

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, jazzer, Вы писали:

E>>>Так мы не получим процедурного кода, тем не менее...
J>>Да фроде чифтый фортран
E>Это никак не гарантирует процедурности...

J>>А что "тем не менее"?

E>ну ты пока что якобы показал, что программа с обработкой ошибок на исключениях эквивалентна некому весьма УГ коду, где куча инфы передаётся через статические переменные, а весь код утыкан конструкциями вида "если в какой-то статической переменной такое-то значение, то goto куда-то"...
Э-э-э.... Надеюсь, не надо доказывать, что от статических переменных можно элементарно избавиться, передавая их всюду (как это делается в функциональных языках, там для этого даже спецсахар есть в виде монад)?
Ты ведь и сам это понимаешь, правда?
Не заставляй меня думать о тебе хуже, чем ты того заслуживаешь.

E>ты правда считаешь, что хотя бы типичная работоспособная программа на С с кодами возврата там и прочими ужосами написана так плохо?..
Причем тут УГ? Ты разве о красоте кода хотел поговорить или о принципиальной переписываемости стиля А в стиль Б, для которого все доказано?

E>IMHO, ты только продемонстрировал мой тезис, что код на исключениях эквивалентиен совершеннийшеё лапше из goto по статичесием ппеременным, что само по себе ужасно, и с чем именно и боролся Дейкстра, когда предлагал процедурное программирование...
Открой для себя дизассемблер, там сплошные goto.

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

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

You will always get what you always got
  If you always do  what you always did