На чем пишуться игр для xbox 360 ? (5 стр)

loonypy
> Это тоже выдумка Страуструпа?
это работает быстрее по одной простой причине

A() : n(1)  - это ты определяешь так называемый список инициализации

а это A() {n=1;}

уже выполнение кода.

Грубо говоря на низком уровне когда выделяется какаято память - она может быть или инициализированной или нет - это вобщем то бесплатно.
т.о.
получается в первом случае n создается УЖЕ с единичкой внутри, а во втором сначала создается n - а потом туда присваивается единичка. Т.е. 2 действия вместо одного - т.о. первый способ ессесно выполняется быстрее. Первый способ хороший тон разработки можно сказать.

ЗЫ
список инициализации определен в стандарте - так что можно сказать придуман Страуструпом - как бе правильно писать так - поэтому и разработчики компилятора будут оптимизировать компиль под правильно пишущих людей :)))

fsmoke
> A() : n(1) - это ты определяешь так называемый список инициализации
>
> а это A() {n=1;}
>
> уже выполнение кода.
На таком уровне сильной разницы не чувствую. Видимо разница заметна на ассемблерном уровне: в случает со списком инициализации компилятор разворачивает код в меньшее количество ассемблерных инструкций?

loonypy
> На таком уровне сильной разницы не чувствую
всмысле
loonypy
> разворачивает код в меньшее количество ассемблерных инструкций?
да каких инструкций причем тут это вообще - ну если грубо говорить то наверное да

A() : n(1) - это список - просто перечисление - какими данными забить память - это не код по крайней мере для фундаментальных типов

ЗЫ
а если тело пустое - то компиль может и от него избавится - тоесть ещё и лишний call долой

fsmoke
> да каких инструкций причем тут это вообще
Например, с инициализацией. Есть 2 варианта инициализации. Зачем нужен второй вариант, если первый работает?
Имхо, два варианта ответа: для удобства программиста и по техническим причинам (уже не на уровне логики программиста, а на низком аппаратном уровне). Так как низкий уровень - это процессор, то речь о количестве процессорных команд (одна команда на уровне высокоуровневого ЯП=N командам ассемблера). Могу еще третий вариант предположить: ускорить работу компилятора. На проекте с тысячами строк кода этот показатель, наверное, становится таким же важным, как и количество процессорных команд на одну высокоуровневую.
И так, наверное, по каждому "приему", "хитрости", "моменту", "нюансу" в с++.

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

loonypy
> Зачем нужен второй вариант, если первый работает?
ну вообще тут ты прав - все же разработка языков идет в какой то степени от железа :))

ЗЫ
рад что ты разобрался

Ruslan
> удобен для инициализации компонентных данных
безусловно - но в этом случае вариантов то вообще нет

fsmoke
> разобрался
ну вроде бы. Тут, получается, удовлетворяются сразу все варианты:
удобство. Ruslan написал про него.
работа компилятора. Ты писал про "лишний call долой" - компилятор не тратит время на разбор и создание метода.
аппаратная реализация. Не создается инструкций, описывающих функцию инициализации, не передается ей управление при создании объекта. Так? Только сейчас в голову пришло, что реализация такая - ассемблера не знаю, никогда на нем не писал.

loonypy
> Так?
хороший компиль с включенной оптимизацией должен делать именно так.

2,5 страницы оффтопа, хотя беседа интересная получилась:)

по-моему глупо начинать с Си по причине не постежимости и не вероятной сложности С++. типО обязательно надо знать полностью весь с++. на с++ можно писать тоже что и на Си и при этом развиваясь уча С++, а не стоять на месте с Си. Темболеее афтору я думаю знакомо ооп и будет не так сложно начать с ++.

стоит учить сразу Си++, чтобы потом не колбасить код в стиле Си с глобальными переменными, define вместо констант и inline функций и прочего...А потом плавно переезжать на C#.

учите сразу Common Lisp и не портите мозг императивной логикой :-p

некро....ы :)