// for gcc
template<int base, u64 bin>
class CToDec
{
public:
enum { value = (bin&0xF) + base*CToDec<bin/0x10>::value };
};
template<int base>
class CToDec<base,0>
{
public: enum { value = 0 };
};
Вес программ на Visual C++ > или < веса программ C++ Builder
Я значит хочу начать изучать Visual C++, лазею по глобальной сети, ищу разные статьи на эту тему, как вдруг наткнулся на такое чудо:
Цитата:
Если же говорить о том, какую среду выбрать для программирования на C/C++, то я однозначно выбираю C++ Builder. Он, хоть и хуже Delphi, но в тысячу и один раз лучше Visual C++, т.к. программы, откомпилированные в нём (я имею в виду на API, либо для консоли), занимают места в 5 и больше раз меньше места, чем их аналоги, написанные в Visual C++.
Разве консольные или API программы, написанные на Visual C++ занимают больше места, чем написанные на C++ Builder? Я всегда думал обратное. Кому верить.
Цитата:
Originally posted by MVH
Я значит хочу начать изучать Visual C++, лазею по глобальной сети, ищу разные статьи на эту тему, как вдруг наткнулся на такое чудо:
Разве консольные или API программы, написанные на Visual C++ занимают больше места, чем написанные на C++ Builder? Я всегда думал обратное. Кому верить.
Я значит хочу начать изучать Visual C++, лазею по глобальной сети, ищу разные статьи на эту тему, как вдруг наткнулся на такое чудо:
Разве консольные или API программы, написанные на Visual C++ занимают больше места, чем написанные на C++ Builder? Я всегда думал обратное. Кому верить.
Мой печальный опыт подтверждает этот факт, возможно не в полной мере, но частично точно. Практически любая программа, пусть даже и консольная, в VC++ занимает от 170КБ. Это много, конечно, для программы, которая говорит "Hello World". Есть какие-то методы по уменьшению объема, но я в это не вникал.
Могу сказать, что автор того изречения, по всей видимости, мало работал в VC++ и много в Builder-е. Каждый бомж хвалит свою помойку %))
Верь толькою себе. Проверь сам.
На самом деле обычно и там и там можно делать супер маленькие программы.
На самом деле обычно и там и там можно делать супер маленькие программы.
Цитата:
Originally posted by mike
Верь толькою себе. Проверь сам.
Верь толькою себе. Проверь сам.
Проверить в ближаёшие несколько дней у меня не будет возможности, а узнать поподробнее об это хочется.
Цитата:
Originally posted by mike
На самом деле обычно и там и там можно делать супер маленькие программы.
На самом деле обычно и там и там можно делать супер маленькие программы.
Но я где-то читал, что на VC++ это делать намного проще. Это так?
Просто надо создавать Release-нутые версии программы.
Меню Build -> Set Active Configuration и выбрать Win32 Release.
Меню Build -> Set Active Configuration и выбрать Win32 Release.
Размер приложения не зависит от среды разработки.
А вообще-то этот топик чистой воды флуд.
Учите С++.
А вообще-то этот топик чистой воды флуд.
Учите С++.
Цитата:
Originally posted by Green
Размер приложения не зависит от среды разработки.
А вообще-то этот топик чистой воды флуд.
Размер приложения не зависит от среды разработки.
А вообще-то этот топик чистой воды флуд.
А мы флудеры %))
Согласен. Объем всегда регулируется, и по незнанию среды разработки возникает ощущение, что ничего не изменить. :)
Не знаю какая среда лучше но, мой MS Visual Studio.Net какой-то глюченный(естественно нелицензионный)!!!
Глюк1:
Неработает из его же хелпа.
Глюк2:
Вставляешь функчию getch() в любую прогу, и...
она не работает.
В Builder все нормально, и мне кажется что Борланд легче в освоении, а по возможностям не уступает.
А насчет размера то он везде одинаковый,сам проверял,прсто нужно настроить компилятор.
Глюк1:
Неработает из его же хелпа.
Глюк2:
Вставляешь функчию getch() в любую прогу, и...
она не работает.
В Builder все нормально, и мне кажется что Борланд легче в освоении, а по возможностям не уступает.
А насчет размера то он везде одинаковый,сам проверял,прсто нужно настроить компилятор.
Цитата:
Originally posted by CyberEx
Не знаю какая среда лучше но, мой MS Visual Studio.Net какой-то глюченный(естественно нелицензионный)!!!
Глюк1:
Неработает из его же хелпа.
Не знаю какая среда лучше но, мой MS Visual Studio.Net какой-то глюченный(естественно нелицензионный)!!!
Глюк1:
Неработает из его же хелпа.
IMHO проблема в кривизне рук устанавливабщего и пиратов. Может тебе не все диски продали?
Цитата:
Originally posted by CyberEx
Глюк2:
Вставляешь функчию getch() в любую прогу, и...
она не работает.
Глюк2:
Вставляешь функчию getch() в любую прогу, и...
она не работает.
А это кривизна рук кодописателя... У меня все нормально работает.
Цитата:
Originally posted by CyberEx
В Builder все нормально, и мне кажется что Борланд легче в освоении, а по возможностям не уступает.
В Builder все нормально, и мне кажется что Борланд легче в освоении, а по возможностям не уступает.
В освоении чего? С++ или Win32 API?
Цитата:
Originally posted by CyberEx
А насчет размера то он везде одинаковый,сам проверял,прсто нужно настроить компилятор.
А насчет размера то он везде одинаковый,сам проверял,прсто нужно настроить компилятор.
Везде одинаковый? Проверял? А можно технологию и результаты проверок?
Поверишь, в основном даже не в компиляторе суть.
Пираты продали мне два диска,но компоненты ироде исе есть.
**********************************************
У меня тоже нормально работают абсолютно те же проги откомпилиные в борланде.
**********************************************
Самого Си++ наверное.
**********************************************
Пишешь(или берешь исходник) какой либо проги(чем меньше тем лучше), компилишь и там и там.Потом полученные exe-шки просто сравниваешь по размеру(лучше при помощи спец утилиты,она точнее Win-а).
Суть в настройках проекта,наверное.
:P
**********************************************
У меня тоже нормально работают абсолютно те же проги откомпилиные в борланде.
**********************************************
Самого Си++ наверное.
**********************************************
Пишешь(или берешь исходник) какой либо проги(чем меньше тем лучше), компилишь и там и там.Потом полученные exe-шки просто сравниваешь по размеру(лучше при помощи спец утилиты,она точнее Win-а).
Суть в настройках проекта,наверное.
:P
Цитата:
Originally posted by CyberEx
Пираты продали мне два диска,но компоненты ироде исе есть.
Пираты продали мне два диска,но компоненты ироде исе есть.
Ну а в стандартном VS.NET их семь или восем, завтра из сейфа достану, точно скажу.
Цитата:
Originally posted by CyberEx
У меня тоже нормально работают абсолютно те же проги откомпилиные в борланде.
У меня тоже нормально работают абсолютно те же проги откомпилиные в борланде.
Покажи код. Уверен дело в нем, а не в VC++
Цитата:
Originally posted by CyberEx
Самого Си++ наверное.
Самого Си++ наверное.
Ну вот тут ты в корне не прав.
Билдер возник из Делфи и поэтому вся техника программирования с использованием VCL больше напоминает Pascal, нежели C++. Не думаю, что ты в своем творчестве на С++ используешь хотя-бы четверть мощности этого языка. Возьми к примеру А.Александреску с его техникой использования С++.
Я тут ради интереса набросал два класса, сможешь понять что они делают? Подсказка: делают они одно и тоже. А вот зачем их тогда два?
Код:
Код:
// for VC++
template<u64 bin, int base=2>
class CToDec
{
private:
template<u64 pin> class CPort
{
public: enum { value = CToDec<pin,base>::value };
};
template<> class CPort<0>
{
public: enum { value = 0 };
};
public:
enum { value = ((bin&0xF) + base*CPort<bin/0x10>::value) };
};
template<u64 bin, int base=2>
class CToDec
{
private:
template<u64 pin> class CPort
{
public: enum { value = CToDec<pin,base>::value };
};
template<> class CPort<0>
{
public: enum { value = 0 };
};
public:
enum { value = ((bin&0xF) + base*CPort<bin/0x10>::value) };
};
Кроме того Билдер своим набором визуальных компонентов отделяет программиста от Win32 API, поэтому они в большинстве своем очень смутно представляют себе механизмы, происходящие в системе.
Цитата:
Originally posted by CyberEx
Пишешь(или берешь исходник) какой либо проги(чем меньше тем лучше), компилишь и там и там.Потом полученные exe-шки просто сравниваешь по размеру(лучше при помощи спец утилиты,она точнее Win-а).
Пишешь(или берешь исходник) какой либо проги(чем меньше тем лучше), компилишь и там и там.Потом полученные exe-шки просто сравниваешь по размеру(лучше при помощи спец утилиты,она точнее Win-а).
Ну а если в коде программы используется разная техника программирования, например, в одной - в основном использование шаблонов, в другой - в основном множественное наследование, в третьей - в основном выделение переменных на стеке?
У разных компиляторов в каждом случае результаты будут разные.
Спец утилита? Какая?
Цитата:
Originally posted by CyberEx
Суть в настройках проекта,наверное.
:P
Суть в настройках проекта,наверное.
:P
Настройки проекта это совокупность параметров компиляции и линковки.
Суть в структуре кода, технике программирования и используемых библиотеках.
Цитата:
Originally posted by Green
Покажи код. Уверен дело в нем, а не в VC++
Покажи код. Уверен дело в нем, а не в VC++
Код(только долго не смеятся):
#include<iostream.h>
#include<conio.h>
void main()
{
cout<<"Hello World";
getch();
}
ВОТ ЭТОТ КОД НЕ РАБОТАЕТ с функцией getch().
Если вместо нее вставить например
int x;
cin>>x;//чтобы консоль сразу не исчезла
то все работает(в борланде все и всегда)
А борланд легче в освоении Си++ потому что,там легче понять саму среду,т.е. как в ней что-либо сделать(самые первые проги).
P.S.Я только начинающий,и у меня ОЧЕНЬ мало опыта.
Я сам хотел бы VC++ только теперь не знаю на какой 6 или 7.
Цитата:
Originally posted by CyberEx
Код(только долго не смеятся):
#include<iostream.h>
#include<conio.h>
void main()
{
cout<<"Hello World";
getch();
}
ВОТ ЭТОТ КОД НЕ РАБОТАЕТ с функцией getch().
Если вместо нее вставить например
int x;
cin>>x;//чтобы консоль сразу не исчезла
то все работает(в борланде все и всегда)
Код(только долго не смеятся):
#include<iostream.h>
#include<conio.h>
void main()
{
cout<<"Hello World";
getch();
}
ВОТ ЭТОТ КОД НЕ РАБОТАЕТ с функцией getch().
Если вместо нее вставить например
int x;
cin>>x;//чтобы консоль сразу не исчезла
то все работает(в борланде все и всегда)
Не используй ты такое старье, как iostream.h
Используй iostream.
Код:
#include<iostream>
#include<conio.h>
void main()
{
std::cout<<"Hello World";
getch();
}
#include<conio.h>
void main()
{
std::cout<<"Hello World";
getch();
}
Цитата:
Originally posted by CyberEx
А борланд легче в освоении Си++ потому что,там легче понять саму среду,т.е. как в ней что-либо сделать(самые первые проги).
А борланд легче в освоении Си++ потому что,там легче понять саму среду,т.е. как в ней что-либо сделать(самые первые проги).
Среда разработки не имеет отношения к языку. Некоторые на этой простоте (перетащил, тыкнул) и останавливаются.
Цитата:
Originally posted by CyberEx
P.S.Я только начинающий,и у меня ОЧЕНЬ мало опыта.
Я сам хотел бы VC++ только теперь не знаю на какой 6 или 7.
P.S.Я только начинающий,и у меня ОЧЕНЬ мало опыта.
Я сам хотел бы VC++ только теперь не знаю на какой 6 или 7.
Принципиальной разницы на начальном этапе нет. Бери то, что по-новее.
Цитата:
Originally posted by Green
Не используй ты такое старье, как iostream.h
Используй iostream.
Среда разработки не имеет отношения к языку. Некоторые на этой простоте (перетащил, тыкнул) и останавливаются.
Принципиальной разницы на начальном этапе нет. Бери то, что по-новее.
Не используй ты такое старье, как iostream.h
Используй iostream.
Код:
#include<iostream>
#include<conio.h>
void main()
{
std::cout<<"Hello World";
getch();
}
#include<conio.h>
void main()
{
std::cout<<"Hello World";
getch();
}
Среда разработки не имеет отношения к языку. Некоторые на этой простоте (перетащил, тыкнул) и останавливаются.
Принципиальной разницы на начальном этапе нет. Бери то, что по-новее.
А в чем разница между iostrem и iostream.h?
Все-таки если вставить в консольную программу getch(),используя iostream, то она перестает работать!(программа очень маленькая:выбирает из строки числа и складывает)
Может купить другой пиратский диск с Visual Studio.Net? А то я брал одни из первых(может сейчас лучше).
Всем привет, F1! Я на с++ вроде работал, пока что немного, но уже кое-что понимаю. Исходник такой:
#include<stdio.h>
#include<stdlib.h>
#include<process.h>
#include<string.h>
//#include<windows.h>
#include<afx.h>
HANDLE hcon=GetStdHandle(STD_OUTPUT_HANDLE);
_CONSOLE_SCREEN_BUFFER_INFO con_info;
//GetConsoleScreenBufferInfo(hcon, con_info);
void main(int argc, char* argv[]) {
printf("Restoring CD letter...\n");
char s[250];
//GetEnvironmentVariable("SYSTEMROOT", s, 200);
//CString proc_file(s); proc_file+="\\system32\\mountvol.exe";
char proc_file[250]; char* c=getenv("SYSTEMROOT");
strcpy(proc_file, c);
strcat(proc_file, "\\system32\\mountvol.xe");
if (!_spawnl(_P_WAIT, proc_file, proc_file, NULL)) {
printf("Child process ");
SetConsoleTextAttribute(hcon, 0x0b);
printf("OK"); SetConsoleTextAttribute(hcon, con_info.wAttributes);
} else {
SetConsoleTextAttribute(hcon, 0x0b);
printf("Process FAILED!\n");
};
printf("%s\n", proc_file);
printf("Done.\n");};
Так вот он под VC компиляется на 160 (!) кил. Это много. Очень. Компилятор под DOS (Borland C) делает то же самое намного меньше. Как и чем можно уменьшить размер готовой проги?
#include<stdio.h>
#include<stdlib.h>
#include<process.h>
#include<string.h>
//#include<windows.h>
#include<afx.h>
HANDLE hcon=GetStdHandle(STD_OUTPUT_HANDLE);
_CONSOLE_SCREEN_BUFFER_INFO con_info;
//GetConsoleScreenBufferInfo(hcon, con_info);
void main(int argc, char* argv[]) {
printf("Restoring CD letter...\n");
char s[250];
//GetEnvironmentVariable("SYSTEMROOT", s, 200);
//CString proc_file(s); proc_file+="\\system32\\mountvol.exe";
char proc_file[250]; char* c=getenv("SYSTEMROOT");
strcpy(proc_file, c);
strcat(proc_file, "\\system32\\mountvol.xe");
if (!_spawnl(_P_WAIT, proc_file, proc_file, NULL)) {
printf("Child process ");
SetConsoleTextAttribute(hcon, 0x0b);
printf("OK"); SetConsoleTextAttribute(hcon, con_info.wAttributes);
} else {
SetConsoleTextAttribute(hcon, 0x0b);
printf("Process FAILED!\n");
};
printf("%s\n", proc_file);
printf("Done.\n");};
Так вот он под VC компиляется на 160 (!) кил. Это много. Очень. Компилятор под DOS (Borland C) делает то же самое намного меньше. Как и чем можно уменьшить размер готовой проги?
Цитата:
Originally posted by fadd
Всем привет, F1! Я на с++ вроде работал, пока что немного, но уже кое-что понимаю. Исходник такой:
#include<stdio.h>
#include<stdlib.h>
#include<process.h>
#include<string.h>
//#include<windows.h>
#include<afx.h>
HANDLE hcon=GetStdHandle(STD_OUTPUT_HANDLE);
_CONSOLE_SCREEN_BUFFER_INFO con_info;
//GetConsoleScreenBufferInfo(hcon, con_info);
void main(int argc, char* argv[]) {
printf("Restoring CD letter...\n");
char s[250];
//GetEnvironmentVariable("SYSTEMROOT", s, 200);
//CString proc_file(s); proc_file+="\\system32\\mountvol.exe";
char proc_file[250]; char* c=getenv("SYSTEMROOT");
strcpy(proc_file, c);
strcat(proc_file, "\\system32\\mountvol.xe");
if (!_spawnl(_P_WAIT, proc_file, proc_file, NULL)) {
printf("Child process ");
SetConsoleTextAttribute(hcon, 0x0b);
printf("OK"); SetConsoleTextAttribute(hcon, con_info.wAttributes);
} else {
SetConsoleTextAttribute(hcon, 0x0b);
printf("Process FAILED!\n");
};
printf("%s\n", proc_file);
printf("Done.\n");};
Так вот он под VC компиляется на 160 (!) кил. Это много. Очень. Компилятор под DOS (Borland C) делает то же самое намного меньше. Как и чем можно уменьшить размер готовой проги?
Всем привет, F1! Я на с++ вроде работал, пока что немного, но уже кое-что понимаю. Исходник такой:
#include<stdio.h>
#include<stdlib.h>
#include<process.h>
#include<string.h>
//#include<windows.h>
#include<afx.h>
HANDLE hcon=GetStdHandle(STD_OUTPUT_HANDLE);
_CONSOLE_SCREEN_BUFFER_INFO con_info;
//GetConsoleScreenBufferInfo(hcon, con_info);
void main(int argc, char* argv[]) {
printf("Restoring CD letter...\n");
char s[250];
//GetEnvironmentVariable("SYSTEMROOT", s, 200);
//CString proc_file(s); proc_file+="\\system32\\mountvol.exe";
char proc_file[250]; char* c=getenv("SYSTEMROOT");
strcpy(proc_file, c);
strcat(proc_file, "\\system32\\mountvol.xe");
if (!_spawnl(_P_WAIT, proc_file, proc_file, NULL)) {
printf("Child process ");
SetConsoleTextAttribute(hcon, 0x0b);
printf("OK"); SetConsoleTextAttribute(hcon, con_info.wAttributes);
} else {
SetConsoleTextAttribute(hcon, 0x0b);
printf("Process FAILED!\n");
};
printf("%s\n", proc_file);
printf("Done.\n");};
Так вот он под VC компиляется на 160 (!) кил. Это много. Очень. Компилятор под DOS (Borland C) делает то же самое намного меньше. Как и чем можно уменьшить размер готовой проги?
Для начала скомпилировать в релизе.
Цитата:
Originally posted by Green
Кроме того Билдер своим набором визуальных компонентов отделяет программиста от Win32 API, поэтому они в большинстве своем очень смутно представляют себе механизмы, происходящие в системе.
Кроме того Билдер своим набором визуальных компонентов отделяет программиста от Win32 API, поэтому они в большинстве своем очень смутно представляют себе механизмы, происходящие в системе.
Несколько замечаний по поводу вышесказанного.
Опять старый, давно знакомый спор между поклонниками Билдера и MSVC. И в том и в другом случае, имхо, хватает своих недостатков. И у того и у другого хватает своих плюсов. И я например всегда стараюсь использовать для каждой конкретной задачи тот или иной компилятор.
Визуальные компоненты отделяют от Win32 API? Черта с два! В большинстве случаев, возникает необходимость сделать свой собственный уникальный компонент на Builder-e, чтобы не тащить за собой половину борландового и никому нафиг не нужного кода - вот тут-то в дело и вступает API, GDI и иже с ним. Сам неоднократно так делал - а ежели программер ни бум-бум в API то, извините меня, ему и MSVC в этом не поможет. Ну а рисовать большой проект, содержащий кучу GUI на MSVC? Не стану ни за какие коврижки. Даже за очень большие и вкусные.
А по поводу размеров файлов - экзешники MSVC гораздо меньше - только их действительно нужно компилять в релизе - ms debug отъедает большую кучу места. Билдер всегда был, есть и будет есть весьма толстым в виду наличия vcl библиотек. Можно конечно скомпилять проект с dynamic VCL - тогда экзешник будет содержать ТОЛЬКО пользовательский код - и поэтому будет меньше msvc-шного. Но библиотеки-то все равно перетаскивать надо. А какая разница где их тащить в одном экзешнике или кучей отдельных файлов? На мой взгляд один exe-шник предпочтительнее - отпадают проблемы переносимости с тачки на тачку.
Так что в любом случае - Билдер ТОЛЩЕ msvc - и двух мнений на эту тему быть не может!
Позвольте и мне втиснуться в обсуждение. Я вообще билдером не пользовался - VC++ only. Есть соображение в сторону VC.
Во-первых, генерация кода - не всегда хорошо. Начинающие сразу создают себе готовое приложение и ваяют ( пытаются ваять ) че-то, хотя зачастую предсталения не имеют как Win32 app должно быть устроено, как создавать окна и т.д.
Во-вторых, вопрос к знающим людям: вы MFC пользуетесь? Я вот чето слышал ( может это гон ) что в этой библиотеке есть утечки памяти, что имхо уже лишает ее пусть не на право существования, но на право использования в реальных проектах - точно.
По поводу VC 7 у меня сложилось не благоприятное ощущение - тормозной сильно, грузится долго, памяти много жрет, хотя компилит вроде быстрей шестого. MSDN 2003 тоже не подарок - у меня 2001 долго ( относительно ) вываливается, а этот еще дольше.
У меня не в тачке дело, если кто подумал.
А по поводу вопроса о размере exe, то во-первых, у компилера ( у VC6 точно ) есть опция оптимизации под размер ( хотя и не всегда работает ), а во-вторых есть все же сжимальщики exe. Я, например, upx юзаю. Да, время загрузки больше, но размер все-таки бывает и в 2 раза меньше.
А вообще имхо дело просто в компилере, если не юзать чужих библиотек ( vcl, MFC ).
Во-первых, генерация кода - не всегда хорошо. Начинающие сразу создают себе готовое приложение и ваяют ( пытаются ваять ) че-то, хотя зачастую предсталения не имеют как Win32 app должно быть устроено, как создавать окна и т.д.
Во-вторых, вопрос к знающим людям: вы MFC пользуетесь? Я вот чето слышал ( может это гон ) что в этой библиотеке есть утечки памяти, что имхо уже лишает ее пусть не на право существования, но на право использования в реальных проектах - точно.
По поводу VC 7 у меня сложилось не благоприятное ощущение - тормозной сильно, грузится долго, памяти много жрет, хотя компилит вроде быстрей шестого. MSDN 2003 тоже не подарок - у меня 2001 долго ( относительно ) вываливается, а этот еще дольше.
У меня не в тачке дело, если кто подумал.
А по поводу вопроса о размере exe, то во-первых, у компилера ( у VC6 точно ) есть опция оптимизации под размер ( хотя и не всегда работает ), а во-вторых есть все же сжимальщики exe. Я, например, upx юзаю. Да, время загрузки больше, но размер все-таки бывает и в 2 раза меньше.
А вообще имхо дело просто в компилере, если не юзать чужих библиотек ( vcl, MFC ).
Цитата:
Originally posted by Green
Для начала скомпилировать в релизе.
Для начала скомпилировать в релизе.
Скомпилировал... При подключении MFC (с единственной целью: CString) тянет где-то на 90К, если в статике. Указываю Use MFC as shared DLL, получаю около 16К. Имхо много. Тем более что в любом HEX-редакторе exe содержит больше двух третей 0x00h-байтов. Покопался в настройках, всё равно не совсем понимаю.. Не может же он так компилять исключительно с целью раздуть конечный файл? Тем более что в коде (exe) практически одни вызовы из kernel32.dll и ещё чего-то... Нули :)
Цитата:
Originally posted by fadd
Скомпилировал... При подключении MFC (с единственной целью: CString) тянет где-то на 90К, если в статике. Указываю Use MFC as shared DLL, получаю около 16К. Имхо много. Тем более что в любом HEX-редакторе exe содержит больше двух третей 0x00h-байтов. Покопался в настройках, всё равно не совсем понимаю.. Не может же он так компилять исключительно с целью раздуть конечный файл? Тем более что в коде (exe) практически одни вызовы из kernel32.dll и ещё чего-то... Нули :)
Скомпилировал... При подключении MFC (с единственной целью: CString) тянет где-то на 90К, если в статике. Указываю Use MFC as shared DLL, получаю около 16К. Имхо много. Тем более что в любом HEX-редакторе exe содержит больше двух третей 0x00h-байтов. Покопался в настройках, всё равно не совсем понимаю.. Не может же он так компилять исключительно с целью раздуть конечный файл? Тем более что в коде (exe) практически одни вызовы из kernel32.dll и ещё чего-то... Нули :)
Знаешь откуда беруться нули? Почитай доки по PE формату - это славный наш мелкомягкий со своей гребанной страстью к различного рода выравниваниям. Ну скажите мне например - ежели у меня секция кода файла будет выровнена на границу 4 байт а не 0x1000 байт - прога от этого что - тормозить станет? Однозначно нет. К тому же, как показывает практика - загрузчику глубоко положить на то - выровнена секция или нет - какой у нее размер указан - такой и грузит. Ну это-же микрософт - как не повыпендриваться и при линковке не напихать в конец секции кучу никому ненужных NOP-ов, INT 3, и прочих нулей.
Да что там секции - внимательно ознакомившись с PE форматом понял одну потрясающую вещь - половина полей из заголовка вообще никому не нужна!!! Так что в результате имеем экзешник с кучей мусора в начале и с гораздо большими кучами того же самого мусора в конце файла.
Короче суксь.
Цитата:
Originally posted by ddnh_bc
Ну скажите мне например - ежели у меня секция кода файла будет выровнена на границу 4 байт а не 0x1000 байт - прога от этого что - тормозить станет?
Ну скажите мне например - ежели у меня секция кода файла будет выровнена на границу 4 байт а не 0x1000 байт - прога от этого что - тормозить станет?
Она перестанет работать вовсе, т.к. минимальная граница 512 байт
Цитата:
Originally posted by ddnh_bc
К тому же, как показывает практика - загрузчику глубоко положить на то - выровнена секция или нет - какой у нее размер указан - такой и грузит.
К тому же, как показывает практика - загрузчику глубоко положить на то - выровнена секция или нет - какой у нее размер указан - такой и грузит.
См. выше
Цитата:
Originally posted by ddnh_bc
Да что там секции - внимательно ознакомившись с PE форматом понял одну потрясающую вещь - половина полей из заголовка вообще никому не нужна!!!
Да что там секции - внимательно ознакомившись с PE форматом понял одну потрясающую вещь - половина полей из заголовка вообще никому не нужна!!!
Формат PE является наследником формата NE, который в свою очередь происходит от COFF.
Все эти форматы создавались относительно давно и с резервом для дальнейшего использования. Некоторые такие резервы себя оправдали, некоторые нет, некоторые поля просто устарели. Формат COFF, вообще, не имеет отношения к MS, это довольно старый формат, заимствованный у UNIX.
Цитата:
Originally posted by Green
Она перестанет работать вовсе, т.к. минимальная граница 512 байт
Она перестанет работать вовсе, т.к. минимальная граница 512 байт
Я не говорю про то что PE лоадер не загрузит прогу если размер граница будет ниже 0x200.
Я говорю про исполняемый образ.
Физически да - для ускорения засасывания файла в память его было бы неплохо выровнять на границу одного физического сектора диска - это да. Но настолько ли это критично?
А ежели говорить с точки зрения выполняемых инструкций - процу глубоко по барабану что, к примеру секция данных у тебя валяется в памяти по смещению +4 или +8 от конца секции кода или по смещению 0x1000.
Конечно, если при загрузке мапить файлы в память - может быть это и будет иметь некоторое значение, но не очень.
Так что вопрос с выравниванием остается открытым.
На мой взгляд если его и использовать так активно - то 0x200 вполне хватит для этих целей (причем в некоторых экзешниках этот параметр фигурирует). А добивать до 0x1000 - уже избыточно, не говоря уж о более высоких степенях.
А к вопросу о PE скажу так - что если уж передирать с чужого формата - так по крайней мере делать это надо с толком, а не мусорить с рассчетом на то что сия помойка может когда-нибудь пригодиться. Динамический размер структур не настолько сложная вещь в этом мире.
Цитата:
Originally posted by fadd
Скомпилировал... При подключении MFC (с единственной целью: CString) тянет где-то на 90К, если в статике. Указываю Use MFC as shared DLL, получаю около 16К. Имхо много. Тем более что в любом HEX-редакторе exe содержит больше двух третей 0x00h-байтов. Покопался в настройках, всё равно не совсем понимаю.. Не может же он так компилять исключительно с целью раздуть конечный файл? Тем более что в коде (exe) практически одни вызовы из kernel32.dll и ещё чего-то... Нули :)
Скомпилировал... При подключении MFC (с единственной целью: CString) тянет где-то на 90К, если в статике. Указываю Use MFC as shared DLL, получаю около 16К. Имхо много. Тем более что в любом HEX-редакторе exe содержит больше двух третей 0x00h-байтов. Покопался в настройках, всё равно не совсем понимаю.. Не может же он так компилять исключительно с целью раздуть конечный файл? Тем более что в коде (exe) практически одни вызовы из kernel32.dll и ещё чего-то... Нули :)
А ты попробуй не подключать MFC как библиотеку, а в конфигурации релиза при компоновке программы укажи использовать стандартные библиотеки windows.
Цитата:
Originally posted by fadd
Всем привет, F1! Я на с++ вроде работал, пока что немного, но уже кое-что понимаю. Исходник такой:
#include<stdio.h>
#include<stdlib.h>
#include<process.h>
#include<string.h>
//#include<windows.h>
#include<afx.h>
HANDLE hcon=GetStdHandle(STD_OUTPUT_HANDLE);
_CONSOLE_SCREEN_BUFFER_INFO con_info;
//GetConsoleScreenBufferInfo(hcon, con_info);
void main(int argc, char* argv[]) {
printf("Restoring CD letter...\n");
char s[250];
//GetEnvironmentVariable("SYSTEMROOT", s, 200);
//CString proc_file(s); proc_file+="\\system32\\mountvol.exe";
char proc_file[250]; char* c=getenv("SYSTEMROOT");
strcpy(proc_file, c);
strcat(proc_file, "\\system32\\mountvol.xe");
if (!_spawnl(_P_WAIT, proc_file, proc_file, NULL)) {
printf("Child process ");
SetConsoleTextAttribute(hcon, 0x0b);
printf("OK"); SetConsoleTextAttribute(hcon, con_info.wAttributes);
} else {
SetConsoleTextAttribute(hcon, 0x0b);
printf("Process FAILED!\n");
};
printf("%s\n", proc_file);
printf("Done.\n");};
Так вот он под VC компиляется на 160 (!) кил. Это много. Очень. Компилятор под DOS (Borland C) делает то же самое намного меньше. Как и чем можно уменьшить размер готовой проги?
Всем привет, F1! Я на с++ вроде работал, пока что немного, но уже кое-что понимаю. Исходник такой:
#include<stdio.h>
#include<stdlib.h>
#include<process.h>
#include<string.h>
//#include<windows.h>
#include<afx.h>
HANDLE hcon=GetStdHandle(STD_OUTPUT_HANDLE);
_CONSOLE_SCREEN_BUFFER_INFO con_info;
//GetConsoleScreenBufferInfo(hcon, con_info);
void main(int argc, char* argv[]) {
printf("Restoring CD letter...\n");
char s[250];
//GetEnvironmentVariable("SYSTEMROOT", s, 200);
//CString proc_file(s); proc_file+="\\system32\\mountvol.exe";
char proc_file[250]; char* c=getenv("SYSTEMROOT");
strcpy(proc_file, c);
strcat(proc_file, "\\system32\\mountvol.xe");
if (!_spawnl(_P_WAIT, proc_file, proc_file, NULL)) {
printf("Child process ");
SetConsoleTextAttribute(hcon, 0x0b);
printf("OK"); SetConsoleTextAttribute(hcon, con_info.wAttributes);
} else {
SetConsoleTextAttribute(hcon, 0x0b);
printf("Process FAILED!\n");
};
printf("%s\n", proc_file);
printf("Done.\n");};
Так вот он под VC компиляется на 160 (!) кил. Это много. Очень. Компилятор под DOS (Borland C) делает то же самое намного меньше. Как и чем можно уменьшить размер готовой проги?
Раз уж разговор зашел о размерах исп.файлов, держите примерчик:
полноценное win32 GUI приложение всего в 4.5 кб... Кроме того имеет еще и полезную функцию ;)
Цитата:
Originally posted by fadd
Всем привет, F1! Я на с++ вроде работал, пока что немного, но уже кое-что понимаю. Исходник такой:
#include<stdio.h>
#include<stdlib.h>
#include<process.h>
#include<string.h>
//#include<windows.h>
#include<afx.h>
HANDLE hcon=GetStdHandle(STD_OUTPUT_HANDLE);
_CONSOLE_SCREEN_BUFFER_INFO con_info;
//GetConsoleScreenBufferInfo(hcon, con_info);
void main(int argc, char* argv[]) {
printf("Restoring CD letter...\n");
char s[250];
//GetEnvironmentVariable("SYSTEMROOT", s, 200);
//CString proc_file(s); proc_file+="\\system32\\mountvol.exe";
char proc_file[250]; char* c=getenv("SYSTEMROOT");
strcpy(proc_file, c);
strcat(proc_file, "\\system32\\mountvol.xe");
if (!_spawnl(_P_WAIT, proc_file, proc_file, NULL)) {
printf("Child process ");
SetConsoleTextAttribute(hcon, 0x0b);
printf("OK"); SetConsoleTextAttribute(hcon, con_info.wAttributes);
} else {
SetConsoleTextAttribute(hcon, 0x0b);
printf("Process FAILED!\n");
};
printf("%s\n", proc_file);
printf("Done.\n");};
Так вот он под VC компиляется на 160 (!) кил. Это много. Очень. Компилятор под DOS (Borland C) делает то же самое намного меньше. Как и чем можно уменьшить размер готовой проги?
Всем привет, F1! Я на с++ вроде работал, пока что немного, но уже кое-что понимаю. Исходник такой:
#include<stdio.h>
#include<stdlib.h>
#include<process.h>
#include<string.h>
//#include<windows.h>
#include<afx.h>
HANDLE hcon=GetStdHandle(STD_OUTPUT_HANDLE);
_CONSOLE_SCREEN_BUFFER_INFO con_info;
//GetConsoleScreenBufferInfo(hcon, con_info);
void main(int argc, char* argv[]) {
printf("Restoring CD letter...\n");
char s[250];
//GetEnvironmentVariable("SYSTEMROOT", s, 200);
//CString proc_file(s); proc_file+="\\system32\\mountvol.exe";
char proc_file[250]; char* c=getenv("SYSTEMROOT");
strcpy(proc_file, c);
strcat(proc_file, "\\system32\\mountvol.xe");
if (!_spawnl(_P_WAIT, proc_file, proc_file, NULL)) {
printf("Child process ");
SetConsoleTextAttribute(hcon, 0x0b);
printf("OK"); SetConsoleTextAttribute(hcon, con_info.wAttributes);
} else {
SetConsoleTextAttribute(hcon, 0x0b);
printf("Process FAILED!\n");
};
printf("%s\n", proc_file);
printf("Done.\n");};
Так вот он под VC компиляется на 160 (!) кил. Это много. Очень. Компилятор под DOS (Borland C) делает то же самое намного меньше. Как и чем можно уменьшить размер готовой проги?
Кроме того, что программы надо компилировать в релизе, там еще можно в настройках Linkerа поставить Exclude debug information
Моя СУБД с кучей диалогов (> 20), соответственно в каждом сделана обработка данных, с вызовом непосредственно функций DAO, 10 таблиц + запросы (по классу на все) с написанными функциями поиска. Притом большинство функций inline. Так вот весит < 500 кБ на static linking.
Моя СУБД с кучей диалогов (> 20), соответственно в каждом сделана обработка данных, с вызовом непосредственно функций DAO, 10 таблиц + запросы (по классу на все) с написанными функциями поиска. Притом большинство функций inline. Так вот весит < 500 кБ на static linking.
Цитата:
Originally posted by pavor
Кроме того, что программы надо компилировать в релизе, там еще можно в настройках Linkerа поставить Exclude debug information
Моя СУБД с кучей диалогов (> 20), соответственно в каждом сделана обработка данных, с вызовом непосредственно функций DAO, 10 таблиц + запросы (по классу на все) с написанными функциями поиска. Притом большинство функций inline. Так вот весит < 500 кБ на static linking.
Кроме того, что программы надо компилировать в релизе, там еще можно в настройках Linkerа поставить Exclude debug information
Моя СУБД с кучей диалогов (> 20), соответственно в каждом сделана обработка данных, с вызовом непосредственно функций DAO, 10 таблиц + запросы (по классу на все) с написанными функциями поиска. Притом большинство функций inline. Так вот весит < 500 кБ на static linking.
Просмотрел все опции закладки Link, ничего похожего на 'Exclude debug information' нет =(
У меня такая же проблема:
Прога скомпилена в MFC static и весит 150Кб, а в памяти 2000-4000Кб! У меня столько памяти жрут тока проги на VB6 (при том, что в них наворотов немеренно).
А на VC6 я делал - MFC + Dialog based (1 диалог всего) + afxinet.h (для httpd) + winsock2.h (для eth).
дорогие программисты!!! я конечно не бог в программировании но на первой страници этой темы я вычитал, что Builder хуже на чем Delphi!!! извените я на 3 курсе учусь!!! за три года и плюс те 2 что я раньше знал паскаль(Delphi)!!! но за последние 3 года которых я работаю на Builder, я не видел ничего такого что можно зделать на Deplhi, не делалось бы на Buikder, но видел и делал на Builder, то что на Delphi нельзя!!! блин ребята может я что то упустил!!! мыльте [email]valera_zlenko@list.ru[/email]:cool:
