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

Ш>>>Для обращения к функциям API придётся делать адаптеры, естественно.
MN>>Вот только если кто-нть обойдёт эти адаптеры — абзац выйдет... И кто в данном случае будет прав? Ведь мы не взирая на рекомендации производителя Visual Studio не использовать stl в своих проектах всё равно используем (кажись когда-то в MSDN-е было такое замечание, что stl поставляется только для совместимости с другим кодом и использовать её в новых проектах не рекоменуется).

maq>Вообще полный бред. Где вы такое вычитали?

В какой-то из старых версий MSDN`а, какой именно не помню (что-то около 2000). Если хотите можете перерыть их и найдёте, я в своё время был очень удивлён этому заявлению. Но к данному спору это не имеет никакого отношения.

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

MN>>Следует заметить, что произвольная реализация C++ возможна только в операционках типа MS DOS, а в операционках класса Windows она будет очень сильно связана с возможностями и требованиями ОС.

maq>ИМХО бред какой то?
Пример, некоторые функции Win32 принимают вещественные числа, причём в формате IEEE 754. Если компилятор будет представлять их по другому, то огребём очень много гемороя по их преобразованию из одного формата в другой.
Ещё пример, тот же преславутый nul-pointer — в Win32 сторого определены указатели, которые вопринимаются ядром как null-pointer. А большинство WinAPI-шных функций, требующих на входе null-pointer вообще просто сравнивают их с 0.

MN>>Строго говоря функция ZeroMemory — это API-функция конкретной операционной системы и реализация компилятора тут не причём — это первое.

maq>Не совсем, вернее не всегда.
maq>Если вы посмотрите .h файл то ZeroMemory определен макросом как memset((Destination),0,(Length)).
maq>А memset это уже функция CRT.
Не правда... читайте внимательнее:

//MAPIWin.h
#if !defined(_WIN32)
#define    ZeroMemory(pb,cb)            memset((pb),0,(cb))
#endif

//WinBase.h
#define ZeroMemory RtlZeroMemory

В memset он превращается только для платформ отличных от Win32 (например, Win16)

MN>>Второе — эта операционная система предполагает, что null-pointer value — это 0 (если быть совсем точным, то это все значения указателей, расположенных в диапазоне 0x00000000 — 0x0000FFFF). Поэтому если компилятор в качестве null-pointer value выбирает скажем 0xFFFFFFFF, любой вызов API-функции, ожадающей получение указателя проинициализированного значением null-pointer values, закончиться неудачей. Следовательно либо такой компилятор будет порождать неработоспособный код, либо надо как раз пользоваться функцией ZeroMemory, а не ={0}.

maq>Вы не найдете такой компилятор для операционки предполагающей что null-pointer value — 0
Не понял утверждения... Win32 предполагает, что null-pointer value — это в том числе 0x00. M$VC, Builder предполагают так же.

maq>Вообще проблема надуманная, преимущество конструкции = {0} в том что это переносимый и безопасный код.
maq>А какое преимущество у ZeroMemory? Никаких.
Я же сказал, читайте внимательнее ветку...
Если у вас структура содержащая UDT, то тогда только ={0} или даже вообще определение конструктора по-умолчанию, который инициализаирует её правильным образом.
Но человек задал вопрос, касающийся низкоуровневого кода, взаимодействующего с API операционной системы. В таком коде фигурируют только POD-структуры, в таких случаях имеет право быть ZeroMemory или даже лучше memset — для переносимости.
Для чего это надо? Хотя бы для таких хитрожопых компиляторов, которые в отличие от операцонной системы считают что null-pointer value это не 0. Операционка же ожидает, что ей прилетит кусок памяти забитый сброшенными битами. И ей по барабану, что данный компилятор не считает такой указатель 0-вым.

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

Д>Признаюсь честно, привык писать обнуление структур в таком стиле:
Д> WNDCLASSEX wcx = { 0 };

здесь лучше так:

WNDCLASSEX wc={sizeof(WNDCLASSEX)};

PS: а на счет обнуления структур я и не знал , ща буду использовать

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

АТ>>Ну тут следует сразу заметить, что в рамках языка С++ термин "платформа" является эквивалентом термина "реализация", а не термина "аппаратная часть" или "оперционная система" как часто ошибочно полагают. Поэтому если ты уже здесь заговорил о платформе, то это — MSVC++ 6 (или какой там имелся в виду) для Win32, а не сама Win32.

MN>Следует заметить, что произвольная реализация C++ возможна только в операционках типа MS DOS, а в операционках класса Windows она будет очень сильно связана с возможностями и требованиями ОС.

Нет.

АТ>>Строго говоря, в официальной теминологии языка С++ вообще нет термина "платформа", а во всех соответствующих местах используется именно термин "реализация". В этом пристутвует очевидная логика — конкретная реализация (компилятор) если захочет, может запросто использовать физически ненулевые null-pointer values, физически ненулевые нули целочисленных типов, обратный код для представления отрицательных чисел (вместо дополнительного), отличный от IEEE 754 формат представления плавающих чисел и т.п. выкрунтасы, даже если все это идет вразрез с соглашениями используемой ОС и аппаратуры — т.е. все на той же x86 Win32.

MN>Строго говоря функция ZeroMemory — это API-функция конкретной операционной системы и реализация компилятора тут не причём — это первое.

Напомню, что речь идет не о 'ZeroMemory' как таковой, а о совместимости результатов 'ZeroMemory' с результатами обнуления, сделанными средствами именно реализации ('={0}'). Так что реализация тут очень даже причем.

MN>Второе — эта операционная система предполагает, что null-pointer value — это 0 (если быть совсем точным, то это все значения указателей, расположенных в диапазоне 0x00000000 — 0x0000FFFF).

У операционной системы нет понятия null-pointer value (NPV). Это понятие чисто языковое. Точнее, даже если таковое и имеется, то это системное понятие NPV к языковому понятию NPV никакого отношения не имеет.

MN>Поэтому если компилятор в качестве null-pointer value выбирает скажем 0xFFFFFFFF, любой вызов API-функции, ожадающей получение указателя проинициализированного значением null-pointer values, закончиться неудачей.

Ну, это уже будет некорректная реализация! Всякий раз, когда требуется переход от языкового NPV к системному NPV (и/или обратно) реализация обязана выполнить соответствующее неявное преобразование.

MN>Следовательно либо такой компилятор будет порождать неработоспособный код, либо надо как раз пользоваться функцией ZeroMemory, а не ={0}.

Вывод построен на неверной посылке.

АТ>>...все это можно достаточно очевидным образом реализовать и заставить работать.
MN>Подкиньте хотя бы идею как это очевидным образом реализовать и заставить работать, если операционная система делает некоторые предположения относительно принимаемых её значений.

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

АТ>>Да, если задаться целью, можно реализовать такую C++ платформу и для x86 Win32.

MN>Инитересно, как в такой реализации будут интерпретироваться результаты вещественного типа, возвращаемые API-вызовами операционной системы? Или придётся ещё писать кучу функций типа float win32_float_to_this_magic_cpp_float(float)?

В смысле "писать"? Кому придется? Реализация, разумеется, должна уметь выполнять все необходимые преобразования прозрачно для пользователя. С помощью именно вот таких функций, например.

Здравствуйте, Mr. None, Вы писали:
Ш>>Для обращения к функциям API придётся делать адаптеры, естественно.
MN>Вот только если кто-нть обойдёт эти адаптеры — абзац выйдет... И кто в данном случае будет прав?

В смысле "обойдет"? Обойдет хаками? Ну так сам виноват. В таком случае это вопрос не заслуживает даже и упоминания.

MN>Ведь мы не взирая на рекомендации производителя Visual Studio не использовать stl в своих проектах всё равно используем (кажись когда-то в MSDN-е было такое замечание, что stl поставляется только для совместимости с другим кодом и использовать её в новых проектах не рекоменуется).

Скорее всего речь шла о поставке двух альтернативных версий STL — старой и новой. И именно о старой говорилось, что она поставляется только для совместимости со старым кодом и использовать ее в новых проектах не рекомендуется.

MN>>>Инитересно, как в такой реализации будут интерпретироваться результаты вещественного типа, возвращаемые API-вызовами операционной системы? Или придётся ещё писать кучу функций типа float win32_float_to_this_magic_cpp_float(float)?

Ш>>Ага, именно так.
MN>МАМА!! РОДИ МЕНЯ ОБРАТНО!!!!!

И? Как именно это надо понимать?

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

MN>>Следует заметить, что произвольная реализация C++ возможна только в операционках типа MS DOS, а в операционках класса Windows она будет очень сильно связана с возможностями и требованиями ОС.

АТ>Нет.

Вы сами себе противоречите:

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

АТ>Реализация, разумеется, должна уметь выполнять все необходимые преобразования прозрачно для пользователя. С помощью именно вот таких функций, например.

Выходит, что всё таки связана реализация с требованиями ОС...

MN>>Строго говоря функция ZeroMemory — это API-функция конкретной операционной системы и реализация компилятора тут не причём — это первое.

АТ>Напомню, что речь идет не о 'ZeroMemory' как таковой, а о совместимости результатов 'ZeroMemory' с результатами обнуления, сделанными средствами именно реализации ('={0}'). Так что реализация тут очень даже причем.

Вообще-то если я не ошибаюсь, то человек спросил о том, что лучше ={0} или ZeroMemory и нигде г-н Дарней не поднимал вопроса о совместимости результатов в первом и во втором способе. В случае POD-структур работающих с API-шными вызовами применение ZeroMemory, или memset (для переносимости), вполне правомерно. Более того в этом случае результат будет точно соответствовать требованиям операционной системы (в данном случае речь идёт о Win32) и никак не будет связан с реализацие компилятора.
Лично я использую такую практику: в модулях высокого уровня чаще всего использую конструкторы (по-умолчанию или с параметрами) или реже зануление в стиле ={0}, в модулях низкого уровня, непосредственно контактирующих со слоем API-вызовов для POD-структур из WinAPI — memset.

MN>>Второе — эта операционная система предполагает, что null-pointer value — это 0 (если быть совсем точным, то это все значения указателей, расположенных в диапазоне 0x00000000 — 0x0000FFFF).

АТ>У операционной системы нет понятия null-pointer value (NPV). Это понятие чисто языковое. Точнее, даже если таковое и имеется, то это системное понятие NPV к языковому понятию NPV никакого отношения не имеет.

Ну давайте ещё забредём в дебри рассуждений о том, что указатель вообще не обязан в точности соответствовать понятию адреса которым оперирует операционная система. И посмотрим, что у нас из этого получиться...
А в случае Win32 и многих компиляторов для этой платформы (я говорю многих, дабы не навлечь на себя новую волну возмущения, хотя IMHO — всех). Указатель — это адрес, NPV — это 0, что соответствует системному требованию налагаемому на значение NPV операционкой — любой указатель в диапазоне [0x00000000; 0x0000FFFF].

MN>>Поэтому если компилятор в качестве null-pointer value выбирает скажем 0xFFFFFFFF, любой вызов API-функции, ожадающей получение указателя проинициализированного значением null-pointer values, закончиться неудачей.

АТ>Ну, это уже будет некорректная реализация! Всякий раз, когда требуется переход от языкового NPV к системному NPV (и/или обратно) реализация обязана выполнить соответствующее неявное преобразование.

Так вы же сказали, что реализация никак не связана с платформой...

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

АТ>Здравствуйте, Mr. None, Вы писали:
Ш>>>Для обращения к функциям API придётся делать адаптеры, естественно.
MN>>Вот только если кто-нть обойдёт эти адаптеры — абзац выйдет... И кто в данном случае будет прав?

АТ>В смысле "обойдет"? Обойдет хаками? Ну так сам виноват. В таком случае это вопрос не заслуживает даже и упоминания.

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

MN>>Ведь мы не взирая на рекомендации производителя Visual Studio не использовать stl в своих проектах всё равно используем (кажись когда-то в MSDN-е было такое замечание, что stl поставляется только для совместимости с другим кодом и использовать её в новых проектах не рекоменуется).

АТ>Скорее всего речь шла о поставке двух альтернативных версий STL — старой и новой. И именно о старой говорилось, что она поставляется только для совместимости со старым кодом и использовать ее в новых проектах не рекомендуется.

Нет речь шла о политике Microsoft в отношении stl. Когда именно она изменилась не знаю, но в те времена stl в поставке шла в единственном экземпляре.

MN>>>>Инитересно, как в такой реализации будут интерпретироваться результаты вещественного типа, возвращаемые API-вызовами операционной системы? Или придётся ещё писать кучу функций типа float win32_float_to_this_magic_cpp_float(float)?

Ш>>>Ага, именно так.
MN>>МАМА!! РОДИ МЕНЯ ОБРАТНО!!!!!

АТ>И? Как именно это надо понимать?
А понимать это так. Представьте, что вам каждое значение возвращённое системной функцией придётся конвертировать вот таким агрегатом: win32_float_to_this_magic_cpp_float, или таким W32F2TMCPPF... Я представил, потому как был опыт такого программизма из-за корявой реализации одного SDK.

maq>>Если вы посмотрите .h файл то ZeroMemory определен макросом как memset((Destination),0,(Length)).
maq>>А memset это уже функция CRT.
MN>Не правда... читайте внимательнее:
MN>

MN>//MAPIWin.h
MN>#if !defined(_WIN32)
MN>#define    ZeroMemory(pb,cb)            memset((pb),0,(cb))
MN>#endif

MN>//WinBase.h
MN>#define ZeroMemory RtlZeroMemory
MN>

MN>В memset он превращается только для платформ отличных от Win32 (например, Win16)

Ну я что такое RtlZeroMemory?

//WinNt.h
#if defined(_M_AMD64)
...
#else
#define RtlZeroMemory(Destination,Length) memset((Destination),0,(Length))
#endif

Так что и на WIN32 это memset
Хотя конечно ntdll.dll экспортирует RtlZeroMemory

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

maq>>>Если вы посмотрите .h файл то ZeroMemory определен макросом как memset((Destination),0,(Length)).
maq>>>А memset это уже функция CRT.
MN>>Не правда... читайте внимательнее:
MN>>

MN>>//MAPIWin.h
MN>>#if !defined(_WIN32)
MN>>#define    ZeroMemory(pb,cb)            memset((pb),0,(cb))
MN>>#endif

MN>>//WinBase.h
MN>>#define ZeroMemory RtlZeroMemory
MN>>

MN>>В memset он превращается только для платформ отличных от Win32 (например, Win16)

MS>Ну я что такое RtlZeroMemory?
MS>

MS>//WinNt.h
MS>#if defined(_M_AMD64)
MS>...
MS>#else
MS>#define RtlZeroMemory(Destination,Length) memset((Destination),0,(Length))
MS>#endif
MS>

MS>Так что и на WIN32 это memset
MS>Хотя конечно ntdll.dll экспортирует RtlZeroMemory

Что ещё один макрос !! Эти уроды из M$ своими макросами уже достали !!! И всё таки снова поправлю:

#if defined(_M_AMD64) || defined(_M_IA64)
NTSYSAPI
VOID
NTAPI
RtlZeroMemory (
   VOID UNALIGNED *Destination,
   SIZE_T Length
   );

#else
#define RtlZeroMemory(Destination,Length) memset((Destination),0,(Length))
#endif

Так что в конечном итоге это всё равно функция API и на Win64 даже не трансформируется в memset (по крайней мере явным образом).

Hello, Plague!
You wrote on Wed, 16 Jun 2004 08:16:10 GMT:

P> Здравствуйте, Дарней, Вы писали:

Д>> Признаюсь честно, привык писать обнуление структур в таком стиле:
Д>> WNDCLASSEX wcx = { 0 };

P> здесь лучше так:
P>

 P> WNDCLASSEX wc={sizeof(WNDCLASSEX)};
 P>

P>

А еще лучше так:

WNDCLASSEX ext_data = { sizeof(ext_data) };

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


[]

WBR

> мы не взирая на рекомендации производителя Visual Studio не использовать stl в своих проектах всё равно используем (кажись когда-то в MSDN-е было такое замечание, что stl поставляется только для совместимости с другим кодом и использовать её в новых проектах не рекоменуется).

Что-то многовато всевозможных "кажись". Я склонен считать это утверждение твоей выдумкой, пока не последует конкретной ссылки или цитаты из MSDN.

Здравствуйте, Павел Кузнецов, Вы писали:

>> мы не взирая на рекомендации производителя Visual Studio не использовать stl в своих проектах всё равно используем (кажись когда-то в MSDN-е было такое замечание, что stl поставляется только для совместимости с другим кодом и использовать её в новых проектах не рекоменуется).

ПК>Что-то многовато всевозможных "кажись". Я склонен считать это утверждение твоей выдумкой, пока не последует конкретной ссылки или цитаты из MSDN.

"Почему вы говорите о ней во множественном числе?" — Полосатый рейс.

Всего один "кажись". Если найду эту цитату то приведу.

> maq>А какое преимущество у ZeroMemory? Никаких.

> Я же сказал, читайте внимательнее ветку...

Пока что преимуществ ZeroMemory в ней не видать.

> Но человек задал вопрос, касающийся низкоуровневого кода, взаимодействующего с API операционной системы.

Это твоя трактовка, не обязательно совпадающая с авторской.

> В таком коде фигурируют только POD-структуры, в таких случаях имеет право быть ZeroMemory или даже лучше memset — для переносимости. Для чего это надо? Хотя бы для таких хитрожопых компиляторов, которые в отличие от операцонной системы считают что null-pointer value это не 0.

Как уже говорилось, если такой компилятор будет на такой операционке, то он как-нибудь должен будет делать соответствующие преобразования. И если ему вместо "логического" нуля подсунут "физический", полученный с помощью memset, то в ходе этих преобразований, "физический" ноль нулем быть перестанет. В случае же "обнуления" через = { 0 }, все отработает, как ожидалось, т.к. никаких сюрпризов для компилятора мы не создавали.

Здравствуйте, Павел Кузнецов, Вы писали:

>> А я предпочитаю такую конструкцию:
>>
>>

>> HANDLE hHeap = GetProcessHeap();
>> MSG *pMsg = (MSG*) HeapAlloc(hHeap, HEAP_ZERO_MEMORY, sizeof(MSG));
>> //...
>> HeapFree(hHeap, 0, pMsg);
>>

ПК>Лечение насморка отрубанием головы: зачем использовать кучу там, где можно обойтись выделением памяти "в стеке"?

Согласен, исправлюсь...

>> Работаю только на win32, поэтому о переносе на другие платформы не задумывался.

ПК>Эквивалентное "решение", работающее и на других платформах — calloc.

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


S>Согласен, исправлюсь...

не ври

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

MN>>>Следует заметить, что произвольная реализация C++ возможна только в операционках типа MS DOS, а в операционках класса Windows она будет очень сильно связана с возможностями и требованиями ОС.

АТ>>Нет.

Мое "нет" относилось именно к Вашему основному утверждению, что "произвольная реализация C++ возможна только в операционках типа MS DOS". Это неверное утверждение. Мое "нет" никак не относится к сопутствующим утверждениям, которые Вы предусмотрительно запихали в процитированное предложеие.

MN>Вы сами себе противоречите:

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

АТ>>Реализация, разумеется, должна уметь выполнять все необходимые преобразования прозрачно для пользователя. С помощью именно вот таких функций, например.

MN>Выходит, что всё таки связана реализация с требованиями ОС...

Я никогда не утверждал, что реализация не связяна с требованиями ОС. Более того, с самого начала моего участия в этой дискуссии я неоднократно ссылался на существование такой связи.

MN>>>Строго говоря функция ZeroMemory — это API-функция конкретной операционной системы и реализация компилятора тут не причём — это первое.

АТ>>Напомню, что речь идет не о 'ZeroMemory' как таковой, а о совместимости результатов 'ZeroMemory' с результатами обнуления, сделанными средствами именно реализации ('={0}'). Так что реализация тут очень даже причем.

MN>Вообще-то если я не ошибаюсь, то человек спросил о том, что лучше ={0} или ZeroMemory и нигде г-н Дарней не поднимал вопроса о совместимости результатов в первом и во втором способе.

Не понял. Вопрос о том "что лучше" существует тогда и только тогда, когда существует выбор. В даном случае — выбор из двух эквивалентных (по мнению автора вопроса) способов произвести обнуление. Другими словами, на посылке совместимости результатов весь вопрос и основан. Во-первых, это посылка в общем случае неверна. Во-вторых, и даже важнее, вся соль в том, что нет никакого смысла делать что-то "хаком", если можно сделать это же корректным с точки зрения языка способом.

MN>В случае POD-структур работающих с API-шными вызовами применение ZeroMemory, или memset (для переносимости), вполне правомерно. Более того в этом случае результат будет точно соответствовать требованиям операционной системы (в данном случае речь идёт о Win32) и никак не будет связан с реализацие компилятора.

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

MN>Лично я использую такую практику: в модулях высокого уровня чаще всего использую конструкторы (по-умолчанию или с параметрами) или реже зануление в стиле ={0}, в модулях низкого уровня, непосредственно контактирующих со слоем API-вызовов для POD-структур из WinAPI — memset.

Не вижу оснований для этого.

MN>>>Второе — эта операционная система предполагает, что null-pointer value — это 0 (если быть совсем точным, то это все значения указателей, расположенных в диапазоне 0x00000000 — 0x0000FFFF).

АТ>>У операционной системы нет понятия null-pointer value (NPV). Это понятие чисто языковое. Точнее, даже если таковое и имеется, то это системное понятие NPV к языковому понятию NPV никакого отношения не имеет.

MN>Ну давайте ещё забредём в дебри рассуждений о том, что указатель вообще не обязан в точности соответствовать понятию адреса которым оперирует операционная система. И посмотрим, что у нас из этого получиться...

Хм... И? За примерами далено ходить не надо — во времена MS-DOS были многочисленные модели памяти, в которых языковый указатель не сответствовал системному. Да и Win32, если внимаиельно посмотреть, ситуация не сильно отличается. А если еще вспомнить указатели на члены классов — так эти вообще к операционной системе и близко не лежали...

MN>А в случае Win32 и многих компиляторов для этой платформы (я говорю многих, дабы не навлечь на себя новую волну возмущения, хотя IMHO — всех). Указатель — это адрес, NPV — это 0, что соответствует системному требованию налагаемому на значение NPV операционкой — любой указатель в диапазоне [0x00000000; 0x0000FFFF].

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

MN>>>Поэтому если компилятор в качестве null-pointer value выбирает скажем 0xFFFFFFFF, любой вызов API-функции, ожадающей получение указателя проинициализированного значением null-pointer values, закончиться неудачей.

АТ>>Ну, это уже будет некорректная реализация! Всякий раз, когда требуется переход от языкового NPV к системному NPV (и/или обратно) реализация обязана выполнить соответствующее неявное преобразование.

MN>Так вы же сказали, что реализация никак не связана с платформой...

Нет, я такого не говорил.

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

MN>Здравствуйте, Андрей Тарасевич, Вы писали:

АТ>>Здравствуйте, Mr. None, Вы писали:
Ш>>>>Для обращения к функциям API придётся делать адаптеры, естественно.
MN>>>Вот только если кто-нть обойдёт эти адаптеры — абзац выйдет... И кто в данном случае будет прав?

АТ>>В смысле "обойдет"? Обойдет хаками? Ну так сам виноват. В таком случае это вопрос не заслуживает даже и упоминания.

MN>Если эти адаптеры будут идти как функции некой внешней библиотеки, то случиться день и программист вызовет функцию API без адаптера. Если они будут встроены в компилятор на уровне языка, то это противоречит вашему утверждению о том, что реализация языка не связана с платформой для которой он предназначен.

Я такого не утверждал. Более того, я неоднократно утверждал обратное.

MN>>>>>Инитересно, как в такой реализации будут интерпретироваться результаты вещественного типа, возвращаемые API-вызовами операционной системы? Или придётся ещё писать кучу функций типа float win32_float_to_this_magic_cpp_float(float)?

Ш>>>>Ага, именно так.
MN>>>МАМА!! РОДИ МЕНЯ ОБРАТНО!!!!!

АТ>>И? Как именно это надо понимать?
MN>А понимать это так. Представьте, что вам каждое значение возвращённое системной функцией придётся конвертировать вот таким агрегатом: win32_float_to_this_magic_cpp_float, или таким W32F2TMCPPF... Я представил, потому как был опыт такого программизма из-за корявой реализации одного SDK.

Он бы ничем не отличался от опыта программизма в условиях корявой реализации традиционного SDK или библиотеки времени выполнения. Строго говоря, нет никакой принципиальной разницы. Современные SDK и библиотеки времени выполнения уже и сейчас выполняют соврешенно аналогичные по свой сути преобразования. Та же поддержка 'FILE*' в ОС, работающей с файлами через handles — ни что иное как именно такое преобразование. Введение дополнительных подобных конверторов ничего бы принципиально не поменяло.

Здравствуйте, Павел Кузнецов, Вы писали:

>> Но человек задал вопрос, касающийся низкоуровневого кода, взаимодействующего с API операционной системы.

ПК>Это твоя трактовка, не обязательно совпадающая с авторской.

А кто сказал, что ваша трактовка совпадает с авторской? Автор не упомянул, что его интересуют способы зануления структур в общем виде, в том числе содержащих UDT и прочее, прочее, прочее... В вопросе автора фигурировали структуры и функции WinAPI — код который может появиться исключительно в модулях самого низкого уровня приложения для ОС Windows. В них и не пахнет ни UDT, ни конструкторами ни чем другим. При ответе же на его вопрос, вомнили всё — и связанное, и не связанное. Даже переносимость кода сюда приплели, хотя о какой переносимости кода может идти речь, когда в нём присуствует WNDCLASSEX и преславутая ZeroMemory... Если уж говорить о переносимости кода между различными компиляторами в рамках одной операционки (Windows), то вариант с ZeroMemory будет более переносим.

>> В таком коде фигурируют только POD-структуры, в таких случаях имеет право быть ZeroMemory или даже лучше memset — для переносимости. Для чего это надо? Хотя бы для таких хитрожопых компиляторов, которые в отличие от операцонной системы считают что null-pointer value это не 0.

ПК>Как уже говорилось, если такой компилятор будет на такой операционке, то он как-нибудь должен будет делать соответствующие преобразования. И если ему вместо "логического" нуля подсунут "физический", полученный с помощью memset, то в ходе этих преобразований, "физический" ноль нулем быть перестанет. В случае же "обнуления" через = { 0 }, все отработает, как ожидалось, т.к. никаких сюрпризов для компилятора мы не создавали.

В таком случае библиотека WinAPI тоже должна будет соответствующим образом портирована на такой компилятор и ZeroMemory должен будет работать так как и работал везде.

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

MN>>Вообще-то если я не ошибаюсь, то человек спросил о том, что лучше ={0} или ZeroMemory и нигде г-н Дарней не поднимал вопроса о совместимости результатов в первом и во втором способе.

АТ>Не понял. Вопрос о том "что лучше" существует тогда и только тогда, когда существует выбор. В даном случае — выбор из двух эквивалентных (по мнению автора вопроса) способов произвести обнуление. Другими словами, на посылке совместимости результатов весь вопрос и основан. Во-первых, это посылка в общем случае неверна.

В том примере который привёл автор эти два способа абсолютно эквиваленты по отношению к результату.

АТ>Во-вторых, и даже важнее, вся соль в том, что нет никакого смысла делать что-то "хаком", если можно сделать это же корректным с точки зрения языка способом.

Использование ZeroMemory — это не хак а вполне корректный с точки зрения операционной системы способ зануления структуры используемой при системном вызове.

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

MN>Здравствуйте, Андрей Тарасевич, Вы писали:

MN>>>Вообще-то если я не ошибаюсь, то человек спросил о том, что лучше ={0} или ZeroMemory и нигде г-н Дарней не поднимал вопроса о совместимости результатов в первом и во втором способе.

АТ>>Не понял. Вопрос о том "что лучше" существует тогда и только тогда, когда существует выбор. В даном случае — выбор из двух эквивалентных (по мнению автора вопроса) способов произвести обнуление. Другими словами, на посылке совместимости результатов весь вопрос и основан. Во-первых, это посылка в общем случае неверна.

MN>В том примере который привёл автор эти два способа абсолютно эквиваленты по отношению к результату.

АТ>>Во-вторых, и даже важнее, вся соль в том, что нет никакого смысла делать что-то "хаком", если можно сделать это же корректным с точки зрения языка способом.

MN>Использование ZeroMemory — это не хак а вполне корректный с точки зрения операционной системы способ зануления структуры используемой при системном вызове.

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы