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

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

_>>>>Привидите пример как вы организуете модули в C++ и я посмотрю у кого макароны.
L>>>Не вижу проблемы, которая стоит заострения внимания.
_>>Очень жаль.

L>Да-да, мне нравится этот троллинг. С одной стороны приводим пример макарон, которые ничего полезного не делают, кроме заката солнца вручную, а с другой стороны требуем от собеседника свержения гор. Так толсто, что даже тонко.
Каких гор? Только что писал что не видит проблем. А тут вдуг горы оказались.
header-only билиотеки вот где макароны.

L>>>Отлаживается? Код, который нужно отлаживать — говнокод по определению. Обсуждению не подлежит.
_>>Сильное заявление. "Отлатчики нинужны" То-то я смотрю кругом идеальные программы.

L>Совершенно верно. Пока разработчики будут продолжать "отлаживать" свеженаписанный код, ситуация не изменится.
А с чего вы взяли что отлаживают свеже написанный код. Отлаживают как раз нештатные ситуации.
Вы считаете что компилятор и куча тестов и статический анализатор это панацея логические анализаторы, и осцилографы и отладчики "нинужны"?
Хочу напомнить что раельный мир гораздо сложнее чем любая его модель.
В любом проекте вы вынуждены использовать сторонние библиотеки, службы и оборудование, так что даже если у вас всё идеально, то это не спасает.
Если вы думаете что компиляторы написаны без ошибок или в железе всё ок, то это не так.
https://medium.com/russian/%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D0%BC%D0%BE%D0%B9-%D1%82%D0%B5%D0%BB%D0%B5%D1%84%D0%BE%D0%BD-%D0%BD%D0%B5-%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%B8%D1%82%D1%81%D1%8F-%D0%B4%D0%BE-%D0%BD%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE-%D0%B0%D0%BD%D0%B4%D1%80%D0%BE%D0%B5%D0%B4%D0%B0-e4cd5fa3fa85

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

P>Это и есть самые типичные макароны. При увеличении количества ресурсов будет всё веселее и веселее.
P>Чисто на вскидку, даже учитывая что для уменьшения размеров ты писал по нескольку операторов на строке чего в реальном проекте тебе никто не даст сделать, посмотри сколько у тебя значимых строк (которые выполняют полезную работу), и сколько вспомогательных/технических (по сути мусор) — которые нужны только для обеспечения корректной работы значимых строк. В случае RAII и исключений количество технических строк будет равно нулю.
Вы приувеличиваете. С это просто процессоро-независимый ассемблер. Я не заставляю вас на нём писать. Он просто есть и на нём вполне можно решать любые задачи. При этом просто и понятно не вводя ненужных сущностей.
Разве я спорю что на C++ можно писать тоже самое короче и чище. Нет. Но от ошибок это всё равно не спасёт.

В случаее C++ для того же RAII надо писать дополнительный код который обчеспечит удобное использование возможностей языка.
Бывает что кода, который решает проблеммы комфортного использования языка больше чем кода решения самой задачи.

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

IID>Здравствуйте, Lonely Dog, Вы писали:

LD>>Я 15 лет пишу на C++, немного знаю C#, Python и пр. Но совершенно не понимаю, как писать на C.
LD>>Может есть какие-нибудь книги? Думаю, посмотреть что-то типа Writing device drivers for Linux.

IID>Если это не вброс — зачем сегодня писать на чистом Си ? ИМХО под любую вменяемую архитектуру сущесвтуют С++ компиляторы.
Бывают невменяемые архитектуры http://www.microchip.com/wwwproducts/en/PIC16F616 зато работают при +150С.
IID>Писал прошивку под STM32F103 около 4 лет назад, для автомобильного CanBus адаптера в свою машину. На Keil. Вполне себе на С++.

