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


под одну платформу, определенный тип компилятора и небольшой плясочки, чтоб привести целевой бинарник к удобному виду. )

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

GoldFinch, [citation needed]

???

Мне не кажется очевидным, что кроссплатформенный исходный код приводит к генерации "плохого" бинарного кода.

Kallikanzarid, из-за "кроссплатформенности", в С(++) нет способа средствами языка сгенерить некоторые x86-87 команды, например загрузку констант в FPU. 
Т.е. в некроссплатформенном паскале есть оператор(функция) Pi который генерит fldpi, а в кроссплатформенном С(++) оператора Pi() нет, и способа сгенерить fldpi (и другие константы) тоже нет.
Впрочем код C++ для FPU местами ужасен %) Ни один нормальный программист такого бы не писал.

Троллинг перерастает в холивар...   
1) Чем плохи заранее обсчитанные константы?
2) Паскаль - не кроссплатформенный?   Да что ви говогите!
3) Меня ты продавишь только цифрами, так как плевать я хотел на красоту бинарного кода  Хочу бенчмарк, в котором те или иные мат. расчеты выполняются сначала в С++, а потом - в асме.
4) А ты можешь вручную оптимизировать расположение инструкций, чтобы минимизировать простой конвеера?

бред
никакой связи тут нет
вопрос лишь в поддержке компилятора


не существует "кода C++ для FPU"
качество кода, сгенерированного компилятором зависит от качества компилятора
оценка качества оптимизированного кода неподготовленными субъектами обычно неадекватна, т.к. понять что оптимально а что нет на уже 2-х процессорных платформах способен только специалист

и вообще на 2-х последних страницах столько бреда, что ужасть   

Kallikanzarid,
1) тем что аппаратные константы много лучше программных
2) паскаль - я имел ввиду турбопаскаль, дельфи
3) цифры: 
   fldpi - 2байта
   pi dt 3.14.... / fld [pi] - 10+6 байт
4) если бы ты видел код который те генерит твой компилятор, ты бы не говорил о "минимизации простоя конвеера"
какбэ вот такой код при конфигурации "релиз" - это реальность
.text:1000122F                 mov     eax, dword ptr [g_hEngine]
.text:10001234                 mov     dword ptr [eax+56F5D8h], offset Hook_ALineagePlayerController_PlayerCalcView(AActor *,FVector *,FRotator *)
.text:1000123E                 mov     ecx, dword ptr [g_hEngine]
.text:10001244                 mov     dword ptr [ecx+57B968h], offset loc_10001190
.text:1000124E                 mov     edx, dword ptr [g_hEngine]


J0ker, ок, будет говорить исключительно о компиляторе MSVC. так вот у него кодогенератор - гуан*

насчет кода для FPU - вот так вот в MSVC передаются 32-разрядные значения float
.text:10001344                 fld     [esp+18h+arg_4]
.text:10001348                 fstp    [esp+18h+var_14]
.text:1000134C                 fld     dword ptr [eax+4]
.text:1000134F                 fstp    [esp+18h+var_18]
.text:10001352                 call    FCanvasUtil::DrawLine(float,float,float,float,FColor,int)
видимо те кто писали кодогенератор малость не учли, что dword'ы в стек можно запихивать командой push, а не через стек FPU %)


Это сообщение отредактировал(а) GoldFinch - 8.12.2008, 20:08

GoldFinch, объясняю еще раз для самых одаренных. Мне. Плевать. На. Красоту. Ассемблерного. Кода. Если бахвалишься своей труъ-ассемблерностью, подтверди свое превосходство, представив реализацию какого-нибудь численного алгоритма на С++ и на асме. И время, за которое эти реализации выполняются.

Kallikanzarid, вот тебе какбэ алгоритм получения 80-разрядной константы Pi, разница в размере - в 8 раз, разница в быстродействии в единицы - десятки раз, в зависимости от расположения константы в кеше или нет.
Не нравится - выбери другой алгоритм, метод, условия измерения и представь свой труъ С++ код, ато я на С++ меньше месяца пишу, могу true с false через strlen() сравнивать.

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

Это сообщение отредактировал(а) J0ker - 8.12.2008, 20:45

J0ker, и где же ты там преобразование увидел? я тольк увидел преобразование m32real->m80real->m32real. там какбэ fld а не fild

Это сообщение отредактировал(а) GoldFinch - 8.12.2008, 20:48

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

а это не решение? о_О
pushd     [esp+18h+arg_4]
pushd     [eax+4]
call    FCanvasUtil::DrawLine(float,float,float,float,FColor,int)