Re[14]: Пределы C++ - C/C++

2.
а)Web. Но это на мой взгляд и то с большими оговорками. Сделать можно всё... только вопрос времени. Нормальный веб сайт на С++ писать долговато.. Потом найти хостинг :-D нормальный.
б) script — скриптовые языки нужны. Как ни крути. С++ не скриптовый язык. Тоесть будь у него хоть куча библиотек и интеграция в броузеры — популярности JavaScript думаю врят ли добьётся

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

J>2. Неудобный неоднозначный синтаксис, из-за которого практически невозможно написать инструменты типа resharper (одни заголовочные файлы чего стоят). Лучшее, что я видел в этом направлении — это XRefactory: тормозилово смертельное для мало-мальски большого проекта, работать практически невозможно.
А VisualAssist?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

J>>2. Неудобный неоднозначный синтаксис, из-за которого практически невозможно написать инструменты типа resharper (одни заголовочные файлы чего стоят). Лучшее, что я видел в этом направлении — это XRefactory: тормозилово смертельное для мало-мальски большого проекта, работать практически невозможно.
CC>А VisualAssist?

Насколько я помню, у него были проблемы с CRTP и operator->.
Ну и макросы он, вроде, дебажить никак не помогал.

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

CC>>А VisualAssist?

J>Насколько я помню, у него были проблемы с CRTP и operator->.
Вроде как с последними версиями не наблюдалось.

J>Ну и макросы он, вроде, дебажить никак не помогал.
И не должен был — это тул не для дебага.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Понимаешь язык должен иметь некоторую степень свободы, чтобы добавление новых фич не вызывало его черезмерное усложнение. Компилируемые языки уже можно сказать исчерпали свою свободу, остались только интерпретируемые юзать + декларотивное программирование.
Хочешь нехочешь, а какой-нить интерпретируемый придётся изучать. Конечено C++ при этом не вытеснится, но ему будет тесно.

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

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

CC>>>А VisualAssist?

J>>Насколько я помню, у него были проблемы с CRTP и operator->.
CC>Вроде как с последними версиями не наблюдалось.

Это хорошо

J>>Ну и макросы он, вроде, дебажить никак не помогал.
CC>И не должен был — это тул не для дебага.
Я имею в виду, если его спросить, где используется какой-то член — он заглянет во все макросы?
А если его попросить переименовать что-то?

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

RO>На C++ пишут меньше прикладных программ, чем он того заслуживает, в первую очередь потому, что мало хороших прикладных библиотек. А вот хотелось бы выяснить: если бы на C++ были удобные библиотеки для всего-всего, то все перешли бы (обратно) на C++, или индусы в любом случае будут продолжать писать на Java, Python и т. п., потому что там сложнее обстрелять свои ноги? Для каких задач C++ останется неприменим даже с самыми лучшими библиотеками?

Все нижеизложенное является крайне субъективным имхом, т.к. прошу именно так это и воспринимать.

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

Нарушение этих условий (рост команды, попадание в команду недостаточно подготовленных программистов) будет вести к проблемам, а то и провалу проекта. Поскольку здесь начнут сказываться самые разные факторы, в том числе и особенности самого языка:
— адресная арифметика и отсутствие контроля за выходом за пределы векторов/буферов;
— отсутствие сборки мусора;
— исключениями могут быть любые объекты, а не только наследники std::exception;
— сложный синтаксис и отсутствие из-за этого продвинутых IDE, анализаторов исходных текстов, автоматизированного рефакторинга и пр.

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

Еще одним фактором является наличие у программистов желания программировать на C++. Все-таки инструмент у разработчика должен быть любимым инструментом. Если кому-то не нравится C++, то сложно ожидать от такого программиста хорошо написанного кода. Поскольку часть его мозга во время программирования будет занято проклятиями в адрес C++, его авторов и тех обстоятельств, которые заставляют человека писать на С++, а не на Java/C# или более понтовых Haskel-ей с OCaml-ами.

Но тут есть вопрос: а насколько привлекательным C++ является для начинающих программистов? Ладно те, кто начинал, когда Java еще не было. Им волей-неволей приходилось к C++ привыкать, а там уже для некоторых сработал принцип "стерпится-слюбится". Но вот сейчас сложно найти причины для массового изучения C++ подрастающим поколением. Единичные случаи, к счастью, есть. Но вот не верю я в то, что молодежь откажется от Java с IDEA или от C# с Reshaper-ом. Может еще и есть какое-то знание C++ у студентов наших ВУЗ-ов за счет того, что преподаватели сами не слишком спешно осваивают Java/C# и продолжают читать C/C++ по материалам N-летней давности. Но я сам видел, как толковые студенты самостоятельно изучают Java и C# или ходят на курсы в буржуинские офшорные компании для того, чтобы попасть туда не работу.

А раз так события развиваются, то возникает еще один фактор против C++: ухудшающася ситуация с поиском новых разработчиков, способных продолжать развитие уже начатых C++ проектов.

Так что пределы C++ следует искать в человеческом факторе, а не в предметных областях. Тем более, что у C++ всегда существовали и существуют конкуренты, способные по своим техническим параметрам заменить C++ в той или иной области. Даже там где нужна скорость и доступ к железу C++ может быть заменен C, Pascal-ем или Ada/Modula-2/Eiffel.

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

J>Я навскидку вижу такие больших проблемы, не решаемых библиотеками:
J>1. Отсутствие GC. На С++ крайне сложно писать прототипы и вообще заниматься "быстрой разработкой", просто потому что в С++ ресурсами приходится управлять вручную, в отличие от управляемых языков, в которых все объекты, будучи однажды созданными, живут вечно. В результате приходится продумывать схему владения, и ее не сменишь одним движением мизинца, что важно при быстрой разработке (в управляемых языках такой проблемы вообще не стоит).

Раньше нужно было не забыть delete/free, а теперь нужно знать в деталях как работает GC

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

J>>>Ну и макросы он, вроде, дебажить никак не помогал.
CC>>И не должен был — это тул не для дебага.
J>Я имею в виду, если его спросить, где используется какой-то член — он заглянет во все макросы?
Вроде как да. Я макросами пользуюсь только в исключительных случаях так что попробовать особо не на чем.
Вот те пример (искал m_roundKey).

(31):    #define SERPENT_XOR_KEY(rPos,a,b,c,d) {a ^= m_roundKey[4*rPos];b ^= m_roundKey[4*rPos+1];c ^= m_roundKey[4*rPos+2];d ^= m_roundKey[4*rPos+3];}
(31):    #define SERPENT_XOR_KEY(rPos,a,b,c,d) {a ^= m_roundKey[4*rPos];b ^= m_roundKey[4*rPos+1];c ^= m_roundKey[4*rPos+2];d ^= m_roundKey[4*rPos+3];}
(31):    #define SERPENT_XOR_KEY(rPos,a,b,c,d) {a ^= m_roundKey[4*rPos];b ^= m_roundKey[4*rPos+1];c ^= m_roundKey[4*rPos+2];d ^= m_roundKey[4*rPos+3];}
(31):    #define SERPENT_XOR_KEY(rPos,a,b,c,d) {a ^= m_roundKey[4*rPos];b ^= m_roundKey[4*rPos+1];c ^= m_roundKey[4*rPos+2];d ^= m_roundKey[4*rPos+3];}
SetKey (89):    memcpy (m_roundKey.ptr(),kEx.c_ptr() + 8, 132*sizeof(DWORD));
Init (20):    void Init   ()      {m_roundKey.clear ();}
InitFrom (21):    void InitFrom  (const Serpent &other) {m_roundKey = other.m_roundKey;}
InitFrom (21):    void InitFrom  (const Serpent &other) {m_roundKey = other.m_roundKey;}
Serpent (32):    SecureBuffer<DWORD,132> m_roundKey;

J>А если его попросить переименовать что-то?
Есть такая в нем фича — refactor rename — покури примеры на wholetomato.com, я все равно не опишу так, как на картинке увидишь.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E>или более понтовых Haskel-ей с OCaml-ами.

просто из любопытства: а этим действительно можно понтануться?.
может есть смысл их выучить..

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

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

E>>или более понтовых Haskel-ей с OCaml-ами.

F>просто из любопытства: а этим действительно можно понтануться?.

Легко!

F>может есть смысл их выучить..

То, что нас не убивает, делает нас сильнее

Я уженеоднократно говорил, основной недостаток — что в С++ постоянно пытаются реализовать сферический язык в вакууме.
Потоков и объектов синхронизации нет — не на всех системах есть потоки. ГУЯ нет — не на всех системах есть гуй. Средств для чтения кталогов нет — не на всех системах есть каталоги. Я уже молчу о таком беспределе, как общение с базами данных!..
В результате получается, что писать что-то кроссплатформенное нереально сложно, приходится выдумывать ненужные слои абстракции и обрастать макросами.

Roman Odaisky пишет:

> На C++ пишут меньше прикладных программ, чем он того заслуживает, в
> первую очередь потому, что мало хороших прикладных библиотек. А вот
> хотелось бы выяснить: если бы на C++ были удобные библиотеки для
> всего-всего, то все перешли бы (обратно) на C++, или индусы в любом
> случае будут продолжать писать на Java, Python и т. п., потому что там
> сложнее обстрелять свои ноги?

ДА !! Я бы — ДА !.
Да мы и сейчас в общем пишем много прикладного ПО именно на С++.

Posted via RSDN NNTP Server 2.1 beta

jazzer пишет:

> 1. Отсутствие GC. На С++ крайне сложно писать прототипы и вообще
> заниматься "быстрой разработкой", просто потому что в С++ ресурсами
> приходится управлять вручную, в отличие от управляемых языков, в которых

IMO — ерунда. SmartPointer -и вперед.
AutoPointer — и еще быстрее.
Да и без них для меня лично это никогда проблемой не было.

Циклически замкнутые ссылки IMO редки и
все равно, как правило, требуют внимания при проектировании, даже
в языках с GC.

> 2. Неудобный неоднозначный синтаксис, из-за которого практически
> невозможно написать инструменты типа resharper (одни заголовочные файлы

Да, это — правда.

Posted via RSDN NNTP Server 2.1 beta

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

RO>На C++ пишут меньше прикладных программ

Меньше чем на чем?

RO>что мало хороших прикладных библиотек.

Я думаю что на С++ (и соотв. C) больше хороших прикладных библиотек чем на чем-то ином.

lollipop пишет:

> а)Web. Но это на мой взгляд и то с большими оговорками. Сделать можно
> всё... только вопрос времени. Нормальный веб сайт на С++ писать
> долговато..

Web сайт на C++ писать не нужно. Web сайт вообще писать не нужно.

> б) script — скриптовые языки нужны. Как ни крути. С++ не скриптовый
> язык. Тоесть будь у него хоть куча библиотек и интеграция в броузеры —
> популярности JavaScript думаю врят ли добьётся

А при чем здесь это ? Не, это здесь ни при чем. Ни скриптовые языки, ни
Web-программирование. Ни на фиг не нужно это делать все на С++.

Posted via RSDN NNTP Server 2.1 beta

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

eao197 пишет:
Но вот сейчас сложно найти
> причины для /массового/ изучения C++ подрастающим поколением. Единичные
> случаи, к счастью, есть. Но вот не верю я в то, что молодежь откажется
> от Java с IDEA или от C# с Reshaper-ом.

Такие причины есть. Это — необходимость знания адресной арифметики любым
программистом, даже на Java. Т.е. УЧИТЬ -то С++ (или С) надо. Но это не
заставляет, конечно, на нем потом программировать.

Posted via RSDN NNTP Server 2.1 beta

Кстати, а в чем существенная разница между GC и «умными» указателями?

Можно даже имитировать поведение GC с помощью контейнера экземпляров shared_ptr<void>. Например, это позволит избежать вызова (потенциально тяжелых) деструкторов во время срочных вычислений.

Разве что GC может (иногда) решить проблему циклических ссылок, которые сложно отследить с помощью «умных» указателей. Но можно. Еще в 2003 г. в списке рассылки Boost показался cyclic_ptr, который их-таки отслеживал. Поступал он очень просто: вызывал **this = **this, что приводило к копированию всех подобъектов — в том числе подобъектов типа cyclic_ptr, чьи операторы присваивания делали то же самое для своих объектов и таким образом обнаруживали циклы. Но требование копируемости класса всё портило.

Однако в C++09 есть конструкторы движения! Их просто реализовать почти для всех классов, требование MoveConstructible/MoveAssignable намного менее обременительно, чем CopyConstructible/CopyAssignable. Можно просто подвигать объект туда-сюда, и все содержащиеся в нем ссылки всплывут на поверхность. Кто возьмется переписать cyclic_ptr для C++09? :-)

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

RO>Кстати, а в чем существенная разница между GC и «умными» указателями?

Тем, что все равно придется схему владения продумывать.
Либо писать в патологическом стиле глобальных контейнеров (тогда и shared_ptr не нужен, вообще-то), если все в контейнерах лежит.

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

RO>Кстати, а в чем существенная разница между GC и «умными» указателями?
GC разруливает циклические ссылки. Это его основное и главное преимущество.

RO>Однако в C++09 есть конструкторы движения! Их просто реализовать почти для всех классов, требование MoveConstructible/MoveAssignable намного менее обременительно, чем CopyConstructible/CopyAssignable. Можно просто подвигать объект туда-сюда, и все содержащиеся в нем ссылки всплывут на поверхность. Кто возьмется переписать cyclic_ptr для C++09?

Очень дорогой способ. Проще каким-то явным образом обходить указатели, хотя бы с помощью макросных карт класса.

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

J>Здравствуйте, Roman Odaisky, Вы писали:

RO>>Кстати, а в чем существенная разница между GC и «умными» указателями?

1. дешево аллокировать
2. автоматическая дефрагментация
3. отсутствие *interlocked*
4. циклические ссылки умирают как класс
5. потерять память практически невозможно
6. никаких AV

J>Тем, что все равно придется схему владения продумывать.
J>Либо писать в патологическом стиле глобальных контейнеров (тогда и shared_ptr не нужен, вообще-то), если все в контейнерах лежит.

Здравствуйте, Константин Л., Вы писали:

RO>>>Кстати, а в чем существенная разница между GC и «умными» указателями?

КЛ>1. дешево аллокировать
КЛ>2. автоматическая дефрагментация
Эти два, я так понимаю, связаны? За это приходится платить лишним уровнем косвенности?

КЛ>3. отсутствие *interlocked*
А это как?

КЛ>4. циклические ссылки умирают как класс
КЛ>5. потерять память практически невозможно
А когда возможно — это только из-за багов в конкретной реализации GC или бывают ситуации, с которыми никакая GC не справится?

КЛ>6. никаких AV
...одни GPF :-) Это уже свойство не GC, а языков без адресной арифметики.

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

E>>или более понтовых Haskel-ей с OCaml-ами.

F>просто из любопытства: а этим действительно можно понтануться?.
F>может есть смысл их выучить..

Я бы сказал, есть смысл их изучить обязательно. Но не для того, чтобы понтануться, а хотя бы для того, чтобы понять какие есть альтернативы. ИМХО, ОКамл реальная альтернатива C++.

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

Y>Я бы сказал, есть смысл их изучить обязательно. Но не для того, чтобы понтануться, а хотя бы для того, чтобы понять какие есть альтернативы. ИМХО, ОКамл реальная альтернатива C++.

Для ограниченного количества приложений на ограниченном числе платформ.

J>Я навскидку вижу такие больших проблемы, не решаемых библиотеками:
J>1. Отсутствие GC. На С++ крайне сложно писать прототипы и вообще заниматься "быстрой разработкой", просто потому что в С++ ресурсами приходится управлять вручную, в отличие от управляемых языков, в которых все объекты, будучи однажды созданными, живут вечно. В результате приходится продумывать схему владения, и ее не сменишь одним движением мизинца, что важно при быстрой разработке (в управляемых языках такой проблемы вообще не стоит).
GC позволяет управлять автоматом тока одним ресурсом — памятью. Я уже забыл когда последний раз писал в прикладном С++ коде delete или free — откройте для себя смарт поинтеры.

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

Y>>Я бы сказал, есть смысл их изучить обязательно. Но не для того, чтобы понтануться, а хотя бы для того, чтобы понять какие есть альтернативы. ИМХО, ОКамл реальная альтернатива C++.

E>Для ограниченного количества приложений на ограниченном числе платформ.

Это такая шутка да?

Вот поддерживаемые платформы здесь. А насчет ограниченного количества приложений даже комментировать не буду

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

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

V>ГУЯ нет — не на всех системах есть гуй.
А тут я не очень представляю, как это вообще сделать в виде стандартной библиотеки, учитывая, насколько разный подход принят в разных системах, сравни хотя бы Windows и X Window.　А если еще и классический мак вспомнить... И еще С++/CLI с их дотнетовскиим гуем... (Это же вообще труба — если я не ошибаюсь, ты можешь в С++/CLI в одной и той же программе писать и обычный Win32-гуй, и дотнетовский — как ты себе представляешь все это втиснутым в одну библиотеку?)

V>Средств для чтения кталогов нет — не на всех системах есть каталоги. Я уже молчу о таком беспределе, как общение с базами данных!..
Ага, давай попробуем скрестить реляционные базы данных с объектно-ориентированными (причем с конкретной, ты понимаешь, о чем я

).

V>В результате получается, что писать что-то кроссплатформенное нереально сложно, приходится выдумывать ненужные слои абстракции и обрастать макросами.

В любом случае, каталоги, базы данных и гуй — это в рамках заявленной Романом концепции "если бы на C++ были удобные библиотеки для всего-всего".
Ты же, надеюсь, не ратуешь, чтобы гуй и прочая были в языке?
А Роман ставит вопрос именно о пределах самого языка.

J>В новом стандарте есть.
Сколько я уже слышал про новый стандарт...

J>А тут я не очень представляю, как это вообще сделать в виде стандартной библиотеки, учитывая, насколько разный подход принят в разных системах, сравни хотя бы Windows и X Window.
Ну, посмотри на Джаву — есть гуй, работает везде одинаково. То, что подсистемы разные, вроде как не должно меня тревожить...

J>Ага, давай попробуем скрестить реляционные базы данных с объектно-ориентированными (причем с конкретной, ты понимаешь, о чем я

).
Понимаю

Но прикрутить встроенные в язык средства для доступка к реляционным базам данным через стандартный драйвер — как в Перле — тоже можно было бы...

J>Ты же, надеюсь, не ратуешь, чтобы гуй и прочая были в языке?
Я не вижу принципиальной разницы между "в языке" и "в библиотеке" с этой точки зрения. printf тоже в библиотеке. Главное, чтобы входило в стандартную поставку

.
Но если все-таки сосредоточится на обственно языке — ты правильно сказал. Просто чудовищный синтаксис, который невозможно парсить

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

RO>Здравствуйте, Константин Л., Вы писали:

RO>>>>Кстати, а в чем существенная разница между GC и «умными» указателями?

КЛ>>1. дешево аллокировать
КЛ>>2. автоматическая дефрагментация
RO>Эти два, я так понимаю, связаны? За это приходится платить лишним уровнем косвенности?

каким уровнем косвенности? ты знаешь чем приходится платить, используя обычный malloc из многопоточной CRT? про dmalloc etc не каждый знает

КЛ>>3. отсутствие *interlocked*
RO>А это как?

а так, что interlockedincrement/decrement не нужен как класс. а сколько они стоят для smp?

КЛ>>4. циклические ссылки умирают как класс
КЛ>>5. потерять память практически невозможно
RO>А когда возможно — это только из-за багов в конкретной реализации GC или бывают ситуации, с которыми никакая GC не справится?

бывают, что не справится. см. trashing например

КЛ>>6. никаких AV
RO>...одни GPF

Это уже свойство не GC, а языков без адресной арифметики.

при чем здесь gpf?

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

J>>В новом стандарте есть.
V>Сколько я уже слышал про новый стандарт...

А чего про него слышать — скачай до почитай

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

J>>А тут я не очень представляю, как это вообще сделать в виде стандартной библиотеки, учитывая, насколько разный подход принят в разных системах, сравни хотя бы Windows и X Window.
V>Ну, посмотри на Джаву — есть гуй, работает везде одинаково. То, что подсистемы разные, вроде как не должно меня тревожить...
Ну так и в плюсах Qt.

J>>Ага, давай попробуем скрестить реляционные базы данных с объектно-ориентированными (причем с конкретной, ты понимаешь, о чем я

).
V>Понимаю