IID>Сейчас, правда, приходится линукс драйверы на чистом СИ писать, с матерком. Из-за совершенно ублюдского kbuild, чтоб они все там передохли. Как нибудь соберусь с духом — и запилю свою систему сборки, с блекджеком и шлюхами человеческим лицом. Только на секунду представь "качество" красноглазого решения: для драйвера, лежащего вне основной ветки, невозможно разделить каталоги исходника и временных файлов — это поделие всенепременнейше срёт в одну кучу. B ещё пачку временных файлов и каталогов в корень проекта заодно. (да, я знаю про опции M и O). Передача CFLAGS и т.д. такая же кривая.
откройте для себя overlayfs

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

_>С это просто процессоро-независимый ассемблер. Я не заставляю вас на нём писать. Он просто есть и на нём вполне можно решать любые задачи.

собственно мне вообще непонятно, зачем сюда залезли с обсуждением плюсов и исключений. ТС задал вопрос по сям
Си — это свой язык со своими правилами и своими сложностями. В любом языке есть сложности. Программирование — вообще сложно. В данной ветке ТС-у надо помочь писать на Си. Лично я не умею писать на Си, я плюсовик. И из резюме давно уже убрал знание Си.

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

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

Ничего подобного. Всё очень локализовано, изолировано, не связно и легко отлаживается.

_>Отлаживают как раз нештатные ситуации.

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

_>Вы считаете что компилятор и куча тестов и статический анализатор это панацея

Это хорошие инструменты, которые нужно уметь использовать правильно и по назначению.

_>логические анализаторы, и осцилографы и отладчики "нинужны"?

А что, вышеописанные макароны нужно отлаживать осцилллографом?

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

IID>>ИМХО под любую вменяемую архитектуру сущесвтуют С++ компиляторы.
_>Бывают невменяемые архитектуры http://www.microchip.com/wwwproducts/en/PIC16F616 зато работают при +150С.

Бывают, чоуж.

IID>>Сейчас, правда, приходится линукс драйверы на чистом СИ писать, с матерком. Из-за совершенно ублюдского kbuild, чтоб они все там передохли.
_>откройте для себя overlayfs

Не, я лучше выжгу калёным железом и закопаю kbuild.

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

IID>>Если это не вброс — зачем сегодня писать на чистом Си ? ИМХО под любую вменяемую архитектуру сущесвтуют С++ компиляторы.
_>Бывают невменяемые архитектуры http://www.microchip.com/wwwproducts/en/PIC16F616 зато работают при +150С.

Атмеги тоже поставляются в исполнениях до +150. Более чем уверен, что все мейнстримовые микропроцессоры доступны в этом исполнении.

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

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

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

L>

L>Ничего подобного. Всё очень локализовано, изолировано, не связно и легко отлаживается.

_>>Отлаживают как раз нештатные ситуации.

L>Ага. Особенно удобно "отлаживать" ситуации, которые под отладчиком не воспроизводятся.
Оно может воспроизводится только на реальном железе. И приходится пользоваться jtag отладчиком.
Видимо не просто так эти инструменты есть, вам не кажется? Если бы они были безполезны ими бы никто не пользовался.

_>>Вы считаете что компилятор и куча тестов и статический анализатор это панацея
L>Это хорошие инструменты, которые нужно уметь использовать правильно и по назначению.
Вода мокрая, масло масленное. Хорошие инструменты в хороших руках, применённые по назначению — хорошо.

_>>логические анализаторы, и осцилографы и отладчики "нинужны"?
L>А что, вышеописанные макароны нужно отлаживать осцилллографом?
Как вы там писали "Дальше можно было не продолжать."

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

P>Я тебя понял — ты (КЕП!) пытаешься показать, что асинхронный механизм с синхронным плохо совмещается.
я пытаюсь показать что асинхронность с исключениями плохо совмещается

P>Но почему-то приплетаешь сюда исключения. Но это не проблема исключений.
нет, это проблема исключений

P>Ещё раз — исключение передаёт информацию о проблеме выше по стеку вызовов — где стек вызовов в асинхронной модели? Вот то то же и оно.
осталось только понять, почему ты говоришь "то то же и оно" мне, а не себе. Ты же ратуешь за исключения.

P>Во вторых, если как ты говоришь OpenFileAsync — функция асинхронная, она просто не может использовать синхронный механизм, то есть исключения она бросать не может.
Хорошо хоть ты признал что исключения здесь не работают. Жаль только что это заняло у тебя так много времени.

P>Она должна вернуть тебе std::future, который прозрачно бросит исключение при доступе к данным.
И в какой момент я должен доставать оттуда значение?


P>В третьих, если у тебя полностью всё асинхронное, то никаких on_result(FILE) быть не должно, так как обработка ошибок должна вестись в асинхронном режиме тоже. Должно быть on_success и on_fail, в коллбек параметра которого пихается код/объект проблемы.
кому должен? Или перефразируя, чем это лучше возврата значения в коллбек?

P>Но это не код возврата, тут возврата нет, потому и проблем с ними нет. Тут проблемы другого рода.
Дефинируй тогда что такое "возврат". Возможно у тебя какая-то своя, особая терминология.

P>В полностью асинхронной программе архитектура должна быть быть такой, чтобы все проблемы можно было обработать на месте возникновения, что сильно ограничивает область её применения, либо архитектуру (к примеру, полностью событийная архитектура, где ни коды возврата, ни исключения не используются).
А обосновать? В чём проблема с кодами возврата? Коллбеки в которые передаются возвращаемые значения используются повсеместно в асинхронном коде. В чём ограничение?

P>Выбираешь точки обработки ошибок и пишешь в оптимистическом ключе. Гораздо проще чем использовать коды возврата.
Пока выходит что сложнее

A>>Зачем здесь promise/future?
P>Это то, с помощью чего достигается совмещение асинхронного и синхронного кода на плюсах.
Серъёзно? Т.е. до C++11 асинхронного кода в C++ не было? ( кстати, ты слышал что-нибудь про коллбеки? ). Ну и повторю вопрос. В какой момент мне доставать из future?

P>Ну, типичный индусский код
ну я вот всё пытаюсь научится писать с исключениями неиндусский код, но как-то никто даже примера не покажет, как эту простую функцию переписать с исключениями

P>наличие файла проверяется косвенным способом
в коде нет ни слова о проверке наличия файла

P>loadData выполняет не столько load сколько поиск файла
где ты увидел в коде поиск файла?

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

P>Как этот код прошёл у вас ревью непонятно.
Псевдокод на форуме всегда легко проходит код-ревью.

P>А где собственно обработка кодов возврата? Её тут нет.
А суслик?

P>Или ты считаешь, что bool — это и есть код возврата? Тогда понятно, почему не видишь проблем, возникающих с ними.
Там нет bool

P>Возвращение bool подразумевает ветвление, что означает возможность локальной обработки. Фактически bool — это не исключительная, а штатная ситуация.
Там возвращается на bool. Ветвление подразумевает практически любое возвращаемое значение, будь оно bool, int, double, vector<T>, pair<T, err>, что угодно кроме void

P>Вот пример, что такое коды исключений: https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa365430(v=vs.85).aspx , а вот возможные значения https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms681381(v=vs.85).aspx .
P>И их надо обрабатывать для каждой функции.
А 20 лет назад майкрософт учила всех использовать HRESULT. Своя голова на плечах есть?

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

P> Я даже не знаю что тебе на это ответить. Нет. Ты должен обеспечить наличие всего требуемого ещё до вызова loadData, а что не смог обеспечить — то проверить в процессе.
Т.е. ты всеръёз утверждаешь, что прежде чем загрузить данные, я должен сначала а) посмотреть в коде как они заружаются б) написать код проверки условий успешной загрузки до вызова loadFile ? Вот уже где фейспалм так фейспалм. Инксапсуляция? Не, не слышал.

