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

T>>>>>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки.

эх, молодёжь. берём программу на С и переписываем её на C++ без конструкторов/деструкторов и virtual. что получаем? ровно то же время работы. в 80-х годах именно дополнительное время, затрачиваемое на эти элементы языка в сравнении с С, считали его серьёзным недостатком. преимущества от ООП ещё доказывать надо, а вот выполнение замедлится, причём неизвестно ещё насколько

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

T>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.

Справедливости ради, не все:
— использование исключений (*)
— использование динамической памяти
— преобразование типов во время выполнения (*) (**)

(*) но есть надежда, что в течение нескольких лет детерменированность будет достигнута.
(**) AFAIR уже есть экпериментальные реализации, выполняющие dynamic_cast за константное время.

Здравствуйте, thesz, Вы писали:
T>>Никакой неоднозначности нет. Зная типы a и b знаешь всё.
T>>Профайлеров и листинов ассемблера не нужно.
T>>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.
T>Какая сложность у new/delete для произвольного класса?
Зависит от менеджера памяти (как и в pure C) + константа зависимая от состава класса — его списка наследования и списка членов.

T>Зависит ли скорость выделения/освобождения памяти от количества и других параметров объектов, выделенных ранее?
Зависит от менеджера памяти (как и в pure C)

T>Скорость работы C++ недостаточно детерминирована. Для её приемлемой определённости необходимо поработать ручками.
Согласен с здесь.

Автор: Alxndr
Дата: 13.03.09

Здравствуйте, Alxndr, Вы писали:
T>>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.
A>Справедливости ради, не все:
A>- использование исключений (*)
A>- использование динамической памяти
A>- преобразование типов во время выполнения (*) (**)
A>(*) но есть надежда, что в течение нескольких лет детерменированность будет достигнута.
A>(**) AFAIR уже есть экпериментальные реализации, выполняющие dynamic_cast за константное время.
Детерминированности общего времени при обработке исключений не очень ясно как добится — ведь она может повлечь за собой произвольное количество вызовов деструкторов.
Хотя, это можно тоже учесть.

T>>>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.
T>>Какая сложность у new/delete для произвольного класса?
T>Зависит от менеджера памяти (как и в pure C) + константа зависимая от состава класса — его списка наследования и списка членов.

Константа?

Менеджер памяти для какого-то класса может находиться в отдельном от определения класса файле?

T>>Зависит ли скорость выделения/освобождения памяти от количества и других параметров объектов, выделенных ранее?
T>Зависит от менеджера памяти (как и в pure C)

Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту.

Без IDE уже становится сложно.

По поводу исключений: в игростроении кидать исключение из основного цикла моветон. В принципе, их можно не рассматривать. Других проблем вполне достаточно.

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

T>>>Какая сложность у new/delete для произвольного класса?
T>>Зависит от менеджера памяти (как и в pure C) + константа зависимая от состава класса — его списка наследования и списка членов.
T>Константа?
Да.

T>Менеджер памяти для какого-то класса может находиться в отдельном от определения класса файле?
Как и в pure C.

T>>Зависит от менеджера памяти (как и в pure C)
T>Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту.
И в pure C при удалении структуры мы должны корректно удалить все его члены.
Чтобы узнать что именно при этом происходит нужно осведомится по всему проекту.

T>Без IDE уже становится сложно.
Да. Как и в pure C.

T>По поводу исключений: в игростроении кидать исключение из основного цикла моветон. В принципе, их можно не рассматривать.
+1

T> Других проблем вполне достаточно.
Кроме исключений и динамического приведения вроде больше никто ничего не приводил.

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

T>>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.
T>>Чего не наблюдается в haskell-е, ну дык он вроде не для того.
T>Именно это и говорили про C++ в 1993-5 годах.
Заметь, недетерминированнасть только для исключений и динамического приведения, которые можно и не использовать.
А вот в haskell-е, насколько я понимаю, главные причины недетерминированности — ленивость и сборка мусора. Или я не прав?

Как-то слабо представляется как от них можно отказатся...

T>>>Все затраты времени в языке детерминированы и могут быть учтены кроме внешних вызовов.
T>>>Чего не наблюдается в haskell-е, ну дык он вроде не для того.
T>>Именно это и говорили про C++ в 1993-5 годах.
T>Заметь, недетерминированнасть только для исключений и динамического приведения, которые можно и не использовать.
T>А вот в haskell-е, насколько я понимаю, главные причины недетерминированности — ленивость и сборка мусора. Или я не прав?

Да-да.

Которые можно (будет) не использовать.

