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

S>>Покажите, пожалуйста, пример реальной проблемы с enable_if, с которой может столкнуться обычный разработчик на C++, и способы ее обхода в чистом C.

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

Вы, пожалуй, единственный вменяемый С-шник в этом треде. Но даже вас я вынужден попросить привести реальный пример, из практики. Ибо абстрактные разговоры о том что могут сделать малолетние дебилы не имея ни опыта, ни здравого смысла, могут продолжаться бесконечно долго.

При этом, все, почему-то забывают, что в C++, к сожалению, до сих пор сидит изрядное подмножество языка C. Что оставляет возможность в C++ писать "кратко и по делу в стиле С". Но раз не пишут и уходят в шаблоны, значит это кому-то и зачем-то надо. Значит "кратко и по делу на С" не получается.

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

S>Вы, пожалуй, единственный вменяемый С-шник в этом треде. Но даже вас я вынужден попросить привести реальный пример, из практики. Ибо абстрактные разговоры о том что могут сделать малолетние дебилы не имея ни опыта, ни здравого смысла, могут продолжаться бесконечно долго.

Реального примера под руками нет, поскольку с C++ я пересекаюсь не слишком часто, а специально сидеть придумывать не охота (да и не будет он реальным, придуманный пример).

S>При этом, все, почему-то забывают, что в C++, к сожалению, до сих пор сидит изрядное подмножество языка C. Что оставляет возможность в C++ писать "кратко и по делу в стиле С". Но раз не пишут и уходят в шаблоны, значит это кому-то и зачем-то надо. Значит "кратко и по делу на С" не получается.

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

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

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

Pzz>Я думаю, тут проблема в дизайне языка. Сам по себе язык очень низкоуровневый, но снабжен инстриментом для создания высокоуровневых конструкций.

Так этим он и ценен. Когда не хватает того, что есть в C, можно создать своими руками.

Pzz>На мой взгляд, лучше строки, динамические массивы и т.п. иметь частью языка, а не библиотеки. Тем более, что в реальной жизни таких конструкций надо не слишком много, проще их включить в язык, чем городить необъятною и неимоверно сложную систему для их написания.

Вот по поводу строк все очень не однозначно. Кому-то достаточно std::string. Кому-то хочется, чтобы был типа std::string, но с utf-8 внутри и с возможности итерирования не по байтам, а по символам. Кому-то нужны строки с UCS-4 внутри. Кому-то нужны продвинутые алгоритмы обработки строк. И т.д., и т.п.

В условиях, когда сам язык позволяет его использовать как с отключенной частью важных конструкций (типа RTTI, исключений), так и с оными, создание базового набора инструментов, которые устраивали бы всех, мне видится маловероятным. Тут уж пусть лучше будут библиотеки классов.

То, что в C++ легко уйти куда-то в overuse, это да. Есть такая проблема. Но решить ее можно разве что уходом в языки с более жестким контролем за программистом (типа Go, Rust, Ada, Eiffel и т.д.).

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

Pzz>>Я думаю, тут проблема в дизайне языка. Сам по себе язык очень низкоуровневый, но снабжен инстриментом для создания высокоуровневых конструкций.

S>Так этим он и ценен. Когда не хватает того, что есть в C, можно создать своими руками.

В Си тоже можно создать своими руками. Причем во многих случаях это будет не сложнее, и не менее безопасно, чем в C++.

Идея иметь некий универсальный язык, ПозволяющийСделатьФсё, красиво звучит в теории. Но в реальной жизни люди не делают Фсё, люди решают какие-то свои вполне практические прикладные задачи. И идея переусложнять инструмент ради гипотетической потребности сделать на нем Фсё, мне не близка.

S>Вот по поводу строк все очень не однозначно. Кому-то достаточно std::string. Кому-то хочется, чтобы был типа std::string, но с utf-8 внутри и с возможности итерирования не по байтам, а по символам. Кому-то нужны строки с UCS-4 внутри. Кому-то нужны продвинутые алгоритмы обработки строк. И т.д., и т.п.

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

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

