Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Коваленко Дмитрий, Вы писали:
КД>>Ну поскольку в эту ветку больше гадят, чем пишут, я тоже нагажу
VD>Здорово, но моно был бы лучше если бы ты разбил эту функцию на несколько по меньше.
Да и так стараюсь как могу
В последнее время рвет на очень длинные функции и громадные файлы, но не всегда удается их победить.
Кстати — тут вот проскальзала мысль (или музыкой навеяло?), что те кто использует goto — не врубаются в ... эээ процесс(?) выполнения программы. Так вот. Как много из тех, кто сюда написал, оборачивают реализацию каждого (COM-)интерфейсного метода ловушками исключений?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте WolfHound, Вы писали:
TL>>>Насчет систем проверки орфографии точно не скажу — похоже все дело в них. Но виснет напрочь... Правда только Word — NT остается в здравии... WH>>У мени Win XP и Word XP тоже виснет.
VD>А у меня нет.
А это потому, что у вас Word ручками без CRT переписан...
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Sergey, Вы писали:
S>>...оправданным я считаю, например, применение goto для очистки ресурсов в C++, совершенно идеоматическое, кстати, особенно если метку называть как-нибудь вроде cleanup.
VD>Все здорово, то только для очистки ресурсов в С++ есть куда более надежный способ — создание оберток которые это делают автоматически. Вот и получается, что в современном С++ любое использование goto или имеет более эффективную замену, или приводит к нарушению структурированности логики.
Мля, описка это была. Вместо С++ должно было быть С. Плюсы сами набрались :)
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Аноним, Вы писали:
А>>Во-первых, применение оптимизатора не дает увеличение скорости программы на порядок (десятичный порядок, по крайней мере). Во-вторых, моя фраза о разных задачах относилось к "А нагромаждение циклов... Мы как то обходится".
VD>Ты это проверял? А я проверял. В 10 раз! Это средняя величина. Даже не средняя, а практически минимальная. Если используются все возможности оптимизатора по скорости, то бывает и больше. Без оптимизации компиляторы генерируют вообще убогий код. На него даже смотреть противно.
В 10 раз? Смотря что за код, можно написать и так, что оптимизированный код в 100 раз быстрее будет. Может я пишу чего неправильно, или у меня компилятор неправильный, но вот сейчас проверил на днях написанный критичный по быстродействию кусок (время в ms):
А поскольку большая часть кода все равно не критична ко времени исполнения, мне все равно, что там компилятор нагенерит. Хотя я тоже за использование оптимизатора :)
VD>>>Значит плохо читал. А про флоат без CRT... Не просто можно но и очень даже ничего получаетя. А>>Нормально читал :) Там, если ты помнишь, про fp всего пара абзацов, которые кратко пересказать можно так: "Если вам надо использовать fp вычисления без CRT, сами разбирайтесь, какая функция что за собой тянет, мне влом этим заниматься".
VD>Там написано, что ты лишаешся обработки ошибок типа переполнения, а в остальном достаточно определить одну глобальную переменную и все. Необходимые выкрутасы с делаются через automation API.
А>>Да и совет линковаться с LIBC.LIB вполне однозначен — это ж просто использование части CRT.
VD>Там объяснено, что многие функции CRT (а вернее ее стартап-код) не тянут и их можно смело использовать.
Я, типа, в курсе, что стартап не все тянут. Но я не считаю, что CRT == CRT startup.
VD>>>Это я тебе говорю, так как мы с БД без CRT работаем, а там флоаты частенько поадаются. А>>И что вы с ними делаете? Юзеру показываете? А логарифм взять?
VD>Логорифм нам не нужен. Но если пондобится, то возмем фунцию и будем использовать. Мат-алгоритмы не должны цеплять стартап-код.
Так я-то говорил про CRT, а не про ейный стартап. А вообще-то, к функции log я исходников не нашел, а беглое разглядывание msvcrt.dll под микроскопом энтузиазма по поводу использования ее без стартапа не вызвало. Код там довольно обширный, и что нужно для обработки ошибок, а что собственно для вычислений я с первого взгляда не понял. И вдобавок зародилось подозрение, что при статической компоновке она все равно за собой добрый кусок CRT потянет. Вот ежели будет у кого время с ней разобраться, тогда поверю, что CRT — пережиток прошлого :-\
А>>Что такое "настройки нет"?
VD>Да это я ступил. Хотел сказать что наш код луче использует настройки ОС, т.е. региональные установки.
VD>>>Мы пишим COM-библиотеки и нужно распространять их по сети.
А>>Я не отрицаю, что есть класс задач, где CRT нафиг не нужна. Просто C++ без CRT — и не C++, и не C. И фиг его знает, что там после выхода очередного сервиспака глючить начнет.
VD>Ну, дык когда у тебя 90% времени уходит на задачи в которых CRT вредно, то привыкаешь к программированию без него. Я же не призываю всех жить без CRT, я прсто говрю, что не нужно делать заявлений, что без него С++ не С++.
Ладно, а C без printf'а — это C?
А>>А начал использовать тяжеленный wxWindows и тоже не жалею :)
VD>А это, что?
А это кроссплатформенная замена MFC. Насколько она кроссплатформенная я пока не проверял, но оно мне нравиться куда больше MFC просто для программирования под винду.
А>>Если wsprintf еще можно хоть как-то замаскировать под sprintf, то с automation API этот номер не пройдет и код (вполне безразличная к операционке его часть) станет windows-only. Да и геморроя с ним на порядок больше, чем с sprintf и иже с ними.
VD>А предствь себе какой может быть рынок сбыта для COM-объектов под Уних? :) А мы именно их делаем.
А я некоторую часть кода на чистом С++ пишу, а потом, по мере необходимости, в COM заворачиваю. Скажут через пять лет к перлу/васику/шарпу/жабе прикрутить — прикручу.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте Андрей, Вы писали:
А>Здравствуйте Mishka<T>, Вы писали:
MT>>Здравствуйте LeonGorbachev, Вы писали:
LG>>>я вот как раз и не хочу через исключения. И не хочу гоу-ту. LG>>>Чего делать?
MT>>Можно так: MT>>
MT>>while(1)
MT>>{
MT>> for(int i = 0; i < 100; i++)
MT>> {
MT>> if(i == 77)
MT>> break;
MT>> }
MT>> if (i < 100) break;
MT>>}
MT>>
А>Это прокатит только на VC6
Это почему же, интересно?! По-моему на любом C. Что здесь скользкого? Мне этот вариант нравится .
А>Я обычно делаю так:
А>
А>bool bContinue = true;
А>while(bContinue) {
А> for(int i = 0; i < 100; i++) {
А> if (i == 77) {
А> bContinue = false;
А> break;
А> }
А> }
А>}
А>
skip
А>>Это прокатит только на VC6
P>Это почему же, интересно?! По-моему на любом C. Что здесь скользкого? Мне этот вариант нравится .
На C не прокатит в любом случае, там конструкции типа (for int ...) вообще запрещены, нужно писать
int i;
for (i...)
А насчет остального: по стандарту в конструкции типа for (int i...) переменная цикла видна только внутри блока и большинство компиялторов этому правилу следуют, поэтому вне цикла переменную i использовать не получится. А вот VC6 этому не соответствует (кстати, в VC7 это исправлено), поэтому там можно обращаться к i после цикла. И то, что такой стиль тебе нравится — может привести к тому, что тебе придется переписывать код при переходе на новую версию компилятора.
А второе твое замечание: вопрос был не про банальность или новаторское решение, а про то, кто и что использует. Я придерживаюсь такого стиля
Здравствуйте Alexander Shargin, Вы писали:
AS>В-третьих, по поводу других предложенных методов. AS>1. Вспомогательная функция+выход по return. Поскольку функции по правилам C могут находиться в любом месте программы (в т. ч. в другом модуле), читателю совершенно непонятно, куда приведёт return. Эту ситуацию можно немного поправить, структурируя код и добавляя комментарии, но это не меняет сути — такой подход не способствует читабельности.
Александр, хоть Вы и правы во всем, что написали в дальнейщем, но тут я непременно поспорю.
Во-первых, я сильно сомневаюсь, что такая функция может оказаться в другом модуле.
Скорее всего, она будет или предшествовать основной, или окажется сразу после нее.
Эх, жаль что в С нельзя писать под-функции для функций (как в паскале, помните такого?)
Во-вторых, проблема с понижением читабельности не возникнет, если дать такой
функции нормальное, читабельное имя, символов на 20-40.
В-третих (тут начинается ИМХО, поэтому не буду столь категоричен), такой подход позволит
сократить основную функцию как раз на эти два вложенных цикла. На мой взгляд (подчеркиваю: мой)
программа, состоящая из 20 функций по 20 строк более читабельна, чем программа из одной
main на 400 строк.
Так что я отдаю свой голос за отдельную функцию + return.
Здравствуйте Patalog, Вы писали:
PP>Насчет вариантов — P>По варианту, который присла ты, я тебе ответил, что считаю изменение переменной цикла внутри цикла еще большими граблями, и еще более непонятным "окружающим".
Значти за всех можешь говорить только ты?
По поводу циклав и граблей. Это применение for может вызвать грабли, как и случилось у троих человек пытавшихся переписать твой код. Многие языки высокого уровня специально не включают никаких кострукций кроме while (тот же Паскль имеет очень ограниченны по возможностям for именно по этому). И сделно это по тем же причинам, по которым не рекомендуется применять goto. В while-е вся логика идет последовательно сверху в низ и не может редставлять проблем для чтения (если конечно код не напихан).
Тебе правильно заметили, что случай твой класичкский. Повтор операции после сбоя. И решатся он именно заключеним в цикл. Ты это и сделал, но цикл организавал на goto. В товем случае это 100% не оправдано. Я понимаю что свои ошибки неприяно признавать, но попробуй взглянуть на этот код глазами человека которй его не писал...
P>И макросами здесь не поможешь.
Дык сдесь они и не нужны.
P>Ибо макросы еще большие грабли. _Имхо_.
Погляди на разные MAP-ы и на реализацию W2A в ATL.
P>На 3-й вариант (от m.a.g) я вообще еще ничего не ответил.
Это какой... Т.е. можно это понимать как согласие с ним?
P>ЗЫж А насчет "более понятные окружающим", еще раз повторюсь — отучаемся говорить за всех.
Я являюсь окружающим? Ну, тогда в чем мои слова не верны? Если не веришь давай поставим это вопрос на голосование.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Sergey, Вы писали:
S>В 10 раз? Смотря что за код, можно написать и так, что оптимизированный код в 100 раз быстрее будет. Может я пишу чего неправильно, или у меня компилятор неправильный, но вот сейчас проверил на днях написанный критичный по быстродействию кусок (время в ms):
S>Без оптимизации, по скорости по размеру S>но с /Ob1
S>3565 3265 3115 S>3755 3284 3645 S>3405 3535 3315 S>3525 3405 3265
Значит не все включил. Я не помню, что такое /Ob1, но там и без того опций хватает.
10 мы получали на своих приложениях. Правда при этом мерился debug vs. release. Тестирование было очень простое. Мы брали наш ascBD и проганяли ряд тестов. Потом компилировали тоже самое в релиз с выкрученой по максимуму оптимизацией по скорости (с автопоинлайнингом...).
В наших приложениях энтенсивно используются шаблоны. Ну, и стараемся делать функции более короткими (декомпозицию проводим). В остольном обычный код.
Я специально не стал брать синтетику (вызов одного метода...).
Как видишь в основном получается около 2-х раз, но один тест аж в 12!
Чем отличаются эти тесты? Во всех случаях кроме String-а это отдельные алгоритмы реализованные в одной функции. String же вызывает оператор += у класса CString. Без оптимизации вызовы делаются как полагается через стек. В оптимизированном варианте VC сделало автоподстановку чем значительно сократило накладные расходы. В остальных же случаях код довольно оптимально написан, так что оптимизатору нужно постараться.
Если твоя программа написана на goto и в стиле дремучего С, то выигрыш будет не велик, но если ты используешь шаблоны и классы-обертки, но разница может значительно превышать 10 раз.
S>А поскольку большая часть кода все равно не критична ко времени исполнения, мне все равно, что там компилятор нагенерит. Хотя я тоже за использование оптимизатора :)
Задачи разные бывают. Мы пишем компоненты которые используются в сервере приложений. Тут не бывает не критичных частей (ну, если только код инициализации и очистки глобальных объектов). К тому же если программа тормозит, то тормозит вся, вместе с теми 10% которые критичны.
VD>>Там объяснено, что многие функции CRT (а вернее ее стартап-код) не тянут и их можно смело использовать.
S>Я, типа, в курсе, что стартап не все тянут. Но я не считаю, что CRT == CRT startup.
Ты говоришь об использовании 1-2 функций из CRT. Так? Думаю, дальше ты и сам поймешь мою мысль. :)
S>Так я-то говорил про CRT, а не про ейный стартап.
А CRT сам по себе вообще никому не нужен. Нужны отдельные его функции. Сегодня мы используем из CRT 2-4 функции которые не цепляют старпап. Если будет нужна пятая, выдерем и ее.
S>Ладно, а C без printf'а — это C?
С — это язык. printf — всего лишь одна функция из его стандартной библиотеки. Зачем мешать пух с котлетами? Вот представь пишешь ты графическую программу на С... зачем тебе буден этот printf?
Хотя printf появился вместе с С и является его культурным пластом (что ли?). С++ же появился без STL. STL появилась значительно позже. Я изучал С++ без STL и использовал много библиотек которые были совершенно не похожи на STL но делали тоже самое. В конце концов не начинать же пользоваться STL только потому, что кто-то сказал что это стандартно? На сегодня у нас есть свои библиотеки которые во многом луче STL... Но опять же я не призываю ее не использовать, я просто не хочу чтобы навязывали мнение, что без нее никуда. Это ведь не правда.
VD>>А предствь себе какой может быть рынок сбыта для COM-объектов под Уних? :) А мы именно их делаем.
S>А я некоторую часть кода на чистом С++ пишу, а потом, по мере необходимости, в COM заворачиваю. Скажут через пять лет к перлу/васику/шарпу/жабе прикрутить — прикручу.
Пойми у нас с тобой разные задачи. Тебе нужна переносимость. Мне производительность, малые размеры и отсутствие зависимости. Поэтому мне CRT вредно, а для тебя без него будет ужасный геморрой. Так что давай жить как жили, только я не будет никого уговаривать, что CRT вообще никому не нужна, а ты что без нее и без STL нельзя жить, и что без них С++ не С++ и т.п. :) Договорились?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Sergey, Вы писали:
...>>Написать программу на C++ для решения задачи, которая естественным образом раскладывается в глобальные действия над глобальными данными.
S>А, таки кто-то вспомнил о мамонте, ради поражения которого и придумывался кремневый наконечник для копья, более известный как goto. Ну так такие задачи, если они большие, уж много лет принято естественным или не очень образом раскладывать на более мелкие, и с данными работать локально.
Да, но если вдруг внутри крупной проблемы возникает мелкая задачка, которая естественным образом раскладывается в глобальные операции над глобальными данными (fe какая-нибудь задача трансформации строки, управляемая правилами), то лучше этот маленький кусочек написать в стиле схем Янова и не мучать себя структурностью.
Вообще, написание действительно большого проекта в одном стиле свидетельствует либо о недостаточной квалификации разработчиков, либо о дефекте проектирования. Всегда возникают локальные подзадачи, лучше выражаемые на стиле, отличном от основного. Если при этом язык позволяет поддержать все используемые стили, то это вообще шикарно. Не буду голословным:
— кто сейчас пишет парсеры вручную? есть же lex/yacc/bison/antlr etc Ведь парсеры — обработка, основанная на
правилах, структурно писать их не слишком удобно
— 'AI' в игрушках, что бы не говорили, писать на Prolog/Refal удобнее, чем на C/C++
— конечные автоматы тоже не слишком удобно реализуются на C/C++. Гораздо удобнее моделировать их на UML и
создавать код автоматически (кстати, проект Zebra, в котором я работаю, этим и занимается)
— Событийная модель. В ООП ложится, но вот в структурность — никак.
— Математика. Ну как ее в ООП засунуть? Самая мощная модель, которая помогает работать с математикой —
объектная, благо отношения наследования в ООП в математике никак не помогают (заинтересовавшихся отсылаю
к книге Элджера "C++ for real programmers" или в любую книгу по теории моделей). Так что писать ООП
программы для работы с математическими выражениями не слишком удобно, тут нужно либо обобщенное, либо
структурное программирование, непосредственно выражающие алгоритмику.
— [место для вашей рекламы]
Таким образом, каждую часть кода нужно писать в том стиле, который наиболее естественен для решаемой подзадачи (вот меня недавно хотели усадить трансформировать UML диаграмму -> HTML с помощью Java. Не дался, на XSLT все сделал), а вот для каждого конкретного стиля можно решать, нужен там goto или его туда вообще вставлять нельзя.
S>>>А вообще, у оператора goto есть одна неприятная особенность — он потенциально может передать управление куда угодно, "вверх" или "вниз", в отличие от return или break. Струкутурно программа написана или как-то иначе, роли не играет — тупо увеличивается время на поиск метки. Чеолвек мыслит в основном идиомами, а неоправданное применение goto эти идиомы разбивает (оправданным я считаю, например, применение goto для очистки ресурсов в C++, совершенно идеоматическое, кстати, особенно если метку называть как-нибудь вроде cleanup).
Поправка. Обыкновенная зашоренность сознания. Идиомы, говорящие, что не будет неожиданного перехода — структурные идиомы. Человеку, привыкшему писать в структурном стиле, сложно понять реализацию схем Янова, очевидно. Человеку, привыкшему реализовывать схемы Янова, трудно понять структурные программы. Бывалому ассемблерщику метку найти очень просто , но он будет долго разбираться со специализацией шаблонов etc
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Patalog, Вы писали:
VD>По поводу циклав и граблей. Это применение for может вызвать грабли, как и случилось у троих человек пытавшихся переписать твой код. Многие языки высокого уровня специально не включают никаких кострукций кроме while (тот же Паскль имеет очень ограниченны по возможностям for именно по этому). И сделно это по тем же причинам, по которым не рекомендуется применять goto. В while-е вся логика идет последовательно сверху в низ и не может редставлять проблем для чтения (если конечно код не напихан).
Имхо, эти грабли которые ты упоминаешь, вызваны протой невнимательностью. _Всю_ логику в "последовательно сверху в низ" не впихнешь.
VD>Тебе правильно заметили, что случай твой класичкский. Повтор операции после сбоя. И решатся он именно заключеним в цикл. Ты это и сделал, но цикл организавал на goto. В товем случае это 100% не оправдано. Я понимаю что свои ошибки неприяно признавать, но попробуй взглянуть на этот код глазами человека которй его не писал...
Vlad, в чем ошибка то, ты объясни наконец. Код верный, работает прекрасно. Кто скажет, что его невозможено модифицировать, пусть первый кинет в меня камень.(c) В чем неоправданность такого решения? То что читать труднее? Спорно. И об этом говорил не только я, но и пресловутые "окружабющие".
В общем, как я и говорил в самом начале, вопрос скорее эстетический, а о вкусах как говориться не спроят. Дальнейший спор не имеет смысла, каждый остался при своем мнении.
P>>И макросами здесь не поможешь.
VD>Дык сдесь они и не нужны.
Дык вроде это ты говорил что что-то там можно завернуть в макросы и т.д.
P>>Ибо макросы еще большие грабли. _Имхо_.
VD>Погляди на разные MAP-ы и на реализацию W2A в ATL.
Ну и? Корректно, как и некорректно можно написать что угодно. Тебе привести примеры, когда макрос будет потенциальной граблей? Или может ты уже сам наступал?
P>>На 3-й вариант (от m.a.g) я вообще еще ничего не ответил.
VD>Это какой... Т.е. можно это понимать как согласие с ним?
Сильно понравился своей оригинальностью.
P>>ЗЫж А насчет "более понятные окружающим", еще раз повторюсь — отучаемся говорить за всех.
VD>Я являюсь окружающим? Ну, тогда в чем мои слова не верны? Если не веришь давай поставим это вопрос на голосование.
Являешься. Но ты говорил о 80%. Или ты и есть все 80?
Поставь. Правда, там уже и так куча гололсований навеянных этим тредом. Может он войдет в историю...
ЗЫж Кстати, идея, может сделать что-то типа книги рекордов RSDN?
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Sergey, Вы писали:
S>>В 10 раз? Смотря что за код, можно написать и так, что оптимизированный код в 100 раз быстрее будет. Может я пишу чего неправильно, или у меня компилятор неправильный, но вот сейчас проверил на днях написанный критичный по быстродействию кусок (время в ms):
S>>Без оптимизации, по скорости по размеру S>>но с /Ob1
S>>3565 3265 3115 S>>3755 3284 3645 S>>3405 3535 3315 S>>3525 3405 3265
VD>Значит не все включил. Я не помню, что такое /Ob1, но там и без того опций хватает.
Ладно, а что надо было включать? Я включал просто "оптимизацию по размеру" и "оптимизацию по скорости". А /Ob1 — разрешить инлайновость.
VD>10 мы получали на своих приложениях. Правда при этом мерился debug vs. release. Тестирование было очень простое. Мы брали наш ascBD и проганяли ряд тестов. Потом компилировали тоже самое в релиз с выкрученой по максимуму оптимизацией по скорости (с автопоинлайнингом...).
Во-первых, debug vs. release сами по себе в среднем (на достаточно большом куске кода) отличаются по производительности в 2-3 раза.
VD>В наших приложениях энтенсивно используются шаблоны. Ну, и стараемся делать функции более короткими (декомпозицию проводим). В остольном обычный код.
. Вот некоторые результаты:
VD>String 3.69 47.80 12.95 VD>pi 3.15 6.16 1.96 VD>QuickSort 6.07 11.80 1.94 VD>BubbleSort 4.19 9.39 2.24 VD>StrangeAttractor 1.4 2.84 2.03
VD>Я специально не стал брать синтетику (вызов одного метода...).
Хм, надо будет QuickSort проверить. Чего то слишком большие отличия.
VD>Как видишь в основном получается около 2-х раз, но один тест аж в 12!
VD>Чем отличаются эти тесты? Во всех случаях кроме String-а это отдельные алгоритмы реализованные в одной функции. String же вызывает оператор += у класса CString. Без оптимизации вызовы делаются как полагается через стек. В оптимизированном варианте VC сделало автоподстановку чем значительно сократило накладные расходы. В остальных же случаях код довольно оптимально написан, так что оптимизатору нужно постараться.
Я ж сказал — я инлайновость тоже включаю. Без нее и вправду плохо бывает. А вот остальные опции выигрыш дают достаточно маленький.
VD>Если твоя программа написана на goto и в стиле дремучего С, то выигрыш будет не велик, но если ты используешь шаблоны и классы-обертки, но разница может значительно превышать 10 раз.
В вычислениях особо не позаворачиваешь :) А вообще, выполнение некоторых достаточно простых правил, например вынесение многоэтажного разыменования из цикла, приводит к тому, что оптимизатору негде разгуляться.
S>>А поскольку большая часть кода все равно не критична ко времени исполнения, мне все равно, что там компилятор нагенерит. Хотя я тоже за использование оптимизатора :)
VD>Задачи разные бывают. Мы пишем компоненты которые используются в сервере приложений. Тут не бывает не критичных частей (ну, если только код инициализации и очистки глобальных объектов). К тому же если программа тормозит, то тормозит вся, вместе с теми 10% которые критичны.
У нас — нет :) Если тормозит вычислительная часть, на юзер интерфейсе это никак не сказывается. Просто будет считать в 10 раз дольше :)
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте m.a.g., Вы писали:
...>>>Написать программу на C++ для решения задачи, которая естественным образом раскладывается в глобальные действия над глобальными данными.
S>>А, таки кто-то вспомнил о мамонте, ради поражения которого и придумывался кремневый наконечник для копья, более известный как goto. Ну так такие задачи, если они большие, уж много лет принято естественным или не очень образом раскладывать на более мелкие, и с данными работать локально.
...>Да, но если вдруг внутри крупной проблемы возникает мелкая задачка, которая естественным образом раскладывается в глобальные операции над глобальными данными (fe какая-нибудь задача трансформации строки, управляемая правилами), то лучше этот маленький кусочек написать в стиле схем Янова и не мучать себя структурностью.
Это все от лени. Получишь (скорее всего, небольшой) выигрыш сейчас и проигрыш (а вот проигрыш обычно поболее) потом, в процессе поддержки программы.
...>Вообще, написание действительно большого проекта в одном стиле свидетельствует либо о недостаточной квалификации разработчиков, либо о дефекте проектирования. Всегда возникают локальные подзадачи, лучше выражаемые на стиле, отличном от основного. Если при этом язык позволяет поддержать все используемые стили, то это вообще шикарно. Не буду голословным:
...>- кто сейчас пишет парсеры вручную? есть же lex/yacc/bison/antlr etc Ведь парсеры — обработка, основанная на ...> правилах, структурно писать их не слишком удобно
...>- 'AI' в игрушках, что бы не говорили, писать на Prolog/Refal удобнее, чем на C/C++
...>- конечные автоматы тоже не слишком удобно реализуются на C/C++. Гораздо удобнее моделировать их на UML и ...> создавать код автоматически (кстати, проект Zebra, в котором я работаю, этим и занимается)
...>- Событийная модель. В ООП ложится, но вот в структурность — никак.
...>- Математика. Ну как ее в ООП засунуть? Самая мощная модель, которая помогает работать с математикой - ...> объектная, благо отношения наследования в ООП в математике никак не помогают (заинтересовавшихся отсылаю ...> к книге Элджера "C++ for real programmers" или в любую книгу по теории моделей). Так что писать ООП ...> программы для работы с математическими выражениями не слишком удобно, тут нужно либо обобщенное, либо ...> структурное программирование, непосредственно выражающие алгоритмику.
...>- [место для вашей рекламы] :)
...>Таким образом, каждую часть кода нужно писать в том стиле, который наиболее естественен для решаемой подзадачи (вот меня недавно хотели усадить трансформировать UML диаграмму -> HTML с помощью Java. Не дался, на XSLT все сделал), а вот для каждого конкретного стиля можно решать, нужен там goto или его туда вообще вставлять нельзя.
Ну-ну. Попробуй тогда для программирования на С++ придумать задачу, где массирование применение goto было бы оправданным. И, кстати, лично я считаю, что обобщенное программирование от ООП отличается только "технологически" — производительностью, способом реализации, но не концептуально. Все, что можно сделать с помощью обобщенного программирования, можно сделать с помощью ООП, но (в рамках существующих языков и компиляторов) с большими издержками и, возможно, менее изящно (хотя на вкус и на цвет...).
S>>>>А вообще, у оператора goto есть одна неприятная особенность — он потенциально может передать управление куда угодно, "вверх" или "вниз", в отличие от return или break. Струкутурно программа написана или как-то иначе, роли не играет — тупо увеличивается время на поиск метки. Чеолвек мыслит в основном идиомами, а неоправданное применение goto эти идиомы разбивает (оправданным я считаю, например, применение goto для очистки ресурсов в C++, совершенно идеоматическое, кстати, особенно если метку называть как-нибудь вроде cleanup).
...>Поправка. Обыкновенная зашоренность сознания. Идиомы, говорящие, что не будет неожиданного перехода — структурные идиомы.
Зашоренность это или нет, но, поскольку возможности мозга не безграничны, речь идет о банальном перераспределении ресурсов — если программисту придется удерживать в голове взаимосвязи между десятком-другим меток и операторов goto, он просто не сможет сконцентрировать внимание ни на чем другом, в том числе на решаемой задаче.
...>Человеку, привыкшему писать в структурном стиле, сложно понять реализацию схем Янова, очевидно. Человеку, привыкшему реализовывать схемы Янова, трудно понять структурные программы. Бывалому ассемблерщику метку найти очень просто ;), но он будет долго разбираться со специализацией шаблонов etc
Ну, сравни производительность труда "бывалого ассемблерщика" и среднего "программиста на С++" при программировании на С++. То, к каким идиомам человек привык, конечно, играет роль, но не ключевую — увидит более удобную, привыкнет и к ней. Это как с аппликатурой при игре на гитаре — если сразу научили правильно ставить пальцы, играть тебе будет проще. Если же нет, возможно, разовьешь большую гибкость пальцев, но играть все равно будешь хуже, если ты, конечно, не гений. Идиомы не на пустом месте возникли, они отражают возможности "среднего" человека, хорошо это или плохо.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
S>Ну, сравни производительность труда "бывалого ассемблерщика" и среднего "программиста на С++" при программировании на С++. То, к каким идиомам человек привык, конечно, играет роль, но не ключевую — увидит более удобную, привыкнет и к ней. Это как с аппликатурой при игре на гитаре — если сразу научили правильно ставить пальцы, играть тебе будет проще. Если же нет, возможно, разовьешь большую гибкость пальцев, но играть все равно будешь хуже, если ты, конечно, не гений. Идиомы не на пустом месте возникли, они отражают возможности "среднего" человека, хорошо это или плохо.
Если уж продолжать метафоры, то C++ — это не гитара, а некий инструмент, превращаемый хоть в баян, хоть в балалайку, хоть в саксофон. И иметь возможность воспользоваться всей силой C++ — это уметь играть на всех этих инструментах. Тогда твои слова звучат так: "поскольку большинство людей пользуется C++ как губной гармошкой, то нужно при работе с C++ в качестве рояля держать рояль двумя руками, прикладывать ко рту и дуть в него".
S>Ну, сравни производительность труда "бывалого ассемблерщика" и среднего "программиста на С++" при программировании на С++. То, к каким идиомам человек привык, конечно, играет роль, но не ключевую — увидит более удобную, привыкнет и к ней. Это как с аппликатурой при игре на гитаре — если сразу научили правильно ставить пальцы, играть тебе будет проще. Если же нет, возможно, разовьешь большую гибкость пальцев, но играть все равно будешь хуже, если ты, конечно, не гений. Идиомы не на пустом месте возникли, они отражают возможности "среднего" человека, хорошо это или плохо.
Если уж продолжать метафоры, то C++ — это не гитара, а некий инструмент, превращаемый хоть в баян, хоть в балалайку, хоть в саксофон. И иметь возможность воспользоваться всей силой C++ — это уметь играть на всех этих инструментах. Тогда твои слова звучат так "поскольку большинство людей пользуется C++ как губной гармошкой, то нужно при работе с C++ в качестве рояля держать рояль двумя руками, прикладывать ко рту и дуть в него".
Здравствуйте m.a.g., Вы писали:
S>>Ну, сравни производительность труда "бывалого ассемблерщика" и среднего "программиста на С++" при программировании на С++. То, к каким идиомам человек привык, конечно, играет роль, но не ключевую — увидит более удобную, привыкнет и к ней. Это как с аппликатурой при игре на гитаре — если сразу научили правильно ставить пальцы, играть тебе будет проще. Если же нет, возможно, разовьешь большую гибкость пальцев, но играть все равно будешь хуже, если ты, конечно, не гений. Идиомы не на пустом месте возникли, они отражают возможности "среднего" человека, хорошо это или плохо.
...>Если уж продолжать метафоры, то C++ — это не гитара, а некий инструмент, превращаемый хоть в баян, хоть в балалайку, хоть в саксофон. И иметь возможность воспользоваться всей силой C++ — это уметь играть на всех этих инструментах. Тогда твои слова звучат так: "поскольку большинство людей пользуется C++ как губной гармошкой, то нужно при работе с C++ в качестве рояля держать рояль двумя руками, прикладывать ко рту и дуть в него".
Ну это уже демагогия пошла — аналогия совершенно некорректная. Попробуй на С++ писать как на прологе.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте Patalog, Вы писали:
P>Имхо, эти грабли которые ты упоминаешь, вызваны протой невнимательностью.
На грабли всегда наступают по невнимательности. Вот только в нормальном доме их по проходу не разбрасывают.
P>_Всю_ логику в "последовательно сверху в низ" не впихнешь.
Естественно, для повторного вызова кода существуют циклы и функции.
P>Vlad, в чем ошибка то, ты объясни наконец.
Ты вместо оператора цикла или перекомпановки кода организовал циклв на goto при этом твой код стал не структурированным и сложным для восприятия.
P>Код верный, работает прекрасно.
Предложенные тебе замены тоже работают прекрасно, но полностью структурированны и легко читаются (не содержат неожиданностей).
P> Кто скажет, что его невозможено модифицировать, пусть первый кинет в меня камень.(c) В чем неоправданность такого решения? То что читать труднее? Спорно. И об этом говорил не только я, но и пресловутые "окружабющие".
И что был хотябы один человек который сказал, что твой вариант оправдан? Если очень хочется то поставь предложенные варианты на голосование. Народ тебе сам покажет какой вариант они выберут.
P>В общем, как я и говорил в самом начале, вопрос скорее эстетический, а о вкусах как говориться не спроят. Дальнейший спор не имеет смысла, каждый остался при своем мнении.
Это к вкусом никакого отношения не имеют. Как грязь и разгильдяйство не могут быть составляющими культуры, так применение конструкций делающих код неструктурированным не имеет отношения к вкусом.
Заметь большинство защитников goto оппелировали к тому, что goto можно использовать не нарушая струкурированнсоти прогаммы. Той же случай таковым не является.
P>>>И макросами здесь не поможешь. VD>>Дык сдесь они и не нужны. P>Дык вроде это ты говорил что что-то там можно завернуть в макросы и т.д.
Это говорил IT и еще ктото. Я сними согласен, но они говорили о другом случае. Там разбирались случаи выхода из вложенного цикла и обработка ошибок с помощью goto. Ты же с помощью этого оператора организуешь дополнительный цикл.
P>>>Ибо макросы еще большие грабли. _Имхо_.
VD>>Погляди на разные MAP-ы и на реализацию W2A в ATL.
P>Ну и? Корректно, как и некорректно можно написать что угодно. Тебе привести примеры, когда макрос будет потенциальной граблей? Или может ты уже сам наступал?
Макросы это механизм позволяющий обойти недостаки языка и реализовать абстракции которых этот язык не поддерживает. Если человек полностью осознает что он делает, то макросы можно использовать для благих целей. Хотя в немумелых руках макросы могут породить очень трудно обнаруживаемые грабли.
P>>>На 3-й вариант (от m.a.g) я вообще еще ничего не ответил. VD>>Это какой... Т.е. можно это понимать как согласие с ним?
P>Сильно понравился своей оригинальностью.
Да, который? И, что же в нем такого оригинального?
P>Являешься. Но ты говорил о 80%. Или ты и есть все 80?
Я делаю предположиния. На сегодня я могу сказать тебе более точную цифру:
Можно ли использовать goto?
Обязательно! 0.86%
Можно. 14.66%
Итого: 15.52%
Нежелательно,
но иногда приходится. 31.90%
Крайне нежелательно. 40.52%
Гнать в шею 6.03%
Можно, но я так
делать не буду. ;^) 6.03%
Итого: 84.48%
Врят ли ты будешь спорить, что в твоем случае представители второй группы согласились бы, что применение в твоем случае goto является необъодимым, а сталобыть и оправданным. Так что я ошибся не сильно... на 4%.
P>Поставь. Правда, там уже и так куча гололсований навеянных этим тредом. Может он войдет в историю...
Он вошел в историю еще 30 лет назад. А ставить должен ты. Мне и так все ясно.
P>ЗЫж Кстати, идея, может сделать что-то типа книги рекордов RSDN?
Боюсь я тебя расстрою... Такая крига уже есть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Sergey, Вы писали:
S>Ладно, а что надо было включать?
Проекты Шустрика доступны на этом сайте. Скачай погляди. Если коротко, то все. У VC7 есть еще одна крутая опция оптимизации (/GL для компилятора и /LTCG для линкера). Называется "Whole program optimithation". Общий смысл таков она помещает в obj-и не машинный код, а нечто на подобии MSIL (промежуточный байт-код) и ликер сам генерирует код. При этом инлайнится могут любые функции, даже если они помещены в отдельных cpp-файлах и доступны через axtern (кроме библиотечных). С этой опцией к сожалению не совместмы прекомпелируемые заголовочные файлы.
S>Я включал просто "оптимизацию по размеру" и "оптимизацию по скорости". А /Ob1 — разрешить инлайновость.
Там еще куча оций. Скачай проект посмотри.
И лучше не /Ob1, а /Ob2, ну, и /GL c /LTCG.
Кстати, инлайн подстановка это очень важная часть оптимизации. Так что говорить, что ты измерял скорость не оптимизированной версии нельзя. Дюди принимающие решение отказаться от оптимизатора считают, что он глючит (хотя в 99% гличит именно их код). По этому они не только не включают какой-нибудь оптимизации, но и оставлюяют все настройки как дебаге. Это позволяет им не вылавливать ошибки в релизе (ошибки попросту замазываются дебаг-инициализацией и т.п.).
S>Во-первых, debug vs. release сами по себе в среднем (на достаточно большом куске кода) отличаются по производительности в 2-3 раза.
Дык все отличия и заключаются в отключенной оптимизации и дебажных библиотеках. В Шустрике библиотекчных функций не использовалось (только класс строк). Но как я уже говорил раньше те кто борятся с оптимизацией борятся и с рантайм-библиотеками.
S>Хм, надо будет QuickSort проверить. Чего то слишком большие отличия.
Я наверно забыл описать колонки.
Так что еще раз:
Тестт С оптимизацией Без оптимизации Разница в %
String 3.69 47.80 12.95
pi 3.15 6.16 1.96
QuickSort 6.07 11.80 1.94
BubbleSort 4.19 9.39 2.24
StrangeAttractor 1.4 2.84 2.03
S>Я ж сказал — я инлайновость тоже включаю. Без нее и вправду плохо бывает. А вот остальные опции выигрыш дают достаточно маленький.
Ну, ты еще /Ox добавь и говори, что без оптимизации.
S>В вычислениях особо не позаворачиваешь А вообще, выполнение некоторых достаточно простых правил, например вынесение многоэтажного разыменования из цикла, приводит к тому, что оптимизатору негде разгуляться.
Этих правил штук двадцать (если не больше), и их выполнение зачастую делает код менее читабельным (хотя иногда и наоборот). Так что лучше заботится о читаемости кода, а пробемы с местной оптимизацие возложить на компилятор.
VD>>Задачи разные бывают. Мы пишем компоненты которые используются в сервере приложений. Тут не бывает не критичных частей (ну, если только код инициализации и очистки глобальных объектов). К тому же если программа тормозит, то тормозит вся, вместе с теми 10% которые критичны.
S>У нас — нет Если тормозит вычислительная часть, на юзер интерфейсе это никак не сказывается. Просто будет считать в 10 раз дольше
Мне вот интересна мотивация тех кто выключает оптимизацию. Я видил много "ошибок релиз-версии", 99% из них не были связаны с оптимизатором.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
S>>Ладно, а что надо было включать?
VD>Проекты Шустрика доступны на этом сайте. Скачай погляди. Если коротко, то все. У VC7 есть еще одна крутая опция оптимизации (/GL для компилятора и /LTCG для линкера). Называется "Whole program optimithation". Общий смысл таков она помещает в obj-и не машинный код, а нечто на подобии MSIL (промежуточный байт-код) и ликер сам генерирует код. При этом инлайнится могут любые функции, даже если они помещены в отдельных cpp-файлах и доступны через axtern (кроме библиотечных). С этой опцией к сожалению не совместмы прекомпелируемые заголовочные файлы.
А прекомпилируемые заголовочные файлы тоже неслабо глючат. Сколько раз из-за них pure virtual function call получал, и не сосчитать.
S>>Я включал просто "оптимизацию по размеру" и "оптимизацию по скорости". А /Ob1 — разрешить инлайновость.
VD>Там еще куча оций. Скачай проект посмотри.
Ну, скачал (первого, для третьего ссылка битая), почти те же опции, что и я использовал для второй колонки. Не считая того, что вы зачем-то включили /Op, и ваша программа "may be slower and larger than one compiled without /Op". И включили две неизвестные моему компилятору опции /O3 и /QaxM :)
VD>И лучше не /Ob1, а /Ob2, ну, и /GL c /LTCG.
С выключенной оптимизацией (/Od) на моем коде я отличий /Ob1 от /Ob2 не заметил — в бинарнике размером 884736 bytes отличаются всего 2726 байт, размер бинарников совпадает.
VD>Кстати, инлайн подстановка это очень важная часть оптимизации. Так что говорить, что ты измерял скорость не оптимизированной версии нельзя. Дюди принимающие решение отказаться от оптимизатора считают, что он глючит (хотя в 99% гличит именно их код). По этому они не только не включают какой-нибудь оптимизации, но и оставлюяют все настройки как дебаге. Это позволяет им не вылавливать ошибки в релизе (ошибки попросту замазываются дебаг-инициализацией и т.п.).
Не надо обобщений :) Во-первых, оптимизатор и вправду глючит — я видел как минимум два случая собственными глазами. Другое дело, что даже для debug я натыкался как минимум на одну ошибку кодогенерации — компилятор построил для одной функции exception frame там, где его быть не должно, а дальше нагенерил код как будто этого фрейма и не было. Естественно, программа падала при обращении к первой же переменной в этой функции. И не надо мне говорить, что это мне померещилось — я часа три потратил, чтобы разобраться что к чему :) Насчет настроек в release как в дебаге — этим не занимаюсь :)) Простое включение опции /Od не приводит к debug инициализации переменных.
S>>Во-первых, debug vs. release сами по себе в среднем (на достаточно большом куске кода) отличаются по производительности в 2-3 раза.
VD>Дык все отличия и заключаются в отключенной оптимизации и дебажных библиотеках. В Шустрике библиотекчных функций не использовалось (только класс строк).
В два-три раза по быстродействию код отличается и из-за разных библиотек, и из-за debug инициализации, я ж release с выключенной оптимизацией c дебагом сравнивал. А может, и еще из-за чего, о чем я и не подозреваю :)
А для CString сравнивать debug с release и говорить, что сравнивали код с оптимизацией и код без оптимизации вообще нельзя. Потому что сравнивали по быстродействию вы совершенно разный код. Загляни в имплементацию MFC'шного CString и убедись.
VD>Но как я уже говорил раньше те кто борятся с оптимизацией борятся и с рантайм-библиотеками.
S>>Хм, надо будет QuickSort проверить. Чего то слишком большие отличия.
VD>Я наверно забыл описать колонки. :shuffle:
VD>Так что еще раз: VD>
VD>Тестт С оптимизацией Без оптимизации Разница в %
VD>String 3.69 47.80 12.95
VD>pi 3.15 6.16 1.96
VD>QuickSort 6.07 11.80 1.94
VD>BubbleSort 4.19 9.39 2.24
VD>StrangeAttractor 1.4 2.84 2.03
VD>
Ну, в отличия по производительности до 2 раз я вполне верю. Я было подумал, третья колонка — какая-нибудь особо извращенная оптимизация :)
S>>Я ж сказал — я инлайновость тоже включаю. Без нее и вправду плохо бывает. А вот остальные опции выигрыш дают достаточно маленький.
VD>Ну, ты еще /Ox добавь и говори, что без оптимизации. ;)
Э, нее... Мы про оптимизацию заговорили, когда кто-то утверждал, что оптимизатор от кода в каком-то конкретном примере камня на камне не оставит, а я сказал что оптимизацию не использую. Вот в том контексте разрешение инлайновости — не оптимизация. А вообще на тему, считать ли инлайновость оптимизацией можно долго и бесплодно флеймить :). Лично я /Ob, /Oy (Frame-Pointer Omission) и /Oi (Generate Intrinsic Functions) за оптимизацию не считаю — их принадлежность к опциям оптимизации скорее маркетинговый ход. Скорее уж /Od следовало бы называть не disable optimization, а generate dumb code :)
Хотя /Oy я тоже не использую — с ней стек не раскрутишь, если программа упадет.
S>>В вычислениях особо не позаворачиваешь :) А вообще, выполнение некоторых достаточно простых правил, например вынесение многоэтажного разыменования из цикла, приводит к тому, что оптимизатору негде разгуляться.
VD>Этих правил штук двадцать (если не больше), и их выполнение зачастую делает код менее читабельным (хотя иногда и наоборот). Так что лучше заботится о читаемости кода, а пробемы с местной оптимизацие возложить на компилятор.
В моем случае проблемы с местной оптимизацией не обсуждаются :) Партия сказала "надо". А насчет двадцати штук правил ты, IMHO, переборщил. А вообще, все эти правила еще со времен царя гороха сидят в башке и под руку толкают, так что их применение почти бесплатно.
VD>Мне вот интересна мотивация тех кто выключает оптимизацию. Я видил много "ошибок релиз-версии", 99% из них не были связаны с оптимизатором.
Да простая мотивация — оптимизатор таки (изредка) поглюкивает, и у нас считают, что выигрыш от его использования не окупает необходимости борьбы с этими глюками. Что касается "ошибок релиз-версии", то вот они мне что-то редко встречаются (как бы не сглазить...)
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте Sergey, Вы писали:
S>А прекомпилируемые заголовочные файлы тоже неслабо глючат. Сколько раз из-за них pure virtual function call получал, и не сосчитать.
Не замечал. Мы в дебаге всегда их используем. Даже с ними компилиция проекта (полная) занимает по 20 минут. Так что без них нугуда. :(
S>>>Я включал просто "оптимизацию по размеру" и "оптимизацию по скорости". А /Ob1 — разрешить инлайновость.
VD>>Там еще куча оций. Скачай проект посмотри.
S>Ну, скачал (первого, для третьего ссылка битая)
Тогда попробуй вот отсюда: http://www.optim.ru/cs/2002/1/shustric3/shustrik3.asp
S>, почти те же опции, что и я использовал для второй колонки. Не считая того, что вы зачем-то включили /Op, и ваша программа "may be slower and larger than one compiled without /Op".
Ты по-моему говорил, что компилировался с одной /Ob1.
S>И включили две неизвестные моему компилятору опции /O3 и /QaxM :)
Это для Intel C++.
VD>>И лучше не /Ob1, а /Ob2, ну, и /GL c /LTCG.
S>С выключенной оптимизацией (/Od) на моем коде я отличий /Ob1 от /Ob2 не заметил — в бинарнике размером 884736 bytes отличаются всего 2726 байт, размер бинарников совпадает.
Компилируя большой проект (ascDB) мы получали примерно 10-20 процентов выигрыша с /Ob2. Что дают /GL c /LTCG пока не пробывали, так как они появились только в VC7. Но судя по иписанию они должны давать хорошую скорость даже с выключенной /Ob
S>Не надо обобщений :) Во-первых, оптимизатор и вправду глючит
Все на свете глючит. Но все же ошибки оптимизатора встречаются на порядки реже чем ляпы программистов которые своливаются на оптимизатор.
VD>>Дык все отличия и заключаются в отключенной оптимизации и дебажных библиотеках. В Шустрике библиотекчных функций не использовалось (только класс строк).
S>В два-три раза по быстродействию код отличается и из-за разных библиотек,
В Шустрике небыло разных быиблиотек. Там вообще не вызывались библиотечные функции.
S>А для CString сравнивать debug с release и говорить, что сравнивали код с оптимизацией и код без оптимизации вообще нельзя. Потому что сравнивали по быстродействию вы совершенно разный код. Загляни в имплементацию MFC'шного CString и убедись.
Все равно оптимизированюй код в этом случае будет значительно быстрее.
VD>>Так что еще раз: VD>>
VD>>Тестт С оптимизацией Без оптимизации Разница в %
VD>>String 3.69 47.80 12.95
VD>>pi 3.15 6.16 1.96
VD>>QuickSort 6.07 11.80 1.94
VD>>BubbleSort 4.19 9.39 2.24
VD>>StrangeAttractor 1.4 2.84 2.03
VD>>
S>Ну, в отличия по производительности до 2 раз я вполне верю. Я было подумал, третья колонка — какая-нибудь особо извращенная оптимизация :)
Учти, что это на чистых алгоритмах. В них и оптимизировать то нечего. А на больших приложениях... К тому же люди отказывающиеся от оптимизации обычно попросту используют дебаг-версии.
VD>>Ну, ты еще /Ox добавь и говори, что без оптимизации. ;)
S>Э, нее... Мы про оптимизацию заговорили, когда кто-то утверждал, что оптимизатор от кода в каком-то конкретном примере камня на камне не оставит, а я сказал что оптимизацию не использую. Вот в том контексте разрешение инлайновости — не оптимизация.
Не, уж. Инлайнинг это часть опций оптимизации. Причем одна из самых выжных. Многих оптимизаций просто нельзя добиться без нее, а многие являются часть процесса подстаноки...
S> А вообще на тему, считать ли инлайновость оптимизацией можно долго и бесплодно флеймить :). Лично я /Ob, /Oy (Frame-Pointer Omission) и /Oi (Generate Intrinsic Functions) за оптимизацию не считаю — их принадлежность к опциям оптимизации скорее маркетинговый ход.
Они сильно изменяют код (выбрасывая здоровые куски, с чем и пытаются бороться отказывающиеся от оптимизации) и приводят к существенному увеличению производительности.
Неужели у вас в конторе запрещают оптимизатор но разрешают инлайнинг?
S>Да простая мотивация — оптимизатор таки (изредка) поглюкивает, и у нас считают, что выигрыш от его использования не окупает необходимости борьбы с этими глюками. Что касается "ошибок релиз-версии", то вот они мне что-то редко встречаются (как бы не сглазить...)
:))
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Правда только Word — NT остается в здравии...
.
.
