macro и micro memory management. Java и С - Философия программирования

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

VD>Зато экономятся память и ресурсы.

Это как? Вотм не нужно 3 кисти, 5 шрифтов чтобы рисовать. Ты предлагаешь создавать из каждый раз до рисования и удалять после, а я говорю что хранить их самими по себе (даже общими для всех контролов программы) куда лучше. То есть если у тебя 10 кнопок рувуют свой текст шрифтов arial Regualr 10pt, то ты на каждое рисование будешь создавать 10 объектов и удалять, а у меня будет всего один пока существует хоть что-то оспользующее этот шрифт. Это не просто хеш, это ещё и Reference counting.

VD>Я вот провел несколько тестов и сделал выводы. А ты на основании чего возмущаешся?

OK, давай вот цифирками кидаться. Я всё делал на Си++ (Даже фактически на Си) для того чтобы исключить возможность влияния GC и прочих сторониих факторов. Время измерял функцией QueryPerfomanceCounter.

Сперва я накидал такой пример

for (int index = 0; index < 100000; ++index)
{
    DeleteObject(CreateFont(17, 0, 60, 60, FW_NORMAL, 0, 0, 0, 0, 0, 0, 0, 0, TEXT("Tahoma")));
    DeleteObject(CreateFont(19, 0, 30, 30, FW_BOLD, 0, 0, 0, 0, 0, 0, 0, 0, TEXT("Arial")));
    DeleteObject(CreateSolidBrush(RGB(255, 255, 255)));
    DeleteObject(CreatePen(PS_SOLID, 3, RGB(255, 255, 255)));
}

Всё это отняло какую-то секунду. Сущий пустяк. Казалось бы ты прав... Нет,такого я мог допустить.
Потом я подумал, что неизвестно как хранятся объекты и возможно время создания и удаления объекта зависит от количества уже существующих. новый код выглядел так

#define ITERATION_COUNT 1000
#define OBJECT_COUNT 100

for (int i = 0; i < ITERATION_COUNT; ++i)
{
    HGDIOBJ hObjectList[4*OBJECT_COUNT];

    for (int j = 0; j < OBJECT_COUNT; ++j)
    {
        hObjectList[4 * j + 0] = CreateFont((j%100) + 10, 0, j % 90, j % 90, FW_NORMAL, 0, 0, 0, 0, 0, 0, 0, 0, TEXT("Tahoma"));
        hObjectList[4 * j + 1] = CreateFont((j%100) + 10, 0, j % 90, j % 90, FW_BOLD, 0, 0, 0, 0, 0, 0, 0, 0, TEXT("Arial"));
        hObjectList[4 * j + 2] = CreateSolidBrush(RGB(255, 255, 255));
        hObjectList[4 * j + 3] = CreatePen(PS_SOLID, 3, RGB(255, 255, 255));
    }
    
    for (int j = 0; j < OBJECT_COUNT; ++j)
    {
        DeleteObject(hObjectList[4 * j + 0]);
        DeleteObject(hObjectList[4 * j + 1]);
        DeleteObject(hObjectList[4 * j + 2]);
        DeleteObject(hObjectList[4 * j + 3]);
    }
}

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

Теперь уже тесты выглядели так