Заметим еще такую тонкую вещь, что если у меня есть, к примеру, два контейнера с совпадающим интерфейсом, то они не взаимозаменяемы, потому что они разные типы. Т.е., если у меня есть сложная прикладная библиотека A, со своим набором низкоуровневых абстракций, и другая сложная прикладная библиотека Б, со своим похожим набором низкоуровневых абстракций, то чтобы применить их в одном проекте, мне надо делать переходники. Которые, по сути, ничего особо полезного делать не будут. А поскольку даже для базовых совершенно вещей народ любит писать свои реализации вместо того, чтобы везде единообразно использовать stl/booost, то в реальной сложной программе эти переходники будут составлять существенную часть. А выбор библиотеки-фреймворка оказывает чрезмерно существенное влияние на архитектуру и дальнейшее развитие программы.

Т.е., жизнь проще не стала, она стала веселей.

S>То, что в C++ легко уйти куда-то в overuse, это да. Есть такая проблема. Но решить ее можно разве что уходом в языки с более жестким контролем за программистом (типа Go, Rust, Ada, Eiffel и т.д.).

Это может быть неплохим вариантом, выбирать язык согласно задаче, вместо того, чтобы использовать язык, позволяющий делать Фсё.

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

Pzz>В Си тоже можно создать своими руками. Причем во многих случаях это будет не сложнее, и не менее безопасно, чем в C++.

Я тут уже устал приводить примеры того, как на C++ делается проще и безопаснее.

Обратного еще не видел. Вообще. Когда появится, тогда можно будет что-то предметно обсуждать.

Pzz>Но в реальной жизни, когда в языке есть встроенные строки, то все немного поджимают свои вычурные хотелки, и оказывается, что встроенные строки всех устраивают.

Если мы продолжаем разговаривать в контексте C vs C++, то чем строки в C лучше оных в C++?

Pzz>Заметим еще такую тонкую вещь, что если у меня есть, к примеру, два контейнера с совпадающим интерфейсом, то они не взаимозаменяемы, потому что они разные типы. Т.е., если у меня есть сложная прикладная библиотека A, со своим набором низкоуровневых абстракций, и другая сложная прикладная библиотека Б, со своим похожим набором низкоуровневых абстракций, то чтобы применить их в одном проекте, мне надо делать переходники. Которые, по сути, ничего особо полезного делать не будут. А поскольку даже для базовых совершенно вещей народ любит писать свои реализации вместо того, чтобы везде единообразно использовать stl/booost, то в реальной сложной программе эти переходники будут составлять существенную часть. А выбор библиотеки-фреймворка оказывает чрезмерно существенное влияние на архитектуру и дальнейшее развитие программы.

Чем это отличается от C, в котором кто-то может использовать контейнеры из APR, а кто-то SGLIB?

Pzz>Это может быть неплохим вариантом, выбирать язык согласно задаче, вместо того, чтобы использовать язык, позволяющий делать Фсё.

Похоже, это уже выход за пределы обсуждения C vs С++.

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

S>Если мы продолжаем разговаривать в контексте C vs C++, то чем строки в C лучше оных в C++?

Ничем. Я хочу сказать:
1) C++ плохо или совсем никак не решает проблем Си
2) C++ сам по себе плохой язык. Основная его проблема — он пытается объять все на свете, он очень сложный, обладает черстовски нетривиальными синтаксисом и семантикой.

В этой связи использование Си там, где "уместен" C++ имеет смысл: Си не так уж чтобы сильно хуже, но он сильно проще, а это важное достоинство.

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

Pzz>Ничем. Я хочу сказать:
Pzz>1) C++ плохо или совсем никак не решает проблем Си

C++ и не собирался решать проблемы Си (для этого изобретали, как минимум, Cyclone и Rust).
Другое дело, что C++ позволяет создать инструменты, которые будут защищать разработчика от граблей Си и стоить это (в run-time) будет совсем не дорого, если вообще будет.

Pzz>2) C++ сам по себе плохой язык. Основная его проблема — он пытается объять все на свете, он очень сложный, обладает черстовски нетривиальными синтаксисом и семантикой.

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

Pzz>В этой связи использование Си там, где "уместен" C++ имеет смысл: Си не так уж чтобы сильно хуже, но он сильно проще, а это важное достоинство.

Пока что я сталкивался с тем, что _везде_ использование C++ было выгоднее использования Си. Но, у меня ограниченный опыт, например, хардкорным эмбеддедом или низкоуровневой системщиной я не занимался. Насколько я знаю, использование C++ там не всегда бывает уместно. Но, опять же, насколько я знаю, это больше связано с тулсетами, нежели с самим языком.

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