P>(Иначе получается ситуация: сел поесть, но оказалось что на котлете нет подливы, как собственно и котлеты, да чего уж — и тарелка отсутствует, и сидишь не на кухне, и даже не у себя дома)
Сильная аргументация. Нечего добавить.

A>>Но даже с синхронными вызовами, какого типа исключения должен ловить фремворк, например, который зовёт твои функции? (Подсказка: Откуда он будет знать про твои типы исключений? И про boost::exception? )
P>Фреймворк предоставляет свой набор исключений, который ты можешь использовать либо как есть, либо наследуясь от них.
Ну т.е. boost::exception отпадает. Как отпадают вообще любые типы исключений, не обрабатываемые фремворком. Тогда какие ты исключения будешь бросать? Или ты заранее знаешь все фреймворки, в которых будет использоваться твой код? А если он будет использоваться в двух сразу?


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

P>Ты описываешь типичный антипаттерн программирования.
где об этом можно почитать?

P>Это всё уже было в истории. А потом изобрели ООП (в частности инкапсуляцию, которая как раз и скрывает от клиента то, что ему не нужно знать) и жизнь стала налаживаться.
Ну, то что ты предполагаешь нарушать инкапсуляцию заради исключений мы уже выяснили, но всё же спрошу, какими боком инкапсуляция соотносится с исключениями?

P>Чисто даже логически то, что это клиент должен решать есть проблема у компонента или нет — это бред, так как только сам компонент владеет наиболее полной информацией о своём выполнении и своих проблемах. А значит ему и решать, когда у него проблемы, а когда нет.
>Клиентский код должен только реагировать на сигналы о проблемах.

Чисто логически OpenFile понятия не имеет, проблема для меня то, что он не мог открыть файл или нет. Как следствие бросать эксепшн — дурость. Надо возвращать результат. А уж клиентский код решит, проблема для него этот результат или нормальная ситуация. Это настолько очевидные вещи что я недоумеваю, почему надо об этом говорить.

P.S.
Ну и да, ты так и не показал как сделать loadFile с исключениями в OpenFile/OpenNetFile

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

IID>>>Сейчас, правда, приходится линукс драйверы на чистом СИ писать, с матерком. Из-за совершенно ублюдского kbuild, чтоб они все там передохли.
_>>откройте для себя overlayfs

IID>Не, я лучше выжгу калёным железом и закопаю kbuild.
Нет проблем дерзайте.

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

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

P>>Я тебя понял — ты (КЕП!) пытаешься показать, что асинхронный механизм с синхронным плохо совмещается.
A>я пытаюсь показать что асинхронность с исключениями плохо совмещается
Это не проблема исключений, это проблема того, что ты пытаешься синхронный механизм применить к асинхронному.

A>Хорошо хоть ты признал что исключения здесь не работают. Жаль только что это заняло у тебя так много времени.
Какой-то детский сад. Сам придумал, сам опроверг.

P>>Она должна вернуть тебе std::future, который прозрачно бросит исключение при доступе к данным.
A>И в какой момент я должен доставать оттуда значение?
Ровно в тот момент, когда оно тебе понадобится.

P>>В третьих, если у тебя полностью всё асинхронное, то никаких on_result(FILE) быть не должно, так как обработка ошибок должна вестись в асинхронном режиме тоже. Должно быть on_success и on_fail, в коллбек параметра которого пихается код/объект проблемы.
A>кому должен? Или перефразируя, чем это лучше возврата значения в коллбек?
Здравому смыслу: избегаем макаронного кода, получаем простоту изменения логики заменой подходящим коллбеком нужной части и инкапсуляцию обработки ошибок в отдельной функции (так как обработка ошибок — это не игнорирование их). Но код ошибки, или объект обозначающий ошибку будет в on_fail присутствовать тоже. Далее, чтобы доставить его в нужное место для обработки — нужны те же слёзы, что и для
синхронного случая.
Но как уже отвечали, можно использовать исключения вместе с короутинами (я про это был не в курсе). И опять получается проблема решена. И опять с помощью исключений.

