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

EP>embedded — это отдельная тема (точно также как и kernel, mission-critical, etc), там накладываются свои ограничения, которые есть и для C и для C++.
EP>Но несмотря на это, даже в 8-ми битниках, при правилом использовании C++ приносит пользу (при наличии компилятора), например.
EP>Да, и не нужно забывать, что в C++ многие механизмы абстракции вообще бесплатны.

Ага) Я тоже предпочитаю C++ в микроконтроллерах. И кстати для тех, которые использую я, компиляторы C++ уже могут практически всё.

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

MTD>Это?

MTD>

MTD>Ну вот собственно я и прошу (тех, кто уверен что исключения — это всегда лучше) показать подходящий юзкейс правильного использования, когда оно улучшило архитектуру или уменьшило объём кода. Потом хочу прикинуть как бы я это сделал без исключений и сравнить объём/читаемость...

MTD>Вот из Adobe Illustrator SDK, обрати внимание, как в середине чуваки сами запарились проверять код возврата и тупо забили на обработку ошибок:

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

Ну и это было только начало дискуссии — там дальше были и примеры)

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

MTD>Вот из Adobe Illustrator SDK, обрати внимание, как в середине чуваки сами запарились проверять код возврата и тупо забили на обработку ошибок:

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

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

C>А при чем здесь Tizen? Ваш eao197 просто не в теме. Самсунг как и обещал еще в прошлом году, добавил поддержку апи Бады.
C>Сравните:
C>здесь tizen
C>и
C>здесь бада

В Самсунге сидят такие быдлокодеры — вам и не снились.. (инсайдерская инфа).

В Интеле, видимо, получше, но не везде (наблюдения извне).

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

MTD>>Вот из Adobe Illustrator SDK, обрати внимание, как в середине чуваки сами запарились проверять код возврата и тупо забили на обработку ошибок:

_>Посмотрел повнимательнее на ваш код... Ха, так это же как раз отличный пример того, о чём я говорил. Именно реализация такой логики (зря вы подумали что они забили в середине — это же очевидно логика такая) как раз и очень неудобна с помощью исключений.

Объясни, какая именно тут логика:

error = sAIPanel->Show(fPanel, true);
error = sAIPanel->SetFlyoutMenuPreVisibilityProc(fPanel, flyoutMenuPreVisFunc);
error = sAIPanel->SetFlyoutMenuProc(fPanel, PanelFlyoutMenuProc);
error = sAIPanel->SetVisibilityChangedNotifyProc(fPanel, PanelVisibilityChangedNotifyProc);
error = sAIPanel->SetSizeChangedNotifyProc(fPanel, PanelSizeChangedNotifyProc);
error = sAIPanel->SetStateChangedNotifyProc(fPanel, PanelStateChangedNotifyProc);
error = sAIPanel->SetClosedNotifyProc(fPanel, PanelClosedNotifyProc);

?
Чем это, отличается от например (предполагая что даже если operator= переопределён, то у него "обычная" семантика):

sAIPanel->Show(fPanel, true);
sAIPanel->SetFlyoutMenuPreVisibilityProc(fPanel, flyoutMenuPreVisFunc);
sAIPanel->SetFlyoutMenuProc(fPanel, PanelFlyoutMenuProc);
sAIPanel->SetVisibilityChangedNotifyProc(fPanel, PanelVisibilityChangedNotifyProc);
sAIPanel->SetSizeChangedNotifyProc(fPanel, PanelSizeChangedNotifyProc);
sAIPanel->SetStateChangedNotifyProc(fPanel, PanelStateChangedNotifyProc);
error = sAIPanel->SetClosedNotifyProc(fPanel, PanelClosedNotifyProc);

?
Я согласен с MTD, это называется — "тупо забили".

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

EP>Объясни, какая именно тут логика:
EP>