S>C++ и не собирался решать проблемы Си (для этого изобретали, как минимум, Cyclone и Rust).
S>Другое дело, что C++ позволяет создать инструменты, которые будут защищать разработчика от граблей Си и стоить это (в run-time) будет совсем не дорого, если вообще будет.

Меня гораздо больше интересуют не run-time а brain-time издержки.

Pzz>>2) C++ сам по себе плохой язык. Основная его проблема — он пытается объять все на свете, он очень сложный, обладает черстовски нетривиальными синтаксисом и семантикой.

S>Это вовсе не означает, что обычный разработчик, который клепает обычный прикладной (или около того) код, будет сталкиваться с какими-то серьезными проблемами.

Будет, конечно. Причем с многими из этих проблем, чтобы столкнуться в Си, надо целую инфраструктуру построить, а в C++ эти проблемы случаются вполне автоматически. Например, неосвобождение памяти при циклическом использовании smart pointer'ов, неожиданные автоматизмы с глобальными спецэффектами, неожиданные тормоза на ровном месте, непонятная многострончая ругань компилятора и т.п.

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

S>Пока что я сталкивался с тем, что _везде_ использование C++ было выгоднее использования Си. Но, у меня ограниченный опыт, например, хардкорным эмбеддедом или низкоуровневой системщиной я не занимался. Насколько я знаю, использование C++ там не всегда бывает уместно. Но, опять же, насколько я знаю, это больше связано с тулсетами, нежели с самим языком.

Личный опыт трудно сравнивать...

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

Pzz>Меня гораздо больше интересуют не run-time а brain-time издержки.

Ну вот как по мне, так самодельные smart-pointer-ы или lock-guard-ы высвобождают гораздо больше brain-time, чем следование методологии goto cleanup в чистом C. А уж использование готовых подобных вещей освобождает голову разработчика от необходимости следить за кучей мелочей в коде.

Brain-time издержки в разы увеличиваются, когда человек пытается написать свой собственный хитрый контейнер, да еще сразу и в виде повторно-используемого шаблона. Тогда да. Но в C это вообще из разряда mission impossible.

S>>Это вовсе не означает, что обычный разработчик, который клепает обычный прикладной (или около того) код, будет сталкиваться с какими-то серьезными проблемами.

Pzz>Будет, конечно.

Так я прошу показать эти самые проблемы. Но все что-то никак.

Pzz>Например, неосвобождение памяти при циклическом использовании smart pointer'ов, неожиданные автоматизмы с глобальными спецэффектами, неожиданные тормоза на ровном месте, непонятная многострончая ругань компилятора и т.п.

Отлично. Что на замену этого предлагает C?

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

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

S>>Другое дело, что C++ позволяет создать инструменты, которые будут защищать разработчика от граблей Си и стоить это (в run-time) будет совсем не дорого, если вообще будет.

Pzz>Меня гораздо больше интересуют не run-time а brain-time издержки.

Pzz>>>2) C++ сам по себе плохой язык. Основная его проблема — он пытается объять все на свете, он очень сложный, обладает черстовски нетривиальными синтаксисом и семантикой.

S>>Это вовсе не означает, что обычный разработчик, который клепает обычный прикладной (или около того) код, будет сталкиваться с какими-то серьезными проблемами.

Pzz>Будет, конечно. Причем с многими из этих проблем, чтобы столкнуться в Си, надо целую инфраструктуру построить, а в C++ эти проблемы случаются вполне автоматически. Например, неосвобождение памяти при циклическом использовании smart pointer'ов, неожиданные автоматизмы с глобальными спецэффектами, неожиданные тормоза на ровном месте, непонятная многострончая ругань компилятора и т.п.

со стороны видится, что программисты, плохо знающие С++ пытаются плюсистам объяснить что с++ плохой язык, а те в свою очередь доказать обратное. Не мучайте друг друга, программируйте на том языке, который вы знаете хорошо. любую хорошую идею можно загубить непрофессиональным исполнением. Да, велосипед проще чем автомобиль, но это не повод, чтобы утверждать, что автомобиль -- плохое средство передвижение, т.к. надо изучать правила движения, учиться на курсах и сдавать экзамены. Да, можно не учась сесть за руль, бросить сцепление и сказать -- "смотрите, мотор глохнет!!!" нажать на газ потерять управление и въехать в столб -- "да это же небезопасно!!! на велосипеде такого не будет!".

