(имхо, вопрос задан чётко и лаконично, и контекста предостаточно) P>>"Является ли приведённый ниже фрагмент кода синтаксическим онанизмом?: Да 21; Нет 3". AS>Пошутил да. )))) Вообще-то ровно в том же объёме что и RAII, иначе говоря нет, не является. А то что миллионы мух... ну ты сам знаешь, дык вот мне это сугубо фиолетово.
синтаксический онанизм/не онанизм — это сугубо субъективные оценки, поэтому я и сделал опрос.
AS>Кстати, показательно что 3 человека язык таки знают.
Знают? или просто не считают это синтаксическим онанизмом?
AS>>>Ну, по причине неадекватной сложности, ведущей к постоянной борьбе с языком, и постоянного вынужденного скатывания к синтаксическому онанизму. P>>То есть ты как на C++ скатывался к синтаксическому онанизму, так и на C. P>>Кэп mode on: Может дело не в языках, а в тебе? AS>Может быть, а может и в том, что ты не знаком с разными методами писания кода на C недостойном внимания настоящих мачо, ограничившись вузовским введением перед прыжком в гламурно-сахарный С++?
А как вообще я причастен к тому, что ты и на C++ и на С "вынужден скатываться к синтаксическому онанизму", но при этом считаешь это неприемлемым для C++, но приемлемым для C?
P>>>>я спросил как это можно сделать.. P>>>>как пример ты привёл трёхэтажный синтаксический препроцессорный онанизм, против которого ты сам высказывался ранее AS>В макросах, количество которых можно пересчитать по пальцам? Кстати, ты уж разъясни в чём именно там онанизм? В использовании препроцессора? Может некоторое неоднозначное поведение, сложная логика, комплексное использование нетривиальных приёмов программирования без особой надобности?
многоэтажные управляющие структуры для реализации простого пост эффекта.
я не спорю — на C это может быть полезно, так как нет встроенного авто-освобождения ресурсов, но — эта реализация всё равно синтаксический онанизм.
AS>Плюс несколько макросов расширяющих язык специальными конструкциями, которые локальны и на написание остального кода практически не влияют. Есть ровно одно правило — всё что осталось на пуле будет освобождено при выходе из маркированного блока, и никаких магических заклинаний. Макрос лишь просто вставка очистки пула в конец блока. В этом и есть существенный плюс в сравнении с двумя плюсами.
В чём, чём плюс?
Может в runtime overhead на освобождение ресурсов?
P>>то есть когда результаты твоего синтаксического онанизма на C обвёрнуты во что-нибудь, то они уже допустимы? P>>Может тебе стоило попробовать делать тоже самое на C++ ?
AS>А ты вот попробуй. ))) Покажи своё владение силой, Люк. Напиши ровно то же что и я, только на С++, хоть с STL, хоть с сиськами, с чем угодно. Давай сравним простоту, понятность кода и конечно же количество использованных сущностей и их внутреннюю сложность. Только рабочий пример, а не сферического коня в вакууме.
только давай ты сначала выдерешь из своего "рантайма" всё что необходимо для этого примера, и оформишь в виде одного файла, ок?
AS>>>Например реализацию исключений. Да ладно менять, хотя бы гарантировать что она есть. Про шаблонные же выверты можно просто скромно промолчать. P>>какого рода гарантии тебе нужны? AS>Хотя бы просто то что я МОГУ их использовать. Я знаешь ли уже не раз сталкивался с случаями когда каменный цветок упорно отказывался выходить.
В каком году у тебя не выходил каменный цветок последний раз?
P>>То есть ты намекаешь, что сам, лично написал пару лямов строк кода? P>>За сколько лет? AS>Больше ))) Много больше ляма только в своих собственных проектах, для души так сказать. В рамках эксперимента, посмотреть что будет если делать так, и вот так, и ещё вот так, если это вообще работать будет. Но куда тебе такое понять, если для тебя даже работающий пример написать проблема непреодолимой сложности.
сколько лет, и сколько лямов строк собственноручно(+-500k)? это такой сложный вопрос для гулявших по граблям по пути через лямы строк гуру?
если это 4M и 10 лет, то в средним на каждый день получается больше 1k строк, что как-то совсем дохреновато. если конечно это не мелкие зубочистки, либо тонны говнокода.
Здравствуйте, Piko, Вы писали:
AS>>Плюс несколько макросов расширяющих язык специальными конструкциями, которые локальны и на написание остального кода практически не влияют. Есть ровно одно правило — всё что осталось на пуле будет освобождено при выходе из маркированного блока, и никаких магических заклинаний. Макрос лишь просто вставка очистки пула в конец блока. В этом и есть существенный плюс в сравнении с двумя плюсами. P>В чём, чём плюс? P>Может в runtime overhead на освобождение ресурсов?
В C++ надо понимать освобождение ресурсов бесплатное. )
AS>>А ты вот попробуй. ))) Покажи своё владение силой, Люк. Напиши ровно то же что и я, только на С++, хоть с STL, хоть с сиськами, с чем угодно. Давай сравним простоту, понятность кода и конечно же количество использованных сущностей и их внутреннюю сложность. Только рабочий пример, а не сферического коня в вакууме. P>только давай ты сначала выдерешь из своего "рантайма" всё что необходимо для этого примера, и оформишь в виде одного файла, ок?
Ровно после того как ты выдернешь из STL в отдельный файлик, то что нужно тебе шоб написать аналогичный моему пример.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>>>Плюс несколько макросов расширяющих язык специальными конструкциями, которые локальны и на написание остального кода практически не влияют. Есть ровно одно правило — всё что осталось на пуле будет освобождено при выходе из маркированного блока, и никаких магических заклинаний. Макрос лишь просто вставка очистки пула в конец блока. В этом и есть существенный плюс в сравнении с двумя плюсами. P>>В чём, чём плюс? P>>Может в runtime overhead на освобождение ресурсов? AS>В C++ надо понимать освобождение ресурсов бесплатное. )
дешевле.
особенно в случаях где не могут быть выкинуты исключения — вообще бесплатно
AS>>>А ты вот попробуй. ))) Покажи своё владение силой, Люк. Напиши ровно то же что и я, только на С++, хоть с STL, хоть с сиськами, с чем угодно. Давай сравним простоту, понятность кода и конечно же количество использованных сущностей и их внутреннюю сложность. Только рабочий пример, а не сферического коня в вакууме. P>>только давай ты сначала выдерешь из своего "рантайма" всё что необходимо для этого примера, и оформишь в виде одного файла, ок? AS>Ровно после того как ты выдернешь из STL в отдельный файлик, то что нужно тебе шоб написать аналогичный моему пример.
STL — это стандарт
я же не сказал, чтобы ты декларации, а то и определения стандартных функций выдирал.
Здравствуйте, Piko, Вы писали:
P>вы понимаете, что абстракции могут иметь разные реализации. и да, некоторые могут быть медленней. P>но, у нас как бы разговор, и есть определённый контекст. P>Конкретно я имею ввиду, что C++ позволяет писать более абстрактный, более безопасный, и более быстрый код — и всё это одновременно.
Дабы завершить наши препирательства:
Изначально я и обратил ваше внимание, на то, что С++ не позволяет писать более быстрые приложения, чем С. http://www.rsdn.ru/poll/3562.aspx
К моей радости, большая часть аудитории данного форума это понимают. И я даже не знаю, как объяснить это вам, потому, что это фундаментальное знание — и если вы знаете С++, вы понимаете, почему так.
Могу лишь понадеется, что в будущем, когда у вас будет больше опыта вы поймете, почему были неправы.
Здравствуйте, 11molniev, Вы писали:
P>>вы понимаете, что абстракции могут иметь разные реализации. и да, некоторые могут быть медленней. P>>но, у нас как бы разговор, и есть определённый контекст. P>>Конкретно я имею ввиду, что C++ позволяет писать более абстрактный, более безопасный, и более быстрый код — и всё это одновременно.
1>Дабы завершить наши препирательства: 1>Изначально я и обратил ваше внимание, на то, что С++ не позволяет писать более быстрые приложения, чем С. 1>http://www.rsdn.ru/poll/3562.aspx
1>К моей радости, большая часть аудитории данного форума это понимают. И я даже не знаю, как объяснить это вам, потому, что это фундаментальное знание — и если вы знаете С++, вы понимаете, почему так.
то что цитата в вопросе вырвана из контекста, я уже писал
"
Вопрос: С++ позволяет писать более быстрый код чем С?
1. Да 12
2. Нет 27
3. Этот аналогичный код на C, зачастую не пишется и оставляется не оптимальная версия 1
"
3 — относится к моей точки зрения
итого, мою точку зрения поддерживают 32.5% (даже при "плохой" постановке вопроса)
и?
Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
что вам не ясно-то?
вы хотели подтвердить моё высказывание своим опросом?
1>Могу лишь понадеется, что в будущем, когда у вас будет больше опыта вы поймете, почему были неправы.
Здравствуйте, Piko, Вы писали:
P>Здравствуйте, 11molniev, Вы писали:
P>>>вы понимаете, что абстракции могут иметь разные реализации. и да, некоторые могут быть медленней. P>>>но, у нас как бы разговор, и есть определённый контекст. P>>>Конкретно я имею ввиду, что C++ позволяет писать более абстрактный, более безопасный, и более быстрый код — и всё это одновременно.
1>>Дабы завершить наши препирательства: 1>>Изначально я и обратил ваше внимание, на то, что С++ не позволяет писать более быстрые приложения, чем С. 1>>http://www.rsdn.ru/poll/3562.aspx
1>>К моей радости, большая часть аудитории данного форума это понимают. И я даже не знаю, как объяснить это вам, потому, что это фундаментальное знание — и если вы знаете С++, вы понимаете, почему так.
P>то что цитата в вопросе вырвана из контекста, я уже писал
Ну сделайте голосовалку не вырванную из контекста. Я чем этому мешаю?
P>итого, мою точку зрения поддерживают 32.5% (даже при "плохой" постановке вопроса) P>и?
Привет им. Мног8ие считают, что питон быстрей всех языков в мире. P>смотрим моё утверждение в этом топике:
Ваше утверждение это самый серьезный пруф, который я только видел. P>http://www.rsdn.ru/forum/cpp/4731645.aspx
P>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
P>что вам не ясно-то?
Мне не ясно, почему вы не думаете головой. пытаетесь противоречить фактам.
P>вы хотели подтвердить моё высказывание своим опросом?
Что 2/3 посетителей этого форума с вами совсем не согласны.
1>>Могу лишь понадеется, что в будущем, когда у вас будет больше опыта вы поймете, почему были неправы. P>аналогично
Ну подождем друг друга)))
Здравствуйте, 11molniev, Вы писали:
P>>>>вы понимаете, что абстракции могут иметь разные реализации. и да, некоторые могут быть медленней. P>>>>но, у нас как бы разговор, и есть определённый контекст. P>>>>Конкретно я имею ввиду, что C++ позволяет писать более абстрактный, более безопасный, и более быстрый код — и всё это одновременно.
1>>>Дабы завершить наши препирательства: 1>>>Изначально я и обратил ваше внимание, на то, что С++ не позволяет писать более быстрые приложения, чем С. 1>>>http://www.rsdn.ru/poll/3562.aspx
1>>>К моей радости, большая часть аудитории данного форума это понимают. И я даже не знаю, как объяснить это вам, потому, что это фундаментальное знание — и если вы знаете С++, вы понимаете, почему так.
P>>то что цитата в вопросе вырвана из контекста, я уже писал 1>Ну сделайте голосовалку не вырванную из контекста. Я чем этому мешаю?
а смысл? вот буквально ниже:
P>>итого, мою точку зрения поддерживают 32.5% (даже при "плохой" постановке вопроса) P>>и? 1>Привет им. Мног8ие считают, что питон быстрей всех языков в мире.
вы приравниваете людей разделяющих мою точку зрения к баранами
P>>смотрим моё утверждение в этом топике: 1>Ваше утверждение это самый серьезный пруф, который я только видел.
P>>Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
P>>что вам не ясно-то? 1>Мне не ясно, почему вы не думаете головой. пытаетесь противоречить фактам.
каким фактам?
Ну так там где в C возможно compile-time, оно возможно и в C++, причём в C++ — оно достигается намного легче/лучше/красивее
Вы с этим согласны/не согласны?
P>>вы хотели подтвердить моё высказывание своим опросом? 1>Что 2/3 посетителей этого форума с вами совсем не согласны.
ну и?:
Это распространённое заблуждение, что код на C более быстр и менее требователен. Если важна эффективность, C++ легко позволяет писать более оптимальные программы чем C.
Здравствуйте, Piko, Вы писали:
P>Как я писал ранее — отсутствие компилятора действительно может затруднять использование С++, но как я уже писал есть компиляторы транслирующие код C++ в код C.
Это совсем не понятно. Такая сложная схема компиляции наверняка будет иметь накладные расходы всякие, надо бы понимать ради чего? Чем подмножество С++ так уж лучше С + анализатор кода?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
P>>Как я писал ранее — отсутствие компилятора действительно может затруднять использование С++, но как я уже писал есть компиляторы транслирующие код C++ в код C.
E>Это совсем не понятно. Такая сложная схема компиляции наверняка будет иметь накладные расходы всякие, надо бы понимать ради чего?
про какие именно накладные расходы вы говорите?
1. отсутствие оптимизации в некоторых местах, из-за того что теряется исходная C++ семантика?
2. накладные расходы во время разработки?
и да, я согласен использование таких схем трансляции может быть головной болью. в таких случаях лучше использовать те языки, для которых есть компилятор.
E>Чем подмножество С++ так уж лучше С + анализатор кода?
1. надёжность
2. безопасность
3. абстракции (зачастую абсолютно ничего не стоящие)
4. скорость программ
5. причём всё это, порождает меньше исходного кода чем C
Здравствуйте, Piko, Вы писали:
P>>>в. выедают stack V>>Это не обязательно проблема — например, если такой массив используется в многократно вызываемой фунцкции. Стек все равно освобождается в ее конце.
Даже если она inline?..
В С99 есть такие гарантии?
P>естественно, что полностью не уберёт, так как в С++ есть перегрузка функций(для каждой должно быть своё имя) и т.п.
В С++ extern "C" функции нельзя перегружать..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
P>>естественно, что полностью не уберёт, так как в С++ есть перегрузка функций(для каждой должно быть своё имя) и т.п. E>В С++ extern "C" функции нельзя перегружать..
я знаю
естественно, что полностью не уберёт, так как в С++ есть перегрузка функций(для каждой должно быть своё имя) и т.п. но ничто не мешает для С++ библиотеки, делать полностью clean-C интерфейс
Здравствуйте, Vamp, Вы писали:
V>Исключения делаются на setjmp. Автоматическое управление ресурсами — не знаю как. Впрочем, мне неизвестны языки с автоматическим управлением ресурсами, кроме С++.
В чём проблемы? Делаешь статического владельца ресурсами, при аллокации их там регишь, при деаллокации -- разрегистрируешь. Хранилище умеет делать с себя слепок и локальное на нить.
При входе в функцию -- делаешь слепок, при выходе -- откатываешься к нему.
Если не откатишься в этой, то откатишься в предыдущей...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
V>>Исключения делаются на setjmp. Автоматическое управление ресурсами — не знаю как. Впрочем, мне неизвестны языки с автоматическим управлением ресурсами, кроме С++. E>В чём проблемы? Делаешь статического владельца ресурсами, при аллокации их там регишь, при деаллокации -- разрегистрируешь. Хранилище умеет делать с себя слепок и локальное на нить. E>При входе в функцию -- делаешь слепок, при выходе -- откатываешься к нему. E>Если не откатишься в этой, то откатишься в предыдущей...
Здравствуйте, Piko, Вы писали:
P>про какие именно накладные расходы вы говорите?
Ну, например, номер строчки в которой из двух версий исходника будет показывать макрос assert?
P>и да, я согласен использование таких схем трансляции может быть головной болью. в таких случаях лучше использовать те языки, для которых есть компилятор.
О том и речь...
E>>Чем подмножество С++ так уж лучше С + анализатор кода?
P>1. надёжность
Не очевидно.
P>2. безопасность
Это не понятно.
P>3. абстракции (зачастую абсолютно ничего не стоящие)
IMHO, это одинаково хорошо на любом языке. На С++ даже хуже, если твои абстракции не совместимы с моделью С++...
P>4. скорость программ
Это не понятно. По идее Вылизанная С-программа и вылизанная С++ программа должны быть одинаково быстры.
Тут скорее вопрос в цене этой скорости/вылизанности.
P>5. причём всё это, порождает меньше исходного кода чем C
Тоже ценность мутная.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Это хорошо, но тут публичный форум. Ты знаешь, а кто-то может быть введён в заблуждение неудачной формулировкой...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
P>>про какие именно накладные расходы вы говорите? E>Ну, например, номер строчки в которой из двух версий исходника будет показывать макрос assert?
смотря где препроцессор отработает..
P>>и да, я согласен использование таких схем трансляции может быть головной болью. в таких случаях лучше использовать те языки, для которых есть компилятор. E>О том и речь...
E>>>Чем подмножество С++ так уж лучше С + анализатор кода?
P>>1. надёжность E>Не очевидно.
меньше скрытых багов выявленных системой типов во время компиляции, отсутствие возможности сделать целые классы ошибок в принципе и т.п.
P>>2. безопасность E>Это не понятно.
да хотя бы сколько было уязвимостей из-за sprintf
P>>3. абстракции (зачастую абсолютно ничего не стоящие) E>IMHO, это одинаково хорошо на любом языке. На С++ даже хуже, если твои абстракции не совместимы с моделью С++...
на любом языке
да на том же C — в qsort: абстрагировались от типа данных и функции сравнения — и что получили?
P>>4. скорость программ E>Это не понятно. По идее Вылизанная С-программа и вылизанная С++ программа должны быть одинаково быстры. E>Тут скорее вопрос в цене этой скорости/вылизанности.
разумеется в цене. если цена это на порядок, а то и на несколько больший объём кода, то зачастую она не платится
опять: std::sort vs qsort
P>>5. причём всё это, порождает меньше исходного кода чем C E>Тоже ценность мутная.
P>смотря где препроцессор отработает..
А есть варианты
Как, по твоему, С будет транслировать С++ хедеры?..
P>>>1. надёжность E>>Не очевидно.
P>меньше скрытых багов выявленных системой типов во время компиляции, отсутствие возможности сделать целые классы ошибок в принципе и т.п.
Ну так это, С + анализатор же рассматривается?..
P>>>2. безопасность E>>Это не понятно.
P>да хотя бы сколько было уязвимостей из-за sprintf
Просто системного С++ кода мало, вот и уязвимостей мало
Опять же, анализаторы кода простые косяки, вроде ловят...
P>на любом языке P>да на том же C — в qsort: абстрагировались от типа данных и функции сравнения — и что получили?
ну просела немного производительность...
Было бы критично -- написали бы макрос...
P>разумеется в цене. если цена это на порядок, а то и на несколько больший объём кода, то зачастую она не платится
Значит скорость в этом месте не так уж и нужна...
Узких мест обычно мало...
P>опять: std::sort vs qsort
Да пофигу. Это редко влияет на скорость реальных программ...
А если уж в твоей проге критична какая-то сортировка, то всё равно скорее всего надо алгоритм адаптировать...
P>>>5. причём всё это, порождает меньше исходного кода чем C E>>Тоже ценность мутная.
P>опять: std::sort vs qsort, самый простой пример.
Он слишком синтетический... Кроме того, чисто IMHO, шаблоны и STL в обсуждаемое подмножество С++ не входят
Я, кстати, тоже сторонник "подмножества С++", а не голого С, но аргументы слабые какие-то...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Я так и не понял, какой неявный способ тут считают приемлемым...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
