Замучился.. постоянно получаю ошибку из-за malloc.
1>LIBCMT.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
Компиляция с /MT

в хидере прописал
#pragma comment(linker, "/ENTRY:WinMain")
если убрать то все нормально собирается (размер увеличивается на ~30kb, видимо с ней появляется рантайм информация в файле), но эту прагму убирать нельзя.

Что можно сделать? Пробовал заменить malloc на C++ вариант new — все тоже самое.

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


P>Что можно сделать? Пробовал заменить malloc на C++ вариант new — все тоже самое.

Если проблема именно в malloc — замени на HeapAlloc с GetProcessHeap. Правда, эта не куча CRT, а другая куча, но раз тебе надо без CRT...

malloc без CRT
Почитайте статьи питрека на эту тему. (ключевый слова: reduce exe size) на rsdn тоже есть статья по этому поводу

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

PD>Если проблема именно в malloc — замени на HeapAlloc с GetProcessHeap. Правда, эта не куча CRT, а другая куча, но раз тебе надо без CRT...

для винды:
inline void* malloc(size_t size){
return HeapAlloc(GetProcessHeap(),0, size);
}
inline void* realloc(void *ptr, size_t new_size){
if(!ptr) return malloc(new_size);
return HeapReAlloc(GetProcessHeap(), 0, ptr, new_size);
}
inline void free(void *ptr){
HeapFree(GetProcessHeap(), 0, ptr);
}

но работает это намного медленнее сишного malloc'а при выделении "средних" обьектов.

S>но работает это намного медленнее сишного malloc'а при выделении "средних" обьектов.
не будет медленнее. в микрософтовских CRT (по кр мере до 8й включительно) malloc это тупой вызов HeapAlloc'а..

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

S>>но работает это намного медленнее сишного malloc'а при выделении "средних" обьектов.
А>не будет медленнее. в микрософтовских CRT (по кр мере до 8й включительно) malloc это тупой вызов HeapAlloc'а..

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

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

S>>>но работает это намного медленнее сишного malloc'а при выделении "средних" обьектов.
А>>не будет медленнее. в микрософтовских CRT (по кр мере до 8й включительно) malloc это тупой вызов HeapAlloc'а..

S>вы ошибаетесь, для больших размеров- да вызывается HeapAlloc, для маленьких и средних вызывается HeapAlloc большего размера- но если есть свободный кусочек из уже выделенного- которого хватит на требуемую память- будет возвращаться он.

Почитай (а лучше потрейси) исходники CRT.
В MS в общем случае (а там еще есть древние аллокаторы зачем то) все всегда приходит к HeapAlloc

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


S>но работает это намного медленнее сишного malloc'а при выделении "средних" обьектов.

Сколько можно...
Re[18]: Какое различие между HeapAlloc и new

Автор: vvotan
Дата: 13.03.06

S>>>но работает это намного медленнее сишного malloc'а при выделении "средних" обьектов.
А>>не будет медленнее. в микрософтовских CRT (по кр мере до 8й включительно) malloc это тупой вызов HeapAlloc'а..
S>вы ошибаетесь, для больших размеров- да вызывается HeapAlloc, для маленьких и средних вызывается HeapAlloc большего размера- но если есть свободный кусочек из уже выделенного- которого хватит на требуемую память- будет возвращаться он.
Это вы наивно ошибаетесь.