Пользуйтесь теми инструментами, которыми хорошо владеете и не вводите других в заблуждение. Чтобы программировать на С++ правильно, безопасно и удобно для коллег, надо иметь большой опыт, постоянную практику, перечитать много литературы. это большой труд! причем постоянный! а зачем напрягаться?..

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

S>>Это вовсе не означает, что обычный разработчик, который клепает обычный прикладной (или около того) код, будет сталкиваться с какими-то серьезными проблемами.
Pzz>Будет, конечно. Причем с многими из этих проблем, чтобы столкнуться в Си, надо целую инфраструктуру построить, а в C++ эти проблемы случаются вполне автоматически. Например, неосвобождение памяти при циклическом использовании smart pointer'ов

Ref-counted smart pointer'ы сейчас нужны там где по смыслу самой задачи нужен ref-counting, там где нужна prompt finalization и не известен последний владелец по построению самого кода. Собственно потребность в ref-counting'е возникает даже в управляемых языках не смотря на казалось бы встроенный GC.
То есть если ref-counting будет в C++ — то он же будет и в C, только в рукопашную — с теми же проблемами плюс ещё вагон

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

_>со стороны видится, что программисты, плохо знающие С++ пытаются плюсистам объяснить что с++ плохой язык, а те в свою очередь доказать обратное. Не мучайте друг друга, программируйте на том языке, который вы знаете хорошо. любую хорошую идею можно загубить непрофессиональным исполнением. Да, велосипед проще чем автомобиль, но это не повод, чтобы утверждать, что автомобиль -- плохое средство передвижение, т.к. надо изучать правила движения, учиться на курсах и сдавать экзамены. Да, можно не учась сесть за руль, бросить сцепление и сказать -- "смотрите, мотор глохнет!!!" нажать на газ потерять управление и въехать в столб -- "да это же небезопасно!!! на велосипеде такого не будет!".

Сложность управления должна быть соразмерна выигрышу. Если что-то управляется, как самолет, а ездит, как велосипед, зачем оно нужно, такое чудо?

_>Пользуйтесь теми инструментами, которыми хорошо владеете и не вводите других в заблуждение. Чтобы программировать на С++ правильно, безопасно и удобно для коллег, надо иметь большой опыт, постоянную практику, перечитать много литературы. это большой труд! причем постоянный! а зачем напрягаться?..

Ну да, что за ответ без личного наезда...

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

S>Ну вот как по мне, так самодельные smart-pointer-ы или lock-guard-ы высвобождают гораздо больше brain-time, чем следование методологии goto cleanup в чистом C. А уж использование готовых подобных вещей освобождает голову разработчика от необходимости следить за кучей мелочей в коде.

Угу. Я напишу самодельные смарт-пойнтеры. Вася напишет самодельные смарт-пойнтеры. Маша напишет самодельные смарт-пойнтеры. А потом, когда мы попытаемся свинтить все эти вместе, кто-то напишет переходник между васиными смарт-пойнтерами и моими. Кто-то между моими и машиными. А кто-то между машиными и васиными. Ведь если некий метод хочет на входе васин смарт-пойнтер, машин ему прямо так не подсунешь, они разные типы, даже если делают одно и то же. Зато разомнемся и мозги потренеруем, хорошее дело.

S>Brain-time издержки в разы увеличиваются, когда человек пытается написать свой собственный хитрый контейнер, да еще сразу и в виде повторно-используемого шаблона. Тогда да. Но в C это вообще из разряда mission impossible.

Тут возникает вопрос, а так уж ли он человеку нужен, свой собственный хитрый контейнер, да еще и в виде повторно-используемого шаблона?

Pzz>>Например, неосвобождение памяти при циклическом использовании smart pointer'ов, неожиданные автоматизмы с глобальными спецэффектами, неожиданные тормоза на ровном месте, непонятная многострончая ругань компилятора и т.п.

S>Отлично. Что на замену этого предлагает C?

Си предлагает сначала подумать, а нужна ли нам в этом месте вся эта сложность?

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

Pzz>Угу. Я напишу самодельные смарт-пойнтеры. Вася напишет самодельные смарт-пойнтеры. Маша напишет самодельные смарт-пойнтеры. А потом, когда мы попытаемся свинтить все эти вместе, кто-то напишет переходник между васиными смарт-пойнтерами и моими. Кто-то между моими и машиными. А кто-то между машиными и васиными. Ведь если некий метод хочет на входе васин смарт-пойнтер, машин ему прямо так не подсунешь, они разные типы, даже если делают одно и то же. Зато разомнемся и мозги потренеруем, хорошее дело.

Что в этом случае предлагает Си? Вася даст зуб, что он освободит ту память, которую для него выделит Маша?

S>>Brain-time издержки в разы увеличиваются, когда человек пытается написать свой собственный хитрый контейнер, да еще сразу и в виде повторно-используемого шаблона. Тогда да. Но в C это вообще из разряда mission impossible.

Pzz>Тут возникает вопрос, а так уж ли он человеку нужен, свой собственный хитрый контейнер, да еще и в виде повторно-используемого шаблона?

Допустим, ответ на этот вопрос да. И, что сможет предложить человеку в этой ситуации С?

Pzz>>>Например, неосвобождение памяти при циклическом использовании smart pointer'ов, неожиданные автоматизмы с глобальными спецэффектами, неожиданные тормоза на ровном месте, непонятная многострончая ругань компилятора и т.п.

S>>Отлично. Что на замену этого предлагает C?

Pzz>Си предлагает сначала подумать, а нужна ли нам в этом месте вся эта сложность?

Допустим, мы и в C++ подумали и пришли к выводу, что без этого никак. Чем нам поможет C?

PS. Проблема всей этой ветки в том, что C-программисты упорно ни могут привести ни одного примера. Да чтож такое то?

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

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

_>>...это большой труд! причем постоянный! а зачем напрягаться?..

Pzz>Ну да, что за ответ без личного наезда...

ни в коем случае! у нас, как в любом приличном обществе, присутствующие не в счет!

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

S>PS. Проблема всей этой ветки в том, что C-программисты упорно ни могут привести ни одного примера. Да чтож такое то?

Я с нетерпением жду когда же они перейдут к конкретике, но пока Ваши оппоненты успешно увиливают или делают вид, что не понимают Вас)

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

Pzz>>Угу. Я напишу самодельные смарт-пойнтеры. Вася напишет самодельные смарт-пойнтеры. Маша напишет самодельные смарт-пойнтеры. А потом, когда мы попытаемся свинтить все эти вместе, кто-то напишет переходник между васиными смарт-пойнтерами и моими. Кто-то между моими и машиными. А кто-то между машиными и васиными. Ведь если некий метод хочет на входе васин смарт-пойнтер, машин ему прямо так не подсунешь, они разные типы, даже если делают одно и то же. Зато разомнемся и мозги потренеруем, хорошее дело.

S>Что в этом случае предлагает Си? Вася даст зуб, что он освободит ту память, которую для него выделит Маша?

Сделайте, как в apache: привяжите выделение памяти к контексту запроса. Отработали запрос — вся память махом и освободится. Все централизованно, ошибиться довольно сложно. И это лучше/проще/быстрее/эффективнее, чем smart pointer'ы, которые, кроме всего прочего, на каждый пук теребят память и процессорный кэш, даже если требуется read-only доступ.

Можете сделать это даже на C++, если вам мил синтаксис с большим количеством угловых скобок. Суть от этого не изменится.

Pzz>>Тут возникает вопрос, а так уж ли он человеку нужен, свой собственный хитрый контейнер, да еще и в виде повторно-используемого шаблона?

S>Допустим, ответ на этот вопрос да. И, что сможет предложить человеку в этой ситуации С?

Зачем он вам сдался, этот хитрый контейнер?

Если вам хочется хитрого интерфейса, в Си эта проблема во многом отсутствует, в Си интерфейсы простые. Если же вам нужен контейнер с хитрым поведением и/или с хитрым внутренним устройством, вам в любом случае самому его писать, независимо от языка.

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

S>>Что в этом случае предлагает Си? Вася даст зуб, что он освободит ту память, которую для него выделит Маша?

Pzz>Сделайте, как в apache: привяжите выделение памяти к контексту запроса. Отработали запрос — вся память махом и освободится. Все централизованно, ошибиться довольно сложно. И это лучше/проще/быстрее/эффективнее, чем smart pointer'ы, которые, кроме всего прочего, на каждый пук теребят память и процессорный кэш, даже если требуется read-only доступ.

Pzz>Можете сделать это даже на C++, если вам мил синтаксис с большим количеством угловых скобок. Суть от этого не изменится.

