Я все пытался понять этот тул... В конце-концов, додумался до такого. Выделяя память, он заставляет систему засвопить все, что там было до того. После того, как процесс завершается, системе достается огромный кусок физической памяти, доступной для использования. на системах с плохой реализацией вирутальной памяти может принести какую-то пользу, наверное...
eao197 пишет:
Но вот сейчас сложно найти > причины для /массового/ изучения C++ подрастающим поколением. Единичные > случаи, к счастью, есть. Но вот не верю я в то, что молодежь откажется > от Java с IDEA или от C# с Reshaper-ом.
Такие причины есть. Это — необходимость знания адресной арифметики любым
программистом, даже на Java. Т.е. УЧИТЬ -то С++ (или С) надо. Но это не
заставляет, конечно, на нем потом программировать.
Кстати, а в чем существенная разница между 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++.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Я бы сказал, есть смысл их изучить обязательно. Но не для того, чтобы понтануться, а хотя бы для того, чтобы понять какие есть альтернативы. ИМХО, ОКамл реальная альтернатива C++.
Для ограниченного количества приложений на ограниченном числе платформ.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
J>Я навскидку вижу такие больших проблемы, не решаемых библиотеками: J>1. Отсутствие GC. На С++ крайне сложно писать прототипы и вообще заниматься "быстрой разработкой", просто потому что в С++ ресурсами приходится управлять вручную, в отличие от управляемых языков, в которых все объекты, будучи однажды созданными, живут вечно. В результате приходится продумывать схему владения, и ее не сменишь одним движением мизинца, что важно при быстрой разработке (в управляемых языках такой проблемы вообще не стоит).
GC позволяет управлять автоматом тока одним ресурсом — памятью. Я уже забыл когда последний раз писал в прикладном С++ коде delete или free — откройте для себя смарт поинтеры.
Здравствуйте, eao197, Вы писали:
Y>>Я бы сказал, есть смысл их изучить обязательно. Но не для того, чтобы понтануться, а хотя бы для того, чтобы понять какие есть альтернативы. ИМХО, ОКамл реальная альтернатива C++.
E>Для ограниченного количества приложений на ограниченном числе платформ.
Это такая шутка да?
Вот поддерживаемые платформы здесь. А насчет ограниченного количества приложений даже комментировать не буду
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, 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, а языков без адресной арифметики.
Здравствуйте, 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. На С++ крайне сложно писать прототипы и вообще заниматься "быстрой разработкой", просто потому что в С++ ресурсами приходится управлять вручную, в отличие от управляемых языков, в которых все объекты, будучи однажды созданными, живут вечно. В результате приходится продумывать схему владения, и ее не сменишь одним движением мизинца, что важно при быстрой разработке (в управляемых языках такой проблемы вообще не стоит).
Отвечаю всем, кто хотел меня научить умным указателям: я не говорю про ГЦ вообще, а отвечаю на заданный Романом вопрос (выделено).
Так вот задачу, которую я имел в виду, я в своем ответе тоже выделю, потому что мне показалось, что это в моем ответе было не замечено.
Чтоб никому не казалось, что я считаю ГЦ фичей, без которой жить в плюсах нельзя, и не умею пользоваться умными указателями.
Скрипты, кстати, рулят в том числе и по этой причине — там ни о чем не надо думать, все живет вечно.
).