for (int i = 0; i < ITERATION_COUNT; ++i)
{
    for (int j = 0; j < OBJECT_COUNT; ++j)
    {
        hObjectList[4 * j + 0] = CreateFont((j%100) + 10, 0, j % 90, j % 90, FW_NORMAL, 0, 0, 0, 0, 0, 0, 0, 0, TEXT("Tahoma"));
        hObjectList[4 * j + 1] = CreateFont((j%100) + 10, 0, j % 90, j % 90, FW_BOLD, 0, 0, 0, 0, 0, 0, 0, 0, TEXT("Arial"));
        hObjectList[4 * j + 2] = CreateSolidBrush(RGB(j%256, j%256, j%256));
        hObjectList[4 * j + 3] = CreatePen(PS_SOLID, 3, RGB(j%256, j%256, j%256));
    }
        
    for (int j = 0; j < OBJECT_COUNT; ++j)
    {
        hObject = SelectObject(hDC, hObjectList[4 * j + 0]);

        DrawText(hDC, TEXT("Test text"), -1, &rect, 0);
                
        SelectObject(hDC, hObject);
                        
        hObject = SelectObject(hDC, hObjectList[4 * j + 1]);
                
        DrawText(hDC, TEXT("Test text"), -1, &rect, 0);
    
        SelectObject(hDC, hObject);
                        
        FillRect(hDC, &rect, (HBRUSH)hObjectList[4 * j + 2]);
                        
        hObject = SelectObject(hDC, hObjectList[4 * j + 3]);
                
        MoveToEx(hDC, 0, 0, NULL);
        LineTo(hDC, 200, 200);
                
        SelectObject(hDC, hObject);
    }

    for (int j = 0; j < OBJECT_COUNT; ++j)
    {
        DeleteObject(hObjectList[4 * j + 0]);
        DeleteObject(hObjectList[4 * j + 1]);
        DeleteObject(hObjectList[4 * j + 2]);
        DeleteObject(hObjectList[4 * j + 3]);
    }
}

и так (чтобы отдельно посчитать скорость рисования)

for (int j = 0; j < OBJECT_COUNT; ++j)
{
    hObjectList[4 * j + 0] = CreateFont((j%100) + 10, 0, j % 90, j % 90, FW_NORMAL, 0, 0, 0, 0, 0, 0, 0, 0, TEXT("Tahoma"));
    hObjectList[4 * j + 1] = CreateFont((j%100) + 10, 0, j % 90, j % 90, FW_BOLD, 0, 0, 0, 0, 0, 0, 0, 0, TEXT("Arial"));
    hObjectList[4 * j + 2] = CreateSolidBrush(RGB(j%256, j%256, j%256));
    hObjectList[4 * j + 3] = CreatePen(PS_SOLID, 3, RGB(j%256, j%256, j%256));
}
             
for (int i = 0; i < ITERATION_COUNT; ++i)
{
    for (int j = 0; j < OBJECT_COUNT; ++j)
    {
        hObject = SelectObject(hDC, hObjectList[4 * j + 0]);

        DrawText(hDC, TEXT("Test text"), -1, &rect, 0);
                
        SelectObject(hDC, hObject);
                        
        hObject = SelectObject(hDC, hObjectList[4 * j + 1]);
                
        DrawText(hDC, TEXT("Test text"), -1, &rect, 0);
    
        SelectObject(hDC, hObject);
                        
        FillRect(hDC, &rect, (HBRUSH)hObjectList[4 * j + 2]);
                        
        hObject = SelectObject(hDC, hObjectList[4 * j + 3]);
                
        MoveToEx(hDC, 0, 0, NULL);
        LineTo(hDC, 200, 200);
                
        SelectObject(hDC, hObject);
    }
}
                 
for (int j = 0; j < OBJECT_COUNT; ++j)
{
    DeleteObject(hObjectList[4 * j + 0]);
    DeleteObject(hObjectList[4 * j + 1]);
    DeleteObject(hObjectList[4 * j + 2]);
    DeleteObject(hObjectList[4 * j + 3]);
}

Получилось 11 и 10 секунд соответсвенно. Выходит ты прав? Ну я всё таки оставлю себе лазейку

Всё что я измерял верно для Windows XP (SP2 если это важно) и GDI. Как обстоят дела в 98, 2000 и GDI+ вопрос отдельный. В целом, если мы говорим о GDI, то ты прав — ресурсы GDI довольно легкие в том смысле, что они довольно быстро создаются и удаляются.

VD>Ром, ты вот мне объясни. Ты поставил аж три бала тематическому сообщению.

Завидуешь?

Вообще-то я ставил три балла не за код, а за поднятие интересного, на мой взгляд, вопроса. Обрати внимание, что это не теоретические фантазии — человек много чего сделал, прежде чем сложить своё мнение.