Но прикрутить встроенные в язык средства для доступка к реляционным базам данным через стандартный драйвер — как в Перле — тоже можно было бы...
Равно как и к ОО, и к прочим

Опять же, библиотеки такие уже есть, кроссплатформенные.
Возможно, и Qt умеет — не помню.

J>>Ты же, надеюсь, не ратуешь, чтобы гуй и прочая были в языке?
V>Я не вижу принципиальной разницы между "в языке" и "в библиотеке" с этой точки зрения.
Принципиальная разница между языком и библиотекой в том, что язык практически неизменяем, а библиотеку взял и выбросил и начал пользоваться другой.

V>printf тоже в библиотеке. Главное, чтобы входило в стандартную поставку

.
V>Но если все-таки сосредоточится на обственно языке — ты правильно сказал. Просто чудовищный синтаксис, который невозможно парсить

.
И неочевидная семантика, и препроцессор.

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

J>Я навскидку вижу такие больших проблемы, не решаемых библиотеками:
J>1. Отсутствие GC. На С++ крайне сложно писать прототипы и вообще заниматься "быстрой разработкой", просто потому что в С++ ресурсами приходится управлять вручную, в отличие от управляемых языков,
Я что-то пропустил, видимо, но с каких это пор ЭТО стало проблемой?

Здравствуйте, Константин Л., Вы писали:

КЛ>>>3. отсутствие *interlocked*
RO>>А это как?

КЛ>а так, что interlockedincrement/decrement не нужен как класс. а сколько они стоят для smp?

А как делать блокировку managed heap при new из разных потоков?

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

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

J>>>>Ну и макросы он, вроде, дебажить никак не помогал.
CC>>>И не должен был — это тул не для дебага.
J>>Я имею в виду, если его спросить, где используется какой-то член — он заглянет во все макросы?
CC>Вроде как да. Я макросами пользуюсь только в исключительных случаях так что попробовать особо не на чем.
CC>Вот те пример (искал m_roundKey).ладно, не удалось объяснить.
Я имею в виду случаи типа

struct tm* ptm;
#define MACRO(xx) xx->// вот тут xref, исходя из того, как макрос используется, выдаст список членов ptm
    MACRO(ptm)

только что проверил — расширяет даже в таком слегка патологическом случае:

#define MACRO(xx,yy) xx##yy->
    MACRO(pt,m)

причем, если попробуешь переименовать pt или m, предложит переименовать и ptm заодно.

а здесь, если попробуешь переименовать х, он предложит переименовать х и там, где этот макрос зовется, чтоб все продолжало компилироваться (и проверит на конфликты, естественно):

#define PRINTX() printf("x == %d\n", x);
    {
        int x = 0; // вот этот х тоже
        PRINTX(); 
    }

J>>А если его попросить переименовать что-то?
CC>Есть такая в нем фича — refactor rename — покури примеры на wholetomato.com, я все равно не опишу так, как на картинке увидишь.
Видимо, не туда посмотрел — ничего впечатляющего по сравнению с xref.
Дашь ссылку?

а auto-complete для такой страшной штуки предложит?

(*(5+(struct tm **)0x13e5f)[0]). // должны появиться члены tm

А вот так он умеет (шаблоны + операторы)?

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

RO>>Для каких задач C++ останется неприменим даже с самыми лучшими библиотеками?

J>Я навскидку вижу такие больших проблемы, не решаемых библиотеками:
J>1. Отсутствие GC. На С++ крайне сложно писать прототипы и вообще заниматься "быстрой разработкой", просто потому что в С++ ресурсами приходится управлять вручную, в отличие от управляемых языков, в которых все объекты, будучи однажды созданными, живут вечно. В результате приходится продумывать схему владения, и ее не сменишь одним движением мизинца, что важно при быстрой разработке (в управляемых языках такой проблемы вообще не стоит).

Отвечаю всем, кто хотел меня научить умным указателям: я не говорю про ГЦ вообще, а отвечаю на заданный Романом вопрос (выделено).
Так вот задачу, которую я имел в виду, я в своем ответе тоже выделю, потому что мне показалось, что это в моем ответе было не замечено.
Чтоб никому не казалось, что я считаю ГЦ фичей, без которой жить в плюсах нельзя, и не умею пользоваться умными указателями.

Скрипты, кстати, рулят в том числе и по этой причине — там ни о чем не надо думать, все живет вечно.

Здравствуйте, Аноним, Вы писали:

А>... откройте для себя смарт поинтеры.

Вы бы в профиль посмотрели, может и открыли бы для себя что-нибудь.

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

J>>В новом стандарте есть.
V>Сколько я уже слышал про новый стандарт...

J>>А тут я не очень представляю, как это вообще сделать в виде стандартной библиотеки, учитывая, насколько разный подход принят в разных системах, сравни хотя бы Windows и X Window.
V>Ну, посмотри на Джаву — есть гуй, работает везде одинаково. То, что подсистемы разные, вроде как не должно меня тревожить...

J>>Ага, давай попробуем скрестить реляционные базы данных с объектно-ориентированными (причем с конкретной, ты понимаешь, о чем я

).
V>Понимаю

Но прикрутить встроенные в язык средства для доступка к реляционным базам данным через стандартный драйвер — как в Перле — тоже можно было бы...

J>>Ты же, надеюсь, не ратуешь, чтобы гуй и прочая были в языке?
V>Я не вижу принципиальной разницы между "в языке" и "в библиотеке" с этой точки зрения. printf тоже в библиотеке. Главное, чтобы входило в стандартную поставку

.

Не надо смешивать мух и котлеты. Есть языки интерпретируемые( это как раз что ты назвал Java, Perl, Python ) а есть компилируемые,
а теперь нука назови компилируемый язык у которого есть кроссплатформенные либы для GUI для DB не говоря уже о драйверах;

С++ в этом отношении самый продвинутый, и если синтаксис тебе кажется чудовищным так это чисто твое личное мнение, и надо преподносить это как факт.
В общем RTFM или в матчасть.

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

E>>>или более понтовых Haskel-ей с OCaml-ами.
F>>просто из любопытства: а этим действительно можно понтануться?.
F>>может есть смысл их выучить..

Y>Я бы сказал, есть смысл их изучить обязательно. Но не для того, чтобы понтануться, а хотя бы для того, чтобы понять какие есть альтернативы.

не, ну без понтов нельзя.. как же самооценку повышать?!.

Y>ИМХО, ОКамл реальная альтернатива C++.

только синтаксис имхо плохо читаемый.. визуально эдакая смесь VB и boost-а.. +)

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

J>Я имею в виду случаи типа
хз. не пробовал. У меня подобного кода не встречается.

J>а auto-complete для такой страшной штуки предложит?
J>

J>(*(5+(struct tm **)0x13e5f)[0]). // должны появиться члены tm
J>

За такой код и по рукам не мешало бы

Надо пробовать — такую кашу не писал — не скажу.

J>А вот так он умеет (шаблоны + операторы)?
судя по картинке он те все равно не покатит — он MSVS only

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Вы не перепутали библиотеки с языком ?

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

J>1. Отсутствие GC. На С++ крайне сложно писать прототипы и вообще заниматься "быстрой разработкой", просто потому что в С++ ресурсами приходится управлять вручную, в отличие от управляемых языков

GC управляет только одним ресурсом — памятью, а поскольку в любой реальной программе используется куча других ресурсов, по прежнему неправляемых — файлы, хендлы, таймеры, GDI и т.д., какого-то уж совсем решающего преимущества GC не дает

, все равно время жизни большинства объектов приходится контролировать вручную

... << RSDN@Home 1.2.0 alpha 4 rev. 1090>>

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

E>>Для ограниченного количества приложений на ограниченном числе платформ.

Y>Это такая шутка да?

Не угадали. Суровая реальность.

Y>Вот поддерживаемые платформы здесь.

Ну так сами бы посмотрели. Например, на скольких платформах работает NetBSD и GCC под ним? И сколько их этих платформ нормально поддерживаются разработчиками OCaml-а?

Где, например, AIX, OpenSolaris, NonStop Kernel?

Y>А насчет ограниченного количества приложений даже комментировать не буду

Это разумно.

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

RO>>что мало хороших прикладных библиотек.

CS>Я думаю что на С++ (и соотв. C) больше хороших прикладных библиотек чем на чем-то ином.

А что вообще понимается под прикладными библиотеками?

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

RO>...

помимо некоторых недостатков высокоуровневых конструкций (как то: делегатов, рефлекшна и иже с ними) есть недостатки "нижнего" уровня.
Вот мне было крайне любопытно узнать о попытках переписывания ядра Линукса на С++:

"In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me — writing kernel code in C++ is a BLOODY STUPID IDEA.

"The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."

Еще есть такое обсуждение здесь.

Получается для высокоуровневых вещей С++ несколько проигрывает по сравнению с Java/C#/Lisp/..., а для низкоуровневых совершенно бесполезен.
Вот вам lower/upper bounds.

Видимо все дело в его исключительной сложности и громоздкости, чересчур высокой чтобы допустить написание компилятора хотя бы полностью удовлетворяющего нынешнему стандарту ISO. Достаточно почитать отзывы создателей comeau C++. То же можно сказать об инструментах рефакторинга кода. Все дело как раз таки в том, что "пределов" очень много и куча хороших и в общем-то здравых идей превратила язык в безобразный винегрет из "соленых огурцов" и "молока".
Сам факт наличия большого числа проблем наглядно проиллюстрирован на наших же cpp/cpp.applied форумах

RO>На C++ пишут меньше прикладных программ, чем он того заслуживает, в первую очередь потому, что мало хороших прикладных библиотек. А вот хотелось бы

чем QT не "хорошая прикладная библиотека" ?

I>Вы бы в профиль посмотрели, может и открыли бы для себя что-нибудь.
Знаете еслиб я зарегался, возможно и вы бы открыли для себя чтото в моем профиле

Но я на профили не смотрю, а только на сообщения. Потому и аноним.

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

SI>Вот мне было крайне любопытно узнать о попытках переписывания ядра Линукса на С++:

SI>

SI> "In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me — writing kernel code in C++ is a BLOODY STUPID IDEA.

SI> "The fact is, C++ compilers are not trustworthy. They were even worse in
SI> 1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."

SI>Еще есть такое обсуждение здесь.

SI>Получается для высокоуровневых вещей С++ несколько проигрывает по сравнению с Java/C#/Lisp/..., а для низкоуровневых совершенно бесполезен.

Слова Линуса здесь не являются доказательством невозможностии использования C++ для разработки ядра ОС. Поскольку в распоряжении разработчиков ядра Linux-а огромное количество временных и людских ресурсов. Если бы на подобный объект были наложены жесткие рамки коммерческого проекта, то еще вопрос, удалось ли бы на C написать лучше, чем на C++.

StevenIvanov пишет:
> помимо некоторых недостатков высокоуровневых конструкций (как то:
> делегатов, рефлекшна и иже с ними) есть недостатки "нижнего" уровня.
> Вот мне было крайне любопытно узнать о попытках переписывания ядра
> Линукса на С++:
>
> "In fact, in Linux we did try C++ once already, back in 1992. It
> sucks. Trust me — writing kernel code in C++ is a BLOODY STUPID IDEA.
>
> "The fact is, C++ compilers are not trustworthy. They were even worse in
> 1992, but some fundamental facts haven't changed: 1) the whole C++
> exception handling thing is fundamentally broken. It's _especially_
> broken for kernels. 2) any compiler or language that likes to hide
> things like memory allocations behind your back just isn't a good
> choice for a kernel. 3) you can write object-oriented code (useful
> for filesystems etc) in C, _without_ the crap that is C++."
>

А как он микроядерные операционки ругал — это вообще пестня

А вообще
в BeOS вроде как ядро было на плюсах написано.

Posted via RSDN NNTP Server 2.1 beta

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

E>...

сложно сказать. Во-первых ясно, что С++ можно в принципе использовать для чего угодно, это универсальный язык.
Вот только для вещей, критичных к памяти и быстродействию (взять то же самое ядро ОС) многие его преимущества сводятся на нет. Поддержка исключений и rtti однозначно будут выключены. Шаблоны из-за их сложности в написании и отладки так же вряд ли будут использованы "во всю ширь". Следует учесть еще и ряд общих ограничений (не относящихся, впрочем, к С++) — ограничения на размер стека и использование арифметики с плавающей точкой в коде ядра. Т.е. получается стандартными библиотеками мы вряд ли сможем воспользоваться.
Что же остается?
Строгий контроль типов? Абстракция выделения памяти new/delete? Стоит заметить, что механизмы распределения памяти в ядре иногда бывают более сложны нежели чем malloc/free.
ООП? По большему счету без особых проблем эмулируется С (во всяком случае в мере, нужной для ядра).
Пространства имен? Перегрузка функций? Согласен, но не могу сказать, что это сделает программирование намного легче в условиях жестких временных рамок

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

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

CS>Здравствуйте, Константин Л., Вы писали:

КЛ>>>>3. отсутствие *interlocked*
RO>>>А это как?

КЛ>>а так, что interlockedincrement/decrement не нужен как класс. а сколько они стоят для smp?

CS>А как делать блокировку managed heap при new из разных потоков?

Это максимум один exchange/increment на выделение.

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

SI>Вот только для вещей, критичных к памяти и быстродействию (взять то же самое ядро ОС) многие его преимущества сводятся на нет. Поддержка исключений и rtti однозначно будут выключены.

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

SI>Шаблоны из-за их сложности в написании и отладки так же вряд ли будут использованы "во всю ширь".

А вот здесь уже перебор. Шаблоны -- это одна из самых больших вкусностей языка. Тем более, с нулевыми накладными расходами в run-time. Так что для подобных задач шаблоны очень хороши. Что и доказывается на практике: Abstraction and the C++ machine model.

SI>Следует учесть еще и ряд общих ограничений (не относящихся, впрочем, к С++) — ограничения на размер стека и использование арифметики с плавающей точкой в коде ядра. Т.е. получается стандартными библиотеками мы вряд ли сможем воспользоваться.

Вещами типа std::list и std::vector -- наверняка.
Но на C++ их аналоги для сильно ограниченных систем написать будет попроще, чем на C. За счет тех же шаблонов и наследования.

SI>Пространства имен? Перегрузка функций? Согласен, но не могу сказать, что это сделает программирование намного легче в условиях жестких временных рамок

Сделают. По крайней мере системы реального времени на C++ мне приходилось писать и желания использовать C не было.

SI>В итоге получается, что С++ в значительной степени будет использован лишь как "better C". Можно конечно, но нет особого смысла забивать гвозди сковородкой

Еще вы забыли про RAII.

Да и в любом случае, зачем брать C, если есть "better C"?

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

RO>если бы на C++ были удобные библиотеки для всего-всего, то все перешли бы (обратно) на C++...

Зачем тогда вообще будет писать на С++?

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

E>...

не могу вам возразить. Возможно, у меня не хватает опыта/квалификации, чтобы доказать обратное (да и не очень хочется устраивать очередной холивар, сам программирую в основном на С++). Вопрос этот довольно тонок, просто есть факт того, что в низкоуровневых вещах опытные люди (из RedHat/MontaVista/Oracle/...) не используют С++, хотя в принципе могли бы. Сомневаюсь, что будь у них возможность дешевого использования С++ они бы продолжили использовать С. Возможно, что просто не хватает таких квалифицированных людей как вы

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

SI>не могу вам возразить. Возможно, у меня не хватает опыта/квалификации, чтобы доказать обратное (да и не очень хочется устраивать очередной холивар, сам программирую в основном на С++). Вопрос этот довольно тонок, просто есть факт того, что в низкоуровневых вещах опытные люди (из RedHat/MontaVista/Oracle/...) не используют С++, хотя в принципе могли бы. Сомневаюсь, что будь у них возможность дешевого использования С++ они бы продолжили использовать С.

Не нужно забывать про фактор унаследованного кода. Большинство Unix-ов сейчас базируются на C-шной кодовой базе, возраст которой изменяется десятилетиями. В таких условиях нет смысла переходить на C++ -- big rewriting никогда ничем хорошим не заканчивался.

SI> Возможно, что просто не хватает таких квалифицированных людей как вы

Про меня -- это вообще бесспорно

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

E>Ну так сами бы посмотрели. Например, на скольких платформах работает NetBSD и GCC под ним? И сколько их этих платформ нормально поддерживаются разработчиками OCaml-а?

Мы значит читать не умеем совсем:

The bytecoded system currently runs on any POSIX-compliant operating system with an ANSI-compliant C compiler (and tries hard to accommodate deviations from POSIX and ANSI-C). It should run straight out of the box on all Unix and Unix-compatible systems, including Linux and MacOS X. (See below for MS Windows.) While not mandatory, it is recommended to use the GNU gcc compiler to compile the distribution.

Y>>А насчет ограниченного количества приложений даже комментировать не буду

E>Это разумно.

Что разумного-то? Это бред какой-то, не удержался, простите. Это такой же general purpose язык как и С++/Java/C#, только более высокоуровневый, с поддержкой одновременно ФП и ООП.

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

E>>Ну так сами бы посмотрели. Например, на скольких платформах работает NetBSD и GCC под ним? И сколько их этих платформ нормально поддерживаются разработчиками OCaml-а?

Y>Мы значит читать не умеем совсем:
Y>

Y>The bytecoded system currently runs on any POSIX-compliant operating system with an ANSI-compliant C compiler (and tries hard to accommodate deviations from POSIX and ANSI-C). It should run straight out of the box on all Unix and Unix-compatible systems, including Linux and MacOS X. (See below for MS Windows.) While not mandatory, it is recommended to use the GNU gcc compiler to compile the distribution.

Так мы пытаемся сравнивать байт-код и нативный код C++? А после этого еще утвержать, что OCaml будет заменой C++ без ограничений предметной области и используемых платформ?

Ну и хотя бы посмотрите, какой функциональностью обладают версии OCaml-а под Windows.

Y>>>А насчет ограниченного количества приложений даже комментировать не буду

E>>Это разумно.

Y>Что разумного-то? Это бред какой-то, не удержался, простите. Это такой же general purpose язык как и С++/Java/C#, только более высокоуровневый, с поддержкой одновременно ФП и ООП.

А я и не спорил с тем, что OCaml может конкурировать с C++ как высокоуровневый. Зато как низкоуровневый OCaml C++у вообще не конкурент.

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

Y>>Что разумного-то? Это бред какой-то, не удержался, простите. Это такой же general purpose язык как и С++/Java/C#, только более высокоуровневый, с поддержкой одновременно ФП и ООП.

E>А я и не спорил с тем, что OCaml может конкурировать с C++ как высокоуровневый. Зато как низкоуровневый OCaml C++у вообще не конкурент.

Ах вот оно что

Ну все с Вами понятно

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

Y>Ну все с Вами понятно

Т.е. вы со мной не согласны?

Можно ли увидеть примеры реализации на OCaml-е встроенного ПО или ПО реального времени?
Для другого конкурента C++, языка Eiffel, можно найти примеры и того, и другого. А вот на OCaml-е есть что-нибудь такое?

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

SI>Вот только для вещей, критичных к памяти и быстродействию (взять то же самое ядро ОС) многие его преимущества сводятся на нет. Поддержка исключений и rtti однозначно будут выключены.

Вовсе не однозначно тут все. Например, в MSDN тоже понаписано, почему нет исключений в ядре. Вроде как стек они расходуют сильно. А в реальности, обёртки вокруг SEH для try{}catch{} менее требователны к стеку, чем оные для __try{}__except{}

Почему же не работают С++ исключения в Windows kernel на самом деле? Реализация MSVC CRT хранит в thread local storage некоторую информацию (в частности, последнее брошенное исключение для throw;). А в ядре просто нет TLS!

(в NT4, похоже, было, но закончилось). То есть ответ такой — просто не досуг было реализовать. Это вероятно больше вопрос политики...

RTTI в общем-то можно использовать опционально, для поддержки исключений type_info::name() не надо.

Раздувает сильнее всего — iostreams, точнее locale. Но в том же WinCE их выкинули.

SI>Шаблоны из-за их сложности в написании и отладки так же вряд ли будут использованы "во всю ширь".

Особой разницы с юзерлендом нет.

SI>Следует учесть еще и ряд общих ограничений (не относящихся, впрочем, к С++) — ограничения на размер стека и использование арифметики с плавающей точкой в коде ядра.

Верно подмечено, то же самое относится и к С. Поэтому аллоцируется все в куче.

SI> Т.е. получается стандартными библиотеками мы вряд ли сможем воспользоваться.

При желании, сможете. У некоторых уже получается...