P>>Но это не код возврата, тут возврата нет, потому и проблем с ними нет. Тут проблемы другого рода.
A>Дефинируй тогда что такое "возврат". Возможно у тебя какая-то своя, особая терминология.

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

... -> func1() -> ... -> func2() -> ... -> func3() -> func4() -> ...
-> func5() -> ...
-> func6() -> func7()
-> func8()
-> ...

Все функции имеют такую сигнатуру (чтобы пользоваться кодами возврата мы уже имеем ограничение на сигнатуру функции):
uint func(.....)
где uint содержит код возврата — он не имитация bool, может содержать разные значения (нет прав, отсутствует база, отсутствует связь и т.д.).
Каждая функция может выдавать свой набор кодов возвратов.
func1() -> самое удобное место, к примеру, запросить креденшелы у пользователя. В случае дальнейшей ошибки доступа мы должны вернуться сюда, где можем описать пользователю проблему и попросить креденшелы с повышенными привилегиями, если таковые у него есть.
func2() -> самое удобное место для выбора вида связи с сервером. Если что-то в дальнейшем пойдёт не так с коммуникациями — то тут мы можем попросить выбрать другой способ связи.
Допустим func5 кроме прочего может возвращать код "недостаточно прав", func7 + func8 + ... — кроме прочего могут возвращать код "пакет данных повреждён"

Итак, проверять коды возврата нужно будет во всех функциях вне зависимости от успеха или неудачи.
В очень удачном случае у нас возникнет проблема "недостаточно прав", код которой мы просто можем передавать выше до func1() и там обработать.
В обычном же случае (с правильной декомпозицией) у нас будут идти снизу(func7, func8, ...) коды возврата вида "пакет данных повреждён", которые мы не можем обработать в func2(), так как мы не знаем о чём речь: про сеть, про локальные файлы, про кеш и т.д. Нам надо по дороге преобразовать его где-то в "канал не доступен", чтобы возможно было обработать в func2() и выбрать другой канал.
И таких кодов возврата как правило далеко не один.
И это масштаб бедствий только для 8 функций, в масштабе приложения всё гораздо печальнее. Я уже не говорю, про человеческий фактор, когда кто-то не обработал исключение, или затёр неверным — дебажить это очень муторно.

В случае же исключений:
1) нет ограничений на сигнатуру функций
2) мы без гемора ловим там, где хотим и то, что хотим — хоть одно исключение, хоть подмножество
3) мы не боимся, что исключение случайно где-то перетрётся.
4) отсутствие мусорного кода (того, что требуется писать всё время для поддержки кодов возврата)
5) по пути исплючения мы можем без гемора собрать весь контекст проблемы


P>>В полностью асинхронной программе архитектура должна быть быть такой, чтобы все проблемы можно было обработать на месте возникновения, что сильно ограничивает область её применения, либо архитектуру (к примеру, полностью событийная архитектура, где ни коды возврата, ни исключения не используются).
A>А обосновать? В чём проблема с кодами возврата? Коллбеки в которые передаются возвращаемые значения используются повсеместно в асинхронном коде. В чём ограничение?

Проблема с кодом ошибки та же, что и в синхронном коде, только посущественнее. Посмотри схему вызовов выше и представь, что они асинхронные. Проблема в функции func8 "пакет данных повреждён" должна быть обработана в func2() как "канал не доступен". Чтобы это было возможным, код должен пройти через func3, где после нескольких попыток "пакет данных повреждён" будет преобразован в "канал не доступен" и направлен в func2(). Чтобы такой вакханалией управлять в масштабе всего асинхронного приложения — всё должно быть построено на каком-либо типе машин состояний. Это настолько усложняет управление всем этим, что коды ошибок обрабатываются либо сразу на месте, либо подбирается другая архитектура.

A>Ну и повторю вопрос. В какой момент мне доставать из future?
Да в какой хочешь, хоть сразу

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

Я даже не знаю, что тебе тут сказать. То есть клиенту не только пофиг есть ли данные локально, а и вообще есть ли они в наличии в принципе? Так зачем тогда все те приседания поиском файла (перебор значений — это и есть поиск) если они не влияют на клиент — сразу принимать, что нет данных и точка! И пляшем дальше. Тогда там у вас архитектурные проблемы. Архитектурой их и надо решать.

P>>А где собственно обработка кодов возврата? Её тут нет.
A>А суслик?
Там даже в псевдокоде нет обработки кодов возврата. Там просто игнор всех проблем. Это пригодно для личных мелких утилит, но не для реального проекта.

P>>Вот пример, что такое коды исключений: https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa365430(v=vs.85).aspx , а вот возможные значения https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms681381(v=vs.85).aspx .
P>>И их надо обрабатывать для каждой функции.
A>А 20 лет назад майкрософт учила всех использовать HRESULT. Своя голова на плечах есть?

И HRESULT эпично вошло в историю примером того как "удобно" было всем этим пользоваться. А потом MS подумало и решило решить все проблемы одним махом — появился .NET
А там обработка проблем реализована через....о боже....ты не поверишь....через исключения! (вот так поворот)

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

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


A>Т.е. ты всеръёз утверждаешь, что прежде чем загрузить данные, я должен сначала а) посмотреть в коде как они заружаются б) написать код проверки условий успешной загрузки до вызова loadFile ? Вот уже где фейспалм так фейспалм.

В случае кодов возврата — это как раз то, чем и придётся заниматься.

A>Ну т.е. boost::exception отпадает. Как отпадают вообще любые типы исключений, не обрабатываемые фремворком. Тогда какие ты исключения будешь бросать? Или ты заранее знаешь все фреймворки, в которых будет использоваться твой код? А если он будет использоваться в двух сразу?
) Код пишется под конкретный фреймворк, в случае чего ты не сможешь заменить один фреймворк другим без обработки кода напильником. Как в случае исключений, так и в случае кодов возврата. Да и вообще в любом случае.

P>>Ты описываешь типичный антипаттерн программирования.
A>где об этом можно почитать?
https://sourcemaking.com/antipatterns/functional-decomposition

P>>Это всё уже было в истории. А потом изобрели ООП (в частности инкапсуляцию, которая как раз и скрывает от клиента то, что ему не нужно знать) и жизнь стала налаживаться.
A>Ну, то что ты предполагаешь нарушать инкапсуляцию заради исключений мы уже выяснили, но всё же спрошу, какими боком инкапсуляция соотносится с исключениями?


A>Чисто логически OpenFile понятия не имеет, проблема для меня то, что он не мог открыть файл или нет. Как следствие бросать эксепшн — дурость. Надо возвращать результат. А уж клиентский код решит, проблема для него этот результат или нормальная ситуация. Это настолько очевидные вещи что я недоумеваю, почему надо об этом говорить.

"Чисто логически OpenFile понятия не имеет, проблема для меня то, что он не мог открыть файл или нет" — в верном ключе мыслишь. Он не знает что для тебя проблема: наличие ли файла, наличие ли прав, возможность ли открытия (например файл заблочен другой программой) и т.д. Это знать ему нафиг не упрёлось — но он знает, что это для него самого проблема. Он не может выполнить то, что ты от него требуешь. А значит ты его используешь в ненадлежащем контексте. Он должен тебе отсигнализировать, что он сделать не может и по какой причине не может.

"Как следствие бросать эксепшн — дурость. Надо возвращать результат." — неверно, разобрано вверху в чём минуса кодов возврата.

"А уж клиентский код решит, проблема для него этот результат или нормальная ситуация." — и опять верно.