http://rsdn.ru/forum/message/3230620.1.aspx

Автор: thesz
Дата: 27.12.08

http://research.microsoft.com/en-us/um/people/simonpj/papers/non-stop/

T>Как-то слабо представляется как от них можно отказатся...

Оптимизациями. В нужных местах.

T>>>>Какая сложность у new/delete для произвольного класса?
T>>>Зависит от менеджера памяти (как и в pure C) + константа зависимая от состава класса — его списка наследования и списка членов.
T>>Константа?
T>Да.

Прошу прощения, а конструкторы могут вызывать внешние сервисы?..

Это самое простое.

new во внутреннем цикле игры подсчитывалось. Каждый свой new надо было оправдать.

T>>Менеджер памяти для какого-то класса может находиться в отдельном от определения класса файле?
T>Как и в pure C.

В чистом Си менеджер указывается именем. malloc, gc_malloc, arena_alloc...

T>>>Зависит от менеджера памяти (как и в pure C)
T>>Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту.
T>И в pure C при удалении структуры мы должны корректно удалить все его члены.

Если ты не используешь арены. Арены рулят, надо сказать.

T>Чтобы узнать что именно при этом происходит нужно осведомится по всему проекту.

Путь проще. Иди себе по вверх именам, и всё. Иерархии наследования нет, опускаться не придётся.

T>>Без IDE уже становится сложно.
T>Да. Как и в pure C.

На pure C я вполне могу справиться с достаточно большим проектом (gcc) с помощью mc и понять, что там к чему.

Похожее по сложности создание на плюсах (творение коллег) без VS в мою голову не поднималось. С VS тоже, однако. Но не всегда по моей вине.

T>> Других проблем вполне достаточно.
T>Кроме исключений и динамического приведения вроде больше никто ничего не приводил.

Ты их не счёл проблемами.

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

T>>>>>Какая сложность у new/delete для произвольного класса?
T>>>>Зависит от менеджера памяти (как и в pure C) + константа зависимая от состава класса — его списка наследования и списка членов.
T>>>Константа?
T>>Да.
T>Прошу прощения, а конструкторы могут вызывать внешние сервисы?..
T>Это самое простое.
T>new во внутреннем цикле игры подсчитывалось. Каждый свой new надо было оправдать.
T>>>Менеджер памяти для какого-то класса может находиться в отдельном от определения класса файле?
T>>Как и в pure C.
T>В чистом Си менеджер указывается именем. malloc, gc_malloc, arena_alloc...
Сергей, я профилировал руками довольно большое gis приложение (профилятора не было bc 5.0.2).
180424 строк на Delphi, 107346 на C++ и 289 на Asm. все данные хранились в базе (paradox файл сервер) ~20мб в исходном (без данных) виде.
Не реалтайм конечно, но основные юзекейсы у нас выполнялись без задержек.
Использовались все средства С++ которые тогда были доступны (всё, что обсуждается).
Среда bc 5 сильно уступает современным, например навигации по коду нет никакой.
Тем не менее, никаких неожиданностей/неучтёнок не обнаружилось.

T>>>>Зависит от менеджера памяти (как и в pure C)
T>>>Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту.
Как и в pure C.
Для освобождения члена структуры нам может понадобится вызвать некоторую функцию.
Что он делает — нужно смотреть.

T>>И в pure C при удалении структуры мы должны корректно удалить все его члены.
T>Если ты не используешь арены. Арены рулят, надо сказать.
+1

T>>Чтобы узнать что именно при этом происходит нужно осведомится по всему проекту.
T>Путь проще. Иди себе по вверх именам, и всё. Иерархии наследования нет, опускаться не придётся.
Значит просто оно тебе непривычно.

T>На pure C я вполне могу справиться с достаточно большим проектом (gcc) с помощью mc и понять, что там к чему.
Хорошо структуированный прроект в понятной предметной области читается с листа даже на не очень знакомом языке.

T>Похожее по сложности создание на плюсах (творение коллег) без VS в мою голову не поднималось. С VS тоже, однако. Но не всегда по моей вине.
Не используй VC. Тот же Slick Edit или Source Navigator может значительно облегчить задачу.

T>>> Других проблем вполне достаточно.
T>>Кроме исключений и динамического приведения вроде больше никто ничего не приводил.
T>Ты их не счёл проблемами.
Они таковыми и не являются.