SI>Что же остается?
SI>Строгий контроль типов? Абстракция выделения памяти new/delete?

Смартпоинтеры тогда уж. Вообще, RAII избавляет от необходимоти писать много ненужного плохоподерживаемого кода.

SI>Стоит заметить, что механизмы распределения памяти в ядре иногда бывают более сложны нежели чем malloc/free.

Вот именно, что malloc/free в эти механизмы не укладывается, в отличие от аллокаторов или перегруженного placement new.

В общем, дурдом: компилятора С у MS попросту нет, зато есть компилятор С++, но без библиотеки.

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

Y>>Я бы сказал, есть смысл их изучить обязательно. Но не для того, чтобы понтануться, а хотя бы для того, чтобы понять какие есть альтернативы.

F>не, ну без понтов нельзя.. как же самооценку повышать?!.

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

Y>>ИМХО, ОКамл реальная альтернатива C++.

F>только синтаксис имхо плохо читаемый.. визуально эдакая смесь VB и boost-а.. +)

Это самое малое, что может мешать. Через недельку, максимум две привыкнешь.

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

J>1. Отсутствие GC. На С++ крайне сложно писать прототипы и вообще заниматься "быстрой разработкой", просто потому что в С++ ресурсами приходится управлять вручную, в отличие от управляемых языков, в которых все объекты, будучи однажды созданными, живут вечно.
Строго говоря GC в С++ есть, только реально никому не нужен, поэтому традиционно не используется.

J>В результате приходится продумывать схему владения, и ее не сменишь одним движением мизинца, что важно при быстрой разработке (в управляемых языках такой проблемы вообще не стоит).
Единственный минус — писанины чуть больше.

P.S.
Хотелось бы побольше синтаксического сахара, ну и более удобоваримые библиотеки.

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

E>Нарушение этих условий (рост команды, попадание в команду недостаточно подготовленных программистов) будет вести к проблемам, а то и провалу проекта. Поскольку здесь начнут сказываться самые разные факторы, в том числе и особенности самого языка:
E>- адресная арифметика и отсутствие контроля за выходом за пределы векторов/буферов;
Оно как раз есть.
E>- отсутствие сборки мусора;
Тоже есть, при определённых оговорках.
E>- исключениями могут быть любые объекты, а не только наследники std::exception;
А в чём проблема?

Здравствуйте, Аноним, Вы писали:

А>Раньше нужно было не забыть delete/free, а теперь нужно знать в деталях как работает GC

В нормальном С++ коде не должно быть слов delete и free.

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

V>В результате получается, что писать что-то кроссплатформенное нереально сложно, приходится выдумывать ненужные слои абстракции и обрастать макросами.

Вообще-то практика показывает, что писать на С++ кроссплатформенные проги как раз проще, чем на других языках.

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

RRO>Разве что GC может (иногда) решить проблему циклических ссылок, которые сложно отследить с помощью «умных» указателей. Но можно. Еще в 2003 г. в списке рассылки Boost показался cyclic_ptr, который их-таки отслеживал. Поступал он очень просто: вызывал **this = **this, что приводило к копированию всех подобъектов — в том числе подобъектов типа cyclic_ptr, чьи операторы присваивания делали то же самое для своих объектов и таким образом обнаруживали циклы. Но требование копируемости класса всё портило.

Лично я не сталкивался с циклическими ссылками уже лет 6, с тех пор как узнал что это. Со всем сталкивался, с целым зверинцем разнообразных багов, со всего света.
Что я делаю не так?

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

Здравствуйте, Константин Л., Вы писали:

КЛ>>>а так, что interlockedincrement/decrement не нужен как класс. а сколько они стоят для smp?

CS>>А как делать блокировку managed heap при new из разных потоков?

КЛ>Это максимум один exchange/increment на выделение.

Значит таки нужен... идем тогда дальше.

Когда тебе мусор собрать надо ты останавливаешь все потоки (stop the world в общем случае).
В связи с этим возникает вопрос: что лучше много маленьких interlockedincrement/decrement или один но толстый stop-the-world?

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

CC>хз. не пробовал. У меня подобного кода не встречается.
CC>За такой код и по рукам не мешало бы

В жизни всякое случается

CC>Надо пробовать — такую кашу не писал — не скажу.

J>>А вот так он умеет (шаблоны + операторы)?
CC>судя по картинке он те все равно не покатит — он MSVS only

Так VA видит шаблоны и операторы или нет?

P.S. Это мне xref не катит, потому что он emacs only (Cyberax пытался писать интеграцию с Code::Blocks, но забил), а на emacs у меня аллергия, в частности, из-за его двухкнопочных горячих клавиш и кривейшей реализации иксового буфера обмена

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

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

J>>1. Отсутствие GC. На С++ крайне сложно писать прототипы и вообще заниматься "быстрой разработкой", просто потому что в С++ ресурсами приходится управлять вручную, в отличие от управляемых языков, в которых все объекты, будучи однажды созданными, живут вечно.
NBN>Строго говоря GC в С++ есть, только реально никому не нужен, поэтому традиционно не используется.
"Строго говоря" — это в стандарте, что ли?

Где он есть? Он умеет разруливать касты к голым указателям и обратно? А указатели внутрь структур? (то же самое относится и к умным указателям, кстати)

J>>В результате приходится продумывать схему владения, и ее не сменишь одним движением мизинца, что важно при быстрой разработке (в управляемых языках такой проблемы вообще не стоит).
NBN>Единственный минус — писанины чуть больше.
См. выше

NBN>P.S.
NBN>Хотелось бы побольше синтаксического сахара, ну и более удобоваримые библиотеки.
+1

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

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

E>>Нарушение этих условий (рост команды, попадание в команду недостаточно подготовленных программистов) будет вести к проблемам, а то и провалу проекта. Поскольку здесь начнут сказываться самые разные факторы, в том числе и особенности самого языка:
E>>- адресная арифметика и отсутствие контроля за выходом за пределы векторов/буферов;
NBN>Оно как раз есть.

Что есть? На каком компиляторе мне дадут по рукам вот за такой код:

int b[100];
int a = 100;
b[ a ] = 1;

E>>- отсутствие сборки мусора;
NBN>Тоже есть, при определённых оговорках.

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

E>>- исключениями могут быть любые объекты, а не только наследники std::exception;
NBN>А в чём проблема?

В том, что:
— вырабатывается привычка для перехвата исключений использовать std::exception. А тут выясняется, что вылетает не пойми что;
— конструкция catch(...) ловит любое пользовательское исключение, но не дает никакой информации о том, что было поймано. В std::exception хотя бы what() есть.

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

NBN>>Строго говоря GC в С++ есть, только реально никому не нужен, поэтому традиционно не используется.
J>"Строго говоря" — это в стандарте, что ли?

J>Где он есть? Он умеет разруливать касты к голым указателям и обратно? А указатели внутрь структур? (то же самое относится и к умным указателям, кстати)
Google: GC C++

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

E>Что есть? На каком компиляторе мне дадут по рукам вот за такой код:
E>

E>int b[100];
E>int a = 100;
E>b[ a ] = 1;
E>

Ну во-первых, вижалка тебе скорее всего сообщит о проблеме. Во-вторых, реальные патцаны используют обёртки из STL & boost

NBN>>Тоже есть, при определённых оговорках.
E>Сборка мусора с определенными оговорками это почти как рыба второй свежести. Вроде и рыба, и свежая, но с оговорками.
Не, просто проект нужно делать в нетрадиционном для С++ стиле. А учитывая, что некоторых личностей не уговорить использовать даже SP... Определённые оговорки по использованию GC всётаки есть. Ну и STL не приспособлен к GC

E>- вырабатывается привычка для перехвата исключений использовать std::exception. А тут выясняется, что вылетает не пойми что;
E>- конструкция catch(...) ловит любое пользовательское исключение, но не дает никакой информации о том, что было поймано. В std::exception хотя бы what() есть.
Ну это больше зависит от организации проекта.

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

GN>...

Ко всему прочему стоит заметить, что, видимо, написание аналогичного кода на С++ потребует большей подготовки и большей квалификации девелопера. Элементарно простой пример: std::map (а так же, например, стандартнуя реализация AVL tree) нельзя (ну или скажем, неблагоразумно) использовать в коде ядра. Насчет Windows не уверен, но в Linux'е точно. Абстракция благо, когда знаешь, что нет подводных камней для её использования, видимо поэтому народ выбирает С для написания низкоуровневых вещей (ядра и его модулей), т.к. язык этот не подходит для заворачивания крутых абстракций.
Вот, к примеру, память в ядре линукса экономится настолько сильно, что нужно помечать инициализирующую функцию и данные для инициализации в модуле ядра специальными ключами (__init/__initdata вроде), которые помещаются линкером в специальную секцию ELF файла, которая будет удалена после инициализации модуля ядром.

Впрочем, учитывая возможное появление WinFX (вроде так это называется, вся ОС — на .NET) все эти опасения теряют смысл — памяти и проца и хватит на любые извращения, не только на С++ с рантаймом и включенными всеми делами, но и на VisualBasic

GN>

GN>В общем, дурдом: компилятора С у MS попросту нет, зато есть компилятор С++, но без библиотеки.

Нет, ну почему же нету, есть, только по стандарту ISO C89 (если не изменяет память). Нету <stdbool.h> и иже с ним, возможности объявлять переменные не только в начале функции и ряда других вещей.

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

J>Так VA видит шаблоны и операторы или нет?
Шаблоны он понимает. Мне правда не сильно понятно что именно тебе надо чтобы он понимал в шаблонах?
Где используется например конкретный operator+ -- искать отказывается.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

А>>Раньше нужно было не забыть delete/free, а теперь нужно знать в деталях как работает GC

NBN>В нормальном С++ коде не должно быть слов delete и free.
с отсутствием delete не согласен категорически. Память освобождать как то нужно. Это С++ а не С# — тут доброго дядюшки GC с памперсом наготове нету.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

CreatorCray пишет:

> А>>Раньше нужно было не забыть delete/free, а теперь нужно знать в
> деталях как работает GC
> NBN>В нормальном С++ коде не должно быть слов delete и free.
> с отсутствием delete не согласен категорически. Память освобождать как
> то нужно. Это С++ а не С# — тут доброго дядюшки GC с памперсом наготове
> нету.

NikeByNike явно имеет в виду, что место delete — в библиотеках. В
принципе, почти так оно и есть.

Posted via RSDN NNTP Server 2.1 beta

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

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

NBN>>>Строго говоря GC в С++ есть, только реально никому не нужен, поэтому традиционно не используется.
J>>"Строго говоря" — это в стандарте, что ли?

J>>Где он есть? Он умеет разруливать касты к голым указателям и обратно? А указатели внутрь структур? (то же самое относится и к умным указателям, кстати)
NBN>Google: GC C++
Уж послал так послал. Это шутка такая была?

Давай простой пример:

struct S
{
  int i;
};

int* f()
{
  S s;
  return &s.i;
}

int main()
{
  int* pi = f();
}

Мне будет очень интересно посмотреть, как твой любимый "GC C++" обеспечит жизнедеятельность объекта s в течение всей жизни pi (и как он вообще узнает о том, что на него есть ссылка).
Модификаторы типа __gc расставь по вкусу везде, кроме pi — он должен оставаться обычным голым указателем.

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

J>кроме pi — он должен оставаться обычным голым указателем.
А почему?

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

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

J>>кроме pi — он должен оставаться обычным голым указателем.
E>А почему?

Потому что я сомневался именно в том, что GC может отследить голые указатели.
Особенно которые void* (сишных интерфейсов пока никто не отменял)

Здравствуйте, NikeByNike

Утверждения на счет реальных пацанов, STL, boost и огранизацию проектов нет времени комментировать. Но вот аббревиатура SP мне не известна:

NBN>Не, просто проект нужно делать в нетрадиционном для С++ стиле. А учитывая, что некоторых личностей не уговорить использовать даже SP

Это что за зверь такой?

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

E>Здравствуйте, NikeByNike

E>Утверждения на счет реальных пацанов, STL, boost и огранизацию проектов нет времени комментировать. Но вот аббревиатура SP мне не известна:

E>Это что за зверь такой?

smart pointer, вестимо

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

J>Особенно которые void* (сишных интерфейсов пока никто не отменял)
Ну очевидно, что если ты куда-то передаёшь владение через void*, то gc использовать нельзя, так как у объекта будет два владельца...
Но никто и не заставляет, в принципе...

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

J>Давай простой пример:
J>

J>struct S
J>{
J>  int i;
J>};

J>int* f()
J>{
J>  S s;
J>  return &s.i;
J>}

J>int main()
J>{
J>  int* pi = f();
J>}
J>

У тебя есть полная свобода выстрелить себе в ногу, я тут спорить не буду

Но это не мои проблемы.

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

J>Потому что я сомневался именно в том, что GC может отследить голые указатели.
J>Особенно которые void* (сишных интерфейсов пока никто не отменял)

Во-первых может, а во-вторых, кто тебя заставляет применять void*? Для нормального программирования требуется определённая культура кода и поддержка определённого стиля. Сила С++ в том что он даёт бОльшое количество возможностей, чем остальные распространённые языки.

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

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

J>>Потому что я сомневался именно в том, что GC может отследить голые указатели.
J>>Особенно которые void* (сишных интерфейсов пока никто не отменял)

NBN>Во-первых может,
Я, по-моему, привел пример, в котором не может. Или уже может?

NBN>а во-вторых, кто тебя заставляет применять void*?
Спустись на землю.
Реальное промышленное программирование — это не райские кущи стандартов.

NBN>Для нормального программирования требуется определённая культура кода и поддержка определённого стиля. Сила С++ в том что он даёт бОльшое количество возможностей, чем остальные распространённые языки.
Я примерно в курсе, что дает С++. Но мы сейчас говорим не о его возможностях, а о то, что в нем нет GC.
Пока что опровержения я не увидел.

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

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

J>>Давай простой пример:

NBN>У тебя есть полная свобода выстрелить себе в ногу, я тут спорить не буду

Но это не мои проблемы.

Занимательный диалог получается:
— Нет поддержки!
— Есть поддержка!
— Ну вот тебе пример!
— Ну и сам дурак, что такой пример привел, это не мои проблемы!

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

S>NikeByNike явно имеет в виду, что место delete — в библиотеках.
Тогда в принципе согласен.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

NBN>>Во-первых может,
J>Я, по-моему, привел пример, в котором не может. Или уже может?
Пример заведомо некорректный. Я могу ещё десяток похожих привести, только толку?

NBN>>а во-вторых, кто тебя заставляет применять void*?
J>Спустись на землю.
Спускался много раз.
J>Реальное промышленное программирование — это не райские кущи стандартов.
Фиговое оправдание. void* имеет ограниченное применение только при разработки либ наподобии STL. Вне этого — повод для увольнения.

J>Я примерно в курсе, что дает С++. Но мы сейчас говорим не о его возможностях, а о то, что в нем нет GC.
J>Пока что опровержения я не увидел.
Оно есть и я его использовал, в том что ты его не увидел — не моя вина

А различного рода API(начиная с Win API) уже отменили что ли ?

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

J>Занимательный диалог получается:
J>- Нет поддержки!
J>- Есть поддержка!
Где я писал что есть поддержка???

J>- Ну вот тебе пример!
J>- Ну и сам дурак, что такой пример привел, это не мои проблемы!
Ну и что? Я могу привести пару дурацких примеров наподобии твоего — доказывающих, что нет смартпоинтеров.
Но они есть

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

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

NBN>>>Во-первых может,
J>>Я, по-моему, привел пример, в котором не может. Или уже может?
NBN>Пример заведомо некорректный. Я могу ещё десяток похожих привести, только толку?

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

NBN>>>а во-вторых, кто тебя заставляет применять void*?
J>>Спустись на землю.
NBN>Спускался много раз.
J>>Реальное промышленное программирование — это не райские кущи стандартов.
NBN>Фиговое оправдание. void* имеет ограниченное применение только при разработки либ наподобии STL. Вне этого — повод для увольнения.

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

J>>Я примерно в курсе, что дает С++. Но мы сейчас говорим не о его возможностях, а о то, что в нем нет GC.
J>>Пока что опровержения я не увидел.
NBN>Оно есть и я его использовал, в том что ты его не увидел — не моя вина

Google GC C++ — это замечательное опровержение, очень удобное. "Примерно 450 000" результатов, и опровержение в одном из них, да? И пока я не прочитаю их все, мой тезис считается опровергнутым?

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

J>>>Я, по-моему, привел пример, в котором не может. Или уже может?
NBN>>Пример заведомо некорректный. Я могу ещё десяток похожих привести, только толку?
_>Почему ?
Почему пример некорректный? Потому что условия работы gc не соблюдаются.

J>>>Реальное промышленное программирование — это не райские кущи стандартов.
NBN>>Фиговое оправдание. void* имеет ограниченное применение только при разработки либ наподобии STL. Вне этого — повод для увольнения.
_>

А различного рода API(начиная с Win API) уже отменили что ли ?
Во-первых, это С.
А во-вторых — а врапперы тоже уже отменили? Я чего-то не вижу у себя в коде непосредственной работы с WinAPI.

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

J>Если тебе не приходилось иметь дела с другими системами, имеющими странные интерфейсы, в том числе написанными на голом С, то ты совсем не много раз спускался. В принципе, можно позавидовать, так как удовольствие то еще.
Я писал проект работающий под 6 операционками, начиная от десктопа и заканчивая холодильниками и кондиционерами.
Сейчас проект попроще — только 3 разные операционки (их вариации и различные платформы не в счёт)

J>Google GC C++ — это замечательное опровержение, очень удобное. "Примерно 450 000" результатов, и опровержение в одном из них, да? И пока я не прочитаю их все, мой тезис считается опровергнутым?
Мне было бы достаточно первой же ссылки.

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

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

J>>>>Я, по-моему, привел пример, в котором не может. Или уже может?
NBN>>>Пример заведомо некорректный. Я могу ещё десяток похожих привести, только толку?
_>>Почему ?
NBN>Почему пример некорректный? Потому что условия работы gc не соблюдаются.

J>>>>Реальное промышленное программирование — это не райские кущи стандартов.
NBN>>>Фиговое оправдание. void* имеет ограниченное применение только при разработки либ наподобии STL. Вне этого — повод для увольнения.
_>>

А различного рода API(начиная с Win API) уже отменили что ли ?
NBN>Во-первых, это С.
Ага, и ты не поверишь, с этим С приходится работать не то что из С++, но из с#, и там подобный код выглядит еще более противоесстественным.

NBN>А во-вторых — а врапперы тоже уже отменили? Я чего-то не вижу у себя в коде непосредственной работы с WinAPI.
И что это доказывает ?

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

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

J>>Если тебе не приходилось иметь дела с другими системами, имеющими странные интерфейсы, в том числе написанными на голом С, то ты совсем не много раз спускался. В принципе, можно позавидовать, так как удовольствие то еще.
NBN>Я писал проект работающий под 6 операционками, начиная от десктопа и заканчивая холодильниками и кондиционерами.
NBN>Сейчас проект попроще — только 3 разные операционки (их вариации и различные платформы не в счёт)

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

J>>Google GC C++ — это замечательное опровержение, очень удобное. "Примерно 450 000" результатов, и опровержение в одном из них, да? И пока я не прочитаю их все, мой тезис считается опровергнутым?
NBN>Мне было бы достаточно первой же ссылки.

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

А это означает, что GC в том смысле, в котором он рулит в управляемых языках, в С++ нет.

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

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

J>>Занимательный диалог получается:
J>>- Нет поддержки!
J>>- Есть поддержка!
NBN>Где я писал что есть поддержка???

http://www.rsdn.ru/forum/message/2975105.1.aspx

Строго говоря GC в С++ есть, только реально никому не нужен, поэтому традиционно не используется.

Твои слова?
Особенно интересно в свете развернувшейся дискуссии, что ты вкладываешь в слово "строго" выше?

J>>- Ну вот тебе пример!
J>>- Ну и сам дурак, что такой пример привел, это не мои проблемы!
NBN>Ну и что? Я могу привести пару дурацких примеров наподобии твоего — доказывающих, что нет смартпоинтеров.
NBN>Но они есть

Да, они есть, а GC нет.
Потому что GC — это "создал и забыл", с гарантией, что никогда не получишь указателей в никуда или в мертвый объект.
А GC в стиле "создал и не дай бог забудешь, где и что и как с ним обращаться" — такой GC действительно никому не нужен, разве что в качестве back-end управляемой среды.

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

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

