> ПК>Только никто об этой "ошибке" тебе не скажет. Например: была когда-то структура, в которой, скажем, был член const char*, и кто-то "обнулял" ее с помощью memset, а впоследствии член был заменен, скажем, на std::string.
> Ок. У меня Visual C++ SP 5. Думаете он скомпилирует следущий код если убрать комментарий? >
Потом, когда у тебя будет предостаточно подобных "обнулений" по всему коду, член s вполне может быть заменен на std::string. И тогда компилятор и не пикнет, а у тебя останутся "мины" в виде заполнения std::string нулями.
Если бы в данном фрагменте была использована инициализация по умолчанию одним из следующих способов, предусмотренных непосредственно языком:
SomeStruct s = SomeStruct();
SomeStruct s = { 0 };
Или даже так, если компилятор поновее:
SomeStruct s = { };
то, при изменении типа s на std::string, либо компилятор бы "возмутился" (нестандартное поведение, но в данном случае это не важно — главное, что ерунду не начнет делать), либо бы продолжал делать правильную вещь.
Таким образом, вопреки твоим прежним заявлениям, использование ZeroMemory вовсе не лучше, чем использование инициализатора. Скорее даже наоборот. Что еще-то до сих пор непонятно?
> ПК>Хорошо, уговорил. Используй Только другим не навязывай.
> Мне это не надо!
Тогда как понимать это твое утверждение?
Лучше использовать ZeroMemory()
> Сколько бы мы тут не говорили, каждый из нас останется при своем мнении.
Мнения тут совершенно ни при чем; это не фасон платья, где уместны суждения: нравится — не нравится. Здесь все просто, как дважды два: есть два подхода к "обнулению" агрегатов. Один предусмотрен языком, и его использование контролируется компилятором. Второй, при том, что ничего к первому не добавляет, непосредственно языком не гарантируется, компилятором не поддерживается, и, соответственно, является менее безопасным. Какие тут могут быть мнения?
> Только Вы говорите о высокоуровневых обьектах, для которых ZeroMemory() неприемлем,
Нет, я говорю о том, какой из двух способов "обнуления" структур более предпочтителен в аналогичных случаях.
> а я же и автор начального топика говорим о низкоуровневом обнулении куска памяти.
От автора оригинального сообщения я подобных заявлений не слышал. Да и какой смысл в абстрактном "низкоуровневом обнулении куска памяти", если оно не означает обнуление всех элементов структуры?
> PS. Меня поражает как люди бросаются ссылками на стандарт по синтаксису словно задались задачей знать каждую синтаксическую конструкцию языка. Только синтаксис-то и знают, а вот в вопросе является ли creat() стандартной функцией или все-таки системным вызовом тормозят. Точно также был вопрос по макросам тут из stdarg.h, так что-то не особо бросались знаниями в этом направлении.
Переход на обсуждение знаний собеседников или других участников форума, мало того, что ничего конструктивного в дискуссию не привносит, так еще и прямо запрещен правилами форумов РСДН.
> PPS. У Вас, Павел, указан неверный автор цитаты!
Настолько верный, насколько верно его указал Кнут, которому эту цитату часто ошибочно приписывают.
Posted via RSDN NNTP Server 1.9 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[9]: ZeroMemory vs xxx = { 0 };
От:
Аноним
Дата:
13.06.04 02:51
Оценка:
Мы говорим о Фоме и о Ереме... ПК>Ты невнимательно читаешь то, что я тебе пишу. Еще раз. Вот такой объект ты не возражаешь так инициализировать? ПК>
Да поймите Вы! Я НЕ говорю об инициализации обьекта! Инициализация поддерживается самим языком, а этот вызов, о котором мы так долго спорим и который Вы только что привели — просто обнуляет кусок памяти, выделенный для s.
ПК>Потом, когда у тебя будет предостаточно подобных "обнулений" по всему коду, член s вполне может быть заменен на std::string. И тогда компилятор и не пикнет, а у тебя останутся "мины" в виде заполнения std::string нулями.
И это я тоже понимаю! Только если Вы замените потом указатель на строку, то получается, что изначально дизайн был корявый, и мины вовсе не потому, что используется ZeroMemory() на string'ах, а из-за недостаточного планирования. Поэтому я и говорю, что ZeroMemory() можно использовать на структурах без классов.
ПК>Таким образом, вопреки твоим прежним заявлениям, использование ZeroMemory вовсе не лучше, чем использование инициализатора. Скорее даже наоборот. Что еще-то до сих пор непонятно?
Опять-таки, ZeroMemory() НЕ инициализрует обьект, и, разумеется это ошибка, использовать эту функция на структурах с классами.
ПК>Тогда как понимать это твое утверждение? ПК>
ПК>Лучше использовать ZeroMemory()
Забудьте про С++! Только С! У вас есть примерно такая структура:
struct packet {
unsigned short packet_len;
unsigned short flags;
union {
char text[100];
...
} u;
...
char reserved[8]; /* must be zero */
} packet;
Перед тем как заполнять эту структуру, имеет смысл ее обнулить (установить reserved в ноль, сбросить флаги и т.д.). Как бы Вы сделали? Я бы через ZeroMemory() обнулил всю структуру зараз а не struct packet packet = { 0 }; Ричард Стивенс так и делает, и по-моему у него есть какой-то комментарий на счет последнего стиля.
А затем через sendto() просто послать ее в сеть. Все sizeof packet байт! А если б std::string был, то посылка была бы сложнее. Вы применили классы и OOП к тому случаю где они совсем не нужны, и разговор давно уже свернул в другую плоскость. Вы говорите о высоко-уровневом коде (каким и должен быть С++) а я говорю о низко-уровневом (какой и есть С).
ПК>Мнения тут совершенно ни при чем; это не фасон платья, где уместны суждения: нравится — не нравится. Здесь все просто, как дважды два: есть два подхода к "обнулению" агрегатов. Один предусмотрен языком, и его использование контролируется компилятором. Второй, при том, что ничего к первому не добавляет, непосредственно языком не гарантируется, компилятором не поддерживается, и, соответственно, является менее безопасным. Какие тут могут быть мнения?
Все это так! Вы абсолютно правы! Только использование ZeroMemory() будет абсолютно безопасным если структура содержит только примитивные типы данных. Такой код, что привел Дарней используется на самом низком уровне системы. Сколько раз Вы инициализировали экземпляры классов через фигурные скобки? Думаю что ноль! А добавив std::string в такую структуру, она сама становится "высокоуровневым классом." (обратите внимание на скобки — я не говорю о конкретной реализации)
ПК>Нет, я говорю о том, какой из двух способов "обнуления" структур более предпочтителен в аналогичных случаях.
Да поймите Вы, обнуляют структуры только на низком уровне, и разумеется этот метод неприемлим для "сложных обьектов."
>> а я же и автор начального топика говорим о низкоуровневом обнулении куска памяти. ПК>От автора оригинального сообщения я подобных заявлений не слышал. Да и какой смысл в абстрактном "низкоуровневом обнулении куска памяти", если оно не означает обнуление всех элементов структуры?
I give up! Лучше выпьем и прекратим все эти споры ни о чем!
ПК>Переход на обсуждение знаний собеседников или других участников форума, мало того, что ничего конструктивного в дискуссию не привносит, так еще и прямо запрещен правилами форумов РСДН.
Сорри! Просто я полностью согласен со Страуструпом, что не нужно знать каждую черту языка, чтобы успешно программировать, а тут такие лойера!
ПК>Настолько верный, насколько верно его указал Кнут, которому эту цитату часто ошибочно приписывают.
Напишем Страуструпу, что он ошибся в авторстве этой цитаты?
> Перед тем как заполнять эту структуру, имеет смысл ее обнулить (установить reserved в ноль, сбросить флаги и т.д.). Как бы Вы сделали? Я бы через ZeroMemory() обнулил всю структуру зараз а не struct packet packet = { 0 }; Ричард Стивенс так и делает, и по-моему у него есть какой-то комментарий на счет последнего стиля.
Итак, правильно ли я понял, что единственным аргументом в пользу ZeroMemory() vs. { 0 } является то, что так делает некий Ричард Стивенс?
Posted via RSDN NNTP Server 1.9 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Аноним, Вы писали:
ПК>>Строго говоря, это относится не только к указателям, но и к целочисленным типам. А>Раз уж мы вдались в дебри юриспруденции языков программирования, то можете привести ссылку на этот "факт?" Насколько я знаю, на всех машинах int 0 будет всегда нулевым набором бит (другое дело разница между big-endian и little-endian архитектурами, но это совсем не то).
Стандарт языка этого не гарантирует. Помнится кто-то в Usenet-е даже упоминал реальную платформу, в которой использовался "бит нечетности".
А>0 float или double может не быть нулевым набором бит (нужно читать стандарт IEEE 754
Стандарт IEEE 754 никакого отношения к стандартам С и С++ не имеет.
А> точно также как 0 void * может не быть нулевым набором бит.
А это уже полный бред. Примеров платформ, в который null-pointer value задается ненулевым набором бит — вагон и маленькая тележка. Сделай поиск по Google Groups — там их навалом приводится.
Здравствуйте, Аноним, Вы писали: А>Перед тем как заполнять эту структуру, имеет смысл ее обнулить (установить reserved в ноль, сбросить флаги и т.д.). Как бы Вы сделали? Я бы через ZeroMemory() обнулил всю структуру зараз а не struct packet packet = { 0 }; Ричард Стивенс так и делает, и по-моему у него есть какой-то комментарий на счет последнего стиля.
Обнуление при помощи '={0}' тоже обнуляет всю структуру сразу в тех ситуациях, когда это возможно. Если какому-то компилятору вдруг захотелось "разбить" процесс обнуления каким-то неоптимальным образом — это проблемы этого компилятора, а не способа '={0}'.
А>Все это так! Вы абсолютно правы! Только использование ZeroMemory() будет абсолютно безопасным если структура содержит только примитивные типы данных.
Это бред. Абсолютно безопасным это является только для char типов. Это станет безопасным для боее широко числа интегральных типов в языке C99, когда выйдет соответствующая коррекция (если выйдет). Для плавающих типов, типов указателей и остальных это не будет безопасным никогда (по краней мере пока такой безопасностью даже и не пахнет).
А>Такой код, что привел Дарней используется на самом низком уровне системы. Сколько раз Вы инициализировали экземпляры классов через фигурные скобки? Думаю что ноль!
А я вот — инициализировал и очень много раз. Доктор, я — феномен?
А>А добавив std::string в такую структуру, она сама становится "высокоуровневым классом." (обратите внимание на скобки — я не говорю о конкретной реализации)
И тем не менее в этом конкретном случае все еще допускает инициализацию вида 'S s = s()'. Это будет по-прежнему выполнять обнуление всего того, для чего обнуление является умолчательной инициализацией. Всякие 'ZeroMemory' тут совсем отдыхают.
ПК>>Нет, я говорю о том, какой из двух способов "обнуления" структур более предпочтителен в аналогичных случаях. А>Да поймите Вы, обнуляют структуры только на низком уровне, и разумеется этот метод неприемлим для "сложных обьектов."
Обнуляют структцры на разных уровнях. Только вот всяких 'ZeroMemory' стараются избежать всегда, когда это возможно.
ПК>>Переход на обсуждение знаний собеседников или других участников форума, мало того, что ничего конструктивного в дискуссию не привносит, так еще и прямо запрещен правилами форумов РСДН. А>Сорри! Просто я полностью согласен со Страуструпом, что не нужно знать каждую черту языка, чтобы успешно программировать, а тут такие лойера!
"Программировать" — понятие весьма и весьма растяжимое.
"Андрей Тарасевич" <2174@news.rsdn.ru> wrote in message news:678449@news.rsdn.ru...
> ПК>>Строго говоря, это относится не только к указателям, но и к целочисленным типам. > А>Раз уж мы вдались в дебри юриспруденции языков программирования, то можете привести ссылку на этот "факт?" Насколько я знаю, на всех машинах int 0 будет всегда нулевым набором бит (другое дело разница между big-endian и little-endian архитектурами, но это совсем не то). > > Стандарт языка этого не гарантирует. Помнится кто-то в Usenet-е даже упоминал реальную платформу, в которой использовался "бит нечетности".
Огромное количество кода на Си заложено на то, что нули целочисленных типов представляются наборами сброшенных битов. Если действительно есть платформа, для которой это не так, то это, главным образом, проблема такой платформы, но не существующего кода.
Вся история использования функции calloc работает против таких платформ.
Здравствуйте, Андрей Тарасевич, Вы писали:
АТ>Здравствуйте, Аноним, Вы писали:
ПК>>>Строго говоря, это относится не только к указателям, но и к целочисленным типам. А>>Раз уж мы вдались в дебри юриспруденции языков программирования, то можете привести ссылку на этот "факт?" Насколько я знаю, на всех машинах int 0 будет всегда нулевым набором бит (другое дело разница между big-endian и little-endian архитектурами, но это совсем не то).
АТ>Стандарт языка этого не гарантирует. Помнится кто-то в Usenet-е даже упоминал реальную платформу, в которой использовался "бит нечетности".
А>>0 float или double может не быть нулевым набором бит (нужно читать стандарт IEEE 754
АТ>Стандарт IEEE 754 никакого отношения к стандартам С и С++ не имеет.
А>> точно также как 0 void * может не быть нулевым набором бит.
АТ>А это уже полный бред. Примеров платформ, в который null-pointer value задается ненулевым набором бит — вагон и маленькая тележка. Сделай поиск по Google Groups — там их навалом приводится.
Все круты — линейку в студию!!!!
Слушайте люди, вам что потрепаться хочется? Чего к человеку привязались? Вы изначальный вопрос прочитайте внимательно! Вас спросили, что лучше ZeroMemory или ={0}. Функция ZeroMemory присутсвует единственной платформе — Win32, и на этой платформе и null-pointer value равен 0 (точнее даже так: значение указателя равное 0 — это есть null-pointer value), и int 0 есть набор сброшенных битов. Причём здесь различные платформы, где есть бит нечётности или ещё что-нть в этом роде. А вот то, что на этой платформе в некоторых компиляторах ={0} может не занулить всю структуру — в это я могу поверить (я не утверждаю, что это так, но и не утверждаю что так не будет в будущем). Поэтому IMHO лучше ZeroMemory или ещё лучше memset(&dst, 0, sizeof(dst)).
Если кого обидел — звиняйте не хотел — просто наболело
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
> Функция ZeroMemory присутсвует единственной платформе — Win32, и на этой платформе и null-pointer value равен 0 <...>
Если ты тему читал невнимательно, напомню, что помимо этого, второстепенного, аспекта, есть еще и основной — использование UDT.
> А вот то, что на этой платформе в некоторых компиляторах ={0} может не занулить всю структуру — в это я могу поверить (я не утверждаю, что это так, но и не утверждаю что так не будет в будущем)
Т.е. ты попросту не знаешь. Соответственно, опираться на это положение в своих рассуждениях неразумно.
> Поэтому IMHO лучше ZeroMemory или ещё лучше memset(&dst, 0, sizeof(dst)).
До добавления первого UDT в структуру.
Posted via RSDN NNTP Server 1.9 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Дарней, Вы писали:
Д>Признаюсь честно, привык писать обнуление структур в таком стиле:
Д> WNDCLASSEX wcx = { 0 };
Д>Немного нагляднее и короче, чем ZeroMemory. Хоть это и небольшой хак Д>Интересно — может быть, есть какие-то аргументы против такой практики?
Работаю только на win32, поэтому о переносе на другие платформы не задумывался. Здорово здесь то, что для проекта ATL 7.0 можно включить опцию Minimize CRT Use in ATL, что делает скомпилированный код меньше процентов на 10...15, и не нужно таскать за собой библиотеку msvcr70.dll. Кто что скажет?
Лечение насморка отрубанием головы: зачем использовать кучу там, где можно обойтись выделением памяти "в стеке"?
> Работаю только на win32, поэтому о переносе на другие платформы не задумывался.
Эквивалентное "решение", работающее и на других платформах — calloc.
Posted via RSDN NNTP Server 1.9 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Mr. None, Вы писали:
MN>Слушайте люди, вам что потрепаться хочется? Чего к человеку привязались? Вы изначальный вопрос прочитайте внимательно! Вас спросили, что лучше ZeroMemory или ={0}. Функция ZeroMemory присутсвует единственной платформе — Win32, и на этой платформе и null-pointer value равен 0 (точнее даже так: значение указателя равное 0 — это есть null-pointer value), и int 0 есть набор сброшенных битов.
Ну тут следует сразу заметить, что в рамках языка С++ термин "платформа" является эквивалентом термина "реализация", а не термина "аппаратная часть" или "оперционная система" как часто ошибочно полагают. Поэтому если ты уже здесь заговорил о платформе, то это — MSVC++ 6 (или какой там имелся в виду) для Win32, а не сама Win32.
Строго говоря, в официальной теминологии языка С++ вообще нет термина "платформа", а во всех соответствующих местах используется именно термин "реализация". В этом пристутвует очевидная логика — конкретная реализация (компилятор) если захочет, может запросто использовать физически ненулевые null-pointer values, физически ненулевые нули целочисленных типов, обратный код для представления отрицательных чисел (вместо дополнительного), отличный от IEEE 754 формат представления плавающих чисел и т.п. выкрунтасы, даже если все это идет вразрез с соглашениями используемой ОС и аппаратуры — т.е. все на той же x86 Win32. Это неэффективно, но тем не менее все это можно достаточно очевидным образом реализовать и заставить работать. Хотя интерес такая реализация если и будет представлять то, наверное, чисто теоретический.
MN>Причём здесь различные платформы, где есть бит нечётности или ещё что-нть в этом роде.
Да, если задаться целью, можно реализовать такую C++ платформу и для x86 Win32.
MN>А вот то, что на этой платформе в некоторых компиляторах ={0} может не занулить всю структуру — в это я могу поверить (я не утверждаю, что это так, но и не утверждаю что так не будет в будущем). Поэтому IMHO лучше ZeroMemory или ещё лучше memset(&dst, 0, sizeof(dst)).
Если какой-то компилятор не занулит всю струкутру по '={0}', то не удивляйся, если такой компилятор будет произвольным образом падать на 'memset(&dst, 0, sizeof dst)'.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Если ты тему читал невнимательно, напомню, что помимо этого, второстепенного, аспекта, есть еще и основной — использование UDT.
>> А вот то, что на этой платформе в некоторых компиляторах ={0} может не занулить всю структуру — в это я могу поверить (я не утверждаю, что это так, но и не утверждаю что так не будет в будущем)
ПК>Т.е. ты попросту не знаешь. Соответственно, опираться на это положение в своих рассуждениях неразумно.
>> Поэтому IMHO лучше ZeroMemory или ещё лучше memset(&dst, 0, sizeof(dst)).
ПК>До добавления первого UDT в структуру.
Я читал тему внимательно, в том числе внимательно читал и первый вопрос — WNDCLASSEX не содержит UDT... ZeroMemory или memset можно и иногда даже нужно применять в отношении любых структур не содержащих UDT, в частности структур используемых в низкоуровневом коде, работающим с голыми API-вызовами к операционной системе.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Андрей Тарасевич, Вы писали:
АТ>Здравствуйте, Mr. None, Вы писали:
АТ>Ну тут следует сразу заметить, что в рамках языка С++ термин "платформа" является эквивалентом термина "реализация", а не термина "аппаратная часть" или "оперционная система" как часто ошибочно полагают. Поэтому если ты уже здесь заговорил о платформе, то это — MSVC++ 6 (или какой там имелся в виду) для Win32, а не сама Win32.
Следует заметить, что произвольная реализация C++ возможна только в операционках типа MS DOS, а в операционках класса Windows она будет очень сильно связана с возможностями и требованиями ОС.
АТ>Строго говоря, в официальной теминологии языка С++ вообще нет термина "платформа", а во всех соответствующих местах используется именно термин "реализация". В этом пристутвует очевидная логика — конкретная реализация (компилятор) если захочет, может запросто использовать физически ненулевые null-pointer values, физически ненулевые нули целочисленных типов, обратный код для представления отрицательных чисел (вместо дополнительного), отличный от IEEE 754 формат представления плавающих чисел и т.п. выкрунтасы, даже если все это идет вразрез с соглашениями используемой ОС и аппаратуры — т.е. все на той же x86 Win32.
Строго говоря функция ZeroMemory — это API-функция конкретной операционной системы и реализация компилятора тут не причём — это первое.
Второе — эта операционная система предполагает, что null-pointer value — это 0 (если быть совсем точным, то это все значения указателей, расположенных в диапазоне 0x00000000 — 0x0000FFFF). Поэтому если компилятор в качестве null-pointer value выбирает скажем 0xFFFFFFFF, любой вызов API-функции, ожадающей получение указателя проинициализированного значением null-pointer values, закончиться неудачей. Следовательно либо такой компилятор будет порождать неработоспособный код, либо надо как раз пользоваться функцией ZeroMemory, а не ={0}.
АТ>...все это можно достаточно очевидным образом реализовать и заставить работать.
Подкиньте хотя бы идею как это очевидным образом реализовать и заставить работать, если операционная система делает некоторые предположения относительно принимаемых её значений.
АТ>Да, если задаться целью, можно реализовать такую C++ платформу и для x86 Win32.
Инитересно, как в такой реализации будут интерпретироваться результаты вещественного типа, возвращаемые API-вызовами операционной системы? Или придётся ещё писать кучу функций типа float win32_float_to_this_magic_cpp_float(float)?
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Mr. None, Вы писали:
MN>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Если ты тему читал невнимательно, напомню, что помимо этого, второстепенного, аспекта, есть еще и основной — использование UDT.
>>> А вот то, что на этой платформе в некоторых компиляторах ={0} может не занулить всю структуру — в это я могу поверить (я не утверждаю, что это так, но и не утверждаю что так не будет в будущем)
ПК>>Т.е. ты попросту не знаешь. Соответственно, опираться на это положение в своих рассуждениях неразумно.
>>> Поэтому IMHO лучше ZeroMemory или ещё лучше memset(&dst, 0, sizeof(dst)).
ПК>>До добавления первого UDT в структуру.
MN>Я читал тему внимательно, в том числе внимательно читал и первый вопрос — WNDCLASSEX не содержит UDT... ZeroMemory или memset можно и иногда даже нужно применять в отношении любых структур не содержащих UDT, в частности структур используемых в низкоуровневом коде, работающим с голыми API-вызовами к операционной системе.
Насчет можно -- да, но это делает код платформенно-зависимым. Насчет нужно -- почему именно нужно? Зачем? Откуда такая необходимость? Тем более, что компилятор, скорее всего, сгенерирует идентичный код.
Здравствуйте, Mr. None, Вы писали:
MN>Здравствуйте, Андрей Тарасевич, Вы писали:
АТ>>Здравствуйте, Mr. None, Вы писали:
АТ>>Ну тут следует сразу заметить, что в рамках языка С++ термин "платформа" является эквивалентом термина "реализация", а не термина "аппаратная часть" или "оперционная система" как часто ошибочно полагают. Поэтому если ты уже здесь заговорил о платформе, то это — MSVC++ 6 (или какой там имелся в виду) для Win32, а не сама Win32.
MN>Следует заметить, что произвольная реализация C++ возможна только в операционках типа MS DOS, а в операционках класса Windows она будет очень сильно связана с возможностями и требованиями ОС.
Как раз наоборот. На досе особенно не разгуляешься -- системных ресурсов маловато. А вот на Виндах можно сделать любое чудо -- если есть желание повыделываться, время и деньги.
Вам ничто не мешает виртуализовать вычислительный процесс любым мыслимым способом.
АТ>>Строго говоря, в официальной теминологии языка С++ вообще нет термина "платформа", а во всех соответствующих местах используется именно термин "реализация". В этом пристутвует очевидная логика — конкретная реализация (компилятор) если захочет, может запросто использовать физически ненулевые null-pointer values, физически ненулевые нули целочисленных типов, обратный код для представления отрицательных чисел (вместо дополнительного), отличный от IEEE 754 формат представления плавающих чисел и т.п. выкрунтасы, даже если все это идет вразрез с соглашениями используемой ОС и аппаратуры — т.е. все на той же x86 Win32.
MN>Строго говоря функция ZeroMemory — это API-функция конкретной операционной системы и реализация компилятора тут не причём — это первое. MN>Второе — эта операционная система предполагает, что null-pointer value — это 0 (если быть совсем точным, то это все значения указателей, расположенных в диапазоне 0x00000000 — 0x0000FFFF). Поэтому если компилятор в качестве null-pointer value выбирает скажем 0xFFFFFFFF, любой вызов API-функции, ожадающей получение указателя проинициализированного значением null-pointer values, закончиться неудачей. Следовательно либо такой компилятор будет порождать неработоспособный код, либо надо как раз пользоваться функцией ZeroMemory, а не ={0}.
Для обращения к функциям API придётся делать адаптеры, естественно.
АТ>>...все это можно достаточно очевидным образом реализовать и заставить работать. MN>Подкиньте хотя бы идею как это очевидным образом реализовать и заставить работать, если операционная система делает некоторые предположения относительно принимаемых её значений.
АТ>>Да, если задаться целью, можно реализовать такую C++ платформу и для x86 Win32.
MN>Инитересно, как в такой реализации будут интерпретироваться результаты вещественного типа, возвращаемые API-вызовами операционной системы? Или придётся ещё писать кучу функций типа float win32_float_to_this_magic_cpp_float(float)?
Здравствуйте, Шахтер, Вы писали:
MN>>Строго говоря функция ZeroMemory — это API-функция конкретной операционной системы и реализация компилятора тут не причём — это первое. MN>>Второе — эта операционная система предполагает, что null-pointer value — это 0 (если быть совсем точным, то это все значения указателей, расположенных в диапазоне 0x00000000 — 0x0000FFFF). Поэтому если компилятор в качестве null-pointer value выбирает скажем 0xFFFFFFFF, любой вызов API-функции, ожадающей получение указателя проинициализированного значением null-pointer values, закончиться неудачей. Следовательно либо такой компилятор будет порождать неработоспособный код, либо надо как раз пользоваться функцией ZeroMemory, а не ={0}.
Ш>Для обращения к функциям API придётся делать адаптеры, естественно.
Вот только если кто-нть обойдёт эти адаптеры — абзац выйдет... И кто в данном случае будет прав? Ведь мы не взирая на рекомендации производителя Visual Studio не использовать stl в своих проектах всё равно используем (кажись когда-то в MSDN-е было такое замечание, что stl поставляется только для совместимости с другим кодом и использовать её в новых проектах не рекоменуется).
MN>>Инитересно, как в такой реализации будут интерпретироваться результаты вещественного типа, возвращаемые API-вызовами операционной системы? Или придётся ещё писать кучу функций типа float win32_float_to_this_magic_cpp_float(float)?
Ш>Ага, именно так.
МАМА!! РОДИ МЕНЯ ОБРАТНО!!!!!
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
S>Работаю только на win32, поэтому о переносе на другие платформы не задумывался. Здорово здесь то, что для проекта ATL 7.0 можно включить опцию Minimize CRT Use in ATL, что делает скомпилированный код меньше процентов на 10...15, и не нужно таскать за собой библиотеку msvcr70.dll. Кто что скажет?
Это даже не из пушки по воробьям, а стратегическим ядерным оружием
Размер уменьшится не на 10-15% а на размер CRT.
Приемлимо только для маленьких очень файлов и если важно чтобы они оставались маленькими, а кого сегодня волнуют ~100kb?
К тому же может подкачать производительность стандартного хипа для маленьких объектов...
MN>Следует заметить, что произвольная реализация C++ возможна только в операционках типа MS DOS, а в операционках класса Windows она будет очень сильно связана с возможностями и требованиями ОС.
ИМХО бред какой то?
MN>Строго говоря функция ZeroMemory — это API-функция конкретной операционной системы и реализация компилятора тут не причём — это первое.
Не совсем, вернее не всегда.
Если вы посмотрите .h файл то ZeroMemory определен макросом как memset((Destination),0,(Length)).
А memset это уже функция CRT.
MN>Второе — эта операционная система предполагает, что null-pointer value — это 0 (если быть совсем точным, то это все значения указателей, расположенных в диапазоне 0x00000000 — 0x0000FFFF). Поэтому если компилятор в качестве null-pointer value выбирает скажем 0xFFFFFFFF, любой вызов API-функции, ожадающей получение указателя проинициализированного значением null-pointer values, закончиться неудачей. Следовательно либо такой компилятор будет порождать неработоспособный код, либо надо как раз пользоваться функцией ZeroMemory, а не ={0}.
Вы не найдете такой компилятор для операционки предполагающей что null-pointer value — 0
Вообще проблема надуманная, преимущество конструкции = {0} в том что это переносимый и безопасный код.
А какое преимущество у ZeroMemory? Никаких.
Ш>>Для обращения к функциям API придётся делать адаптеры, естественно. MN>Вот только если кто-нть обойдёт эти адаптеры — абзац выйдет... И кто в данном случае будет прав? Ведь мы не взирая на рекомендации производителя Visual Studio не использовать stl в своих проектах всё равно используем (кажись когда-то в MSDN-е было такое замечание, что stl поставляется только для совместимости с другим кодом и использовать её в новых проектах не рекоменуется).
Только другим не навязывай.
и прекратим все эти споры ни о чем!