T>>>Как и в pure C.
T>>В чистом Си менеджер указывается именем. malloc, gc_malloc, arena_alloc...
T>Сергей, я профилировал руками довольно большое gis приложение (профилятора не было bc 5.0.2).
T>180424 строк на Delphi, 107346 на C++ и 289 на Asm. все данные хранились в базе (paradox файл сервер) ~20мб в исходном (без данных) виде.
T>Не реалтайм конечно, но основные юзекейсы у нас выполнялись без задержек.
T>Использовались все средства С++ которые тогда были доступны (всё, что обсуждается).
T>Среда bc 5 сильно уступает современным, например навигации по коду нет никакой.
T>Тем не менее, никаких неожиданностей/неучтёнок не обнаружилось.

Самое простое: ты на разброс (дисперсию) времён внимание обращал? В игре будь добр уложится в 16 миллисекунд 99,99% времени. Да и то, четыре девятки означает, что раз в три минуты у тебя будет скачок FPS.

T>>>>>Зависит от менеджера памяти (как и в pure C)
T>>>>Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту.
T>Как и в pure C.
T>Для освобождения члена структуры нам может понадобится вызвать некоторую функцию.
T>Что он делает — нужно смотреть.

В случае арен ты эту структуру вообще не освобождаешь. ВООБЩЕ. Это раз. В C++ такой практики не встречал ни разу. Слыхом не слыхивал.

Второе — путь отслеживания не содержит никаких неявных вещей.

T>>>Чтобы узнать что именно при этом происходит нужно осведомится по всему проекту.
T>>Путь проще. Иди себе по вверх именам, и всё. Иерархии наследования нет, опускаться не придётся.
T>Значит просто оно тебе непривычно.

В общем, да. Непривычно. Напомню, что речь идёт не только обо мне, так и не привыкшему к [i]особенностям[/u] c++, но и про Джона Кармака образца 1995 года.

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

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

Этот аргумент повторяется чаще, чем любому из нас хотелось бы.

T>>На pure C я вполне могу справиться с достаточно большим проектом (gcc) с помощью mc и понять, что там к чему.
T>Хорошо структуированный прроект в понятной предметной области читается с листа даже на не очень знакомом языке.

Tell me that about gcc once more, ага. Уровень вхождения в gcc очень высок, по словам товарищей, которые за это деньги получают.

T>>Похожее по сложности создание на плюсах (творение коллег) без VS в мою голову не поднималось. С VS тоже, однако. Но не всегда по моей вине.
T>Не используй VC. Тот же Slick Edit или Source Navigator может значительно облегчить задачу.

Это тоже встречается чаще, чем хотелось бы уже мне лично.

Нахрена мне сейчас этот Slick Edit, когда та работа в прошлом? Зачем мне это, если я буду стараться держаться подальше от C++?

Более того, нахрена мне все эти инструменты, если для работы на Си достаточно ctags и редактора с их поддержкой (а то и без поддержки)?

T>>>> Других проблем вполне достаточно.
T>>>Кроме исключений и динамического приведения вроде больше никто ничего не приводил.
T>>Ты их не счёл проблемами.
T>Они таковыми и не являются.

Итак, поскольку ты не считаешь мои проблемы проблемами, я могу не считать проблемами твои.

Ты только что разрушил возможность диалога. Отличный ход, очень взрослый.

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

T>>>>>Да. Но менеджер для C либо один на всех, либо явен — XXX* arena_XXX_allocate(void). В случае new/delete мы должны осведомиться по всему проекту.
T>>Как и в pure C.
T>>Для освобождения члена структуры нам может понадобится вызвать некоторую функцию.
T>>Что он делает — нужно смотреть.

T>В случае арен ты эту структуру вообще не освобождаешь. ВООБЩЕ. Это раз. В C++ такой практики не встречал ни разу. Слыхом не слыхивал.

Элементарно реализуется в C++: роль арены выполняет placement new, с помощью которого создаются структуры без деструкторов. Что-то вроде:

first_child_t * child_one = new(arena) first_child_t(...);
second_child_t * child_two = new(arena) second_child_t(...);
owner_t * owner = new(arena) owner_t(child_one, child_two);
...

T>>>На pure C я вполне могу справиться с достаточно большим проектом (gcc) с помощью mc и понять, что там к чему.
T>>Хорошо структуированный прроект в понятной предметной области читается с листа даже на не очень знакомом языке.

T>Tell me that about gcc once more, ага. Уровень вхождения в gcc очень высок, по словам товарищей, которые за это деньги получают.

Уровень вхождения в OpenSSL (даже на уровне пользователя) так же очень высок. В отличии от, например, Crypto++. Не в последнюю очередь из-за того, что в OpenSSL на C пытались реализовать какое-то подобие объектно-ориентированного подхода.