EP>error = sAIPanel->Show(fPanel, true);
EP>error = sAIPanel->SetFlyoutMenuPreVisibilityProc(fPanel, flyoutMenuPreVisFunc);
EP>error = sAIPanel->SetFlyoutMenuProc(fPanel, PanelFlyoutMenuProc);
EP>error = sAIPanel->SetVisibilityChangedNotifyProc(fPanel, PanelVisibilityChangedNotifyProc);
EP>error = sAIPanel->SetSizeChangedNotifyProc(fPanel, PanelSizeChangedNotifyProc);
EP>error = sAIPanel->SetStateChangedNotifyProc(fPanel, PanelStateChangedNotifyProc);
EP>error = sAIPanel->SetClosedNotifyProc(fPanel, PanelClosedNotifyProc);
EP>

EP>?
EP>Чем это, отличается от например (предполагая что даже если operator= переопределён, то у него "обычная" семантика):
EP>

EP>sAIPanel->Show(fPanel, true);
EP>sAIPanel->SetFlyoutMenuPreVisibilityProc(fPanel, flyoutMenuPreVisFunc);
EP>sAIPanel->SetFlyoutMenuProc(fPanel, PanelFlyoutMenuProc);
EP>sAIPanel->SetVisibilityChangedNotifyProc(fPanel, PanelVisibilityChangedNotifyProc);
EP>sAIPanel->SetSizeChangedNotifyProc(fPanel, PanelSizeChangedNotifyProc);
EP>sAIPanel->SetStateChangedNotifyProc(fPanel, PanelStateChangedNotifyProc);
EP>error = sAIPanel->SetClosedNotifyProc(fPanel, PanelClosedNotifyProc);
EP>

EP>?
EP>Я согласен с MTD, это называется — "тупо забили".

Ну вы даёте... Очевидно же что в первом случае в error будет код ошибки (не важно какой, главное что ошибка) при возврате ошибки из любой из этих функций, а не только из последней. Да, и кстати после этого куска там как раз стоит код проверяющий этот факт с соответствующими действиями далее. Причём таких блока там целых 2, так что версия что "к середине функции устали и забили" звучит очень забавно конечно. )))

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

EP>>Да, и не нужно забывать, что в C++ многие механизмы абстракции вообще бесплатны.

P>Согласен что бесплатны (если они есть), но часто бесполезны.

Почему? Они помогают сократить как код, так и нагрузку на "мозги" программистов.
IMHO, абстракции — это самое мощное оружие в арсенале разработчика.

P>Если после каждой операции проверять ее результат — то исключения — просто синтаксический оверхед.

Наоборот, if-error-goto на каждой операции это синтаксический overhead, от которого можно избавится с помощью исключений
Если же ты говоришь про использование исключений как return values — то я не вижу смысла в обсуждении патологических случаев.

P>А там именно так и пишут.

Где?

P>Ну вот сам посуди, что можно сделать с исключением в такой ситуации в стэке выше?

Тоже самое что и с error-code Если при использовании error-code он не передаётся "далеко" наверх, то и исключения можно обрабатывать "пониже".

P>Сомоубиться — но в реальности есть много способов — но почти никогда на стэке выше уже ничего. Такова специфика. Поэтому и пишут так.

Кто пишет? Где?

P>И просто С с классами вроде и неплохо для РАИИ, но всегда найдется тот кто начнет применять там ненужный оверхед.

Ты о чём?

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

_>Ну вы даёте... Очевидно же что в первом случае в error будет код ошибки (не важно какой, главное что ошибка) при возврате ошибки из любой из этих функций, а не только из последней.

Это откуда следует? Там же = , а не |=

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

_>Хотя на самом деле я не против исключений именно для обработки критических ошибок (т.е. грубо говоря один try на всю программку и соответствующие исключения). Но чаще всего если их уж используют, то для обработки всех видов ошибок вообще. А это уже бред — они были созданы для другого!

Никто не заставляет использовать исключения для каждого вида ошибок, а тем более для return values.

_>Так что проще запретить вообще, как Гугл и сделали.

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Exceptions#Exceptions
То что ты выше описал Google относит к Cons:

The availability of exceptions may encourage developers to throw them when they are not appropriate or recover from them when it's not safe to do so. For example, invalid user input should not cause exceptions to be thrown. We would need to make the style guide even longer to document these restrictions!

Но решение было сделано на основе другого фактора:

On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

Period.

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

L>