NBN>>А во-вторых — а врапперы тоже уже отменили? Я чего-то не вижу у себя в коде непосредственной работы с WinAPI.
_>И что это доказывает ?

Всё что надо.

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

NBN>>Я писал проект работающий под 6 операционками, начиная от десктопа и заканчивая холодильниками и кондиционерами.
NBN>>Сейчас проект попроще — только 3 разные операционки (их вариации и различные платформы не в счёт)

J>Тогда я не понимаю, о чем ты споришь — в твоем коде тоже будут и голые указатели, и указатели на void (а то и что похуже, типа LPARAM).

Где-то внутри — они есть. Только в 99% случаев я их не вижу.
То что кто-то пишет что-то наподобии:

return ((int (*)(int, int))0x12345678)(1, 1);

не означает что я тоже должен так писать.

J>В первой ссылке написано, что есть такой классный GC для С++, что если не дышать и не топать громко, то он работает примерно так, как должен работать GC в нормальном управляемом языке.
J>А это означает, что GC в том смысле, в котором он рулит в управляемых языках, в С++ нет.
Ага, смартпоинтеров тоже нет. Если их используешь — тоже топать низя. И наследования тоже нет — ану как забудешь виртуальный деструктор?

Вобщем ничего нет, одна адресная арифметика.

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

NBN>>Фиговое оправдание. void* имеет ограниченное применение только при разработки либ наподобии STL. Вне этого — повод для увольнения.
_>

А различного рода API(начиная с Win API) уже отменили что ли ?
А в какое API ты отдаёшь буфер во владение?

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

J>А это означает, что GC в том смысле, в котором он рулит в управляемых языках, в С++ нет.

И не может быть.

Желающие могут сделать xor list на языке с GC.

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

NBN>>Где я писал что есть поддержка???

J>http://www.rsdn.ru/forum/message/2975105.1.aspx
J>

J>Строго говоря GC в С++ есть, только реально никому не нужен, поэтому традиционно не используется.

J>Твои слова?
Тут нет ни слова про поддержку. Поддержка будет в следующем стандарте.
Это из разряда — в С можно писать в ООП стиле, включая использование виртуальных функций, но вот поддежки ООП в языке нет.

J>Особенно интересно в свете развернувшейся дискуссии, что ты вкладываешь в слово "строго" выше?

Строго — значит оно есть. А выделил это слово чтобы показать что есть нюансы использования. Классический пример — если будешь хранить указатели в разобранном виде или выделять память нестандартным образом — ничего не будет работать.

NBN>>Ну и что? Я могу привести пару дурацких примеров наподобии твоего — доказывающих, что нет смартпоинтеров.
NBN>>Но они есть

J>Да, они есть, а GC нет.
J>Потому что GC — это "создал и забыл", с гарантией, что никогда не получишь указателей в никуда или в мертвый объект.
Ну я примерно так и писал в тестовом проекте. Выделял-выделял-выделял память и не заботился о её удалении и всё работает зашибись. Единственное что я когда пишу — понимаю, что происходит и соблюдаю условия необходимые для работы gc.

J>А GC в стиле "создал и не дай бог забудешь, где и что и как с ним обращаться" — такой GC действительно никому не нужен, разве что в качестве back-end управляемой среды.
C++ у нас феррари

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

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

NBN>>>Фиговое оправдание. void* имеет ограниченное применение только при разработки либ наподобии STL. Вне этого — повод для увольнения.
_>>

А различного рода API(начиная с Win API) уже отменили что ли ?
E>А в какое API ты отдаёшь буфер во владение?
в исходном примере от jazzer'a была немного другая история. мы скорее получали владение. А таких историй масса

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

J>>А это означает, что GC в том смысле, в котором он рулит в управляемых языках, в С++ нет.

RO>И не может быть.

Хоть 10 раз можно повторить, это бесполезно пока есть конкретные работающие примеры.

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

J>А GC в стиле "создал и не дай бог забудешь, где и что и как с ним обращаться" — такой GC действительно никому не нужен, разве что в качестве back-end управляемой среды.
Например, ты можешь завернуть управляемый указаетль в умный, который просто не даст тебе сделать из него неуправляемый неявно...
В целом я так тебя понял, что ты считаешь, что в C++ нет GC? так как можно получить неуправляемый указатель и он останется после разрушения нашего объекта. Так в С++ много чего можно. Если тебе не нужны неуправляемые указатели, то просо не пользуйся ими

Или ты боишься, что скажется неуправляемость аргументов в функции типа strstr? Так старый С-шный код вроде как GC никак не зовёт...

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

E>>А в какое API ты отдаёшь буфер во владение?
_>в исходном примере от jazzer'a была немного другая история. мы скорее получали владение. А таких историй масса

Пример jazzer'a никакого отношения к gc не имеет.

Пример с gc выглядит так:

{
  int** pp = gcnew int*( gcnew int(1) );
  **p = 2;
  pp = 0;
  pp = gcnew int*( gcnew int(3) );
}

При использовании подходящей либы — данный код вполне корректен и утечки памяти не происходит.

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

NBN>>Хоть 10 раз можно повторить, это бесполезно пока есть конкретные работающие примеры.

E>Пока эти примеры похожи на исключения, только подтверждающие общие правила.

Ты о чём?

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

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

E>>>А в какое API ты отдаёшь буфер во владение?
_>>в исходном примере от jazzer'a была немного другая история. мы скорее получали владение. А таких историй масса

NBN>Пример jazzer'a никакого отношения к gc не имеет.
Имхо, мой пример как раз в нему отношение и имеет, потому что этот код в системах с GC будет работать без запинки.
И можно будет говорить о том, что в С++ есть GC, только тогда, когда код на С++ с использованием GC будет таким же прозрачным.

NBN>Пример с gc выглядит так:

NBN>

NBN>{
NBN>  int** pp = gcnew int*( gcnew int(1) );
NBN>  **p = 2;
NBN>  pp = 0;
NBN>  pp = gcnew int*( gcnew int(3) );
NBN>}
NBN>

NBN>При использовании подходящей либы — данный код вполне корректен и утечки памяти не происходит.

А можешь продемонстрировать, как это будет с моим примером (ссылка на член структуры)?
Измени его, чтобы удовлетворяло правилам боэмовского GС.

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

NBN>Пример jazzer'a никакого отношения к gc не имеет.
Слушайте, уважаемый... я щас несколько раз перечитал исходный пост jazzer'a, там несколько раз русским по белому упоминается GC. Но это еще пол беды, началось все с вашей фразы

Строго говоря GC в С++ есть

которую на протяжении всей дисскуссии вас просят прояснить, а прояснения не наступает

Это конечно безумно интересная дисскуссия, но я не готов в ней учавствовать со скоростью 2 поста в минуту

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

Извиняюсь, что вмешался

Посмотрим на сколько у jazzer'a хватит терпения

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

NBN>>>Хоть 10 раз можно повторить, это бесполезно пока есть конкретные работающие примеры.

E>>Пока эти примеры похожи на исключения, только подтверждающие общие правила.

NBN>Ты о чём?

О том, что приведенные в качестве примера разработанные тобой программы, работающие на С++ c GC, не являются достаточным опровержением тезиса о том, что в C++ нет GC. Это всего лишь демонстрация того, что на C++ можно написать так, что какой-то GC будет работать. В общем, как секс ежиков -- очень и очень осторожный.

Но в общем случае для C++ GC до сих пор нет.

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

J>Имхо, мой пример как раз в нему отношение и имеет, потому что этот код в системах с GC будет работать без запинки.
Ойли, ты можешь получить gc-указатель на объект созанный на стеке?

J>И можно будет говорить о том, что в С++ есть GC, только тогда, когда код на С++ с использованием GC будет таким же прозрачным.
Я не вижу никакого смысла отменять возможность выделения памяти на стеке под временные объекты.

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

J>>>1. Отсутствие GC. На С++ крайне сложно писать прототипы и вообще заниматься "быстрой разработкой", просто потому что в С++ ресурсами приходится управлять вручную, в отличие от управляемых языков, в которых все объекты, будучи однажды созданными, живут вечно.

NBN>>Строго говоря GC в С++ есть, только реально никому не нужен, поэтому традиционно не используется.

J>"Строго говоря" — это в стандарте, что ли?

J>Где он есть? Он умеет разруливать касты к голым указателям и обратно? А указатели внутрь структур? (то же самое относится и к умным указателям, кстати)

Для С++ есть ряд GC с разными характеристиками. Причём есть ряд GC так сказать промышленного уровня.
Первое, что надо упомянуть, это естественно Boehm GC:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Platforms
The collector is not completely portable, but the distribution includes ports to most standard PC and UNIX/Linux platforms. The collector should work on Linux, *BSD, recent Windows versions, MacOS X, HP/UX, Solaris, Tru64, Irix and a few other operating systems. Some ports are more polished than others. There are instructions for porting the collector to a new platform.

Current users:
Known current users of some variant of this collector include:
The runtime system for GCJ, the static GNU java compiler.
W3m, a text-based web browser.
Some versions of the Xerox DocuPrint printer software.
The Mozilla project, as leak detector.
The Mono project, an open source implementation of the .NET development framework.
The DotGNU Portable.NET project, another open source .NET implementation.
The Irssi IRC client.
The Berkeley Titanium project.
The NAGWare f90 Fortran 90 compiler.
Elwood Corporation's Eclipse Common Lisp system, C library, and translator.
The Bigloo Scheme and Camloo ML compilers written by Manuel Serrano and others.
Brent Benson's libscheme.
The MzScheme scheme implementation.
The University of Washington Cecil Implementation.
The Berkeley Sather implementation.
The Berkeley Harmonia Project.
The Toba Java Virtual Machine to C translator.
The Gwydion Dylan compiler.
The GNU Objective C runtime.
Macaulay 2, a system to support research in algebraic geometry and commutative algebra.
The Vesta configuration management system.
Visual Prolog 6.
Asymptote LaTeX-compatible vector graphics language.

GC консервативный, т.е. никакая дополнительная мета-информация ему не нужна, но зато он считает указателем всё, что похоже на указатель. Т.е. "void*" он будет обрабатывать корректно.

Далее есть HnxGC:
http://hnxgc.harnixworld.com/
Он точный, т.е. ему нужна мета-информация относительно расположения указателей в объектах. Соотв. управляет он только объектами отнаследованными от спец. класса. Плюс использует умные указатели и подсчёт ссылок. Т.е. не-циклический мусор удаляется синхронно. А циклический во время запуска сборки мусора, которая соотв. проходит очень редко. Если нет циклического мусора, то видимо сборку можно вообще не запускать, но на всякий случай она всё равно "будет там".

SGCL
http://sourceforge.net/projects/sgcl/
Его не смотрел, но в описании написано "Precise, concurrent Garbage Collection library for C++.", т.е. видимо тоже использует мета-информацию. Плюс parallel и concurrent.

Не пользуются ими C++ программисты видимо просто из "исторических" причин. Типа мы же 20 обходились без GC, а теперь Вы нам пытаетесь сказать, что без него нельзя писать работающие программы и жить вообще

Хотя можно и писать на C++, и использовтаь GC одновременно — достаточно поглядеть на список пользователей Boehm GC.

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

_>Слушайте, уважаемый... я щас несколько раз перечитал исходный пост jazzer'a, там несколько раз русским по белому упоминается GC. Но это еще пол беды, началось все с вашей фразы
_>

_>Строго говоря GC в С++ есть

_>которую на протяжении всей дисскуссии вас просят прояснить, а прояснения не наступает

http://www.rsdn.ru/forum/message/2975642.1.aspx
http://www.rsdn.ru/forum/message/2975624.1.aspx

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

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

J>>Имхо, мой пример как раз в нему отношение и имеет, потому что этот код в системах с GC будет работать без запинки.
NBN>Ойли, ты можешь получить gc-указатель на объект созанный на стеке?
Я же сказал, расставь __gc по вкусу.
Естественно, подразумевается, что s создан управляемым.
Прошу прощения, если запутал тебя.

J>>И можно будет говорить о том, что в С++ есть GC, только тогда, когда код на С++ с использованием GC будет таким же прозрачным.
NBN>Я не вижу никакого смысла отменять возможность выделения памяти на стеке под временные объекты.
По этому поводу никто с тобой и не спорит, вроде.

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

NBN>>Ты о чём?

E>О том, что приведенные в качестве примера разработанные тобой программы, работающие на С++ c GC
Где я приводил такой пример???

E>не являются достаточным опровержением тезиса о том, что в C++ нет GC.
Ага, если код есть и работает, это не является доказательством его наличия?

E>Это всего лишь демонстрация того, что на C++ можно написать так, что какой-то GC будет работать.
А этого не достаточно, для того чтобы признать, что на С++ можно писать используя gc?

E>В общем, как секс ежиков -- очень и очень осторожный.
Спорно.

E>Но в общем случае для C++ GC до сих пор нет.
Как раз в общем он есть. Просто не используется по нескольким причинам (скорость, нераспространённость, отсуствие поддержки со стороны стандартных либ).

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

NBN>>Ойли, ты можешь получить gc-указатель на объект созанный на стеке?
J>Я же сказал, расставь __gc по вкусу.
А это что?

J>Естественно, подразумевается, что s создан управляемым.
J>Прошу прощения, если запутал тебя.

Если я правильно понял, то всё будет выглядеть так:

struct S
{
  int* i;
  S()
  {
    i = gcnew int(1);
  }
};

int* f()
{
  S s;
  return s.i;
}

int main()
{
  int* pi = f();
}

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

NBN>

NBN>int main()
NBN>{
NBN>  <- тут естественно инициализация gc
NBN>  int* pi = f();
NBN>  <- а тут соответственно уничтожение
NBN>}
NBN>

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

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

NBN>>>Где я писал что есть поддержка???

J>>http://www.rsdn.ru/forum/message/2975105.1.aspx
J>>

J>>Строго говоря GC в С++ есть, только реально никому не нужен, поэтому традиционно не используется.

J>>Твои слова?
NBN>Тут нет ни слова про поддержку. Поддержка будет в следующем стандарте.
Ну так и у меня не слова про поддержку, если искать именно это слово

Я просто проиллюстрировал, как выглядит наш диалог со стороны.
Хотя... если что-то "есть в С++", это, имхо, значит, что есть именно поддержка со стороны языка.
Но это уже терминологических спор, который, я думаю, никому затевать неинтересно.

NBN>Это из разряда — в С можно писать в ООП стиле, включая использование виртуальных функций, но вот поддежки ООП в языке нет.
А что, есть? Или я опять тебя не понял?

J>>Особенно интересно в свете развернувшейся дискуссии, что ты вкладываешь в слово "строго" выше?

NBN>Строго — значит оно есть. А выделил это слово чтобы показать что есть нюансы использования. Классический пример — если будешь хранить указатели в разобранном виде или выделять память нестандартным образом — ничего не будет работать.
ОК, принято. (Хоть и противоречит математическому смыслу слова "строго")

NBN>>>Ну и что? Я могу привести пару дурацких примеров наподобии твоего — доказывающих, что нет смартпоинтеров.
NBN>>>Но они есть

J>>Да, они есть, а GC нет.
J>>Потому что GC — это "создал и забыл", с гарантией, что никогда не получишь указателей в никуда или в мертвый объект.
NBN>Ну я примерно так и писал в тестовом проекте. Выделял-выделял-выделял память и не заботился о её удалении и всё работает зашибись. Единственное что я когда пишу — понимаю, что происходит и соблюдаю условия необходимые для работы gc.
Т.е. ты никогда не передавал ссылки на внутренности, только на объекты целиком?

J>>А GC в стиле "создал и не дай бог забудешь, где и что и как с ним обращаться" — такой GC действительно никому не нужен, разве что в качестве back-end управляемой среды.
NBN>C++ у нас феррари

Вот о чем и речь. На феррари на дачу не поедешь. Это к вопросу об обсуждаемых пределах С++.

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

NBN>Здравствуйте, Аноним, Вы писали:

А>>Раньше нужно было не забыть delete/free, а теперь нужно знать в деталях как работает GC

NBN>В нормальном С++ коде не должно быть слов delete и free.

Речь о другом, о том что с GC нужно знать его принцип работы иначе можна быстро за#$%ть память, а в некоторых случаях и еще хуже необходимо самому звать Dispose. То есть реально легче прогеру не стало, так как нужно помнить много ньюансов GC, а в С++ управление памятью намного проще.

Вот если бы GC сам по себе эффективно управлял памятью и не нужно было знать принцип его работы то тогда согласен

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

V>>В результате получается, что писать что-то кроссплатформенное нереально сложно, приходится выдумывать ненужные слои абстракции и обрастать макросами.

NBN>Вообще-то практика показывает, что писать на С++ кроссплатформенные проги как раз проще, чем на других языках.

Например, чем на Java? :-)

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

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

NBN>>>Ойли, ты можешь получить gc-указатель на объект созанный на стеке?
J>>Я же сказал, расставь __gc по вкусу.
NBN>А это что?

J>>Естественно, подразумевается, что s создан управляемым.
J>>Прошу прощения, если запутал тебя.

NBN>Если я правильно понял, то всё будет выглядеть так:

NBN>

NBN>struct S
NBN>{
NBN>  int* i;
NBN>  S()
NBN>  {
NBN>    i = gcnew int(1);
NBN>  }
NBN>};

NBN>int* f()
NBN>{
NBN>  S s;
NBN>  return s.i;
NBN>}

NBN>int main()
NBN>{
NBN>  int* pi = f();
NBN>}
NBN>

Не совсем, я имел в виду

struct S
{
  int i;
};
int* f() // как-то поменять
{
  S* s = gcnew S(); // правильный синтаксис?
  return &s.i; // как-то поменять
}

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

E>>О том, что приведенные в качестве примера разработанные тобой программы, работающие на С++ c GC
NBN>Где я приводил такой пример???

Здесь речь шла о программах для 6 операционок: http://www.rsdn.ru/Forum/message/2975546.aspx
Я подумал, что в них применялся GC

E>>не являются достаточным опровержением тезиса о том, что в C++ нет GC.
NBN>Ага, если код есть и работает, это не является доказательством его наличия?

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

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

E>>Но в общем случае для C++ GC до сих пор нет.
NBN>Как раз в общем он есть. Просто не используется по нескольким причинам (скорость, нераспространённость, отсуствие поддержки со стороны стандартных либ).

Если по твоим же словам с STL он не дружит, значит его и нет.

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

J>>>А это означает, что GC в том смысле, в котором он рулит в управляемых языках, в С++ нет.
RO>>И не может быть.
NBN>Хоть 10 раз можно повторить, это бесполезно пока есть конкретные работающие примеры.

Пока в C++ можно преобразовать void* в int, который писать в файлы и читать оттуда, полнофункциональная GC невозможен.

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

// в недрах библиотеки
intptr_t getX()
{
    return reinterpret_cast<intptr_t>(new X);
    // ссылки на объект остались, GC его не тронет!
}

// код пользователя
reinterpret_cast<X *>(getX())->doSomething();
// а вот теперь можно и удалить

На мой взгляд, жестоко.

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

NBN>>Вообще-то практика показывает, что писать на С++ кроссплатформенные проги как раз проще, чем на других языках.

RO>Например, чем на Java?

Любимая шутка наших ребят разрабатывающих какие-то части ?явамашины?: "Вы всё ещё думаете, что ява кросплатформенна?"

Хотя ява конечно тоже рулит. С другой стороны С++ способен залесть в большее количество щелей и в частности на нём можно без проблем писать на покеты

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

R>Не пользуются ими C++ программисты видимо просто из "исторических" причин. Типа мы же 20 обходились без GC, а теперь Вы нам пытаетесь сказать, что без него нельзя писать работающие программы и жить вообще

R>Хотя можно и писать на C++, и использовтаь GC одновременно — достаточно поглядеть на список пользователей Boehm GC.

В языке D использовался консервативный GC, который считал указателями все, что было похоже на указатели. После чего пользователи стали жаловаться на неправильную работу программ, обрабатывающих большие массивы вещественных данных -- определенные значения float-ов и double-ов воспринимались таким GC как указатели и соответствующим образом обрабатывались. После чего в D были добавлены специальные функции, позволяющие пометить область памяти как гарантированно не содержащую указателей.

Аналогичные проблемы могут возникнуть при использовании криптографии -- фрагменты криптоключей, криптотекста и подписей/хешей могут быть очень похожы на указатели, что снесет башку консервативному GC.