T>Нахрена мне сейчас этот Slick Edit, когда та работа в прошлом? Зачем мне это, если я буду стараться держаться подальше от C++?

T>Более того, нахрена мне все эти инструменты, если для работы на Си достаточно ctags и редактора с их поддержкой (а то и без поддержки)?

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

T>>В случае арен ты эту структуру вообще не освобождаешь. ВООБЩЕ. Это раз. В C++ такой практики не встречал ни разу. Слыхом не слыхивал.
E>Элементарно реализуется в C++: роль арены выполняет placement new, с помощью которого создаются структуры без деструкторов. Что-то вроде:
E>

E>first_child_t * child_one = new(arena) first_child_t(...);
E>second_child_t * child_two = new(arena) second_child_t(...);
E>owner_t * owner = new(arena) owner_t(child_one, child_two);
E>...
E>

1) мне не совсем понятен сам механизм и
2) не отменяет того, что арены в C++ слегка менее часто используются.

T>>Tell me that about gcc once more, ага. Уровень вхождения в gcc очень высок, по словам товарищей, которые за это деньги получают.
E>Уровень вхождения в OpenSSL (даже на уровне пользователя) так же очень высок. В отличии от, например, Crypto++. Не в последнюю очередь из-за того, что в OpenSSL на C пытались реализовать какое-то подобие объектно-ориентированного подхода.

То есть, усложняли на ровном месте.

Нет, чтобы писать, как проще.

T>>Более того, нахрена мне все эти инструменты, если для работы на Си достаточно ctags и редактора с их поддержкой (а то и без поддержки)?
E>Просто в качестве ремарки. Никогда не встречал языка, от которого бы люди плевались больше, чем от C++. В крайнем случае на C++ можно программировать в стиле C. Только использовать такие удобные вещи, как ссылки, шаблоны и RAII.

Я тут Java изучаю...

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

T>Самое простое: ты на разброс (дисперсию) времён внимание обращал? В игре будь добр уложится в 16 миллисекунд 99,99% времени. Да и то, четыре девятки означает, что раз в три минуты у тебя будет скачок FPS.
Разброс не мерял.

T>В случае арен ты эту структуру вообще не освобождаешь. ВООБЩЕ. Это раз. В C++ такой практики не встречал ни разу. Слыхом не слыхивал.
Это стандартная практика. Читал по моему у Страуструпа и ещё где-то.
Оператор new с дополнительными параметрами называется "размещающим" и соответствующего оператора delete не имеет.

T>Второе — путь отслеживания не содержит никаких неявных вещей.
Деструкторы — вполне явная вещь.

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


T>>>На pure C я вполне могу справиться с достаточно большим проектом (gcc) с помощью mc и понять, что там к чему.
T>>Хорошо структуированный прроект в понятной предметной области читается с листа даже на не очень знакомом языке.
T>Tell me that about gcc once more, ага. Уровень вхождения в gcc очень высок, по словам товарищей, которые за это деньги получают.
Думаю им можно верить.
Одно дело исправить ошибку или добавить незначительную фичу какую-нибудь, а другое — реализовать что-нибудь существенно новое.
Язык, например.
Или вон уже который год для мингвы нормальную обработку исключений сделать не могут. И реализацию SEH-а.

T>>>>> Других проблем вполне достаточно.
T>>>>Кроме исключений и динамического приведения вроде больше никто ничего не приводил.
T>>>Ты их не счёл проблемами.
T>>Они таковыми и не являются.
T>Итак, поскольку ты не считаешь мои проблемы проблемами, я могу не считать проблемами твои.
Ну так и доказательств никаких небыло, ежели ты о скорости выполнения.
Был выделено 3 бесспорных недетерминированных свойства:
1. Внешние вызовы (работа с памятью сюдаже);
2. Исключения;
3. Динамическое приведение.
Два последних решили не рассматривать. Осталось одна.
Да, забыли виртуальность:
Если у нас где-то вызывается виртуальный метод (деструктор) мы не можем сказать сколько вызов займёт времени, потому как реально может произойти вызов любой из реализаций метода.
Опять же, на критических участках не нужно злоупотреблять виртуальностью.

Ни и моих проблем я тут как-то не высказывал.

П.С. То, что С++ сложен и временами монструозен я не отрицаю.
Хотя по мне ему сейчас не хватает 2х вещей:
1. Возможность статически итерировать по членам класса/структуры/области видимости.
2. Диспач и фильтрация по типу? члена при итерации.
Частично 2е входит в tr1 и новый сандарт.
Если к этому добавиь возможность изменяь состав этих членов, то макросистема получится очень мощная.

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

