On 21.02.2013 9:10, niXman wrote:

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

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

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

X>>понятно-понятно. не знал, что там тоже отказались от исключений. а говорят, что в Г работают только адекваты =)

Ops>http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

http://www.rsdn.ru/forum/cpp/4621115.1

Автор: jazzer
Дата: 16.02.12

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

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

E>>(или как это правильно называется)
X>гетерогенные?
именно

X>на яве я не писатель, но от описанной тобою идеалогии становится непонятно, почему на фоне ява, с++ считается "опасным" ЯП %)

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

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

J>как ты туда запихнешь int, если контейнер без шаблонов параметром Object* принимает??

никак. Поэтому int упаковывается в Integer, собственно как оно и происходит в C# / яве...

Но собственно что это меняет?

map.Add(new String(L"Two"), new Integer(2));     

String*    pValue = static_cast< String* > (map.GetValue(String(L"Zero"))); 

pValue->length(); // тут все плохо...

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


J>то что в плюсах выделенная строчка компилируется — это именно плюсовый касяк. но мне либо dynamic_cast либо reinterpret_cast.

тут просто дело в том, что static_cast разрешен от void* к любому указателю. Кстати dynamic_cast для указателя возвращает 0 при ошибке, и если ты это не проверишь перед использованием — будет ровно такое же UB, что и при static_cast

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

X>MTD, Evgeny.Panasyuk, осталось понять, что является истинной причиной некоторых, отказ от использования исключений. ибо я сомневаюсь, что причина отказа кроется в мегаоверхеде =)
X>в двух примерах, кстати, используются неоверхедные исключения(SEH & DWARF).

Ну например некоторые компилеры их не поддерживают. Также имеет место оверхед по размеру программы, для МК-шек иногда важно...

On 21.02.2013 12:37, enji wrote:

> Ну например некоторые компилеры их не поддерживают. Также имеет место
> оверхед по размеру программы, для МК-шек иногда важно...
Кстати, а 8048 еще используется?

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

E>Ну например некоторые компилеры их не поддерживают.
ну..микрософтстудия не поддерживает DWARF, ибо ей не за чем. зато mingw-x86_64 поддерживает SEH.

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

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

X>>в двух примерах, кстати, используются неоверхедные исключения(SEH & DWARF).

E>Ну например некоторые компилеры их не поддерживают. Также имеет место оверхед по размеру программы, для МК-шек иногда важно...

Например, gcc-avr. Только AVR-ы, для которых собирается код, имеют 1024 килобайта оперативки, а то и меньше, и там много чего еще нет. Например, new тоже обычно отключено (да и некуда его, этот new, делать). Впрочем, задачи, решаемые микроконтроллерами, редко требуют выхода из многократно вложенного блока по ошибке. Кстати, как раз на u-контроллерах исключительные ситуации можно обрабатывать исключительно — jmp <где тут у нас загрузчик>

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

L>Например, gcc-avr.
с микроконтроллерами понятно. но речь ведь про андроид и тизен.

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

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

L>>Например, gcc-avr.
X>с микроконтроллерами понятно. но речь ведь про андроид и тизен.

У железок, на которых работает андроид и тизен, оперативки больше, чем объем жесткого диска на моем первом компьютере. О каком оверхеде тут можно вообще говорить —

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

MTD>>1. Бородатые дядьки которые в начале 90-х попробовали С++ и обожглись, а теперь негативный опыт проецируют на сегодняшнее положение дел
X>а что, в начале 90-ых, с исключениями в с++ было не так?
X>(я тогда еще совсем сопливый был)

Их просто не было. Появились где-то в 1992, ранее были только эксперименты.

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

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

L>>Да есть одна такая. На букву Г как раз.
X>понятно-понятно. не знал, что там тоже отказались от исключений. а говорят, что в Г работают только адекваты =)

Адекваты, как и в любом стартапе, там были в самом начале. Сейчас это, похоже, обычное корпоративное гнездо взвешивателей гномиков.

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

EP>Их просто не было. Появились где-то в 1992, ранее были только эксперименты.

Есть еще момент того — что, часто эксперты в предметной области железа, оперируют в работе только логикой работы железа. Для этого хорош С но С++ уже некая "ненужная" абстракция. Я в эмбедед тоже поработал — и хочу сказать, это хорошая практика там. Кроме того на многих контроллерах С++ до сих пор сильно урезан. Кода там обычно мало — но "ответственность" больше. Поэтому на каждой операции проверка — норма, а вот исключение с потерей контекста — уже хуже ложится в логику.

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

J>http://www.rsdn.ru/forum/cpp/4621115.1

Автор: jazzer
Дата: 16.02.12

Ага, ага, помним эту темку... Там ещё дальше есть моё обоснование почему я тоже считаю отказ от исключений хорошей практикой. И вроде никто так и не смог опровергнуть его. )))

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

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

_>я тоже считаю отказ от исключений хорошей практикой. И вроде никто так и не смог опровергнуть его. )))
хоть номер страницы укажи. их же там 25! %)

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

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

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

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

_>Ага, ага, помним эту темку... Там ещё дальше есть моё обоснование почему я тоже считаю отказ от исключений хорошей практикой. И вроде никто так и не смог опровергнуть его. )))

Это?

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

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

ASErr EmptyPanelPlugin::StartupPlugin(SPInterfaceMessage *message)
{
    AIErr err = kNoErr;
    
    // Call base class routine
    err = Plugin::StartupPlugin(message);
    if (err)
        return err;

    AINotifierHandle appShutDownNotifier;
    err = sAINotifier->AddNotifier(fPluginRef, "AI Application Shutdown Notifier", kAIApplicationShutdownNotifier, &appShutDownNotifier);
    if(err)
        return err;
    
    AIErr error = kNoErr;

    // Add About Plugins menu item for this plug-in.
    SDKAboutPluginsHelper aboutPluginsHelper;
    error = aboutPluginsHelper.AddAboutPluginsMenuItem(message, 
                kSDKDefAboutSDKCompanyPluginsGroupName, 
                ai::UnicodeString(kSDKDefAboutSDKCompanyPluginsGroupNameString), 
                "EmptyPanel...", 
                &fAboutPluginMenu);

    if (error)
        return error;

    // Add menu item
    error = sAIMenu->AddMenuItemZString(fPluginRef, "Third Party Panel", kOtherPalettesMenuGroup, ZREF("Third Party Panel"),
                                        kMenuItemNoOptions, &fEmptyPanelPanelMenuItemHandle);
    if (error)
        return error;

    fPanelFlyoutMenu = NULL;
    error = sAIPanelFlyoutMenu->Create(fPanelFlyoutMenu);
    if (error)
        return error;

    error = sAIPanelFlyoutMenu->AppendItem(fPanelFlyoutMenu, 1, ai::UnicodeString("First Item"));
    error = sAIPanelFlyoutMenu->AppendItem(fPanelFlyoutMenu, 3, ai::UnicodeString("Third Item"));
    error = sAIPanelFlyoutMenu->InsertItem(fPanelFlyoutMenu, 3, 2, ai::UnicodeString("Second Item"));
    error = sAIPanelFlyoutMenu->InsertSeparator(fPanelFlyoutMenu, 3, 5);
    error = sAIPanelFlyoutMenu->AppendItem(fPanelFlyoutMenu, 4, ai::UnicodeString("Fourth Item"));

    error = sAIPanelFlyoutMenu->SetItemEnabled(fPanelFlyoutMenu, 4, false);
    error = sAIPanelFlyoutMenu->SetItemMark(fPanelFlyoutMenu, 1 , kAIPanelFlyoutMenuItemMark_BULLET);
    error = sAIPanelFlyoutMenu->SetItemMark(fPanelFlyoutMenu, 2 , kAIPanelFlyoutMenuItemMark_CHECK);
    error = sAIPanelFlyoutMenu->SetItemMark(fPanelFlyoutMenu, 3 , kAIPanelFlyoutMenuItemMark_DASH);

    AISize pnSize = {240, 320};
    error = sAIPanel->Create(fPluginRef, ai::UnicodeString("Third Party Panel"), ai::UnicodeString("Third Party Panel"), 3, pnSize, true, fPanelFlyoutMenu, this, fPanel);
    if (error)
        return error;

    AISize minSize = {50, 50};
    AISize maxSize = {800, 800};
    AISize prefConstSize = {100, 100};
    AISize prefUnconstSize = {600, 600};

    error = sAIPanel->SetSizes(fPanel, minSize, prefUnconstSize, prefConstSize, maxSize);

    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);

    error = SetIcon();

    error = AddWidgets();
    
    //Add Menu Item for Control Bar
    if(!error)
        error = sAIMenu->AddMenuItemZString(fPluginRef, "Third Party Control Bar", kOtherPalettesMenuGroup, ZREF("Third Party Control Bar"),
                                            kMenuItemNoOptions, &fEmptyPanelControlBarMenuItemHandle);
    
    //Create Control Bar
    AISize sizeControlBar = {controlBarWidth, controlBarHeight};
    if(!error)
        error = sAIControlBar->Create(fPluginRef, sizeControlBar, controlBarWidthMin, controlBarWidthMax,NULL/*Userdata*/,fControlBar);
    if(!error)
        error = sAIControlBar->SetUserData(fControlBar, this);
    
    //Set Callbacks
    if(!error)
        error = sAIControlBar->SetVisibilityChangedNotifyProc(fControlBar, ControlBarVisibilityChangedNotifyProc);
    if(!error)
        error = sAIControlBar->SetSizeChangedNotifyProc(fControlBar, ControlBarSizeChangedNotifyProc);
    
    //Add Different Widgets to Control Bar
    if(!error)
        AddWidgetsToControlBar();
    
    return error;
}

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

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

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

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

_>>я тоже считаю отказ от исключений хорошей практикой. И вроде никто так и не смог опровергнуть его. )))
X>хоть номер страницы укажи. их же там 25! %)

Нуу началось кажется на 10-ой странице, а итог был подведён на 13-ой.

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

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