L>The object is not fully constructed after this constructor is called. For full construction,
L>the Construct() method must be called right after calling this constructor.

Интересно, а какие могут быть объекивные причины так делать? например.

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

L>>

L>>The object is not fully constructed after this constructor is called. For full construction,
L>>the Construct() method must be called right after calling this constructor.

ML>Интересно, а какие могут быть объекивные причины так делать? например.

Это делается скорей всего из-за бана исключений ( так же как и у Google ).
А вот почему у них исключения забанены —

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

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

L>>

L>>The object is not fully constructed after this constructor is called. For full construction,
L>>the Construct() method must be called right after calling this constructor.

ML>Интересно, а какие могут быть объекивные причины так делать? например.

Если не рассматривать дурость с "исключения нельзя использовать, потом что мы на самом деле их ниасилили", то остается исчезающе мало причин. Например, когда объект по какой-то причине создается в один момент, но его инициализация должна произойти намного позже. Такой паттерн с методом Init иногда используется, но подобный ужас почти всегда можно вылечить банальнейшим IoC (фабрикой).

On 21.02.2013 22:31, Evgeny.Panasyuk wrote:

> использовать исключения для return values.
Это как бы противоречит самому поняттию исключение?

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

L>Только AVR-ы, для которых собирается код, имеют 1024 килобайта оперативки,
avr-ки стока не имеют В самых толстых речь идет о 4-8 килобайтах...

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

>> использовать исключения для return values.
V>Это как бы противоречит самому поняттию исключение?

Художественная резка по цитатам?

Никто не заставляет использовать исключения для каждого вида ошибок, а тем более для return values.

Вообще, речь шла про abuse.

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

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

L>>Только AVR-ы, для которых собирается код, имеют 1024 килобайта оперативки,
E>avr-ки стока не имеют В самых толстых речь идет о 4-8 килобайтах...

Вообще-то самая популярная Atmega328 имеет целых 2 килобайта. Тут можно разугляться!

On 22.02.2013 15:24, Evgeny.Panasyuk wrote:

> Художественная резка по цитатам?
Нет, я не спорил с тобой. Я просто удивился, зачем использовать таким
странным образом то, что для этого не предназначено.

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

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

_>>Ну вы даёте... Очевидно же что в первом случае в error будет код ошибки (не важно какой, главное что ошибка) при возврате ошибки из любой из этих функций, а не только из последней.

EP>Это откуда следует? Там же = , а не |=

Ааа мой косяк, проглядел))) Уже в полусне писал и показалось))) Тогда действительно сомнительный код у них там. Что впрочем никак не влияет на нашу основную дискуссию. )

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

EP>Никто не заставляет использовать исключения для каждого вида ошибок, а тем более для return values.

Ну так в контексте обсуждения Tizen api как раз было ближе к реализации замены кодов ошибок на исключения.

Да, кстати, но вот одну вещь я на самом деле не очень понял. Почему следствием отказа от исключений является обязательное наличие двухшаговой инициализации всех объектов? У нас вот исключения в таких случаях не используются, но и потребности в такой инициализации что-то не припомню...

EP>http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Exceptions#Exceptions
EP>То что ты выше описал Google относит к Cons:
EP>Но решение было сделано на основе другого фактора:
EP>Period.

Ну так я свою точку зрения высказываю. При этом выходит так что она частично пересекается с гугловскими. )

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

_>Да, кстати, но вот одну вещь я на самом деле не очень понял. Почему следствием отказа от исключений является обязательное наличие двухшаговой инициализации всех объектов? У нас вот исключения в таких случаях не используются, но и потребности в такой инициализации что-то не припомню...

В нормальной ситуации, когда конструктор не может установить нужные инварианты объекта, не может нормально создать объект — он кидает исключение.
При таком подходе нету места "частично созданным" объектам, так как по правилам языка если из конструктора вылетает исключение, то нет возможности что-либо с ним сделать (не будем рассматривать патологические случаи ковыряния в raw bytes of dead object).

Например, что ты будешь делать без исключений в следующем случае?:

{
    vector<int> v(16); // may fail on allocation
    cout << v[0];
}

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