T>>>В случае арен ты эту структуру вообще не освобождаешь. ВООБЩЕ. Это раз. В C++ такой практики не встречал ни разу. Слыхом не слыхивал.
E>>Элементарно реализуется в C++: роль арены выполняет placement new, с помощью которого создаются структуры без деструкторов. Что-то вроде:
E>>

E>>first_child_t * child_one = new(arena) first_child_t(...);
E>>second_child_t * child_two = new(arena) second_child_t(...);
E>>owner_t * owner = new(arena) owner_t(child_one, child_two);
E>>...
E>>

T>1) мне не совсем понятен сам механизм и

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

T>2) не отменяет того, что арены в C++ слегка менее часто используются.

Бытие определяет сознание.

В свое время механизм placement new был краеугольным камнем многих коммерческих ООБД (iirc, Versant, Objectivity, Poet). Какие-то из них (iirc, Versant и Objectivity) шли еще дальше. Они держали в памяти только часть страниц с загруженными из БД объектов. Когда нужно было загрузить новую страницу, они выбрасывали какую-то из уже загруженных ранее страниц. При этом перехватывались исключения, вызванные обращениями по неверным адресам и автоматически подкачивались выброшенные ранее из памяти страницы.

T>Нет, чтобы писать, как проще.

Каждый мнит себя стратегом, видя бой со стороны

E>>Просто в качестве ремарки. Никогда не встречал языка, от которого бы люди плевались больше, чем от C++.

T>Я тут Java изучаю...

Java точно не вызывает у людей затем потом такого отвращения, как C++.

Здравствуйте, eao197, Вы писали:
T>>Я тут Java изучаю...
E>Java точно не вызывает у людей затем потом такого отвращения, как C++.
Интересно почему так?
Я вот изучал Java уже после того, как довольно хорошо освоил плюсы.
Ощущение — так себе. Есть интересные решения и сахар, но в основном Java изрядно сильнее ограничивает.
Поэтому пересесть не захотелось.

Вот Python — пришелся. И haskell.

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

E>Java точно не вызывает у людей затем потом такого отвращения, как C++.

Вызывает, вызывает

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

T>Здравствуйте, eao197, Вы писали:
T>>>Я тут Java изучаю...
E>>Java точно не вызывает у людей затем потом такого отвращения, как C++.
T>Интересно почему так?

Не знаю. Тайна сия велика есть.

T>Я вот изучал Java уже после того, как довольно хорошо освоил плюсы.
T>Ощущение — так себе. Есть интересные решения и сахар, но в основном Java изрядно сильнее ограничивает.

Я тоже программирован на Java после плюсов. Впечатления двойственные. С одной стороны, ловил себя на мыслях, что пишу многословный тупой код. Там, где на C++ можно было обойтись шаблонами или указателями на функции/методы, в Java нужно было делать интерфейсы, классы-наследники и пр. лабуду (правда я пользовался Java еще до введения в нее generic-ов). Зато в Java не нужно было думать об освобождении памяти. И никогда не было моментов, когда бы я не понимал где программа сломалась. Stack trace -- великая сила! А в C++ скомпилированная в релизе программа ломается через три недели непрерывной работы -- и все. Сиди и думай, где, как и почему, никаких следов.

Тем не менее, очень часто в адрес C++ слышатся высказывания о том, что С++ чуть ли не жизнь человеку поломал. Так уже поносят язык, что просто поражаешься. А адрес Java я такого пока не слышал. Хотя сам не упускаю момента вставить где-нибудь при случае Java must die!

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

[и тут выхожу я — весь в белом ]

E>Я тоже программирован на Java после плюсов. Впечатления двойственные. С одной стороны, ловил себя на мыслях, что пишу многословный тупой код. Там, где на C++ можно было обойтись шаблонами или указателями на функции/методы, в Java нужно было делать интерфейсы, классы-наследники и пр. лабуду (правда я пользовался Java еще до введения в нее generic-ов). Зато в Java не нужно было думать об освобождении памяти. И никогда не было моментов, когда бы я не понимал где программа сломалась. Stack trace -- великая сила! А в C++ скомпилированная в релизе программа ломается через три недели непрерывной работы -- и все. Сиди и думай, где, как и почему, никаких следов.

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

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

BZ>а теперь отгадаем с одного раза — какой язык сочетает преимущества их обоих?

Eiffel.

И стоит, зараза, столько же, сколько C++ и Java со всеми IDE, профайлерами и отладчиками вместе взятыми.