VD>Ты вчитывался в код который привел c-smile? Погляди внимательно на фрагменты вроде:
VD>

VD>gfx.setBrush(Color.RGB(0xFF,0,0));
VD>gfx.fillRect(10,10,100, 100);
VD>

VD>Заметь. Ни о каком кэшировании c-smile не заикался.

Из интерфейса нельзя сделать вывод что кеширования нет.

VD>Стало быть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению старых.

Не знаю как ты, а я ознакомлялся тем что пишет c-smile и я не думая что он там поступил бы. Кроме того напомню, для того чтобы делать подобные выводы слишком мало информации.

VD>Так что совсем не ясно, что ты так взъелся на мою идею и при этом не предъявляшь тех же претензий к идее c-smile-а? Не уж то предвзятое отношение?

Влад, у тебя мания преследования? Я просто увидел то, что мне не понравилось ответил и забыл. Если бы не твой сообщение я бы про тебя и не вспомнил.
Я вот легкостью признал, что ты прав, а тебе везде заговоры мерещатся. Будь проще и люди к тебе потянутся

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

IT>>Точно. И как раз с этим в шарпе дела обстоят гораздо лучше чем в джаве.

N>да ну? и чемже? отсутствием checked exceptions?

Ну Влад уже как бы всё сказал, остаётся только добавить, что он поскромничал и привёл не самый кошмарный пример try/finally. Вот если я сейчас тут начну рисовать вложенности этих самых try/finally, вот тогда веселуха и начнётся.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

MS>Что-то я не понял. В каком именно месте происходит "ассоциация моря неуправляемой памяти" с объектом?

С объектом я погорячисля. Ассоциируется конечно не с объектом, а с поколением. ЖЦ ведь по барабану что там за объекты. Ему важно рассчитать когда собрать мусор. Если ты зацепил море памяти, то нудно только сказать об этом ЖЦ и он сдвинет сборку на более ранее время.

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

Вот блог... глянь сам.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

A>Это как? Вотм не нужно 3 кисти, 5 шрифтов чтобы рисовать. Ты предлагаешь создавать из каждый раз до рисования и удалять после, а я говорю что хранить их самими по себе (даже общими для всех контролов программы) куда лучше.

3 и 5 это вообще не цифры. А вот 40 уже цифры. Причем не смертельные по скорости, но ощутимые по памяти.

A> То есть если у тебя 10 кнопок рувуют свой текст шрифтов arial Regualr 10pt, то ты на каждое рисование будешь создавать 10 объектов и удалять, а у меня будет всего один пока существует хоть что-то оспользующее этот шрифт. Это не просто хеш, это ещё и Reference counting.

Понимашь, ли для кнопок можно вообще ничего не кэшировать. У них основное место простой закраской заполняется. Они и н GDI+ влет рисуются. Я виду речь о немного более сложных контролах вроде гридов и текстовых редакторов (мне именно они были интересны). Площади поверхности у них относительно большие и закраска разнообразная. Вот на них мой подход очень неплохо себя показывает.

Но кэшировать можно и более глобально. В конце концов можно заводить один графикс на форму или еще что придумать.

Еще раз повторяю, что подход c-smile-а — это вообще создание всех ресурсов на один раз. И все чтобы сэкономить по 8 байт на объект (не создавать его в хипе).

VD>>Я вот провел несколько тестов и сделал выводы. А ты на основании чего возмущаешся?

A>OK, давай вот цифирками кидаться.

Просба помочь в проведении теста — 2

A>Получилось 11 и 10 секунд соответсвенно. Выходит ты прав? Ну я всё таки оставлю себе лазейку

Всё что я измерял верно для Windows XP (SP2 если это важно) и GDI. Как обстоят дела в 98, 2000 и GDI+ вопрос отдельный.

От ОС зависит тут мало. 98-е я уже 5 лет не видел и видеть не хочу. А вот от режима сглаживания шрифтов скорость отрисовки зависит сильно. Но включить его можно только на ХРюше. Так что 2000-ые можешь рассматривать как ХР без сглаживания, т.е. на ней быстрее.