"Это настолько очевидные вещи что я недоумеваю, почему надо об этом говорить." — у меня тоже самое. Ход твоих мыслей вроде верен, но потом какой-то скачёк — и опять игнор проблемы.

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

lpd>Чистый C применяется только в ядре,где нужно работать с оборудованием и C++ только мешает, и в коде embedded устройств. Последние нередко real-time и задержки на обработку исключений составляют существенную проблему и недопустимы.

А вот и нет, статический полиморфизм в embedded иногда очень удобен, когда, например, пишешь обобщенный код под архитектуру, включающую МК с разными аппаратными фичами. Конечно, это не весь C++, но огульно говорить "не применяется" не стоит.

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

EP>Отсутствие компилятора это один из немногих случаев где оправданно использование C, по очевидным причинам.
Есть еще причина. Т.к. C менее универсальный нежели С++ авторы вынужденые реализовывать конкретику, а не абстракции.
Такая деятельность дисциплинирует, требует большей ответственности и усердия от ремеслеников, занимающихся подобным трудом.
И если нужно понять как что-то работает, то смотреть лучше в C реализации, нежели в C++.
Что бы далеко не ходить можно посмотреть реализацию базовых операций с полигонами GPC и boost

ps: посоветуйте хороший C++11 компилятор под winxp

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

O>>Мечтаю увидеть, как пишутся драйверы и прочий системный низкоуровневый код на Python/Clojure/etc.

P>Пишутся, и еще как: готовится модель, описывается на любом языке с минимальным синтаксисом (Clojure, Scheme, Lisp, Ruby), из этой модели делается кодогенерация в С. Бывает что кодогенерацию делают прямо в реалтайме, с учетом внешнего окружения.

Можно пример такого драйвера?

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

P>Например, выделять и освобождать ресурсы внутри одной функции.

Можно вообще не выделять, тогда и освобождать не придется.

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

_>ps: посоветуйте хороший C++11 компилятор под winxp

MSVC 2015 достаточно хорош?

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

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

_>>ps: посоветуйте хороший C++11 компилятор под winxp

Ops>MSVC 2015 достаточно хорош?
Даже с командной строки не запускается.
Если пускать из под Win7, то даже линковщик отказывется делать исполняемые файлы ниже чем под win7

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

_>Даже с командной строки не запускается.
_>Если пускать из под Win7, то даже линковщик отказывется делать исполняемые файлы ниже чем под win7

В смысле не запускается? Не хочешь ли ты сказать, что в 2016 году используешь XP в качестве рабочей ОС? А чего не Windows 3.0?

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

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

_>>Даже с командной строки не запускается.
_>>Если пускать из под Win7, то даже линковщик отказывется делать исполняемые файлы ниже чем под win7

Ops>В смысле не запускается?
В прямом. Ни компилятор, ни результат компиляции.
Ops>Не хочешь ли ты сказать, что в 2016 году используешь XP в качестве рабочей ОС?
У меня рабочая ос ubuntu 14.04 и вней есть виртуалки со виндами от winnt до win2016server
Это вопрос из серии у нас эта фича не работает. Неужели она вам еще нужна? "Берите вот эту её все берут"
Ops>А чего не Windows 3.0?
Есть еще ПЛК которые под dos-ом работают.

WinXP под виртуальными машинами отлично работает и требует меньше ресурсов. На ноутах, на промышленных компьютерах, в составе станков втречается.
Там где это было поставлено и работает и не обновляется.
Получается добавили вы лямды в свой архиватор и он уже не будет пускаться не под win9x ни под winnt ни даже под winxp.
Принесли флешку, а распоковать не можете — красота
Еще прикольнее смотрится когда установщик не пускается под winxp, а само п.о. работает.

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

_>Получается добавили вы лямды в свой архиватор и он уже не будет пускаться не под win9x ни под winnt ни даже под winxp.
Запускаться и нормально работать твоя программа под XP будет. А вот разрабатывать под ней не получится.