массив ( new грабли )

Полный текст исходника:

Код (Text):

1.     #define WIN32_LEAN_AND_MEAN
2.     #pragma comment(linker,"/MERGE:.rdata=.text")
3.     #pragma comment(linker, "/subsystem:windows")
4.     #pragma comment(linker,"/ENTRY:main")
5.     #pragma comment(linker,"/NODEFAULTLIB:LIBCMT /NODEFAULTLIB:OLDNAMES")
6.     //#pragma warning(disable : 4530)
7.     #pragma comment(lib, "kernel32.lib")
8.     #pragma comment(lib, "user32.lib")
9.  
10.     #include <windows.h>
11.  
12.     #define size 100000L
13.  
14. //==================================================================== =====
15. void main()
16. {
17.     unsigned int*   array;
18.  
19.     array = new unsigned int[size];
20.     MessageBox(0, "array created", "caption", MB_ICONASTERISK);
21.     delete[] array;
22.     return;
23. }
24.  

Ключи: /Ox /EHsc

Компилируется и линкуется без варнингов и ошибок. На array = new unsigned int[size];

выпадает. Где тут грабли - не пойму. Самое непонятное - в другом проекте эта конструкция работает.

 

Ты используешь new, а это часть "runtime C library" (CRT), которая требует своей инициализации. Если бы ты не переопределил точку входа, всё было бы нормально.



Хочешь маленькое приложение? Читай соответствующую статью на UINC или примеры с этого форума. Но придётся отказаться от CRT и использовать только чистый WinAPI (как на асме). Хочешь CRT? Не извращайся. Есть и компромисс: использовать альтернативные облегчённые версии CRT (libctiny, wincrt и куча других). В конце концов, можешь создать свою альтернативу.

 

Тогда почему компилятор не ругнулся и пропустил это? Куда менее значительные вещи подмечает, а тут...



Да crt мне со своим new собственно даром не сдался, до сих пор делал маленькие на чистых апи, и дальше буду, просто хотел сравнить выделение памяти с new, VirtualAlloc и SysAllocString.



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

 

А откуда компилятор знает, с какого места начнётся исполнение кода?

Чего там сравнивать, new спускается к Heap* или Virtual*, в зависимости от размера. На РСДН не раз сравнения по скорости проводили различных аллокаторов.

 

new можно использовать и с измененной точкой входа, вот пример:

Код (Text):

1. #pragma comment(linker, "/ENTRY:main")
2. #define _CRTBLD
3. #include <../../crt/src/winheap.h>
4. #include <windows.h>
5.  
6. int main(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR lpszCmdLine, int nCmdShow)
7. {
8.     _heap_init(0);
9.     char *Str;
10.     int n=100;
11.     Str = new char [n];
12.     delete [] Str;
13.     _heap_term();
14.     ExitProcess(0);
15. }

 

Т.е. как я понял, не хватало инициализации кучи?

 

В данном случае, кучи. Начнёшь использовать что-то ещё — будет не хватать другого

 

Вот потому std мне и не нравится Потянешь ниточку - весь клубок размотать придётся. То ли дело апи:

Код (Text):

1. int* alloc( int dwSize ){
2.     return (int*) VirtualAlloc( NULL, dwSize, MEM_COMMIT, PAGE_READWRITE );
3. }

вот тебе и весь new...

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

 

Хм.. Использовать VA для выделения нескольких байт? Черезчур.. лучше уж HeapAlloc. Потом, почему int*, а не char*? захочешь потом инкрементировать указатель и удивишься.



Если не нужны библиотеки - не используй. Пиши на С, зачем тебе new?

 

Я уже однажды удивлялся, почем у меня HWND* по четыре штуки скачет Эти грабли мне уже знакомы.

Можно и HeapAlloc, непринципиально, главное под контролем, и на new грабли я уже не наступлю )