Согласись, что GC, в котором нужно явно указавать характер данных в определенных областях памяти, не сильно похож на GC из C#/Java.

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

J>Хотя... если что-то "есть в С++", это, имхо, значит, что есть именно поддержка со стороны языка.
C++ старается как можно больше функций отдать на откуп библиотекам. В случае gc у него это получается недостаточно красиво — хотя данную функциональность можно использовать — из-за недостатока сахара это получается не очень красиво. Так же как с виртуальными функциями языка С.

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

NBN>>C++ у нас феррари

J>Вот о чем и речь. На феррари на дачу не поедешь. Это к вопросу об обсуждаемых пределах С++.
Доказательства по аналогиям.

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

J>>http://www.rsdn.ru/forum/message/2975105.1.aspx
J>>

J>>Строго говоря GC в С++ есть, только реально никому не нужен, поэтому традиционно не используется.

J>>Твои слова?
NBN>Тут нет ни слова про поддержку. Поддержка будет в следующем стандарте.

N2586: Minimal Support for Garbage Collection and Reachability-Based Leak Detection (revised)
Minimal Support for Garbage Collection and Reachability-Based Leak Detection
N2587: Minimal Garbage Collection Status API

Суппорт предполагается очень ограниченный:

Goal
• Support
– Conservative Garbage Collection
– Reachability-based leak detection
• Which becomes more critical with quick_exit()
• By
– Giving undefined behavior to programs that hide pointers.
– Providing a small API to “unhide” pointers.
– Providing a small API to make collection less conservative.

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

E>Здесь речь шла о программах для 6 операционок: http://www.rsdn.ru/Forum/message/2975546.aspx
E>Я подумал, что в них применялся GC
Я этого не говорил.

E>У меня есть масса C++ного кода, который работает и использует сериализацию C++ классов. Что ни в коем случае не доказывает наличия сериализации в C++.
Ну сейчас буст включат в стандарт и будет тебе сериализация в С++.

E>Следуя определенным правилам можно написать программу на языке C++, которая будет работать под GC. Но это будет конкретная программа, а вовсе не факт того, что в C++ появился GC.
Налицо явное нарушение логики...

E>Если по твоим же словам с STL он не дружит, значит его и нет.
Не значит.

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

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

R>>Не пользуются ими C++ программисты видимо просто из "исторических" причин. Типа мы же 20 обходились без GC, а теперь Вы нам пытаетесь сказать, что без него нельзя писать работающие программы и жить вообще

R>>Хотя можно и писать на C++, и использовтаь GC одновременно — достаточно поглядеть на список пользователей Boehm GC.

E>В языке D использовался консервативный GC, который считал указателями все, что было похоже на указатели. После чего пользователи стали жаловаться на неправильную работу программ, обрабатывающих большие массивы вещественных данных -- определенные значения float-ов и double-ов воспринимались таким GC как указатели и соответствующим образом обрабатывались. После чего в D были добавлены специальные функции, позволяющие пометить область памяти как гарантированно не содержащую указателей.

E>Аналогичные проблемы могут возникнуть при использовании криптографии -- фрагменты криптоключей, криптотекста и подписей/хешей могут быть очень похожы на указатели, что снесет башку консервативному GC.

E>Согласись, что GC, в котором нужно явно указавать характер данных в определенных областях памяти, не сильно похож на GC из C#/Java.

Да. Не похож. Прострелить ногу и голову одним выстрелом всё ещё можно.
Помниться сам Boehm как-то говорил, что если Вы хотите его сломать, то не вопрос — у Вас получится

Но если если Вы ставите целью его использовать, а не ломать, то он будет работать хорошо, при этом надо понимать что это такое и как работает (последнее в принципе справедливо и для "GC из C#/Java", хотя наверное в меньшей степени).

Кстати, вот гляди, что Boehm хочет припихнуть в C++0x:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2586.html

void declare_no_pointers( char* p, size_t n ) throw()

Effects:
The n bytes starting at p no longer contain traceable pointer locations, independent of their type. Hence pointers located there may no longer be dereferenced. [Note: This may be used to inform a garbage collector or leak detector that this region of memory need not be traced.]
Throws:
Throws no exceptions. [Note: Under some conditions implementations may need to allocate memory. However the request can be ignored if memory allocation fails. -- end note]
Requires:
No bytes in the specified range may have been previously registered with declare_no_pointers(). If the specified range is in an allocated object, then it must be entirely within a single allocated object. The object must be live until the corresponding undeclare_no_pointers() call. [Note: In a garbage-collecting implementation, the fact that a region in an object is registered with declare_no_pointers() should not prevent the object from being collected. --end note]

void undeclare_no_pointers( char* p, size_t n ) throw()

Effects:
Prepares an object containing a range registered with declare_no_pointers() for destruction. It must be called before the lifetime of the object ends. It has no other effect. It does not recreate any traceable pointer locations in the object.
Requires:
The same range must previously have been passed to declare_no_pointers().

И вдобавок для кода, который может "прятать" указатели:

void declare_reachable( void* p ) throw(std::bad_alloc)

Effects:
If p is not null, the complete object referenced by p is subsequently declared reachable (see 3.7.3.3).
Throws:
May throw std::bad_alloc if the system cannot allocate additional memory that may be required to track objects declared reachable.
Requires:
The argument p shall be a safely derived pointer.

template < typename T >
T* undeclare_reachable( T* p ) throw()

Returns:
A safely derived copy of p. The result will compare equal to p.
Effects:
Once the number of calls to undeclare_reachable(p) equals the number of calls to declare_reachable(p) for all non-null p referencing the argument is no longer declared reachable (see [above section]). When this happens, pointers to the object referenced by p may not be subsequently dereferenced unless they are safely derived. [Note: Since the returned pointer is safely derived, it may be used to access the referenced object, even if previously no safely derived pointer existed. -- end note]
Requires:
If p is not null, declare_reachable(p) was previously called, and shall be live from the time of the call until the last undeclare_reachable(p) call on the object.

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

RRO>>Разве что GC может (иногда) решить проблему циклических ссылок, которые сложно отследить с помощью «умных» указателей. Но можно. Еще в 2003 г. в списке рассылки Boost показался cyclic_ptr, который их-таки отслеживал. Поступал он очень просто: вызывал **this = **this, что приводило к копированию всех подобъектов — в том числе подобъектов типа cyclic_ptr, чьи операторы присваивания делали то же самое для своих объектов и таким образом обнаруживали циклы. Но требование копируемости класса всё портило.

NBN>Лично я не сталкивался с циклическими ссылками уже лет 6, с тех пор как узнал что это. Со всем сталкивался, с целым зверинцем разнообразных багов, со всего света.
NBN>Что я делаю не так? :))

Может быть. Но речь-то о (не)возможности искать их в языках без GC, а не о правильном проектировании владения.

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

Ну то понятно, но он всё равно не даст 100% гарантии.

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

CS>Здравствуйте, Константин Л., Вы писали:

КЛ>>>>а так, что interlockedincrement/decrement не нужен как класс. а сколько они стоят для smp?

CS>>>А как делать блокировку managed heap при new из разных потоков?

КЛ>>Это максимум один exchange/increment на выделение.

CS>Значит таки нужен... идем тогда дальше.

CS>Когда тебе мусор собрать надо ты останавливаешь все потоки (stop the world в общем случае).
CS>В связи с этим возникает вопрос: что лучше много маленьких interlockedincrement/decrement или один но толстый stop-the-world?

Во-первых, аллокация/деаллокация памяти и GC — это разные вещи, предназначенные для разного. Да, Java преподносит всё в одном флаконе: язык_виртуальная_машина_библиотека_подсистема_пямяти_управление_временем_жизни_объектов. Но вообще никто не запрещает (и это сильная сторона С++) использовать для управления памятью одно решение, а для управления временем жизни — другое, и произвольно их комбинировать.
Для управления памятью можно использовать: хип, хип на поток, хип с перемещаемыми объектами, регионы, ропы, аллокаторы для объектов фикмированного размера и т.д.
Для управления временем жизни можно использовать: ручное, подсчёт ссылок, сборку мусора, множество гибридных схем и т.д.
Наибольшее приемущество С++ тут в том, что схемы можно выбирать и комбинировать, и даже применять разные схемы для разных объектов. Причём всё не так страшно, как кажется на первый взгляд. Например вполне можно представить систему, где:
— для маленьких объектов, которые выделяются в большом кол-ве, используется аллокатор для объектов фиксированного размера
— для объектов, для которых время жизни чётко ограничено определенной областью, регион-аллокатор
— для аллокации все остальных объектов используется хип
для управления временем жизни используется:
— регион-аллокатор (он же разновидность ручного управления памяти)
— для остальных подсчёт ссылок

Как следствие второй момент. В общем случае ничего не обязательно — не обязательно делать "interlockedincrement/decrement", не обязательно делать "stop the world".
Например смотри схему управления памятю без "interlockedincrement/decrement":
http://www.rsdn.ru/forum/message/2605738.1.aspx
http://www.rsdn.ru/forum/message/2605751.1.aspx

Например смотри схему управления временем жизни объектов на основе подсчёта ссылок без "interlockedincrement/decrement" ( Scalable distributed reference counting):
http://groups.google.com/group/lock-free/browse_frm/thread/46d00a0f543a758e

Например смотри некоторые concurrent GC для С++ (это уже не моё):
Далее есть HnxGC:
http://hnxgc.harnixworld.com/
SGCL
http://sourceforge.net/projects/sgcl/

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

R>Да. Не похож. Прострелить ногу и голову одним выстрелом всё ещё можно.
R>Помниться сам Boehm как-то говорил, что если Вы хотите его сломать, то не вопрос — у Вас получится

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

E>>Здесь речь шла о программах для 6 операционок: http://www.rsdn.ru/Forum/message/2975546.aspx
E>>Я подумал, что в них применялся GC
NBN>Я этого не говорил.

Тогда давай так: тебе лично удавалось писать C++ный программы с GC?

E>>У меня есть масса C++ного кода, который работает и использует сериализацию C++ классов. Что ни в коем случае не доказывает наличия сериализации в C++.
NBN>Ну сейчас буст включат в стандарт и будет тебе сериализация в С++.

Не нужно подменять тему разговора. В существующем стандарте C++ нет ни сериализации, ни GC.

E>>Следуя определенным правилам можно написать программу на языке C++, которая будет работать под GC. Но это будет конкретная программа, а вовсе не факт того, что в C++ появился GC.
NBN>Налицо явное нарушение логики...

Если не обращать внимания на "следуя определенным правилам" -- то нарушение. Но ее игнорирование так же является нарушением логики.

E>>Если по твоим же словам с STL он не дружит, значит его и нет.
NBN>Не значит.

Тогда еще раз: http://www.rsdn.ru/forum/message/2975315.1.aspx

Не, просто проект нужно делать в нетрадиционном для С++ стиле. А учитывая, что некоторых личностей не уговорить использовать даже SP... Определённые оговорки по использованию GC всётаки есть. Ну и STL не приспособлен к GC

Вопрос простой: совместим ли C++ный STL с GC в C++?

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

E>А другая сторона медали в том, что я могу написать библиотеку, использующую внутри вещественную арифметику. А кто-то возьмется ее использовать совместно с консервативным GC даже не зная, что у меня внутри матрицы перемножаются. И временами у его программы будет крышу яносить, а найти причины этому вообще вряд ли удастся.

Сильно сносить не будет. А вообще — думаю, что gc под С++ получит значительно большее распространение с выходом стандарта.

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

E>Тогда давай так: тебе лично удавалось писать C++ный программы с GC?
Нет, я только проверял его работоспособность на разного рода тестах. Лично мне gc не нужен, ни в одном из проектов. Специфика не та.

NBN>>Ну сейчас буст включат в стандарт и будет тебе сериализация в С++.
E>Не нужно подменять тему разговора. В существующем стандарте C++ нет ни сериализации, ни GC.
Ну и что??? Гуйни там тоже нет, но это не мешает писать гуйню на С++.

E>>>Следуя определенным правилам можно написать программу на языке C++, которая будет работать под GC. Но это будет конкретная программа, а вовсе не факт того, что в C++ появился GC.
NBN>>Налицо явное нарушение логики...
E>Если не обращать внимания на "следуя определенным правилам" -- то нарушение. Но ее игнорирование так же является нарушением логики.

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

Аналогия ясна?

E>Вопрос простой: совместим ли C++ный STL с GC в C++?
При определённой реализации GC — определённо совместимы. В общем же случае — надо думать.

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

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

R>>Да. Не похож. Прострелить ногу и голову одним выстрелом всё ещё можно.
R>>Помниться сам Boehm как-то говорил, что если Вы хотите его сломать, то не вопрос — у Вас получится

Но если если Вы ставите целью его использовать, а не ломать, то он будет работать хорошо, при этом надо понимать что это такое и как работает (последнее в принципе справедливо и для "GC из C#/Java", хотя наверное в меньшей степени).

E>Проблема в том, что разработчик, выделяя буфер для шифрования или массив для перемножения матриц, даже не будет задумываться о том, что это может повлиять на GC.

E>А другая сторона медали в том, что я могу написать библиотеку, использующую внутри вещественную арифметику. А кто-то возьмется ее использовать совместно с консервативным GC даже не зная, что у меня внутри матрицы перемножаются. И временами у его программы будет крышу яносить, а найти причины этому вообще вряд ли удастся.

Если ты хочешь дружить с Boehm GC, а не воевать, то всё будет работать хорошо.
Во-первых, он не рассматривает объекты, выделенные с помощью других аллокаторов (malloc, new, VirtualAlloc) — не управляет их временем жизни и не ищет в них указатели. Т.е. выделять надо с помощью специального GC_MALLOC. Т.е. сторонняя библиотека, выделевшая матрицу, отпадает.
Далее можно выделить "плоский" блок данных, в котором GC не будет искать указатели (для матриц, строк, массивов и т.д.) — GC_MALLOC_ATOMIC.
Далее можно выделить блок памяти, которым GC не будет управлять, но тем не менее будет искать в нём ссылки — GC_MALLOC_UNCOLLECTABLE.
Далее можно выделить блок памяти, который должен "держаться" указателями на своё начало (на первые 512 байт) — GC_MALLOC_IGNORE_OFF_PAGE. Допустим есть огроменный объект, и допустим ты держишь указатель на его начало, пока используешь его. В таком случае GC "соберёт" его если нет указателей на первые 512 его байт, даже если есть некий double прикинувшийся указателем на 513 байт этого объекта.

http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html

Естественно, это всё надо знать и учитывать. Ествественно, надо прочитать описание интерфейса и доступные функции, перед тем, как использовать в проекте. И т.д. Но в целом это — работающий GC для C++.

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

E>>Тогда давай так: тебе лично удавалось писать C++ный программы с GC?
NBN>Нет, я только проверял его работоспособность на разного рода тестах. Лично мне gc не нужен, ни в одном из проектов. Специфика не та.

Тогда тему можно не развивать. На тестах много чего работает.

NBN>>>Ну сейчас буст включат в стандарт и будет тебе сериализация в С++.
E>>Не нужно подменять тему разговора. В существующем стандарте C++ нет ни сериализации, ни GC.
NBN>Ну и что??? Гуйни там тоже нет, но это не мешает писать гуйню на С++.

Гуйня идет лесом, т.к. я вообще на вскидку не припомню ни одного языка, в котором GUI был бы частью языка.

А вот GC, как и сериализация, являясь частью языка, сказывается самым непосредственным образом на общем стиле программирования на этом языке. Вот в Java есть GC и разработчики не думают о том, каким компилятором и скакими дополнительными библиотеками они работают. А в C++ нужно заботится не только о библиотеках, но еще и о специальной модификации программы под работу с GC (использовать вызовы GC_MALLOC или gcnew, специальные типы указателей и пр.).

E>>>>Следуя определенным правилам можно написать программу на языке C++, которая будет работать под GC. Но это будет конкретная программа, а вовсе не факт того, что в C++ появился GC.
NBN>>>Налицо явное нарушение логики...
E>>Если не обращать внимания на "следуя определенным правилам" -- то нарушение. Но ее игнорирование так же является нарушением логики.
NBN>

NBN>Следуя определенным правилам можно написать программу на языке C++, которая будет работать с использованием SP. Но это будет конкретная программа, а вовсе не факт того, что в C++ появился SP.

NBN>Аналогия ясна?

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

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

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

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

E>А что, из явы с этими интерфейссам можно работать?..

E>Как-то не понятно, почему то, что из С++ легко позвать неуправляемый код, выдаёшь за то, что нет GC...
E>Логика какя-то странная...

Логика простая, если вспомнить, о чем мы говорим. А именно: из-за отсутствия GC　использоваться С++ для быстрой разработки и прототипирования проблематично.
Не надо мой тезис превращать в "С++ отстой, так как нет GC".

Erop, ты с чем не согласен-то?

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

R>Во-первых, он не рассматривает объекты, выделенные с помощью других аллокаторов (malloc, new, VirtualAlloc) — не управляет их временем жизни и не ищет в них указатели. Т.е. выделять надо с помощью специального GC_MALLOC. Т.е. сторонняя библиотека, выделевшая матрицу, отпадает.

С помощью чего размещать в памяти объект следующего вида:

class my_linked_list_node_t {
  private :
    // Какие-то данные объекта.
    float m_scales[ 1024 ];
    // Следующий элемент вектора.
    my_linked_list_node_t * m_next;
  public :
    ...
};

R>Естественно, это всё надо знать и учитывать. Ествественно, надо прочитать описание интерфейса и доступные функции, перед тем, как использовать в проекте. И т.д. Но в целом это — работающий GC для C++.

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

Так же и внешние по отношению к языку GC -- это всего лишь библиотеки, требующие специального использования.

ЗЫ. Никто не мешает какому-нибудь умнику взять статические версии библиотек и добавить свой new, обращающийся к GC_MALLOC.

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

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

J>>Хотя... если что-то "есть в С++", это, имхо, значит, что есть именно поддержка со стороны языка.
NBN>C++ старается как можно больше функций отдать на откуп библиотекам. В случае gc у него это получается недостаточно красиво — хотя данную функциональность можно использовать — из-за недостатока сахара это получается не очень красиво. Так же как с виртуальными функциями языка С.

Помимо отсутствия сахара, есть принципиальные проблемы, которые и выражаются в тех самых пресловутых правилах.

J>>Т.е. ты никогда не передавал ссылки на внутренности, только на объекты целиком?
NBN>Эээ, если так сходу, то либо константную ссылку для кратковременного использования, либо (если мембер должен шарится) через умный указатель.

Для этого он должен быть сразу объявлен таковым.

NBN>>>C++ у нас феррари

J>>Вот о чем и речь. На феррари на дачу не поедешь. Это к вопросу об обсуждаемых пределах С++.
NBN>Доказательства по аналогиям.
Прости, но это твоя аналогия была.

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

E>А вот в языках с GC не нужно прилагать усилий для использования GC.

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

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

J>Помимо отсутствия сахара, есть принципиальные проблемы, которые и выражаются в тех самых пресловутых правилах.
Не вижу тут проблем. Без учёта правил, я тебе и на шарпе напишу так, что прога будет падать из-за памяти.

NBN>>>>C++ у нас феррари

J>>>Вот о чем и речь. На феррари на дачу не поедешь. Это к вопросу об обсуждаемых пределах С++.
NBN>>Доказательства по аналогиям.
J>Прости, но это твоя аналогия была.
Я только демонстрировал идею. Это невозбраняется.

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

E>>А вот в языках с GC не нужно прилагать усилий для использования GC.

NBN>Ну зато возникает обратная проблема и получается, что в общем случае они обладают меньшим манёвром в области управления памятью. Т.е. С++ более универсальный язык, тем и живёт.

Речь не о том, а о том, есть ли GC в С++.
Все, что здесь было рассказано касалось средст обеспечения GC для C++. А это несколько разные вещи.

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

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

Чем же он заслужиает того, чтобы на нём писали больше прикладных программ ?

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

NBN>>Ну зато возникает обратная проблема и получается, что в общем случае они обладают меньшим манёвром в области управления памятью. Т.е. С++ более универсальный язык, тем и живёт.

E>Речь не о том, а о том, есть ли GC в С++.
E>Все, что здесь было рассказано касалось средст обеспечения GC для C++. А это несколько разные вещи.

Тут надо определиться

Кто-то ратует, за то что раз в STL нет GC — значит его и в С++ нет. Кто-то наоборот

Практически — есть либы, котрые можно свободно скачать, подключить и писать проекты на С++ управляя памятью только с использованием GC.

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

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

