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

L>Я знаю одно замечение где C++ медленне С — это использование глобальных статический объектов с конструкторами и/или деструкторами. В этом случае относительно долго (по сравнению с С кодом) происходит запуск/завершение процесса. Для UNIX систем это бывает важно.

А кто тебя заставляет использовать глобальные статические объекты ?

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

PD>>Если ты утверждаешь. что здесь нет в С++ цикла — я категорически не согласен. Есть она тут на С++. Но VC++/Release этот код выкинет и правильно сделает.
CC>С точки зрения сравнения производительности/эффективности языков тут цикла нет. Стоимость этой строки в runtime == 0.

Я этого не знаю, и не могу знать, поскольку не знаю, как это компилируется, и не имею права на это закладываться. Кстати, в VC++ Debug этот цикл есть и реально выполняется.

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

Pzz>Да я и не пользуюсь этим языком, ноги берегу. Так что по большому счету мне все равно, что туда внесут
Так чего ты тогда берёшься учить тех, кто им пользуется?

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

L>Я знаю одно замечение где C++ медленне С — это использование глобальных статический объектов с конструкторами и/или деструкторами. В этом случае относительно долго (по сравнению с С кодом) происходит запуск/завершение процесса.

Т.е. если вместо глобальных объектов с конструкторами и деструкторами сделать глобальные структуры с вызовом в main() для каждой из них mystruct_init()/mystruct_cleanup () то будет быстрее?
Конструкторы глобальных объектов это обычные функции, которые вызывает рантайм перед тем как передать управление main().

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

Pzz>>Если вам важно, чтобы какая-то операция произошла в определенное время, сделайте ее явной и явно в нужное время пните.
CC>И тут начинается суровая рукопашная C-style.

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

Я лично предпочитаю, когда программа текстуально кореллирует с ходом мысли, описывающей ее ожидаемое поведение. Т.е., если вы пишете, например, сетевой протокол, и в его описании написано "сделай раз, сделай два, сделай три", то эти раз-два-три должны иметь в тексте программы некий эквиавалент. Желательно с теми же или похожими названиями, если character set позволяет.

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

Pzz>>>Если вам важно, чтобы какая-то операция произошла в определенное время, сделайте ее явной и явно в нужное время пните.
CC>>И тут начинается суровая рукопашная C-style.

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

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

Pzz> Т.е., если вы пишете, например, сетевой протокол, и в его описании написано "сделай раз, сделай два, сделай три", то эти раз-два-три должны иметь в тексте программы некий эквиавалент. Желательно с теми же или похожими названиями, если character set позволяет.
У меня это находится в комментариях к блокам кода, которые сии хотелки реализуют.

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

Pzz>> Т.е., если вы пишете, например, сетевой протокол, и в его описании написано "сделай раз, сделай два, сделай три", то эти раз-два-три должны иметь в тексте программы некий эквиавалент. Желательно с теми же или похожими названиями, если character set позволяет.
CC>У меня это находится в комментариях к блокам кода, которые сии хотелки реализуют.

Я про код говорю, а не про комментарии

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

А>Некоторые говорят что код на С работает быстрее чем C++. Т. е. для разработки высокопроизводительного SW предпочтительно использовать С вместо C++. Кто нибудь может подсказать в чем это преимущество (не считая использование виртуальных функции, здесь очевидно почему медленее)

Преимущество? Преимущества не сводятся к скорости.

Об этом лучше бы почитать людей, которые давно пишут top notch приложения на том и другом, и еще на чем-нибудь. Например, Кармак пишет, что кроме производительности были и другие важные issues: portability и bloating. Там же он указывает, что это дело early days.

http://www.team5150.com/~andrew/carmack/slashdot.html

Что такое Си? Кросс-ассемблер высокого уровня. Представьте, вам надо перенести проект на какую-нибудь консьюмерскую телеприставку девяностых. Там, может, и компилятора-то плюсового нет.

Bloating комментировать не берусь.

Erop wrote:

> Это рассуждение легко выворачивается. Если часть всё равно на С++, то на
> кой в проекте два языка?

выворачивать, так выворачивать если всё в итоге будет странслировано в
машинный код, то почему бы не на нем писать?
разработка на managed языке мне кажется более эффективной. но ничто не
мешает особенно критичные места оставлять unmanaged, если это необходимо.
примерно как ассемблерные вставки в c/c++.

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

SV.>Что такое Си? Кросс-ассемблер высокого уровня. Представьте, вам надо перенести проект на какую-нибудь консьюмерскую телеприставку девяностых. Там, может, и компилятора-то плюсового нет.
Ну теперь gcc есть почти везде. Раньше был семантековский компиллер из С++ в С...

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

L>Я знаю одно замечение где C++ медленне С — это использование глобальных статический объектов с конструкторами и/или деструкторами. В этом случае относительно долго (по сравнению с С кодом) происходит запуск/завершение процесса. Для UNIX систем это бывает важно.

Не понимаю, а в С версии аналогичная инициализация происходит или нет?

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

MC>Using — это тот же raii. Просто в случае с using под область действия ресурса создается новый блок, а не используется текущий. Или покажи, в чем на твой взгляд принципиальное отличие.

Принципиальных отличий — вагон и маленькая тележка.

In short, IDisposable prevents designing reusable software. The underlying problem causing all this difficulty is the violation of one of the central principles of Object Oriented Design: keep the interface separate from the implementation.

...

Generally speaking, finalizers may not access managed objects.

Интересно, а много ли среди сторонников C# тех, кто действительно хорошо знают его?

Здравствуйте, -MyXa-, Вы писали:
MX>Принципиальных отличий — вагон и маленькая тележка.
Ну местами сомнительная, местами полезная статья. Список-то где?

MX>

MX>In short, IDisposable prevents designing reusable software. The underlying problem causing all this difficulty is the violation of one of the central principles of Object Oriented Design: keep the interface separate from the implementation.

А кто говорил, что детерминированная финализация — это в общем случае просто? Но чаще встречаются частные, более простые случаи.

MX>

MX>Generally speaking, finalizers may not access managed objects.

Спасибо, капитан.

MX>Интересно, а много ли среди сторонников C# тех, кто действительно хорошо знают его?
Много.