A>В целом, если мы говорим о GDI, то ты прав — ресурсы GDI довольно легкие в том смысле, что они довольно быстро создаются и удаляются.

Все не так просто. Как видишь создание всего этого дела 1000 раз удовольствие дорогое. Все же отрисовка должна уложиться хотя бы в 0.4 сек. А лучше в 0.01. Но при среденей отрисовке создается пара шрифтов и пара браше. Ну, даже там десяток. Это роли не ирает. А вот тормоза начинаются когда ты создашь, например, для каждой ячейки грида по шрифту и кисти. Вот тут наступает полный приплызд. И тут кэширование в неком Графиксе получается очень красивым решением. Код по прежнеме работает с объектами. Мы может даже наследовать их друг от друга. Ну, там перо от кисти, нисть еще от чего... Можем хранить объекты типа шрифтов в ячейках. Стоить они будут минимум. Особенно это актуально для управляемого мира. Ну, а кэш нас спасает от создания тысяч шрифтов. В итоге мы получаем хороший контроль ресурсов, удобную ОО-модель, не заморачиваемся на С-шной модели предложенной c-smile-ом и приличную скорость. Что еще желать? Дальнейшая экономия бессмысленна.

VD>>Ром, ты вот мне объясни. Ты поставил аж три бала тематическому сообщению.

A>Завидуешь?

Нет. Логику хочу понять. Для меня странно столь алогичные действия даже несмотря на полное понимания причин этого.

A>

Вообще-то я ставил три балла не за код, а за поднятие интересного, на мой взгляд, вопроса. Обрати внимание, что это не теоретические фантазии — человек много чего сделал, прежде чем сложить своё мнение.

Ясно. Ну, тогда зашел бы чтоли в дотнет. Там эта тема месяц или два назад поднималась.

A>Из интерфейса нельзя сделать вывод что кеширования нет.

А ты подумай. Как он будет кэшировать и где? Ведь максимум так же как я. Но ты же был так бурно против моего предложения. Хотя по сути интерфейсно оно отличалось только тем, что предлагало все же не отказываться от объектов вообще, а всего лишь сделать объекты по легче, кэширую хэндлы в отдельном объекте. Кстати, объект можно было бы сделать и глобальным для потока запихнув в сред-статик-переменную... если уж на то пошло.

То есть речь шла по существу о "С-стиле vs. ОО-стиле".

VD>>Стало быть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению старых.

A>Не знаю как ты, а я ознакомлялся тем что пишет c-smile и я не думая что он там поступил бы. Кроме того напомню, для того чтобы делать подобные выводы слишком мало информации.

Ну, я ему прямой вопрос задал. И он молчит как рыба об лед.

Думаю, что кэшированием там и не пахло. Объекты, блин, экономил.

VD>>Так что совсем не ясно, что ты так взъелся на мою идею и при этом не предъявляшь тех же претензий к идее c-smile-а? Не уж то предвзятое отношение?

A>Влад, у тебя мания преследования?

Я тебе уже второй раз говорю. Ага. Бегаю за тобой... преследую. Вот сейчас... ты тихо мирно предложил c-smile-у свою идею, а прибежал и неподумал влепил тебе минус. Смотрю на себя и удивляюс... маньяк да и только.

A> Я просто увидел то, что мне не понравилось ответил и забыл. Если бы не твой сообщение я бы про тебя и не вспомнил.

Ох я уж вижу как ты про меня не вспоминашь. Ну, разубеди мнея в моей мании. Покажи где ты еще кого-то так же дружески критиковал?

A>Я вот легкостью признал, что ты прав, а тебе везде заговоры мерещатся. Будь проще и люди к тебе потянутся

Я прост как три копейки. Что вижу о том и говорю. Заметь без какой-то задней злобы. Говорю тебе открыто. Перестань все время меня провцировать и будет у нас с тобой мир да любовь.

... << RSDN@Home 1.2.0 alpha rev. 620>>

Паш, а можно узнать, что смешного ты узрел в этом сообщении?

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

ПК>>А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?

VD>Они спасают от случайных ошибок в 90%. Параллельно читаемый файлик ими закрывать конечно грешно, но вот оставить на них ресурсы вроде соеденения с БД или битмапа какого очень даже можно.

VD>Незнаю как там в Яве, но в дотнете за всеми системными хэндлами следят. Так что наличие большого количества хэндлов автоматом приводит к сборки мусора с последующей финализацией повисших хэндлов.

VD>Как говорится: Если у вас параноя — это еще не означает, что за вами не следят.

Только высказал предположение о шоке, как он уже начался.

Пашь, во что на этот раз не веришь то? Колись.

VladD2,

> Паш, а можно узнать, что смешного ты узрел в этом сообщении?

Это всего лишь оптимизация компилятора. Очень мощьная оптимизация. Но боюсь он ее будет делать редко. А так отличная фича.

Posted via RSDN NNTP Server 2.0

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

VD>Это всего лишь оптимизация компилятора. Очень мощьная оптимизация. Но боюсь он ее будет делать редко. А так отличная фича.

Вот именно. Фича может и отличная, но редкая. Примерно как динозавры в наше время.

... << RSDN@Home 1.2.0 alpha rev. 0>>

VladD2,

> Пашь, во что на этот раз не веришь то? Колись.

Не не верю, а не согласен.

ПК>А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?

Они спасают от случайных ошибок в 90%. Параллельно читаемый файлик ими закрывать конечно грешно, но вот оставить на них ресурсы вроде соеденения с БД или битмапа какого очень даже можно.

Незнаю как там в Яве, но в дотнете за всеми системными хэндлами следят.

Posted via RSDN NNTP Server 2.0

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

VD>Все не так просто. Как видишь создание всего этого дела 1000 раз удовольствие дорогое.

Я создавал 100 раз по 100 штук. У Word/Excel где-то по 200 объектов GDI. У VS ~800, так что 100 это вполне реальный ориентир. И один "комплект" создаётся на 1 миллисекунду.

A>>

Вообще-то я ставил три балла не за код, а за поднятие интересного, на мой взгляд, вопроса. Обрати внимание, что это не теоретические фантазии — человек много чего сделал, прежде чем сложить своё мнение.
VD>Ясно. Ну, тогда зашел бы чтоли в дотнет. Там эта тема месяц или два назад поднималась.

Мне c-smale просто симпатичен

Только сильно огорчайся, у тебя ещё не всё потеряно.

A>>Из интерфейса нельзя сделать вывод что кеширования нет.

VD>А ты подумай. Как он будет кэшировать и где? Ведь максимум так же как я.

Можно в статической переменной/синглтоне. Тогда объект будет уникален не для Graphics, а для приложения вообще.

VD>То есть речь шла по существу о "С-стиле vs. ОО-стиле".

Не факт. Можно иметь объекты Brush в которых будет хранится описание кисти, но не систменый ресурс. А ресурс будет создаватся на лету объектом Graphics. Вот о чём говорим мы, а c-smile говорил вообще не об этом, а о накладности создания большого количества мелких объектов. Рисование было просто примером такого случая.
И дело не в большой любви к Си стилю, а в оптимизации. По сути время создания и удаления системного ресурса HBRUSH может быть сравнимо со временем выделения и освобождения памяти объекта Brush. Ну в GC среде ещё может быть и переноса. А может и не быть сравнимо. Но вся разработка c-smile исходит из того что сравнимо.

VD>>>Стало быть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению старых.

Зависит от реализации.

VD>Ну, я ему прямой вопрос задал. И он молчит как рыба об лед.

Подожди ещё 37 секунд, а потом засчитай ему нокаут.

A>>Влад, у тебя мания преследования?

VD>Я тебе уже второй раз говорю. Ага. Бегаю за тобой... преследую. Вот сейчас... ты тихо мирно предложил c-smile-у свою идею, а прибежал и неподумал влепил тебе минус. Смотрю на себя и удивляюс... маньяк да и только.

Так ты на минус обиделся? Бедный мальчик. Ну ладно, я больше не буду.

VD>Перестань все время меня провцировать

Нда. Ну и аргументы пошли. Ещё посуду побей и расскажи что ты потратил на меня лучшие 10 лет своей жизни с 29 до 32 лет

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

ПК>>А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?

ПК>

Они спасают от случайных ошибок в 90%. Параллельно читаемый файлик ими закрывать конечно грешно, но вот оставить на них ресурсы вроде соеденения с БД или битмапа какого очень даже можно.

ПК>

Незнаю как там в Яве, но в дотнете за всеми системными хэндлами следят.

Так с сказал бы что-нибудь. Или ты как этот который несогласен с обоими...

Можешь обосновать мою неправоту? Глядишь что-то интересное получилось бы. А то по твоему минусу народ может подумать, буд-то со всеми остальными моими словами ты согласен.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

ПК>

ПК>Это всего лишь оптимизация компилятора. Очень мощьная оптимизация. Но боюсь он ее будет делать редко. А так отличная фича.

Я как бы читать, то умею. Хотелось бы пояснений.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

VD>>Это всего лишь оптимизация компилятора. Очень мощьная оптимизация. Но боюсь он ее будет делать редко. А так отличная фича.

IT>Вот именно. Фича может и отличная, но редкая. Примерно как динозавры в наше время.

Да, нет. Видишь вот ПК улыбками изошелся. Понимает чем дело может обернуться.

На самом деле оптимизация мощьнейшая. Вопрос только в качестве ее реализации. Там анализ нужен нехилый ведь.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

>> Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует.

ПК>Не уверен, насколько это работает, но многие рекламируют Safe Handles из .Net FW 2.0.

Сдается мне, что ты что-то путашь. Этот класс от перерасхода памяти не гарантирует.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

MS>В силу ряда причин это сделать нереально.

Что же это за причины?

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

IT>Очень похоже. Одно только то, что в GDI+ невозможно установить отдельно стоящий пиксель уже наводит на некоторые размышления

Вообще-то можно вроде. Через битмап.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

PD>1000 раз дергать кучу там, где можно и один раз не дергать — хорошая, кстати иллюстрация на тему микрооптимизации, за которую меня некоторые ругали

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

Интересно что ты скажешь когда через год на Яве первый вариант кода порвет твой вотрой на С++? Они тоже будут размещать данные на стеке, только у них вообще нет ни деструкторов, ни конструкторов и думать о том где буфер размещен не нужно.

Вот погляди, тут где-то на Окамле битмапчик рассчитвали. Окамл явно тоже связаннй список вместо того чтобы в ЖЦ создавать превратил в массив и бросил в стэк.

А все потому, что когда программист не может "помочь" компилятору, компилятор может сам думать как лучше.

На сегодня компиляторы делают человека по кодогенерации маш.кода для конкретных процессоров. А завтра начнут делать в вопросах размещения переменных в памяти. Просто для этого нужно как следует вложиться в компиляторы.

ЗЫ

Что до add esp... Такой глупости даже дотнетный джит не сделает. Память под переменные будет выделена еще перед циклом (в начале функции). Так что в цикле максимум будет вызван конструктор и деструктор. Если это структуры, то вообще ничего. Правда память при этом тоже не проинициализируется.

... << RSDN@Home 1.2.0 alpha rev. 620>>

От:	VladD2	www.nemerle.org
Дата:	09.12.05 23:52
Оценка:

От:	McSeem2	http://www.antigrain.com
Дата:	10.12.05 00:10
Оценка:

От:	McSeem2	http://www.antigrain.com
Дата:	10.12.05 00:20
Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	10.12.05 01:12
Оценка:

От:	IT	linq2db.com
Дата:	10.12.05 03:12
Оценка:

	От:	Павел Кузнецов
	Дата:	10.12.05 03:40
	Оценка:	+1