J>>Помимо отсутствия сахара, есть принципиальные проблемы, которые и выражаются в тех самых пресловутых правилах.
NBN>Не вижу тут проблем. Без учёта правил, я тебе и на шарпе напишу так, что прога будет падать из-за памяти.
в смысле, будут указатели в никуда?
код в студию!

NBN>>>>>C++ у нас феррари

J>>>>Вот о чем и речь. На феррари на дачу не поедешь. Это к вопросу об обсуждаемых пределах С++.
NBN>>>Доказательства по аналогиям.
J>>Прости, но это твоя аналогия была.
NBN>Я только демонстрировал идею. Это невозбраняется.
А я, типа, не демонстрировал.
Ладно, разговор ни о чем.

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

J>>В первой ссылке написано, что есть такой классный GC для С++, что если не дышать и не топать громко, то он работает примерно так, как должен работать GC в нормальном управляемом языке.
J>>А это означает, что GC в том смысле, в котором он рулит в управляемых языках, в С++ нет.
NBN>Ага, смартпоинтеров тоже нет. Если их используешь — тоже топать низя. И наследования тоже нет — ану как забудешь виртуальный деструктор?

Вобщем ничего нет, одна адресная арифметика.

Вот смартпоинтеры как раз есть, потому что они появились в С++ и являются сущностью С++.
И все правила, которым они подчиняются, лежат в рамках С++ с самого начала.

А вот наследование, сборка мусора — это понятия, пришедшие в С++ извне, и если мы говорим, что в С++ есть — это значит, что мы должны поддерживать это в том же или по крайней мере в сравнимом объеме, что и в исходном языке.
Сборка мусора была еще в Симуле (только так тормозила, что появился С++), не говоря уже о Smalltalk и современных java и .net и скриптах (там, правда, был просто мусор, без уборки).

Кстати, по поводу наследования: видел я пуристов ООП, которые утверждают, что С++ — не настоящий ООП, а так, вариации на тему, и у них своя веская аргументация на этот счет имеется. Так что с наследованием ты в точку попал.

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

[]

А предел с++ в том, что все это нужно прикручивать в том или ином виде, с привлечением специалистов. В языках с gc люди просто садятся и пишут. Уделяют внимание не ликам, а BL. Что из этого иногда получается, не важно. Важно то, что это дешево, надежно и практично (с). .net, java как STL, сначала бери его. Не подходит — рассматриваем другие варианты.

Это я про enterprise если кто не понял.

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

E>>Речь не о том, а о том, есть ли GC в С++.
E>>Все, что здесь было рассказано касалось средст обеспечения GC для C++. А это несколько разные вещи.

NBN>Тут надо определиться

Кто-то ратует, за то что раз в STL нет GC — значит его и в С++ нет. Кто-то наоборот

NBN>Практически — есть либы, котрые можно свободно скачать, подключить и писать проекты на С++ управляя памятью только с использованием GC.

ЕМНИП, уже давным давно и Никлаус Вирт, и Бертранд Майер доказали, что сборка мусора должна быть неотъемлимой частью языка. Наличие библиотек, упрощающих управление памятью в C++, не делают из C++ язык с GC.

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

Вскользь упоминались также: сложный для автоматизированной обработки синтаксис, проблемы с использованием в ядрах, недостаток специалистов.

Странно, что обошли вниманием рефлексию (отсутствие таковой). Это игрушка только для БД и сериализации, или нечто намного более серьезное?

Чего еще не хватает в жизни? Например, в C# есть LINQ, насколько это упрощает разработку в сравнении с C++? В Perl есть именованные блоки, которые позволяют аккуратно выпрыгивать из нескольких циклов без впадания в ересь goto — сколько еще времени C++ сможет без них прожить? Встроенное в язык pattern matching — это прорыв или развлечение?

Здравствуйте, Константин Л., Вы писали:

КЛ>А предел с++ в том, что все это нужно прикручивать в том или ином виде, с привлечением специалистов. В языках с gc люди просто садятся и пишут. Уделяют внимание не ликам, а BL. Что из этого иногда получается, не важно. Важно то, что это дешево, надежно и практично (с). .net, java как STL, сначала бери его. Не подходит — рассматриваем другие варианты.

+1

КЛ>Это я про enterprise если кто не понял.

Более того, популярность Perl, Python и Ruby показывает, что это касается не только enterprise.

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

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

R>>Во-первых, он не рассматривает объекты, выделенные с помощью других аллокаторов (malloc, new, VirtualAlloc) — не управляет их временем жизни и не ищет в них указатели. Т.е. выделять надо с помощью специального GC_MALLOC. Т.е. сторонняя библиотека, выделевшая матрицу, отпадает.

E>С помощью чего размещать в памяти объект следующего вида:
E>

E>class my_linked_list_node_t {
E>  private :
E>    // Какие-то данные объекта.
E>    float m_scales[ 1024 ];
E>    // Следующий элемент вектора.
E>    my_linked_list_node_t * m_next;
E>  public :
E>    ...
E>};
E>

Такой объект делать не надо, если ты хочешь дружить с GC.

R>>Естественно, это всё надо знать и учитывать. Ествественно, надо прочитать описание интерфейса и доступные функции, перед тем, как использовать в проекте. И т.д. Но в целом это — работающий GC для C++.

E>С таким количеством оговорок это то же самое, что говорить, что в C++ есть сериализация. Есть библиотеки, предоставляющие подобную функциональность, но это библиотеки, а не часть языка.

E>Так же и внешние по отношению к языку GC -- это всего лишь библиотеки, требующие специального использования.

Я по-крайней мере не гворил, что в С++ есть GC... я говорил, что можно писать на C++ и при этом пользоваться GC.

Надо различать GC как таковой и кол-во усилий необходимое для использования GC.
GC — есть, пользоваться — это другой вопрос.
При прототипировании, наверное, и в Java и в GC+С++, кол-во усилий практически нулевое. Ну в GC+С++ наверное всё-таки чуть больше... в первый раз.
При промышленном использовании, в Java — некое (не будем углубляться), в GC+С++ — некое, но ощутимо большее, чем "некое" в Java.
Если GC будет частью С++, то кол-во усилий при промышленном применении резко снизится. Но bullet-proof оно всё равно не будет в С++. Никто не помешает написать:

int main()
{
  int* p = non_garbage_collected_new int;
}

и возмущаться, почему происходит утечка памяти.
Есть и более серьёзные проблемы — что делать, если указатель на управляемый объект кладётся в неуправляемый объект, или если указатель на управляемый объект отдаётся "во-вне". Ну и там классические примеры с xor'ом указателя. Ну с т.з. языка-то все понятно — объявить все UB

а вот с т.з. программиста — не понятно.
Мне кажется, что именно для С++ вопрос GC часть языка или нет — имеет не такое значение как для Java/C#. Всё равно это будет... С++. Кол-во простреленных конечностей с одного выстрела — не ограничено

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

RO>Чего еще не хватает в жизни?
ИМХО стоит продолжать сотрясать воздух после того как распробуем С++0х.
Мне например не хватает некоторых вещей, которые должны появиться с выходом нового стандарта. Какой смысл их обсасывать сейчас?

RO>В Perl есть именованные блоки, которые позволяют аккуратно выпрыгивать из нескольких циклов без впадания в ересь goto — сколько еще времени C++ сможет без них прожить?
Думаю что долго. Не такая уж это и проблема, да и в нормально структурированном коде встречается ничуть не чаще чем пресловутые циклические ссылки ИМХО

RO>Встроенное в язык pattern matching — это прорыв или развлечение?
Для C++ ИМХО достаточно библиотеки std::regex. Встраивать не обязательно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

CC>Для C++ ИМХО достаточно библиотеки std::regex. Встраивать не обязательно.

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, remark, Вы писали:

КЛ>[]

КЛ>А предел с++ в том, что все это нужно прикручивать в том или ином виде, с привлечением специалистов. В языках с gc люди просто садятся и пишут. Уделяют внимание не ликам, а BL. Что из этого иногда получается, не важно. Важно то, что это дешево, надежно и практично (с). .net, java как STL, сначала бери его. Не подходит — рассматриваем другие варианты.

КЛ>Это я про enterprise если кто не понял.

Для enterprise — да. Но enterprise, мне кажется, на С++ сейчас практически никто и не начинает писать. Если только унаследованный.
С++ программистов держут для чего поинтереснее

А вообще так со всем в С++. Собственно с чего начали — с библиотек. Для С++ даже библиотеку парсинга XML проблема подобрать. То слишком маленькая, то слишком большая, то слишком медленная, то гнутая, то схему именования идентификаторов использует не ту

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

R>Надо различать GC как таковой и кол-во усилий необходимое для использования GC.
R>GC — есть, пользоваться — это другой вопрос.

Имхо, с таким количеством ограничений нельзя считать, что GC есть. Средства для облегчения управлением памятью -- да, но не GC. Иначе понятие GC сильно девальвируется.

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

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

CC>>Для C++ ИМХО достаточно библиотеки std::regex. Встраивать не обязательно.
_>

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1429.htm

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, c-smile, Вы писали:

CS>>Здравствуйте, Константин Л., Вы писали:

КЛ>>>>>а так, что interlockedincrement/decrement не нужен как класс. а сколько они стоят для smp?

CS>>>>А как делать блокировку managed heap при new из разных потоков?

КЛ>>>Это максимум один exchange/increment на выделение.

CS>>Значит таки нужен... идем тогда дальше.

КЛ>почему-то мне кажется, что их нужно горадло меньше

Слово "нужно" тут не релевантно. Назови любое число я тебе сделаю с таким кол-вом.

CS>>Когда тебе мусор собрать надо ты останавливаешь все потоки (stop the world в общем случае).
CS>>В связи с этим возникает вопрос: что лучше много маленьких interlockedincrement/decrement или один но толстый stop-the-world?

КЛ>stop-the-world, тк он наступает только для одного процесса. lock шины аффектит все процессы.

Кстати, lock шины сейчас Intel и AMD уже не делают в большинстве случаев. Обычно всё обходится "локальным" cache-lock'ом.

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

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

CC>>>Для C++ ИМХО достаточно библиотеки std::regex. Встраивать не обязательно.
_>>

CC>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1429.htm

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

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

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

CC>>>>Для C++ ИМХО достаточно библиотеки std::regex. Встраивать не обязательно.
_>>>

CC>>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1429.htm
_>

Если не ошибаюсь, то pattern matching и regular expressions -- это разные вещи.

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

E>ЕМНИП, уже давным давно и Никлаус Вирт, и Бертранд Майер доказали, что сборка мусора должна быть неотъемлимой частью языка. Наличие библиотек, упрощающих управление памятью в C++, не делают из C++ язык с GC.

Есть такое доказательство ? я бы почитал , если бы вы кинулись ссылкой.

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

R>Здравствуйте, Константин Л., Вы писали:

КЛ>>Здравствуйте, remark, Вы писали:

КЛ>>[]

КЛ>>А предел с++ в том, что все это нужно прикручивать в том или ином виде, с привлечением специалистов. В языках с gc люди просто садятся и пишут. Уделяют внимание не ликам, а BL. Что из этого иногда получается, не важно. Важно то, что это дешево, надежно и практично (с). .net, java как STL, сначала бери его. Не подходит — рассматриваем другие варианты.

КЛ>>Это я про enterprise если кто не понял.

R>Для enterprise — да. Но enterprise, мне кажется, на С++ сейчас практически никто и не начинает писать. Если только унаследованный.
R>С++ программистов держут для чего поинтереснее

дело в том, что мы (с++) пытаемся людям, которые пишут enterprise, доказывать, что с++ ничем мне хуже. Все наши холивары — это борьба не-enterprise с++-ников с enterprise девелоперами. А мы еще и удивляемся, что они такие странные.

Более того, с сегодняшним выбором языков/фреймворков с++ даже не-enterpise не достается. Это факт. И не вижу причин для вопросов "а почему?". Да потому, что 90% задач еффективность с++ нужна меньше, чем простота и надежность не-с++.

R>А вообще так со всем в С++. Собственно с чего начали — с библиотек. Для С++ даже библиотеку парсинга XML проблема подобрать. То слишком маленькая, то слишком большая, то слишком медленная, то гнутая, то схему именования идентификаторов использует не ту

странно то, что с таким зоопарком фришных библиотек в жабе они почему-то умудряются подобрать

R>

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

E>>ЕМНИП, уже давным давно и Никлаус Вирт, и Бертранд Майер доказали, что сборка мусора должна быть неотъемлимой частью языка. Наличие библиотек, упрощающих управление памятью в C++, не делают из C++ язык с GC.

M>Есть такое доказательство ? я бы почитал , если бы вы кинулись ссылкой.

У меня бумажное издание книги "Объектно-ориентированное конструирование программных систем", издательско-торговый дом "Русская редакция", 2005г, 1232 стр. Там глава 9 (стр. 277) посвящена вопросам управления памятью. И объяснению причин, по которым нельзя получать это дело программисту в компонентной среде.

Аналогичная работа была у Вирта, но вот где именно я не могу вспомнить. Может быть сам читал, может быть слышал от оберонщиков: мол Вирт считал сборку мусора в Оберон обязательным условием для языка, поддерживающего компонентное программирование.

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

R>Здравствуйте, Константин Л., Вы писали:

КЛ>>Здравствуйте, c-smile, Вы писали:

CS>>>Здравствуйте, Константин Л., Вы писали:

КЛ>>>>>>а так, что interlockedincrement/decrement не нужен как класс. а сколько они стоят для smp?

CS>>>>>А как делать блокировку managed heap при new из разных потоков?

КЛ>>>>Это максимум один exchange/increment на выделение.

CS>>>Значит таки нужен... идем тогда дальше.

КЛ>>почему-то мне кажется, что их нужно горадло меньше

R>Слово "нужно" тут не релевантно. Назови любое число я тебе сделаю с таким кол-вом.

ну что за детсад? предположим, что для аллокации упр. объекта нам нужен один interlocked. Для аллокации неупр. объекта нам нужен как минимум один
interlocked (это с учетом того, что нужно для этого прикрутить какой-нить dmalloc, и то я тут не спец по поводу того, можно ли в этом случае обойтись одним atomic*), плюс энное количество вплоть до его смерти.

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

CS>>>Когда тебе мусор собрать надо ты останавливаешь все потоки (stop the world в общем случае).
CS>>>В связи с этим возникает вопрос: что лучше много маленьких interlockedincrement/decrement или один но толстый stop-the-world?

КЛ>>stop-the-world, тк он наступает только для одного процесса. lock шины аффектит все процессы.

R>Кстати, lock шины сейчас Intel и AMD уже не делают в большинстве случаев. Обычно всё обходится "локальным" cache-lock'ом.

Не делают? В большинстве? Отлично. Одной серьезной проблемой меньше. Теперь объясни, что такое "локальный" cache-lock

R>

RO>Вскользь упоминались также: сложный для автоматизированной обработки синтаксис, проблемы с использованием в ядрах, недостаток специалистов.

RO>Странно, что обошли вниманием рефлексию (отсутствие таковой). Это игрушка только для БД и сериализации, или нечто намного более серьезное?

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

RO>Чего еще не хватает в жизни? Например, в C# есть LINQ, насколько это упрощает разработку в сравнении с C++? В Perl есть именованные блоки, которые позволяют аккуратно выпрыгивать из нескольких циклов без впадания в ересь goto — сколько еще времени C++ сможет без них прожить? Встроенное в язык pattern matching — это прорыв или развлечение?

лямбды, замыкания.

Основная проблема с++ — толщина стандарта, и кол-во костылей в нем. Из-за чего это мне рассказывать не нужно, и так знаю.

Модель компиляции достала. И ее время.

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

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

[]

RO>>Встроенное в язык pattern matching — это прорыв или развлечение?
CC>Для C++ ИМХО достаточно библиотеки std::regex. Встраивать не обязательно.

SI>Вот, к примеру, память в ядре линукса экономится настолько сильно, что нужно помечать инициализирующую функцию и данные для инициализации в модуле ядра специальными ключами (__init/__initdata вроде), которые помещаются линкером в специальную секцию ELF файла, которая будет удалена после инициализации модуля ядром.

Windows поступает аналогично — секция INIT имеет атрибут discardable, позволяющей системе удалить и использовать память занятую этой секцией после инициализации драйвера. Кроме того, разработчик может ( сами MS цы так делают местами ) управлять размещением кода в свопируемые и несвопируемые секции, уменьшая тем самым требования к "дорогой" невытесняемой памяти. Тут кстати, есть один из подводных камней: если используются полиформные классы — не очень понятно, как управлять положением vtbl, а то может ( чисто принципиально ) получиться нехорошесть — экземпляр класса находиться в NonPaged памяти, а vtbl в Paged с возможными плачевными последствиями. Я лично когда юзал С++ ( сейчас отказался от этого ) в ядре писал __declspec(novtable) — чтобы даже руки не чесались

Здравствуйте, Константин Л., Вы писали:

КЛ>>>>>Это максимум один exchange/increment на выделение.

CS>>>>Значит таки нужен... идем тогда дальше.

КЛ>>>почему-то мне кажется, что их нужно горадло меньше

R>>Слово "нужно" тут не релевантно. Назови любое число я тебе сделаю с таким кол-вом.

КЛ>ну что за детсад? предположим, что для аллокации упр. объекта нам нужен один interlocked. Для аллокации неупр. объекта нам нужен как минимум один
КЛ>interlocked (это с учетом того, что нужно для этого прикрутить какой-нить dmalloc, и то я тут не спец по поводу того, можно ли в этом случае обойтись одним atomic*), плюс энное количество вплоть до его смерти.

КЛ>все это имеет значение, только если нам действительно нужны atomic* для подсчета ссылок. если не нужны — тогда можно считать что и оверхеда нет.

Здесь и как делать управление памятью без interlocked и как делать управление временем жизни без interlocked:
http://gzip.rsdn.ru/forum/message/2975820.1.aspx

CS>>>>Когда тебе мусор собрать надо ты останавливаешь все потоки (stop the world в общем случае).
CS>>>>В связи с этим возникает вопрос: что лучше много маленьких interlockedincrement/decrement или один но толстый stop-the-world?

КЛ>>>stop-the-world, тк он наступает только для одного процесса. lock шины аффектит все процессы.

R>>Кстати, lock шины сейчас Intel и AMD уже не делают в большинстве случаев. Обычно всё обходится "локальным" cache-lock'ом.

КЛ>Не делают? В большинстве? Отлично. Одной серьезной проблемой меньше. Теперь объясни, что такое "локальный" cache-lock

Если коротко: если кэш-линия, для которой надо сделать interlocked, находится в кэше процессора в статусе modified, то она локально помечается как залоченная и никому не "отдаётся" до окончания операции.

R>>

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

J>Я навскидку вижу такие больших проблемы, не решаемых библиотеками:
J>1. Отсутствие GC. На С++ крайне сложно писать прототипы

А зачем тебе в прототипе вообще память освобождать?

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

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

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

E>Если не ошибаюсь, то pattern matching и regular expressions -- это разные вещи.
regex это частный случай pattern matching для строк
в общем случае да — разные. Тут я что то протупил

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

J>>Я навскидку вижу такие больших проблемы, не решаемых библиотеками:
J>>1. Отсутствие GC. На С++ крайне сложно писать прототипы

R>А зачем тебе в прототипе вообще память освобождать?

Тоже верно

Но на скриптах (питоне каком-нть) все равно быстрее, согласись, даже если ты на С++ забьешь на память.

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

R>А так — выделяй по new и не освобождай. Я даже помнится утилиту какую-то рабочую делал таким образом (не прототип) — она просто отъедала максимум пару мегабайт, делала свою работу и выходила. Чем не быстрая разработка.

Ну тоже верно, хоть и неудобно все время new тыркать

Просто на С++ я сервера пишу обычно долгоиграющие, а утилиты — на перле, по привычке

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

RO>Итак, единственным обсуждаемым недостатком C++ оказалось отсутствие GC, которая решает несуществующую проблему циклических ссылок, важную для быстрой разработки прототипов.

RO>Вскользь упоминались также: сложный для автоматизированной обработки синтаксис, проблемы с использованием в ядрах, недостаток специалистов.

А как же синтаксический оверхед?!

RO>Странно, что обошли вниманием рефлексию (отсутствие таковой). Это игрушка только для БД и сериализации, или нечто намного более серьезное?
RO>Чего еще не хватает в жизни?

Нормального языка времени компиляции с доступом ко всей (вообще ко всей) информации, которой располагает компилятор относительно программы — АСТ, типы, имена, члены, модификаторы и т.д. и т.п. Короче, всё. Вот тогда можно будет и LINQ, и вообще все, что хочешь.

А, еще нормальные макросы типа немерлевских — тоже очень бы в тему пошли. ПОтому что те убогие, которые мы имеем сейчас — на них смотреть больно, а писать на них — еще больнее.

Но это все — не killer-фичи. Хотя сегмент БД недооценивать нельзя.

RO>Например, в C# есть LINQ, насколько это упрощает разработку в сравнении с C++?
Наверняка упрощает, судя по крикам апологетов в соответствующих форумах.

RO>В Perl есть именованные блоки, которые позволяют аккуратно выпрыгивать из нескольких циклов без впадания в ересь goto — сколько еще времени C++ сможет без них прожить?
Имхо, ересь goto в данном случае сильно преувеличена

Хотя в перле, конечно, удобно.

RO> Встроенное в язык pattern matching — это прорыв или развлечение?
Я не уверен, что его можно хорошо реализовать в рамках С++.
Хотя ПМ по типам уже есть, в шаблонах.

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

J>Но на скриптах (питоне каком-нть) все равно быстрее, согласись, даже если ты на С++ забьешь на память.

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

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

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

J>>Так VA видит шаблоны и операторы или нет?
CC>Шаблоны он понимает. Мне правда не сильно понятно что именно тебе надо чтобы он понимал в шаблонах?
CC>Где используется например конкретный operator+ -- искать отказывается.

а где проинстанцируется конкретная шаблонная функция (а особенно — конкретная специализация) — показывает?

Отсутсвие метаданных во времени компиляции

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

Убогие макросы

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

Недоступность стандартных фич во всех компиляторах.
Например: мистический эскпорт шаблоннов, throw specification.
И вообще всякие баги в стандарте

Нет нормальных макросов.
Да и вообще проблемы с макросами постоянные.
Вот кто-то решил в MS SDK, что ANY_SIZE хорошее название для макроса, а другой решил, что это хорошее название для константы, иди пойми в чем ошибка

Медленная скорость компиляции.

Несовместимость меджу компиляторами.
Каджый компилятор добавляет свои специфичиские фичи для удобства.
Было бы очень хорошо если бы каждый мог делать те же самые дополнительные функции, с синтаксисом уже можно разобраться как-нибудь.

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

На пой взгляд это все исходит из того, что С++ позиционируется как язык для всех платформ в отличии от других языков.
Может пора прекратить это дело.
Все равно не на все embedded есть С++, да и процессоров с размером int в 36 бит мало встречается.

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

SI>Ко всему прочему стоит заметить, что, видимо, написание аналогичного кода на С++ потребует большей подготовки и большей квалификации девелопера.

Потому, что С можно изучить за 2 дня, а С++ "несколько" дольше? Значит, для библиотечного кода — да, для пользовательсокго кода — наоборот. Как минимум, квалификация С кодера должна быть таковой, что он не имеет права забыть освободить любой ресурс. Тоже самое делает RAII...

SI>Элементарно простой пример: std::map (а так же, например, стандартнуя реализация AVL tree) нельзя (ну или скажем, неблагоразумно) использовать в коде ядра. Насчет Windows не уверен, но в Linux'е точно.

В чём проблема то, в памяти? Это обычный trade-off — стоит или нет, решает пользователь. Или у Линуса не получилось в 92м году? Тут есть один нюанс — подобный биржевым медведю и быку — мнение может быть не объективно.

SI>Вот, к примеру, память в ядре линукса экономится настолько сильно, что нужно помечать инициализирующую функцию и данные для инициализации в модуле ядра специальными ключами (__init/__initdata вроде), которые помещаются линкером в специальную секцию ELF файла, которая будет удалена после инициализации модуля ядром.

В виндосе так же, плюс еще разделение на (non)pageable секции. Это, кстати единственное непреодолимое ограничение для С++ — нельзя сделать для функций с C++ linkage. Можно конечно делать обходные манёвры с обертками на С... Но, как правило, забивают, если пишут на "С с классами". Вообще, непоняно, почему еще не доработан транслятор

SI>Нет, ну почему же нету, есть, только по стандарту ISO C89 (если не изменяет память). Нету <stdbool.h> и иже с ним, возможности объявлять переменные не только в начале функции и ряда других вещей.

Угу, чего только нет: этого нет, того нет

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

J>Логика простая, если вспомнить, о чем мы говорим. А именно: из-за отсутствия GC　использоваться С++ для быстрой разработки и прототипирования проблематично.
J>Не надо мой тезис превращать в "С++ отстой, так как нет GC".

1) Странно, вроде как получалось прототипы писать на M$ конструкции. Вроде проблем не возникало особых...
2) Нужность GC тоже обсуждаемая вещь, хотя это уже очень от методологии разработки зависит...

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

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

IMHO всё так, но в целом "трудно только в первый раз"...

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

J>Просто на С++ я сервера пишу обычно долгоиграющие, а утилиты — на перле, по привычке

Можно придерживаться такой же стратегии на запрос, а потом грохать аллокатор...

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

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

J>>Логика простая, если вспомнить, о чем мы говорим. А именно: из-за отсутствия GC　использоваться С++ для быстрой разработки и прототипирования проблематично.
J>>Не надо мой тезис превращать в "С++ отстой, так как нет GC".

E>1) Странно, вроде как получалось прототипы писать на M$ конструкции. Вроде проблем не возникало особых...
Ну что я могу сказать... Только позавидовать!

У меня быстро не получается, все время натыкаешься на что-то, чему надо уделять повышенное внимание, причем это "что-то" в твои планы не входило.

E>2) Нужность GC тоже обсуждаемая вещь, хотя это уже очень от методологии разработки зависит...
Просто при прототипировании хочется как можно меньше думать о посторонних вещах и как можно меньше уделять им внимание.
Лучше всего, когда их нет вовсе.
И управление владением к этим посторонним вещам и относится, пока ты не начнешь прототипировать собственно их, да и то на только последних этапах.

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

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

J>>Но на скриптах (питоне каком-нть) все равно быстрее, согласись, даже если ты на С++ забьешь на память.

NBN>Смотря в каких ситуациях. В последних прототипах которые я делал — важной частью были разные алгоритмы, на отладку которых я потратил большую часть времени. В тех случаях было глубоко без разницы на каком языке писать.
Так в том-то и дело, что хочется все доступное время посвятить алгоритмам, а не борьбе с различными граблями.
А в С++ у меня так не получается, хотя я, вроде, и не могу пожаловаться, что не знаю С++.
Постоянно на что-то напарываешься, и чаще всего, по моему опыту, это время жизни объекта.

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

С++ очень хорош, когда хорошо представляешь себе то, что собираешься написать — он предоставляет очень много ручек тонкой настройки.
А когда не очень и многократно переделываешь по ходу дела — все эти торчащие ручки управления (и упомянутый корявый синтаксис, который не позволяет создать хорошие инструменты для рефакторинга) только мешают.

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

J>>>кроме pi — он должен оставаться обычным голым указателем.
E>>А почему?

J>Потому что я сомневался именно в том, что GC может отследить голые указатели.
J>Особенно которые void* (сишных интерфейсов пока никто не отменял)

Как раз голые указатели консервативный GC (например Boehm GC) отслеживает без проблем http://www.digitalmars.com/d/2.0/garbage.html он не любит только фокусы с совпадениями. Прикрутить и использовать такой GC к C++ несложно, я в небольших проектах использовал.

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

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

J>>>>кроме pi — он должен оставаться обычным голым указателем.
E>>>А почему?

J>>Потому что я сомневался именно в том, что GC может отследить голые указатели.
J>>Особенно которые void* (сишных интерфейсов пока никто не отменял)

FR>Как раз голые указатели консервативный GC (например Boehm GC) отслеживает без проблем http://www.digitalmars.com/d/2.0/garbage.html он не любит только фокусы с совпадениями. Прикрутить и использовать такой GC к C++ несложно, я в небольших проектах использовал.

Он указатели внутрь управляемых объектов видит (как в моем примере)?
Я такого не нашел на странице, которую ты указал.

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

J>Он указатели внутрь управляемых объектов видит (как в моем примере)?
J>Я такого не нашел на странице, которую ты указал.

Видит, он помнит все выделенные интервалы. Вот пример на D:

import std.stdio;
import std.gc;

struct S
{
  int i;
};

int* f()
{
  S *s = new S;
  //s = null;  
  return &s.i;
}

void main()
{
int* pi = f();
fullCollect();

*pi = 123;
writefln(*pi);
}

отрабатывает нормально, если раскомментировать //s = null; будет Access Violation

E>В языке D использовался консервативный GC, который считал указателями все, что было похоже на указатели. После чего пользователи стали жаловаться на неправильную работу программ, обрабатывающих большие массивы вещественных данных -- определенные значения float-ов и double-ов воспринимались таким GC как указатели и соответствующим образом обрабатывались. После чего в D были добавлены специальные функции, позволяющие пометить область памяти как гарантированно не содержащую указателей.

Так в Boehm GC они изначально были, D шный же на нем основан.

E>Аналогичные проблемы могут возникнуть при использовании криптографии -- фрагменты криптоключей, криптотекста и подписей/хешей могут быть очень похожы на указатели, что снесет башку консервативному GC.

E>Согласись, что GC, в котором нужно явно указавать характер данных в определенных областях памяти, не сильно похож на GC из C#/Java.

Но это лучше чем ничего, а для C++ мелочью больше — меньше значения не имеет

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

E>Проблема в том, что разработчик, выделяя буфер для шифрования или массив для перемножения матриц, даже не будет задумываться о том, что это может повлиять на GC.

Он должен знать как функционируют такие GC. Если не знает то не должен использовать.

E>А другая сторона медали в том, что я могу написать библиотеку, использующую внутри вещественную арифметику. А кто-то возьмется ее использовать совместно с консервативным GC даже не зная, что у меня внутри матрицы перемножаются. И временами у его программы будет крышу яносить, а найти причины этому вообще вряд ли удастся.

Ничего у его программмы не снесет, просто будут утечки памяти.

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

E>>1) Странно, вроде как получалось прототипы писать на M$ конструкции. Вроде проблем не возникало особых...
J>Ну что я могу сказать... Только позавидовать!

J>У меня быстро не получается, все время натыкаешься на что-то, чему надо уделять повышенное внимание, причем это "что-то" в твои планы не входило.
Ну, видимо, ты слишком фиксируешься на эффективности прототипа

E>>2) Нужность GC тоже обсуждаемая вещь, хотя это уже очень от методологии разработки зависит...
J>Просто при прототипировании хочется как можно меньше думать о посторонних вещах и как можно меньше уделять им внимание.
J>Лучше всего, когда их нет вовсе.
J>И управление владением к этим посторонним вещам и относится, пока ты не начнешь прототипировать собственно их, да и то на только последних этапах.

Ну "нет вовсе" всё равно иллюзия. С GC пофиг на владение маленькими объектами, зато очень всё плохо при наличии больших (скажем по 100 метров). В коде о управлении их существованием вообще никто не думает, а память на таких масштабах всё-таки не резиновая...

Всё от задач и методологии зависит...

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

E>Имхо, с таким количеством ограничений нельзя считать, что GC есть. Средства для облегчения управлением памятью -- да, но не GC. Иначе понятие GC сильно девальвируется.

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

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

Здесь согласен.

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

J>Постоянно на что-то напарываешься, и чаще всего, по моему опыту, это время жизни объекта.
IMHO ты пишешь на C++ слишком сложно. Это конечно может быть хорошо в финальном коде, но совсем не нужно в прототипах. Попробуй как-то ограничить себя по сложности кода, скажем boost не использовать (кроме ptr), например...

J>С++ очень хорош, когда хорошо представляешь себе то, что собираешься написать — он предоставляет очень много ручек тонкой настройки.
J>А когда не очень и многократно переделываешь по ходу дела — все эти торчащие ручки управления (и упомянутый корявый синтаксис, который не позволяет создать хорошие инструменты для рефакторинга) только мешают.

Дык это просто культура программирования в этом направлении плохая. Ты не можешь почему-то управлять степениь проработанности своего кода с точки зрения подробностей реализации. Правда я согласен, что STL этому, как ни странно, не способствует, вынуждая программиста учитывать слимшком мелкие подробности реализации в очень абстрактном коде, ну да STL-way не догма на самом деле...
Если у тебя проблема с владением в С++, ну просто реализуй себе умный указатель простой какой-ниубдь интрузивный, и в прототипах всегда владей через него. И будет тебе таки счастье. Ну, на крайняк будут иногда циклические ссылки => будет течь в прототипе память. Ну и что?

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

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

E>>>1) Странно, вроде как получалось прототипы писать на M$ конструкции. Вроде проблем не возникало особых...
J>>Ну что я могу сказать... Только позавидовать!

J>>У меня быстро не получается, все время натыкаешься на что-то, чему надо уделять повышенное внимание, причем это "что-то" в твои планы не входило.
E>Ну, видимо, ты слишком фиксируешься на эффективности прототипа

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

E>>>2) Нужность GC тоже обсуждаемая вещь, хотя это уже очень от методологии разработки зависит...
J>>Просто при прототипировании хочется как можно меньше думать о посторонних вещах и как можно меньше уделять им внимание.
J>>Лучше всего, когда их нет вовсе.
J>>И управление владением к этим посторонним вещам и относится, пока ты не начнешь прототипировать собственно их, да и то на только последних этапах.

E>Ну "нет вовсе" всё равно иллюзия. С GC пофиг на владение маленькими объектами, зато очень всё плохо при наличии больших (скажем по 100 метров). В коде о управлении их существованием вообще никто не думает, а память на таких масштабах всё-таки не резиновая...

E>Всё от задач и методологии зависит...
Ну да, и я про то же (про задачи, в смысле)

А про "нет вовсе" — даже если ты используешь умные указатели, все равно тебе придется многократно писать shared_ptr<...> и прочая, везде ходить по указателям и т.д.
Неудобно, путается под ногами и мешает сконцентрироваться на деле.

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

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

J>>Он указатели внутрь управляемых объектов видит (как в моем примере)?
J>>Я такого не нашел на странице, которую ты указал.

FR>Видит, он помнит все выделенные интервалы. Вот пример на D:

Наконец-то ответ по делу

А в С++ он такое тоже сможет?
Или для этого требуется внешняя поддержка (может, Д регистрирует там где-нть все созданные указатели).

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

J>А в С++ он такое тоже сможет?
J>Или для этого требуется внешняя поддержка (может, Д регистрирует там где-нть все созданные указатели).

Может, в D все усовершенствование ограничиваются ускорением работы за счет знаний о типах.

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

E>>Ну, видимо, ты слишком фиксируешься на эффективности прототипа

J>ну, оценки сложности алгоритмов ведь надо на этапе прототипирования делать, не согласен?
1) При чём тут вообще управление памятью, включая GC?
2) Зачем для оценки сложности алгоритмов вообще какой-то язык программирования?

J>А про "нет вовсе" — даже если ты используешь умные указатели, все равно тебе придется многократно писать shared_ptr<...> и прочая, везде ходить по указателям и т.д.
Ну всегда -> -- доступ к аттрибуту + указатель зовёшь Ptr<xxx> и счастье...
На всяк случай: Про то, что STL + boost враги краткости и простоты кода я не спорю

J>Неудобно, путается под ногами и мешает сконцентрироваться на деле.
Ну, IMHO, это всё равно, что сказать: "Ну не умею я быстро на С++ кодировать, а на Жабе умею"...
Мне кажется, что это персонально твои навыки и склонности всего лишь.

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

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

E>>>Ну, видимо, ты слишком фиксируешься на эффективности прототипа

J>>ну, оценки сложности алгоритмов ведь надо на этапе прототипирования делать, не согласен?
E>1) При чём тут вообще управление памятью, включая GC?
E>2) Зачем для оценки сложности алгоритмов вообще какой-то язык программирования?
Потому что бывает, что алгоритм вырисовывается на этапе прототипирования, а для прототипирования нужен какой-то язык программирования.
И структура данных тоже не сразу ясна, потому что вдруг оказывается, что то, что ты спрятал вот сюда, нужно еще и вот здесь, и приходится все переделывать, и вот это хотелось бы делать легко и быстро.

Но это не эффективность прототипа, конечно

J>>А про "нет вовсе" — даже если ты используешь умные указатели, все равно тебе придется многократно писать shared_ptr<...> и прочая, везде ходить по указателям и т.д.
E>Ну всегда -> -- доступ к аттрибуту + указатель зовёшь Ptr<xxx> и счастье...
ну да, и везде чтоб только они и летали, и не дай бог ссылку передать, и чтоб атрибуты сами тоже указателями были и, соответственно, конструкторы из гроздьев new состояли + конструкторы копирования и операторы присваивания везде придется руками организовывать, чтоб было глубокое копирование, потому что те, что по умолчанию генерятся, никак с смарт-поинтерами не дружат, и так далее...
Можно, конечно, не спорю, только на поддержку быстрой разработки это, имхо, слабо тянет.

E>На всяк случай: Про то, что STL + boost враги краткости и простоты кода я не спорю
При чем тут буст с стлем.
Все проблемы, которые я тут озвучивал, возникают до буста/стля.

А насчет работы с контейнерами — имхо, те же самые проблемы, если не хуже, будут с ручными циклами: попробуй тут заменить вектор на список, скажем.
буст в этом смысле как раз очень хорош, особенно BOOST_FOREACH — ему вообще на тип контейнера начихать, лишь бы был стл-совместимый.

J>>Неудобно, путается под ногами и мешает сконцентрироваться на деле.
E>Ну, IMHO, это всё равно, что сказать: "Ну не умею я быстро на С++ кодировать, а на Жабе умею"...

Да, можно и так сказать, только не о жабе (в ней я особого ускорения не видел, но я ее бросил юзать до того, как появились умные IDE), а о скриптовых языках.
Потому что в плюсах чтоб просто, например, распечатать нечто (в прототипах печатать много приходится, не все ж под дебаггером запускать), надо присесть двадцать раз, а в скрипты все это встроено сразу (помнишь такой чудо-синтаксис: "asd $qwe zxc $qweqweqwe"?)

E>Мне кажется, что это персонально твои навыки и склонности всего лишь.
Они, конечно, тоже есть, но нельзя и отрицать того, что определенные языки (типа перла, скажем) объективно специально заточены под то, чтоб определенные задачи решались минимальным количеством нажатий и мозговых усилий.
Чего о С++ не скажешь, сила С++ совсем в другом: возможность сваять что угодно любой сложности, а вот цена ваяния — дело десятое.

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

RO>Итак, единственным обсуждаемым недостатком C++ оказалось отсутствие GC
из обсуждений касаемо GC мне понравилось вот это.

RO>Странно, что обошли вниманием рефлексию (отсутствие таковой). Это игрушка только для БД и сериализации, или нечто намного более серьезное?

Это ОЧЕНЬ богатая удобная вещь. Имхо, вещь много ценнее GC.
На РСДНе же был очень вдохновенный пост на эту тему:

...
Начнём хотя бы с того, что ты слабо себе представляешь что такое рефлекшин. Рефлекшин — это такая штука, Рома, которая предоставляет исчерпывающую метадату о твоём приложении. С помощью рефлекшина ты можешь исследовать структуру любого типа, любой сборки вдоль и поперёк. IDispatch & ITypeInfo со своими возможностями рядом даже близко никогда не стояли. Добавим сюда возможность расширять метаданные с помощью атрибутов и, в результате, имеем ещё одно дополниетельное измерение. Как им распорядиться это уже дело твоей фантазии. Например, студия умеет распознавать и использовать твои собственные редакторы для твоих же объектов. Веб-сервисы используют атрибуты для отделения веб-методов от остальных процедур, для управления параметрими сессии и куками и т.п. Сериализаторы полностью настраиваются с помощью атрибутов. Защита, управление компиляцией и отладкой, всё это может свободно управляться с помощью атрибутов.

В числе прочего атрибуты(часть рефлекшена) кажутся очень неплохим нововведениям.
Вот маленький пример:

    public class FooModel
        : BaseModel
    {
        [XmlElementAttribute(ElementName = "h")]
        [DisplayName("Height")]
        [Description("Height of the Foo Model")]
        [Category("Model's Geometry")]
        public int Height
        { get/set... }

        [XmlElementAttribute(ElementName = "w")]
        [DisplayName("Width")]
        [Description("Width of the Foo Model")]
        [Category("Model's Geometry")]
        public int Width
        { get/set... }

        [XmlElementAttribute(ElementName = "name")]
        [DisplayName("Name")]
        [Description("Name of the Foo Model")]
        [Category("General")]
        public string Name
        { get/set... }
    }