Прекрасно. В C++ для этих целей даже placement new есть из покон веков. Более того, за счет RAII мы можем получить еще и автоматическое освобождение всего пула, когда он перестает быть нужен. Т.е. здесь мы уже имеем выигрыш от использования C++.

А теперь представим, что пулы и арены в нашей предметной области не шибко применимы и нам таки нужны объекты со своими деструкторами, которые нужно таки вызвать. Например, это какое-то содержимое окошка с rich-text-ом или векторным-изображением и нам нужно чистить за собой GUI-объекты (шрифты, кисти, карандаши и т.д.). В C++ мы все это имеем из коробки в виде деструкторов. Что в C?

Pzz>Зачем он вам сдался, этот хитрый контейнер?

Ну вот Boost.MultiIndex отличный пример такого контейнера. Или я захочу сделать реализацию std::map-а на базе BTree, а не на базе rb-tree.

Pzz>Если вам хочется хитрого интерфейса, в Си эта проблема во многом отсутствует, в Си интерфейсы простые. Если же вам нужен контейнер с хитрым поведением и/или с хитрым внутренним устройством, вам в любом случае самому его писать, независимо от языка.

Да, но в C++ я напишу его один раз под целое семейство типов. А в Си это будет либо трах с макросами, либо копипаста. И то, и другое сложно назвать более лучшим вариантом.

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

S>>Что в этом случае предлагает Си? Вася даст зуб, что он освободит ту память, которую для него выделит Маша?
Pzz>Сделайте, как в apache: привяжите выделение памяти к контексту запроса. Отработали запрос — вся память махом и освободится. Все централизованно, ошибиться довольно сложно.

Так регионы/арены и на C++ используются, там где применимы

Pzz>И это лучше/проще/быстрее/эффективнее, чем smart pointer'ы, которые, кроме всего прочего, на каждый пук теребят память и процессорный кэш, даже если требуется read-only доступ.

Какой кэш? Если ты всё про тот же подсчёт ссылок — то повторюсь, там где он нужен на C++, он нужен и на C.

Какой read-only доступ? Если ты про non-owning raw pointers — то они и на C++ используются, и не являются никаким "антипаттерном" вопреки всяким фантазиям.

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

V>>С на месте тоже не стоит и тоже позволяет делать то, что С++ делал всегда (см. диалекты).
S>П — переносимость. О — отсутствие.
И?

V>>Да, да, мало кому нужен. Именно поэтому он на первых местах во всяких рейтингах
S>Ссылка на TIOBE, как на авторитет. Показательно.
Приведи свой авторитетный, мы тоже поржём. Хотя, забавно, мне тут самому тиобе тыкали, а теперь в обратку пошли. Показательно.

V>>Меня эти другие окружают, а я не должен значит? Или, не нравиться, чемодан-вокзал-другой язык?
S>К — конструктивность.
О — отсутствие аргументов

V>>Вот вам статья почему C предпочтительнее С++, из которой можно почерпнуть ответ сразу на несколько ваших вопросов: http://eax.me/c-vs-cpp/
S>Александр Алексеев теперь числится в экспертах по C и C++. Прикольно. Его профессиональный стаж в качестве С-разработчика измеряется годом, ну или двумя. А образчик его C++ кода демонстрирует недюжинную усидчивость и терпение автора, что дано далеко не всем. Кому не дано, тому проще воспользоваться C++.
Так все сишники пишут, тоже мне открытие

S>Так что не того авторитета вы привели, ох не того. Особенно после эпичного фейла с попыткой обосрать Rust.
Предпочитаете переходить на личности автора? В его статье было масса правильных мыслей, к примеру, про pimpl и разбухание реализации класса на ровном месте.
ЗЫЖ постоянно убеждаюсь, что LOR — один большой высер анонимуса, читать такое — себя не уважать

S>Надо было сразу с козырей заходить, с Линуса, вашего, Торвальдса.
Идолам не поклоняюсь

S>Ну и поскольку вы упорно не можете разродиться примером, то придется что-нибудь из своего опыта показывать. Вот это, например. Сорри, enable_if там нет. Если еще чего вспомню, кину ссылочку.
Видел я этот пример, и да

template< typename P >

ни разу не копипаста и в глазах не рябит

S>И да, без ответного примера можете ответ не писать. Пожалейте и мое и свое время, перестаньте демонстрировать свои жалкие потуги на убогий троллинг.so
Здесь тебе не ЛОР, с хамством завязывай