Здравствуйте, 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.
Не правда... читайте внимательнее:
В 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-вым.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, 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>
Здравствуйте, MShura, Вы писали:
maq>>>Если вы посмотрите .h файл то ZeroMemory определен макросом как memset((Destination),0,(Length)). maq>>>А memset это уже функция CRT. MN>>Не правда... читайте внимательнее: MN>>
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
> мы не взирая на рекомендации производителя Visual Studio не использовать stl в своих проектах всё равно используем (кажись когда-то в MSDN-е было такое замечание, что stl поставляется только для совместимости с другим кодом и использовать её в новых проектах не рекоменуется).
Что-то многовато всевозможных "кажись". Я склонен считать это утверждение твоей выдумкой, пока не последует конкретной ссылки или цитаты из MSDN.
Posted via RSDN NNTP Server 1.9 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> мы не взирая на рекомендации производителя Visual Studio не использовать stl в своих проектах всё равно используем (кажись когда-то в MSDN-е было такое замечание, что stl поставляется только для совместимости с другим кодом и использовать её в новых проектах не рекоменуется).
ПК>Что-то многовато всевозможных "кажись". Я склонен считать это утверждение твоей выдумкой, пока не последует конкретной ссылки или цитаты из MSDN.
"Почему вы говорите о ней во множественном числе?" — Полосатый рейс.
Всего один "кажись". Если найду эту цитату то приведу.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
> maq>А какое преимущество у ZeroMemory? Никаких.
> Я же сказал, читайте внимательнее ветку...
Пока что преимуществ ZeroMemory в ней не видать.
> Но человек задал вопрос, касающийся низкоуровневого кода, взаимодействующего с API операционной системы.
Это твоя трактовка, не обязательно совпадающая с авторской.
> В таком коде фигурируют только POD-структуры, в таких случаях имеет право быть ZeroMemory или даже лучше memset — для переносимости. Для чего это надо? Хотя бы для таких хитрожопых компиляторов, которые в отличие от операцонной системы считают что null-pointer value это не 0.
Как уже говорилось, если такой компилятор будет на такой операционке, то он как-нибудь должен будет делать соответствующие преобразования. И если ему вместо "логического" нуля подсунут "физический", полученный с помощью memset, то в ходе этих преобразований, "физический" ноль нулем быть перестанет. В случае же "обнуления" через = { 0 }, все отработает, как ожидалось, т.к. никаких сюрпризов для компилятора мы не создавали.
Posted via RSDN NNTP Server 1.9 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
ПК>Лечение насморка отрубанием головы: зачем использовать кучу там, где можно обойтись выделением памяти "в стеке"?
Согласен, исправлюсь...
>> Работаю только на win32, поэтому о переносе на другие платформы не задумывался.
ПК>Эквивалентное "решение", работающее и на других платформах — calloc.
Здравствуйте, 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 — это не хак а вполне корректный с точки зрения операционной системы способ зануления структуры используемой при системном вызове.
Не с точки зрения операционной системы, а в рамках конкретной платформы. В данном случае используется особенность платформы, состоящая в том, что примитивные типы данных имеют нулевое значение, представимое цепочкой нулевых байт.
, ща буду использовать 
!!! И всё таки снова поправлю:
и на Win64 даже не трансформируется в memset (по крайней мере явным образом).