Что это дают эти атрибуты? Если вкратце — настраиваемую сериализацию, возможность истинного отделения представления от модели (т.е. крайне легкое написание визуального компонента редактирования/отображения основываясь только на концепции атрибутов).

В качестве маленького примера — для того, чтобы показать наш объект на стандартном компоненте — страницах свойств (PropertyGrid) достаточно выполнить только одно присвоение объекта свойству SelectedObject:

mPropertyGridObject.SelectedObject = mFooModel;

Этим, конечно же, не исчерпывается возможности сериализации

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

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

SI>>Ко всему прочему стоит заметить, что, видимо, написание аналогичного кода на С++ потребует большей подготовки и большей квалификации девелопера.

GN>Потому, что С можно изучить за 2 дня, а С++ "несколько" дольше? Значит, для библиотечного кода — да, для пользовательсокго кода — наоборот. Как минимум, квалификация С кодера должна быть таковой, что он не имеет права забыть освободить любой ресурс. Тоже самое делает RAII...

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

SI>>Элементарно простой пример: std::map (а так же, например, стандартнуя реализация AVL tree) нельзя (ну или скажем, неблагоразумно) использовать в коде ядра. Насчет Windows не уверен, но в Linux'е точно.

GN>В чём проблема то, в памяти? Это обычный trade-off — стоит или нет, решает пользователь. Или у Линуса не получилось в 92м году? Тут есть один нюанс — подобный биржевым медведю и быку — мнение может быть не объективно.

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

SI>>Вот, к примеру, память в ядре линукса экономится настолько сильно, что нужно помечать инициализирующую функцию и данные для инициализации в модуле ядра специальными ключами (__init/__initdata вроде), которые помещаются линкером в специальную секцию ELF файла, которая будет удалена после инициализации модуля ядром.

GN>В виндосе так же, плюс еще разделение на (non)pageable секции. Это, кстати единственное непреодолимое ограничение для С++ — нельзя сделать для функций с C++ linkage. Можно конечно делать обходные манёвры с обертками на С... Но, как правило, забивают, если пишут на "С с классами". Вообще, непоняно, почему еще не доработан транслятор

SI>>Нет, ну почему же нету, есть, только по стандарту ISO C89 (если не изменяет память). Нету <stdbool.h> и иже с ним, возможности объявлять переменные не только в начале функции и ряда других вещей.

GN>Угу, чего только нет: этого нет, того нет

... а то, что есть — бажное и недоделанное

Вот меня бесит, почему в стандарт не включили #pragma once? Это мелочь конечно, но нафига каждый раз изобретать новый макрос?

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

SI>В размере стека в ядре. В линуксе, как правило, он совсем небольшой — вроде всего одна страница — 4096 байт. В то же время указанные вещи (RB и AVL деревья) используют (во многих реализациях) рекурсивные алгоритмы вставки и удаления.
Сколько деревьев видел/писал — ни в одном при insert/erase не была использована рекурсия. Да и не нужна она там.
Единственное применение рекурсии там могу придумать только когда надо грохнуть все дерево/ветку. Но даже в этом случае можно обойтись без рекурсии.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

TC>Тут кстати, есть один из подводных камней: если используются полиформные классы — не очень понятно, как управлять положением vtbl, а то может ( чисто принципиально ) получиться нехорошесть — экземпляр класса находиться в NonPaged памяти, а vtbl в Paged с возможными плачевными последствиями.

По умолчанию, весь код идет в невыгружаемые секции PE. То есть, нужно специально написать свободные функции, поместить их в выгружаемые секции и вызывать их из функций-членов, что бы споткнуться?

TC> Я лично когда юзал С++ ( сейчас отказался от этого )

Почему, если не секрет?

TC>в ядре писал __declspec(novtable) — чтобы даже руки не чесались

.

Впринципе можно в (дебажном) operator new поверить, в какой секции VTbl. Где-то может и static_assert(std::is_polymorphic<T>) ( __is_polymorphic(T) ) пригодиться...

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

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

Я именнно это и имел ввиду, упоминая "библиотечный код". Там — да. Но порог вхождения (и, как следствие, общая стоимость разработки) понижается, поскольку пользователи этой библиотеки в определённых случаях могут вообще ничего не понимать в ядре. Им достаточно знать С++ (а стало быть и стандартную библиотеку).

SI>В размере стека в ядре. В линуксе, как правило, он совсем небольшой — вроде всего одна страница — 4096 байт. В то же время указанные вещи (RB и AVL деревья) используют (во многих реализациях) рекурсивные алгоритмы вставки и удаления.

Даже в общем случае: стек для рекурсии — это не обязательно стек процессора. Например, рекурсия, реализованная через for() не его использует

SI>Вот меня бесит, почему в стандарт не включили #pragma once? Это мелочь конечно, но нафига каждый раз изобретать новый макрос?

Что бы можно было этот макрос проверить в других файлах

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

RO>>Странно, что обошли вниманием рефлексию (отсутствие таковой). Это игрушка только для БД и сериализации, или нечто намного более серьезное?

SI>Это ОЧЕНЬ богатая удобная вещь. Имхо, вещь много ценнее GC.
SI>В числе прочего атрибуты(часть рефлекшена) кажутся очень неплохим нововведениям.
SI> [XmlElementAttribute(ElementName = "h")]
SI> [DisplayName("Height")]
SI> [Description("Height of the Foo Model")]
SI> [Category("Model's Geometry")]
SI> public int Height
SI> { get/set... }

Я видел такое и раньше. Меня всё время смущало, что будет, если нужно отображать один и тот же класс в разных элементах управления, или если его нужно уметь класть в файлы разной структуры (разные XML, или что-нибудь вроде CSV, или S-выражения и т. п.)? Или просто перевести Description и Category на другой язык?

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

J>Но это не эффективность прототипа, конечно

Вот и я про то же

J>ну да, и везде чтоб только они и летали, и не дай бог ссылку передать, и чтоб атрибуты сами тоже указателями были и, соответственно, конструкторы из гроздьев new состояли + конструкторы копирования и операторы присваивания везде придется руками организовывать, чтоб было глубокое копирование, потому что те, что по умолчанию генерятся, никак с смарт-поинтерами не дружат, и так далее...
А ты напиши себе удобный смарт-поинтер. И будет тебе тут же счастье, IMHO...

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

J>Потому что в плюсах чтоб просто, например, распечатать нечто (в прототипах печатать много приходится, не все ж под дебаггером запускать), надо присесть двадцать раз, а в скрипты все это встроено сразу (помнишь такой чудо-синтаксис: "asd $qwe zxc $qweqweqwe"?)
Да в плюсах тоже вроде бы печатать всё удобно... Ещё и формат задавать просто.
Правда я в прототипах и эксперементах никогда не печатаю, так вот просто. Обычно пишется довольно сложно устроенный "деревянный" лог, к которому есть вьюшка, которая поддерживает небанальную по себе навигацию, и нетривиальные отображалки. IMHO очень удобно, кстати...
Если уж у тебя задача прототипирования стоит во весь рост, то возьми какой-нибудь тулкит для этого, или сам напиши. Вот это и будет С++-way...

J>Чего о С++ не скажешь, сила С++ совсем в другом: возможность сваять что угодно любой сложности, а вот цена ваяния — дело десятое.
Ну если тебе надо решать задачи, под которые заточен пёрл, то не вопрос, С++ тебе не нужен конечно. Но GC тут не при чём, при этом.
А вот если тебе нужно решать какие-то сложные задачи, да ещё и сложную архитектуру к этому привинтить, то пёрл тебе точно не подходит. Я бы ещё понял прототипирование на прологе или лиспе, скажем, но на пёле --

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

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

RO>>>Странно, что обошли вниманием рефлексию (отсутствие таковой). Это игрушка только для БД и сериализации, или нечто намного более серьезное?

SI>>Это ОЧЕНЬ богатая удобная вещь. Имхо, вещь много ценнее GC.
SI>>В числе прочего атрибуты(часть рефлекшена) кажутся очень неплохим нововведениям.
SI>> [XmlElementAttribute(ElementName = "h")]
SI>> [DisplayName("Height")]
SI>> [Description("Height of the Foo Model")]
SI>> [Category("Model's Geometry")]
SI>> public int Height
SI>> { get/set... }

RO>Я видел такое и раньше. Меня всё время смущало, что будет, если нужно отображать один и тот же класс в разных элементах управления, или если его нужно уметь класть в файлы разной структуры (разные XML, или что-нибудь вроде CSV, или S-выражения и т. п.)? Или просто перевести Description и Category на другой язык?

Справедливый вопрос.
Ну вот более подробный пример (здесь вместо сериализации я представил вывод полей некоего объекта на экран):

// FooModel.cs

using System;
using System.ComponentModel;

namespace CsReflectionTest
{
    class FooModel
    {
        int width;
        int height;
        string name;


        // assign specific display name attribute to the FooModel.Width prop.
        // instead of DisplayName other Attribute's descendant can be used.
        [DisplayName("SuperMegaWidthOfFoo")]
        public int Width
        {
            get { return width; }
            set { width = value; }
        }

        public int Height
        {
            get { return height; }
            set { height = value; }
        }

        public string Name
        {
            get { return name; }
            set { name = value; }
        }

        public FooModel(int w, int h, string n)
        {
            width = w;
            height = h;
            name = n;
        }
    }
}

// Program.cs

using System;
using System.Reflection;
using System.ComponentModel;

namespace CsReflectionTest
{
    class Program
    {

        static void OutputSample(object model)
        {
            Type modelType = model.GetType();
            PropertyInfo[] modelProperties = modelType.GetProperties();

            foreach (PropertyInfo propInfo in modelProperties)
            {
                // all our data memebers shall have a display name attribute
                object[] attrs = propInfo.GetCustomAttributes(
                        typeof(DisplayNameAttribute), // type of attribute we want to see
                        false // inherit?
                        );

                string propertyDisplayName;

                if (attrs.GetLength(0) > 0)
                {
                    // for this property there is an assigned specific name
                    DisplayNameAttribute a = (DisplayNameAttribute)attrs[0];
                    propertyDisplayName = a.DisplayName;
                }
                else
                {
                    propertyDisplayName = propInfo.Name;
                }

                object propertyValue = modelType.InvokeMember(
                    propInfo.Name, BindingFlags.GetProperty, null, model, null);

                Console.WriteLine("{0} -> {1}", propertyDisplayName, propertyValue);
            }
        }

        static void Main(string[] args)
        {
            FooModel f1 = new FooModel(12, 34, "foo1");

            OutputSample(f1);

            Console.ReadLine();
        }
    }
}

Здесь основной интерес представляет функция OutputSample. Она довольна проста — пробеаем по всем свойствам объекта, извлекаем атрибут DisplayName(можно любой другой — некий user-defined например) и вызываем это свойство у объекта.

Вывод программы:

SuperMegaWidthOfFoo -> 12
Height -> 34
Name -> foo1

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

CC>Сколько деревьев видел/писал — ни в одном при insert/erase не была использована рекурсия. Да и не нужна она там.
CC>Единственное применение рекурсии там могу придумать только когда надо грохнуть все дерево/ветку. Но даже в этом случае можно обойтись без рекурсии.

Да я ж не спорю — есть нерекурсивные алгоритмы, слава Богу. Но во многих книжках — Н. Вирт "Алгоритмы и структуры данных", например, я не видел нерекурсивный алгоритм вставки-удаления для того же AVL дерева.

Не спорю, в грамотных реализациях stl (в том числе стандартной для msvc, во всяком случае msvc2005) алгоритм вставки-удаления в RB дерево нерекурсивен, но кто может поручится за все реализации?

Если в стандарте написана явно рекомендация-требование к такой реализации деревьев для map/set, тогда прошу меня простить

Щаз придёт Котд и всё разрулит! И вас помирит!

"Roman Odaisky" <48787@users.rsdn.ru> сообщил/сообщила в новостях следующее: news:2972943@news.rsdn.ru...
> На C++ пишут меньше прикладных программ, чем он того заслуживает, в первую очередь потому, что мало хороших прикладных библиотек. А вот хотелось бы выяснить: если бы на C++ были удобные библиотеки для всего-всего, то все перешли бы (обратно) на C++, или индусы в любом случае будут продолжать писать на Java, Python и т. п., потому что там сложнее обстрелять свои ноги? Для каких задач C++ останется неприменим даже с самыми лучшими библиотеками?

Posted via RSDN NNTP Server 2.1 beta

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

SI>Не спорю, в грамотных реализациях stl (в том числе стандартной для msvc, во всяком случае msvc2005) алгоритм вставки-удаления в RB дерево нерекурсивен, но кто может поручится за все реализации?
Ну, я просто удивлялся. Потому как рекурсивно работать с деревьями ИМХО это как то очень дубово в большинстве случаев.

SI>Если в стандарте написана явно рекомендация-требование к такой реализации деревьев для map/set, тогда прошу меня простить

Не, не написана.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

SI>>Не спорю, в грамотных реализациях stl (в том числе стандартной для msvc, во всяком случае msvc2005) алгоритм вставки-удаления в RB дерево нерекурсивен, но кто может поручится за все реализации?
CC>Ну, я просто удивлялся. Потому как рекурсивно работать с деревьями ИМХО это как то очень дубово в большинстве случаев.

Между тем в ФП только рекурсивно и работают

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

SI>>>Не спорю, в грамотных реализациях stl (в том числе стандартной для msvc, во всяком случае msvc2005) алгоритм вставки-удаления в RB дерево нерекурсивен, но кто может поручится за все реализации?
CC>>Ну, я просто удивлялся. Потому как рекурсивно работать с деревьями ИМХО это как то очень дубово в большинстве случаев.

J>Между тем в ФП только рекурсивно и работают ;)

Там преимущественно хвостовая рекурсия.

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

J>Между тем в ФП только рекурсивно и работают

так то ж в ФП.
Там почти все через ж.... пардон, рекурсию

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

GN>По умолчанию, весь код идет в невыгружаемые секции PE. То есть, нужно специально написать свободные функции, поместить их в выгружаемые секции и вызывать их из функций-членов, что бы споткнуться?

Естественно. Маленький драйвер наверное и не нуждается в подобной оптимизации ( разделение на выгружаемые и не выгружаемые функции ). А если проект большой, то довольно вероятен такой сценарий: сначала делали все в NonPaged. Сделали. Отладили. Занялись оптимизацией. Расставить прагмы вокруг функций, содержащих отладочный макрос PAGED_CODE, дело не хитрое. А вот после этого может начаться та самая ж..а.

TC>> Я лично когда юзал С++ ( сейчас отказался от этого )
GN>Почему, если не секрет?

1)
А потому что, когда писал на С++ занимался не кодированием, т.е решением конкретной задачи, а постоянными размышлениями — как бы это написать на С++? Почитайте форум, половина вопросов в стиле "как бы так выпендриться, чтобы заставить данный код работать"? Мне нравится С — там есть все, чтобы писать простой и понятный всем код и он не занимает мой мозг синтаксическими извращениями и размышлениями, как лучше сделать. Кроме того, драйвера — достаточно простые с точки зрения алгоритмов и типов данных программки. При этом повторяемость кода — нулевая практически. Пишу я драйвер всегда один. На что мне полиморфизм? На что мне наследование? На что мне инкапсуляция? На что мне паттерны проектирования, если я сам себе гуру в своей области?

2)
Нет СТАНДАРТНЫХ библиотек. Чужие велосипеды даже не рассматриваются ( я никогда даже не смотрю на библиотеки вроде "вот, создал свой фреймворк для ядра" ), не хватало потом чужие баги по крешдампам искать. Я ради интереса собирал драйвера с STL контейнерами, но как то это стремно. Кроме того, как сделать, чтобы STL нормально работал в условиях отказов в выделении памяти? При том, что обработка исключений — невозможна. Кроме того, большая часть стандартной библиотеки — это всякие классы для потокового ВВ, на что мне это добро в ядре?

Короче, нет весомых плюсов у плюсов

в моем нелегком деле. Это как раз та нишка, где остался чистый С. Век плюсов тоже прошел, вытеснят их в нишку анализа текста. Чего бороться за мертвеца? Если у меня будет времячко, я буду C# изучать, ибо лет через 10 закончится наконец то век слоноподобных ОС со всеми этими процессами и виртуальными памятями. Вендекапец будет вместе с линухкапцом — эти два урода-близнеца тоже близятся к своему климаксу.

. Будущее — это платформы виртуализации и управляемый код. Window, Linux, C++ — в кочегарку, там знают что с ними делать.

Здравствуйте, TarasCo, Вы писали:
GN>>Почему, если не секрет?

TC>1)
TC>А потому что, когда писал на С++ занимался не кодированием, т.е решением конкретной задачи, а постоянными размышлениями — как бы это написать на С++? Почитайте форум, половина вопросов в стиле "как бы так выпендриться, чтобы заставить данный код работать"? Мне нравится С — там есть все, чтобы писать простой и понятный всем код и он не занимает мой мозг синтаксическими извращениями и размышлениями, как лучше сделать. Кроме того, драйвера — достаточно простые с точки зрения алгоритмов и типов данных программки. При этом повторяемость кода — нулевая практически. Пишу я драйвер всегда один. На что мне полиморфизм? На что мне наследование? На что мне инкапсуляция? На что мне паттерны проектирования, если я сам себе гуру в своей области?
А почему нельзя писать на плюсах просто? Без заморок, STL, исключений и полиморфизма?
Уже проверка типов + ООП довольно много. + простые понятные шаблоны -- ещё больше...
Какой смысл исползовать С вместо С++, используемого, как "С с классами"?

Здравствуйте, TarasCo,

Спасибо, в первую очередь интересны "пессимистичные" точки зрения

Сначала написал развёрнутый ответ по-пунктам, но мне не интересен "спор", поэтому решил попробовать выделить главное:

Итак, фреймворки для ядра не нужны (это конечно не относится к тому что двигает MS

).

Могут быть полезны стандартные кирпичики — а именно STL часть, string library, что-то еще (атомарные типы из нового стандарта). Но, что бы этим можно было спокойно пользоваться, нужно имплементировать нормальный __CxxFrameHandler (который не будет завязан на TLS)

Правильно?

Что же до перспектив С++ в не столь отдалённом будущем — я совершенно спокоен, MS давно похоронили С, но заметно вкладываются в С++. Поживём, увидим... пока я угадал судьбу Itanic'а и про дотнет в ядре Vista

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

TC>Вендекапец будет вместе с линухкапцом — эти два урода-близнеца тоже близятся к своему климаксу.

. Будущее — это платформы виртуализации и управляемый код. Window, Linux, C++ — в кочегарку, там знают что с ними делать.

Смешно. История деляет полный круг и возвращается к VM/CMS

Я думаю, будушее принесет нам осознание, что 1) пользователю все равно, какое там у ОС ядро, линух ли, BSD, или MS-DOS на стероидах. Пользователь пользуется приложениями, а не ядрами 2) приложения нуждаются в более высокоуровневой прослойке, чем API, предлагаемый современными OS. Грубо говоря, война OS кончится тем же, чем война бровсеров: как сейчас более-менее любой сайт можно открыть в любом бровсере, так через N лет любое приложение можно будет запустить на любом компутере с любой OS, лишь бы хватило памяти и мегагерцев.

	От:	Roman Odaisky
	Дата:	02.06.08 07:47
	Оценка:

	От:	Аноним
	Дата:	02.06.08 07:51
	Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	02.06.08 08:02
Оценка:	1 (1)

	От:	lollipop
	Дата:	02.06.08 08:10
	Оценка:

	От:	CreatorCray
	Дата:	02.06.08 08:56
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	02.06.08 11:24
Оценка:	+1

От:	c-smile	http://terrainformatica.com
Дата:	02.06.08 16:53
Оценка:	+2

	От:	Константин Л.
	Дата:	02.06.08 18:04
	Оценка:

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	03.06.08 07:55
Оценка:

От:	remark	http://www.1024cores.net/
Дата:	03.06.08 09:38
Оценка:	+1

	От:	NikeByNike
	Дата:	03.06.08 22:13
	Оценка:	1 (1)

От:	_nn_	www.nemerleweb.com
Дата:	04.06.08 16:49
Оценка:	-1

От:	Pzz	https://github.com/alexpevzner
Дата:	12.06.08 01:05
Оценка:	16 (1)