0:016> u MSVCR80!malloc MSVCR80!malloc+100
MSVCR80!malloc:
78134d09 53              push    ebx
78134d0a 8b5c2408        mov     ebx,dword ptr [esp+8]
78134d0e 83fbe0          cmp     ebx,0FFFFFFE0h
78134d11 0f87ac000000    ja      MSVCR80!malloc+0xba (78134dc3)
78134d17 55              push    ebp
78134d18 8b2d48401978    mov     ebp,dword ptr [MSVCR80!_imp__HeapAlloc (78194048)]
78134d1e 56              push    esi
78134d1f 57              push    edi
78134d20 33f6            xor     esi,esi
78134d22 3935fc3f1c78    cmp     dword ptr [MSVCR80!_crtheap (781c3ffc)],esi
78134d28 8bfb            mov     edi,ebx
78134d2a 7518            jne     MSVCR80!malloc+0x3b (78134d44)
78134d2c e859cfffff      call    MSVCR80!_FF_MSGBANNER (78131c8a)
78134d31 6a1e            push    1Eh
78134d33 e892cdffff      call    MSVCR80!_NMSG_WRITE (78131aca)
78134d38 68ff000000      push    offset <Unloaded_ml.dll>+0xfe (000000ff)
78134d3d e8cac9ffff      call    MSVCR80!__crtExitProcess (7813170c)
78134d42 59              pop     ecx
78134d43 59              pop     ecx
78134d44 a108481c78      mov     eax,dword ptr [MSVCR80!__active_heap (781c4808)]
78134d49 83f801          cmp     eax,1
78134d4c 750e            jne     MSVCR80!malloc+0x53 (78134d5c)
78134d4e 3bde            cmp     ebx,esi
78134d50 7404            je      MSVCR80!malloc+0x4d (78134d56)
78134d52 8bc3            mov     eax,ebx
78134d54 eb03            jmp     MSVCR80!malloc+0x50 (78134d59)
78134d56 33c0            xor     eax,eax
78134d58 40              inc     eax
78134d59 50              push    eax
78134d5a eb1e            jmp     MSVCR80!malloc+0x71 (78134d7a)
78134d5c 83f803          cmp     eax,3
78134d5f 7540            jne     MSVCR80!malloc+0x98 (78134da1)
78134d61 53              push    ebx
78134d62 e8f2feffff      call    MSVCR80!V6_HeapAlloc (78134c59)
78134d67 3bc6            cmp     eax,esi
78134d69 59              pop     ecx
78134d6a 7517            jne     MSVCR80!malloc+0x7a (78134d83)
78134d6c 3bde            cmp     ebx,esi
78134d6e 7503            jne     MSVCR80!malloc+0x6a (78134d73)
78134d70 33ff            xor     edi,edi
78134d72 47              inc     edi
78134d73 83c70f          add     edi,0Fh
78134d76 83e7f0          and     edi,0FFFFFFF0h
78134d79 57              push    edi
78134d7a 56              push    esi
78134d7b ff35fc3f1c78    push    dword ptr [MSVCR80!_crtheap (781c3ffc)]
78134d81 ffd5            call    ebp
78134d83 8bf0            mov     esi,eax
78134d85 85f6            test    esi,esi
78134d87 7533            jne     MSVCR80!malloc+0xb3 (78134dbc)
78134d89 3905f43f1c78    cmp     dword ptr [MSVCR80!_newmode (781c3ff4)],eax
78134d8f 6a0c            push    0Ch
78134d91 5f              pop     edi
78134d92 741a            je      MSVCR80!malloc+0xa5 (78134dae)
78134d94 53              push    ebx
78134d95 e8b7c2ffff      call    MSVCR80!_callnewh (78131051)
78134d9a 85c0            test    eax,eax
78134d9c 59              pop     ecx
78134d9d 7581            jne     MSVCR80!malloc+0x17 (78134d20)
78134d9f eb14            jmp     MSVCR80!malloc+0xac (78134db5)
78134da1 83f802          cmp     eax,2
78134da4 75c6            jne     MSVCR80!malloc+0x63 (78134d6c)
78134da6 53              push    ebx
78134da7 e8fcfeffff      call    MSVCR80!V5_HeapAlloc (78134ca8)
78134dac ebb9            jmp     MSVCR80!malloc+0x5e (78134d67)
78134dae e899f5ffff      call    MSVCR80!_errno (7813434c)
78134db3 8938            mov     dword ptr [eax],edi
78134db5 e892f5ffff      call    MSVCR80!_errno (7813434c)
78134dba 8938            mov     dword ptr [eax],edi
78134dbc 5f              pop     edi
78134dbd 8bc6            mov     eax,esi
78134dbf 5e              pop     esi
78134dc0 5d              pop     ebp
78134dc1 5b              pop     ebx
78134dc2 c3              ret
78134dc3 53              push    ebx
78134dc4 e888c2ffff      call    MSVCR80!_callnewh (78131051)
78134dc9 59              pop     ecx
78134dca e87df5ffff      call    MSVCR80!_errno (7813434c)
78134dcf c7000c000000    mov     dword ptr [eax],offset <Unloaded_ml.dll>+0xb (0000000c)
78134dd5 33c0            xor     eax,eax
78134dd7 5b              pop     ebx
78134dd8 c3              ret
MSVCR80!_calloc_impl:
78134dd9 6a0c            push    0Ch
78134ddb 68c84c1b78      push    offset MSVCR80!__rtc_tzz+0x194 (781b4cc8)
78134de0 e8af3e0000      call    MSVCR80!_SEH_prolog4 (78138c94)
78134de5 8b4d08          mov     ecx,dword ptr [ebp+8]
78134de8 33ff            xor     edi,edi
78134dea 3bcf            cmp     ecx,edi
78134dec 762e            jbe     MSVCR80!_calloc_impl+0x43 (78134e1c)
78134dee 6ae0            push    0FFFFFFE0h
78134df0 58              pop     eax
78134df1 33d2            xor     edx,edx
78134df3 f7f1            div     eax,ecx
78134df5 3b450c          cmp     eax,dword ptr [ebp+0Ch]
78134df8 1bc0            sbb     eax,eax
78134dfa 40              inc     eax
78134dfb 751f            jne     MSVCR80!_calloc_impl+0x43 (78134e1c)
78134dfd e84af5ffff      call    MSVCR80!_errno (7813434c)
78134e02 c7000c000000    mov     dword ptr [eax],offset <Unloaded_ml.dll>+0xb (0000000c)
78134e08 57              push    edi

как видим все что делает malloc — проверяет что внутренний CRT heap (переменная _crtheap) проинициализирован как надо, если нет — то инициализирует его, затем проверяет что юзер просит выделить не 0 байт, и затем просто тупо вызывается HeapAlloc. А все что вы рассказали — делается внутри HeapAlloc'а когда тот уже в себе юзает VirtualAlloc.
И в принципе логично — ntdll'ным хипом пользуется сама система и он должен быть максимально производительным. Если можно сделать быстрее — быстрее должен быть именно виндовый хип а не его надстройки. А тормозными могут быть (я являются) всякие VirtualAlloc'и и тп.
Единственное почему MSVCRT'шный malloc может оказаться быстрее HeapAlloc(GetProcessHeap() -дык это потому что он выделяет не на дефолтовом хипе, а на своем, CRTном. Но ничего не мешает вам сделать свой личный хип HeapCreate'ом.