Шо за прикол с компиляцией???
Установил MSVCPP6. Вобще я VB содер, но пора перестраиваться, я си в кратцах поизучал, дык вот, пишу консольный хелловорд, компилирую - ПОЛ Мега размер!! В ЧЕМ ПРИКОЛ?? Я на ассемблере тоже самое в десять байт сделаю! Подсобите, мож я че не так сделал? Или вобще посоветуйте, где мне под Винду кодить нормально.
ты компилял в дебажной (от слова debug) конфигурации и к твоему EXEэшнику подкеено куча отладочной информации, поэтому такой большой файл, после того как прогу отладишь, компиляй в Release конфигурации, там фсё нинужное будет откинуто и получишь маленький файл
Установил MSVCPP6. Вобще я VB содер, но пора перестраиваться, я си в кратцах поизучал, дык вот, пишу консольный хелловорд, компилирую - ПОЛ Мега размер!! В ЧЕМ ПРИКОЛ?? Я на ассемблере тоже самое в десять байт сделаю! Подсобите, мож я че не так сделал? Или вобще посоветуйте, где мне под Винду кодить нормально.
EXE PE-формата в 10 байт?
Сомневаюсь...
Не верю!
Плз, сделай и покажи :)
EXE PE-формата в 10 байт?
Сомневаюсь...
Не верю!
Плз, сделай и покажи :)
гм.. а на$уй тебе exe размером 10 байт???
что он дельного будет делать?
если ты пишешь серьёзную софтину под Windows, основным параметром будет - скорость написания проги, а не её размер, мы не в 80-90х прошлого века, когда "узкие" каналы связи, дорогая оперативная память, и реальный режим x86 проца (в DOS'е) заставляли задуматься о размере проги.
Сейчас тебе ни один работодатель не даст ковырять, отлаживать и вылизывать код проги на асме два месяца если тоже самое можно сделать за 2 дня на Вижуал-Ваське или Дельфях. И пусть второй вариант будет на 100 байт больше.
Сейчас тока если ты пишешь под какой-нить могильник или наладонник можно заморочиться с размером, да и то прогресс не стоит на месте, J2ME тому подтверждение.
З.Ы. (касаемо скорости и асма) большинство GUI Windows приложений, офисного плана (ну там текстовые процессоры, электронные таблицы, финансовые проги) 90% процессорного времени в WaitMessage(), пожалуй тока приложения реального времени, игры, или проги обрабатыввающие пакетно большие объёмы (мультимедиа) данных нуждаються в оптимизации на асме, но и тут следует помнить что неудачно выбранный алгоритм не спасёт никакой асм. Как ты не оптимизируй сортировку "пузырьком", алгоритм "Быстрой сортировки" написанный на языке высокого уровня, или тем более на Си будет всёравно быстрее. :)
в опщем нах. проехали.
Спокуха, про ехе 10 байт - ето я конечно сгиперболил.
Просто под досину раньше увлекался писать хекс-редактором.
да, в ПЕ, вроде один заголовок и то больше.
Что дельного сделает мелкая прога? Я просто имелл в виду
хеловорд, который по умолчанию весит пол мега.
Кстати я пробовал отключать Debug, ставил галку на
Release, но вроде результ тотже.
Касательно скорости асма:
Вот как всегда - типа, прогрес, память дешевка, процы за 2Гц
бегают, можно халявить. Я согласен шо в винде большенство прог
постоянно в простое, но тот же ехсел, когра перерасчитывает
формулы на большом листе, сильно загружает ЦП. Тут можно
тоже пооптимизировать..
Впрочем я за си не из оптимизации взялся.
Скорость написания прог? Согласен, я лучше завалюся в родной
VB6, и накидаю формочку, шоб она мне решала степенные
неравенства, чем тоже самое буду мудить на асм.
НО ведь в чем прикол, можно писать досконально действия
микрокомандами, а можно создать паченьку нужных математич
процедурок(шо уже впрочем создано), и юзать их при вычислении.
Вот тут кстати особенности:
TASM5 обычно юзает макросы, и каждая процеДура ну вызывается
а просто каждый раз копируется там, где ее упомянули.
Результат - лишний размер
VC++ должен вроде всегда должен вызывать процедуры.
Я еще вот че подумал, коды он подсоединяет к проекту
набор стандартных функций, он же их ВСЕ шоли потом и компилит
может отсюда лишний сайз? или же он их фильтрует? типа
ету не вызывают, идем дальше, а ету вызывают, компилируем.
и чем кстати отличается компил-ние под MSVCPP от IBCPP?
теоретич при идеальном алгоритме компил-я должен получиться
одинаковый код на обоих, хотя я не раз встречал талбицы
сравнения етих компилей.
Тут у меня еще валяется "Metrowerks CodeWarrior PRO v8.0"
тоже доп компилер, чем он лучшей?
> "большинство GUI Windows приложений, офисного плана"
ну ето понятно, проще высоким уровнем писать, но ведь для
чего я и взялся за С++, разве можно написать действительно
нормальный вирус на высоком уровне? Чур палками не кидаться,
я знаю шо можно, у меня и сыр валялся от Паскаля с Бесиком.
Но я говорю о действительно норм вирусе, где, кстати, критичен
размер, посему не проще
"тоже самое сделать за 2 дня на Вижуал-Ваське или Дельфях.
И пусть второй вариант будет на 100 байт больше."
С уважением, xkip.
гм.. а на$уй тебе exe размером 10 байт???
что он дельного будет делать?
если ты пишешь серьёзную софтину под Windows, основным параметром будет - скорость написания проги, а не её размер, мы не в 80-90х прошлого века, когда "узкие" каналы связи, дорогая оперативная память, и реальный режим x86 проца (в DOS'е) заставляли задуматься о размере проги.
Сейчас тебе ни один работодатель не даст ковырять, отлаживать и вылизывать код проги на асме два месяца если тоже самое можно сделать за 2 дня на Вижуал-Ваське или Дельфях. И пусть второй вариант будет на 100 байт больше.
Сейчас тока если ты пишешь под какой-нить могильник или наладонник можно заморочиться с размером, да и то прогресс не стоит на месте, J2ME тому подтверждение.
З.Ы. (касаемо скорости и асма) большинство GUI Windows приложений, офисного плана (ну там текстовые процессоры, электронные таблицы, финансовые проги) 90% процессорного времени в WaitMessage(), пожалуй тока приложения реального времени, игры, или проги обрабатыввающие пакетно большие объёмы (мультимедиа) данных нуждаються в оптимизации на асме, но и тут следует помнить что неудачно выбранный алгоритм не спасёт никакой асм. Как ты не оптимизируй сортировку "пузырьком", алгоритм "Быстрой сортировки" написанный на языке высокого уровня, или тем более на Си будет всёравно быстрее. :)
в опщем нах. проехали.
Спасибо за научно-популярную лекцию... :D
Но мне интересно, как можно написать прогу для Windows, т.е. модуль PE-формата размером 10 байт, если только заголовок около 256 байт не считая таблиц секций, импорта, переходов и т.д.
если ты пишешь серьёзную софтину под Windows, основным параметром будет - скорость написания проги, а не её размер, мы не в 80-90х прошлого века, когда "узкие" каналы связи, дорогая оперативная память, и реальный режим x86 проца (в DOS'е) заставляли задуматься о размере проги.
Ну... вообще-то я серьезные софтины и пишу...
и скажу, что скорость разработки конечно важна, но она четко определена регламентами, например, периодом итерации.
Размер программы важен и сейчас, ошибкой является приуменьшение значения этого параметра. Небольшой размер удобен, как для пользователя, так и для разработчика (небольшие по объёму программы легче отлаживать и поддерживать).
Кроме того,
Сейчас тебе ни один работодатель не даст ковырять, отлаживать и вылизывать код проги на асме два месяца если тоже самое можно сделать за 2 дня на Вижуал-Ваське или Дельфях. И пусть второй вариант будет на 100 байт больше.
Во-первых, срок создания серьезной программы где-то от 6 мес. и более, это где-то 12-15 итераций.
Во-вторых, где ты видел полноценные, серьезные программы на VB и Делфи? Конкретные примеры?
В-третьих, асм, как полноценный язык, действительно, малоприменим, но для расширения возможностей и сокращения кода вполне используем, например, при разработке VxD.
...неудачно выбранный алгоритм не спасёт никакой асм. Как ты не оптимизируй сортировку "пузырьком", алгоритм "Быстрой сортировки" написанный на языке высокого уровня, или тем более на Си будет всёравно быстрее. :)
А Си не является языком высокого уровня?
Про неудачно выбранный алгоритм я согласен, но вот только, такой неправильный выбор влияет и на избыточный размер программы. Например, неправильное понимание и использование виртуальных ф-ций, вместо применения шаблонов, и т.п. В большенстве случаев кратко реализованные алгоритмы и работают быстрее.
Спокуха, про ехе 10 байт - ето я конечно сгиперболил.
Просто под досину раньше увлекался писать хекс-редактором.
да, в ПЕ, вроде один заголовок и то больше.
Что дельного сделает мелкая прога? Я просто имелл в виду
хеловорд, который по умолчанию весит пол мега.
Кстати я пробовал отключать Debug, ставил галку на
Release, но вроде результ тотже.
Касательно скорости асма:
Вот как всегда - типа, прогрес, память дешевка, процы за 2Гц
бегают, можно халявить. Я согласен шо в винде большенство прог
постоянно в простое, но тот же ехсел, когра перерасчитывает
формулы на большом листе, сильно загружает ЦП. Тут можно
тоже пооптимизировать..
Впрочем я за си не из оптимизации взялся.
Скорость написания прог? Согласен, я лучше завалюся в родной
VB6, и накидаю формочку, шоб она мне решала степенные
неравенства, чем тоже самое буду мудить на асм.
НО ведь в чем прикол, можно писать досконально действия
микрокомандами, а можно создать паченьку нужных математич
процедурок(шо уже впрочем создано), и юзать их при вычислении.
Вот тут кстати особенности:
TASM5 обычно юзает макросы, и каждая процеДура ну вызывается
а просто каждый раз копируется там, где ее упомянули.
Результат - лишний размер
VC++ должен вроде всегда должен вызывать процедуры.
Я еще вот че подумал, коды он подсоединяет к проекту
набор стандартных функций, он же их ВСЕ шоли потом и компилит
может отсюда лишний сайз? или же он их фильтрует? типа
ету не вызывают, идем дальше, а ету вызывают, компилируем.
и чем кстати отличается компил-ние под MSVCPP от IBCPP?
теоретич при идеальном алгоритме компил-я должен получиться
одинаковый код на обоих, хотя я не раз встречал талбицы
сравнения етих компилей.
Тут у меня еще валяется "Metrowerks CodeWarrior PRO v8.0"
тоже доп компилер, чем он лучшей?
> "большинство GUI Windows приложений, офисного плана"
ну ето понятно, проще высоким уровнем писать, но ведь для
чего я и взялся за С++, разве можно написать действительно
нормальный вирус на высоком уровне? Чур палками не кидаться,
я знаю шо можно, у меня и сыр валялся от Паскаля с Бесиком.
Но я говорю о действительно норм вирусе, где, кстати, критичен
размер, посему не проще
"тоже самое сделать за 2 дня на Вижуал-Ваське или Дельфях.
И пусть второй вариант будет на 100 байт больше."
С уважением, xkip.
Современные компиляторы, действительно, довольно неплохо оптимизируют код и не компилят то, что не используется.
А различные компиляторы по разному реализуют стандарты и спецификации языка, кроме того по-разному реализованы стандартные библиотеки, поэтому и используют разные компиляторы.
Почему-то, говоря о скорости разработки, часто говорят о скорости разработки пользовательского интерфейса, как будто программирование заключается в разработке интерфейсов.
Про размеры и вирусы... Могу предоставить пример написания кл.шпиона размером 4кб (2кб - EXE + 2кб DLL). И это не предел, почитайте статью на uinc.ru про проги менее 1кб.
Я просто имелл в виду хеловорд, который по умолчанию весит пол мега.
Кстати я пробовал отключать Debug, ставил галку на
Release, но вроде результ тотже.
ты о Windows Application Hello-world'е? он должен быть около 64 кб, а Console Application и того меньше, а вот MFC будет большой, если к нему MFC еще и прилинковать то вашще под несколько метров :))
...но тот же ехсел, когра перерасчитывает
формулы на большом листе, сильно загружает ЦП. Тут можно
тоже пооптимизировать..
тут можно, я же говорил, всё что нуждаётся в оптимизации, необходимо оптимизировать
Вот тут кстати особенности:
TASM5 обычно юзает макросы, и каждая процеДура ну вызывается
а просто каждый раз копируется там, где ее упомянули.
Результат - лишний размер
VC++ должен вроде всегда должен вызывать процедуры.
нет это не так, и в TASM'е можна обойтись без макросов, писать продцедуры, call, jmp, int, как будет удобно в конкретном случае, макросы тока для прямой подстановки кода.
1.в MSVC++ можно писать макросы используя #define:
#define FIXMUL(a,b) (a * b >> 16)
2. Но define прямо подставляет, текст ПЕРЕД компиляцией, и это может вызвать траблы:
#define MIN(a,b) ((a) < (b) ? (a) : (b))
...
c = MIN(a, ++b) -> c = a < (++a) ? (++a) : a;
что даёт не то что подразумавалось.
поэтому в C++ ввели inline ф-ции они проверяют типы и лишены побочных эффектов:
inline min(int a, int b)
{
return a < b ? a : b;
}
3. чтобы inline ф-ции работали не тока с теми типами для которых написаны (у меня в примере это int), но и с другими, произвольными пишут template:
inline template<class T> min(T a, T b)
{
return a < b ? a : b;
}
4. и наконец можно в опциях компилятора и компоновщика указать что подставлять inline'ом ЛЮБУЮ подходящую ф-цию
Я еще вот че подумал, коды он подсоединяет к проекту
набор стандартных функций, он же их ВСЕ шоли потом и компилит
никак нет, он компонует только то, что реально может вызываться. и стартовый код, см исходники.
и чем кстати отличается компил-ние под MSVCPP от IBCPP?
теоретич при идеальном алгоритме компил-я должен получиться
одинаковый код на обоих, хотя я не раз встречал талбицы
тут дело не тока в алгоритме компиляции, сколько в алгоритме оптимизации, он перемещивает инструкции чтобы оптимально использовать аппаратные особенности процессора, например, UV-конвеера, кэш и прочее. А оптимума нету эта задача не разрешима, эти алгоритмы используют эвристику, по этому результаты разняться.
тут у меня еще валяется "Metrowerks CodeWarrior PRO v8.0"
тоже доп компилер, чем он лучшей?
я про такой не слышал, но имхо, для DOS идеальным будет Watcom C++ 11, он поддерживает навороты Visual C++ 5/(6 ?), и кучу платформ:
DOS 16-bit/DOS4GW/PMODE/Windows16/32/Autodesk CAD и пр.
Но я говорю о действительно норм вирусе, где, кстати, критичен
так, отсюда по-подробнее, что мы будем считать нормальным вирусом???
ассемблер почти не нужен чтобы заразить тысячи компьютеров в Internet, распространяясь через дырки Outlook/IIS/IE :))
а на мой взгляд, удачным вирусом можно считать тот вирус который нанёс больше всего ущерба...
А Си не является языком высокого уровня?
Моё текущее представление о Си:
Тама (каж-ся) можно напрямуя шлёпать асемблером (т.е. ето низкий уровень), но в тоже время всегда можно заюзить каку-нить высокоуровневую ф-цию, написаную в подгр файлах, тем самым получая высокий уровень программир-я.
Я прав?
Моё текущее представление о Си:
Тама (каж-ся) можно напрямуя шлёпать асемблером (т.е. ето низкий уровень), но в тоже время всегда можно заюзить каку-нить высокоуровневую ф-цию, написаную в подгр файлах, тем самым получая высокий уровень программир-я.
Я прав?
НЕТ
Моё текущее представление о Си:
Тама (каж-ся) можно напрямуя шлёпать асемблером (т.е. ето низкий уровень), но в тоже время всегда можно заюзить каку-нить высокоуровневую ф-цию, написаную в подгр файлах, тем самым получая высокий уровень программир-я.
Я прав?
нет.
высокоуровневый/низкоуровневый обычно имеют ввиду отвязку от аппаратной части, асм это уровень низкий, зависимость от аппаратуры 100% ная, Smalltalk, Perl, VisualBasic, Java и т.п. уровень высокий, (отвязка от процессора, событийная/объектная ориентированность)
Язык Си это язык алгоритмический, как скажем то-же паскаль, НО этот язык придназначался для написания операционных систем, тут мы видим, побитовые операции, сдвиги, прямое управление памятью, зависимость от платформы велика (например, sizeof() типов неопределён, в стандарте определена тока относительная зависимость),расположение у вамяти данных в структурах строго определено, (чего нельзя сказать о паскале и васике) хотя программу портировать легче чем на асме. Поэтому принято язык Си считать языком среднего уровня.
Во-вторых, где ты видел полноценные, серьезные программы на VB и Делфи? Конкретные примеры?
что касаемо VB и Delphi я их обычно не юзаю (Pascal(и Delphi) я вапще никада не разбирал :), ну не точно бы совсем...но...), проги написанные на них обычно смотряться жалко, но тут дело не в самих средах разработки, а в компетентности программистов, т.к. обычно это люди начинающие или средней руки студенты-программисты.
...небольшие по объёму программы легче отлаживать и поддерживать...
гы...небольшые программы, а не EXE'шники, если ты перепишешь прогу на асме, чтобы был небольшой выходной exe, то отлаживать, дополнять и поддерживать такую прогу будет ооой как сложно :)
P.S. я не призывал не использовать асм. я говорил что его использование существенно усложняет процесс программирования, и поэтому должно применяться тока когда это действительно необходимо. Мне часто приходилось наблюдать крайности когда народ оптимизировал то, что в оптимизации по скорости/размеру не нуждалось, а на отладку и оптимизацию тратилось время
> он должен быть около 64 кб, а Console
> Application и того меньше, а вот MFC
> будет большой, если к нему MFC еще и
> прилинковать то вашще под несколько
> метров :))
Лично у меня MSVC++ v6.0 Console Application
встроеный Нелловорд, Debug, весит почти
ровно пол мега
> в MSVC++ можно писать макросы
> используя #define
> в C++ ввели inline
ну про инлайн я пока не въехал, просто
токо недавно стал Си изучать, но ето
еще впереди, если я че-то захочу изучить,
я ето сделаю. Поставив VB я, спустя месяц
ужо в совершенстве въехал в об-ориент
программиров-е, а через пол года вполне
совершенные проги стал писать, типа
DialUpForceHack, TCPScaner3, NetAdmin...
(судите по названию)
Вот кстати, может подкинете какой учебник
крутой? Я читаю англ "C++ WroxTutorial"
но там маловато, я привык получать много
подробной инфы. И там нет справочников,
токо учебник.
> никак нет, он компонует только то, что
> реально может вызываться. и стартовый
> код, см исходники.
Вот ето радует
> тут дело не тока в алгоритме компиляции,
> сколько в алгоритме оптимизации
Да, про оптимизаторы я слыхал.
А можно ли отключать оптимизацию?
Чтобы получить чисто перекодированную
в машин код прогу. Ето конешно маразм,
но для изучения дизасм-ного дампа удобнее,
а то на первых парах я постараюсь быть привязан
к чистому асму, получаемому при компиле.
Хотя всю жись я не собираюсь под винду шлепать.
У меня кое-чо задумано :)
> так, отсюда по-подробнее, что мы будем
> считать нормальным вирусом???
> ассемблер почти не нужен чтобы заразить
> тысячи компьютеров в Internet, распространяясь
> через дырки Outlook/IIS/IE :))
соверш согласен, но НОРМАЛЬНЫЙ вирус,
в отличии от написанного на яз выс уровн,
недолжен иметь никаких недостатков,
в часности ето размер. При зараж-е через
дыры, чем меньше файл, тем быстрее он
перешлется, и тем менее будет заметно.
И при фийловом зараж-и - таже история,
чем меньше, тем лучшей.
> а на мой взгляд, удачным вирусом можно
> считать тот вирус который нанёс больше
> всего ущерба...
лично я против дсруктивных вирусов.
конешно если нужно комуто навредить...
но тут я бы предусмотрел меры, шоб
другие как можно меньше страдали
а пор "удачность вируса" - между прочим
мелкий размер - залог удачи, как краткость -
сестра таланта ;)
Я же за Си из за етого и взялся, вот и был
поражен, шо егоный хеловорд в 15 раз больше,
чем от MSVB6 (там 24Кб). Ну щас то я въезжаю,
надеюсь шо добьюсь своего - изучу
Си досканально :)
Благодарствую за активность форума!
даа, куда-то тему понесло...
нет.
высокоуровневый/низкоуровневый обычно имеют ввиду отвязку от аппаратной части, асм это уровень низкий, зависимость от аппаратуры 100% ная, Smalltalk, Perl, VisualBasic, Java и т.п. уровень высокий, (отвязка от процессора, событийная/объектная ориентированность)
Язык Си это язык алгоритмический, как скажем то-же паскаль, НО этот язык придназначался для написания операционных систем, тут мы видим, побитовые операции, сдвиги, прямое управление памятью, зависимость от платформы велика (например, sizeof() типов неопределён, в стандарте определена тока относительная зависимость),расположение у вамяти данных в структурах строго определено, (чего нельзя сказать о паскале и васике) хотя программу портировать легче чем на асме. Поэтому принято язык Си считать языком среднего уровня.
Ну в какой то степени я был прав
Я сразу заметил, шо в Си команды оч приближены к ЦП, но ведь можно в какой то степени "отвязаться" от ЦП, юзая подготовленные
ф-ции. Как я понял, можно вобще наклепать подгр файлик, с командами, скажем, как на бесике, и топтать с довольной рожой :) практически бесиковскими командами, но ето опять почти маразм - теряются преимущества Си. Но результ - внешне программируешь как на высоком уровне, а событийно-объектная ориентированность ето проблены системы, ее дело - обслужить, а мы, потипу пишем как на высоком уровне, токо в любой момент юзаем асм, привязываясь к ПЦ. Разве не так?
Лично у меня MSVC++ v6.0 Console Application
встроеный Нелловорд, Debug, весит почти
ровно пол мега
я же говорю что ВЫХОДНЫМ продуктом является Release версия, смотри её размер, также выиграть в размере ты можень используя Runtime-Library в DLL варианте, правда такая прога не везде пойдёт, а тока там где такая DLL есть (это типа как VBXyyy.DLL для VB)
Поставив VB я, спустя месяц
ужо в совершенстве въехал в об-ориент
программиров-е
ну для этого он и сделан чтобы голову не забивать
Вот кстати, может подкинете какой учебник
крутой? Я читаю англ "C++ WroxTutorial"
но там маловато, я привык получать много
подробной инфы. И там нет справочников,
токо учебник.
ИМХО, самым лучшим учебником станет код написанный проффесиональным программером, а всеобъемлющий справочник это MSDN.
А можно ли отключать оптимизацию?
Чтобы получить чисто перекодированную
в машин код прогу. Ето конешно маразм,
но для изучения дизасм-ного дампа удобнее,
а то на первых парах я постараюсь быть привязан
к чистому асму, получаемому при компиле.
Хотя всю жись я не собираюсь под винду шлепать.
У меня кое-чо задумано :)
оптимизацию отключить можно, например в дебажной версии она отключена, ты можешь сам создать кончигурацию, в которой отрубишь и оптимизацию и отладочную информацию. Но этого делать не рекомендую, т.к. оптимизация даёт довольно осщутимый прирост производительности (который зависит от конкретного случая), да и LST изучать такие нет смысла, т.к. они тебе ничего не дадут, ведь в реальной проге будет всё не так :)
просто знай, что без оптимизации получаем прямой перевод:
допустим код:
int _cdecl sum(int a, int b)
{
return x+b
}
....
int a = sum(1,2);
компилятор это озвучит примерно так:
sum proc near
push ebp
mov ebp,esp
mov eax,dword ptr 8[ebp]
add eax,dword ptr 12[ebp] ; результат в eax по соглащению _cdecl
pop ebp
ret 0
sum endp
...
push 2
push 1
call sum
add esp,8 ; освобождаем стэк т.к. вызов cdecl
ну может не совсем так, в дебажной версии он ещё добывит проверку переполнения стэка, повреждения переменных и прочий кал, но код будет прямым, а вот в релизе, со включённой оптимизацией, он просто нагло подставит sum и вычислит константы и выдет что-то типа:
mov eax,3
что естественно съекономит кучу процессорного времени, может и выкинет вызов вообще если его результат не используется :), а если результат передаёться параметром в другую ф-цию, он схитрит ещё больше:
int a = sum(1,2);
printf ("%d", a);
или
printf ("%d", sum(1,2));
генерит одинаковый код:
fmt db '%d', 00h
..
push 3
push offset fmt
call _printf
поэтому используй оптимизатор и забей на генерируемый код, кастати оптимизатор бывает ошибается и генерит код с ошибками, но это случается довольно редко :)
вапще оптимизатор Microsoft штука клёвая.
MSVC++ или IBC++??
Второй кстати занимает вроде пол гига в то время как мой ВБ6 всего 50М (без msdn)...
Я как раз все почистил, налысо поставил WinMe, и незнаю че ставить MSC или BC?
В конце концов, чем же лучшей кодить?
MSVC++ или IBC++??
Второй кстати занимает вроде пол гига в то время как мой ВБ6 всего 50М (без msdn)...
Я как раз все почистил, налысо поставил WinMe, и незнаю че ставить MSC или BC?
Ставь MSVCPP 6.0 или если мощная машина MSVS .NET (правда он потормознее и поглючнее шестой версии и MSDN там неудобный, но .NET содержит ряд интересных фич, новый MFC, и свежий MSDN), а про борланд забудь, они неудачники. :)
MSDN тебе нужен будет всеравно.
Ставь MSVCPP 6.0 или если мощная машина MSVS .NET (правда он потормознее и поглючнее шестой версии и MSDN там неудобный, но .NET содержит ряд интересных фич, новый MFC, и свежий MSDN), а про борланд забудь, они неудачники. :)
MSDN тебе нужен будет всеравно.
А компиляция так тормозит из за оптимизации?
На VB у меня все буквально сразу после нажатия запускается...
Кстать у меня на диске нет MSDN. Он большой? Может качнуть можно? Если да, то где?
А кстати сколько быдет весить весь MSVC++ после установки?
и еще:
Он в папку проектов кидает кучу больших файлов, штук 5 пробных хеловордов у меня на 13 метров вышли. Весь мой многолетний архив на Бесике при хорошей паковке занимает меньше 5М (почти без ресурсов, токо исходники). С етим можно че-нить поделать?
А компиляция так тормозит из за оптимизации?
На VB у меня все буквально сразу после нажатия запускается...
там как-таковой компиляции не происходило
Кстать у меня на диске нет MSDN. Он большой? Может качнуть можно? Если да, то где?
он ОГРОМНЫЙ, на April 2001 на трёх CD, мой Visual Studio .NET Enterprise Architect весит 5 дисков
А кстати сколько быдет весить весь MSVC++ после установки?
смотря что ставишь, у меня стоит на работе по-моему не всё: MSDN + C++, а VisualBasic'а и C# нету, весит 1.4 Gb
Он в папку проектов кидает кучу больших файлов, штук 5 пробных хеловордов у меня на 13 метров вышли. Весь мой многолетний архив на Бесике при хорошей паковке занимает меньше 5М (почти без ресурсов, токо исходники). С етим можно че-нить поделать?
Это нормально когда проект в двадцать строк весит несколько мегабайт, удаляй папки Debug И Release перед архивацией, в них объёктные файлы, прекомпилированные заголовки (в MFC такой заголовок может быть с десяток мегов), остальное нужно. (вместо ручного удаления папок можешь использовать команду Clean из Среды разработки, как будет удобнее)
Ставь MSVCPP 6.0 или если мощная машина MSVS .NET (правда он потормознее и поглючнее шестой версии и MSDN там неудобный, но .NET содержит ряд интересных фич, новый MFC, и свежий MSDN), а про борланд забудь, они неудачники. :)
MSDN тебе нужен будет всеравно.
Советую отказаться от MFC насовсем и полностью, а юзать WTL.
Кстати, удобство или неудобство MSDN в версиях это сугубо субъективно, мне например нравиться новый MSDN, тем более, что там уже и дока из DDK есть.
Советую отказаться от MFC насовсем и полностью, а юзать WTL.
что это такое? ужё второй раз вижу... :)
Кстати, удобство или неудобство MSDN в версиях это сугубо субъективно, мне например нравиться новый MSDN, тем более, что там уже и дока из DDK есть.
дык мне тоже нравиться его полнота, не не нравиться его эргономика, он неудобен :
MSND Library->User Interface Design and Development->Windows user Interface->SDK Documentation->Windows user Interface->Windowing->Windowing - это не бред это типичный путь в MSDN от VS .NET, а также есть в индексе ссылки на несуществующие страницы, хотя у меня стоит всё.
что это такое? ужё второй раз вижу... :)
http://www.rsdn.ru/article/default.asp?wtl/wtl-1.xml
http://www.rsdn.ru/article/default.asp?wtl/wtl-2.xml
>> На VB у меня все буквально сразу после нажатия >> запускается...
>там как-таковой компиляции не происходило
А все же если отключить оптимизацию, он будет быстро компилировать?
> Это нормально когда проект в двадцать строк
> весит несколько мегабайт,
Блин дык там вроде половина файлов (подгружаемых) одинаковая, мож где в опциях мона пути указать?? шоб он их каждый раз не копировал..
Ну иль хыть автоочистку..
Всеже ети файлы генерируются, зн он их может создавать токо на время работы с проектом..
> Ето нормально..
Да уж, может для MSVC и нормально, но ведь ето же лажа - главное сам проект, остальное же всегда можно подгрузить или сгенерировать/скомпилировать
А IBC такие же толстые проекты пишет??
А все же если отключить оптимизацию, он будет быстро компилировать?
она и так отключена в Debug версии, основной тормоз, это то что у Windows ОЧЕНЬ большие заголовки, и чтобы ускорить компиляцию, надо не в каждом файле писать двадцать #inlcude а перечислить их в отдельном файле (stdafx.h - по умолчанию) и везде подключать его, первым делом при компиляции копилир строит прекомпилиные заголовки (компилит stdafx.cpp, в *.pch) (это прописано в настройках, из какого файла их строить), компиляция заголовков занимает время, а потом он побыстрому компиляет отстальные файлы, и далее при следующей перекомпиляции он компилит не всё, а только тот файл который был отредактирован, да и ещё он использует incremental linking для ускорения компоновки, главное уменьшай зависимотсти модулей друг от друга, а то если завести один global.h и всё пихать в него а патом его подключать везде, это спровоцируюет перекомпиляцию всех файлов после модификации этого global.h. В общем планируй проект правильно и будет компилить быстро. Как раз проекты такие большие из-за того что эти "ненужные файлы" ускоряют компиляцию.
Блин дык там вроде половина файлов (подгружаемых) одинаковая, мож где в опциях мона пути указать?? шоб он их каждый раз не копировал..
я никада не пытался это сделать, мож кто и извращался но я не знаю, вапще глянь настройки проекта, но я думаю врятли.
Ну иль хыть автоочистку..
Всеже ети файлы генерируются, зн он их может создавать токо на время работы с проектом..
сделай Clean, но после первой-же компиляции он х опять создаст, да и она будет долгой.
Да уж, может для MSVC и нормально, но ведь ето же лажа - главное сам проект, остальное же всегда можно подгрузить или сгенерировать/скомпилировать
Если проект в разработке, можно пожертвовать лишний десяток мегов, но зато компилять быстро, чем ждать по пол-часа когда всё скомпилится.
А если ты его отправляешь на консервацию или собрался куда-то перенести то удали папки Release и Debug
А IBC такие же толстые проекты пишет??
незнаю, скорее всего, либо долго компиляет.
Во-вторых, где ты видел полноценные, серьезные программы на VB и Делфи? Конкретные примеры?
что касаемо VB и Delphi я их обычно не юзаю (Pascal(и Delphi) я вапще никада не разбирал :), ну не точно бы совсем...но...), проги написанные на них обычно смотряться жалко, но тут дело не в самих средах разработки, а в компетентности программистов, т.к. обычно это люди начинающие или средней руки студенты-программисты.
Эх, зря вы так. Я просто уверен что половина из вас юзает Windows Commander (теперь Total Commander). Ну не виндозовский же эксплорер в самом деле :) Ну может кто еще юзает NC или FAR. Так вот, представьте себе, что этот самый коммандер написан на.. Delphi! Может кто то хочет сказать что это кривая и не оптимизированная прога? Более того, автор сам переписал некоторые С-библиотеки на паскаль, чтобы использовать их в WinCmd. Все зависит только от человека, а не от языка.
P.S. Че то стало мне интересно, и я скомпилил Hello world :) Так вот, при использовании такого кода:
#include <stdio.h>
int main(){
printf("Hello, world!\n");
return 0;}
exe весит <30kb, а если ктото решит что я схитрил и воспользовался функцией С :)
#include <iostream>
int main() {
std::cout<<"Hello, world!\n";
return 0;
}
Такая прога весит в exe 53+ kb. Так что нечего рассказывать про пол-мега. (компилил я конечно в Release).
Удачи!
> Так что нечего рассказывать про
> пол-мега. (компилил я конечно в Release).
А я то имел ввиду Debug, ну да ладно все, я уже понял, кажеться вопрос исчерпан :)
Всем спасибо за участие! :)
Эх, зря вы так. Я просто уверен что половина из вас юзает Windows Commander (теперь Total Commander). Ну не виндозовский же эксплорер в самом деле :)
нет я не юзаю Windows Commander, правда пробовал когда-то давно, и скорее всего сейчас это другая программа, но когда я её установил это был клон NC, но в Windows окошке, не консольным и именно GUI приложением использующим Windows-контролсы, и нортоновские цвета. В плане удобства(горячие клавиши, командная строка) он проигрывал NC, правда последний "не понимал" длинных имён файлов. Я думал даже сам написать консольный NC, но вот я нарыл FAR и он подошёл мне на 100% :)
Так вот, представьте себе, что этот самый коммандер написан на.. Delphi! Может кто то хочет сказать что это кривая и не оптимизированная прога?
да я никада не отрицал наличия прекрасных программ на любых языках программирования, главное в проге, не её язык, а её работа, то как она выполняет свои функии.
Я говорил только, то что зачастую начинающие используют именно VB/Delphi и их креатиф ужасен. Начиная от юзабилити и дизайна (видимо они не читали Design Guidelines от MS :)), заканчивая и их работой. Delphi подливает масла в огонь давая простые маханизмы извращения Windows интерфейса (уродливые иконки на кнопках, страшные картинки бэкграундом MDI, и resizable - диалоги тока начинают список ужасов :)). :) Почему-то у некоторых получается отходить от стандартного GUI но тем не менее вписаться в общий вид системы (MS Office, MS Visual Studio, MS Money, OutPost, Personal Cash) нововведения интерфейса (и главное юзабилити) в некоторых этих программах потом становился стандартом.
Более того, автор сам переписал некоторые С-библиотеки на паскаль, чтобы использовать их в WinCmd. Все зависит только от человека, а не от языка.
Я же сказал что большинство программ на VB/Delphi ужасны, и не из-за "ущербности" языков, а самих программистов.
> но вот я нарыл FAR и он подошёл мне на 100% :)
Лично я гарантирую, шо WC подойдет на 200%, и многие меня поддержут.
Я давно невидел фар, но наскоко помню главное отличие - в прозрачном отношении к архивам и ФТП + раскраска файлов (а, ну ето и в фаре есть)
ктомуже многие несоветуют из под винды юзать досовские шелы, тк они порой некорректно работают с фс32.. (хотя я етого не замечал, развешто был глюк с именами из под SafeMode) но после WC4.51 я фар закинул (правда уже еще новее есть, но я пока не рвусь, вдруг там дыры найдут :)
и поиск там офигенный, и везде где задается маска файлов (поиск, раскраска, фильтр) всегда можно намекнуть про атрибуты, граници размера, времени..
такшо WC Forever!
> нет я не юзаю Windows Commander
> но вот я нарыл FAR и он подошёл мне на 100% :)
Лично я гарантирую, шо WC подойдет на 200%, и многие меня поддержут.
Я давно невидел фар, но наскоко помню главное отличие - в прозрачном отношении к архивам и ФТП + раскраска файлов (а, ну ето и в фаре есть)
ктомуже многие несоветуют из под винды юзать досовские шелы, тк они порой некорректно работают с фс32.. (хотя я етого не замечал, развешто был глюк с именами из под SafeMode) но после WC4.51 я фар закинул (правда уже еще новее есть, но я пока не рвусь, вдруг там дыры найдут :)
и поиск там офигенный, и везде где задается маска файлов (поиск, раскраска, фильтр) всегда можно намекнуть про атрибуты, граници размера, времени..
такшо WC Forever!
А как в WC работать с командной строкой и с прогами, которые делают вывод в стандартный поток, например, nmake, cl, link, build и т.п. ?
А как в WC работать с командной строкой и с прогами, которые делают вывод в стандартный поток, например, nmake, cl, link, build и т.п. ?
configuration\layout\showcommandline
там даже перенаправление ввода вывода работает
(ну там и руский можно поставить, просто мне так больше нрав-ся :)
28 ответов - просто пугает
По-моему всё перемяли - от Debug/Release
вплоть до Far/WC/NC !
Круто!
P.S.: мне FAR всегда больше нравится!
Ностальгия по древним временам ,когда
юзал 386dx и был у меня NC!Хотя WC
ничуть FAR не уступает!
-------------------------------------
"Не бейте меня , только не бейте!
Я вам вот что скажу! Эти 'чёрные' твари
собираются взорвать всю базу! Их надо
остановить! ... Я подожду здесь!"
OpFor
configuration\layout\showcommandline
там даже перенаправление ввода вывода работает
(ну там и руский можно поставить, просто мне так больше нрав-ся :)
Одно дело - командная строка (типа EDIT), а другое дело - обычная консоль.
Если расскажете, как мне в WC пользоваться обычными утилитами командной строки, компиляторами и т.п. (cl, build, nmake и т.д.), отрекусь от FAR :D
Одно дело - командная строка (типа EDIT), а другое дело - обычная консоль.
Если расскажете, как мне в WC пользоваться обычными утилитами командной строки, компиляторами и т.п. (cl, build, nmake и т.д.), отрекусь от FAR :D
четыре клавиши: c m d <enter> :D :D :D
четыре клавиши: c m d <enter> :D :D :D
Значит преимуществ у WC нет.
FAR форева!:D
Значит преимуществ у WC нет.
FAR форева!:D
видима так!
я тожа за FAR Manager :)
видима так!
я тожа за FAR Manager :)
Но ето просто вам возможно он удобней, тк вам нужен именно консоль, шо торчит из-за панелей. Просто выше перечисленные Игорем проги, еще не загнаны в вин32 (да и нужно ли) поетому тут неспорю, фар окажется умеснее, но на данный момент, мало кто пользуется этими утилитами, вручную подставляя параметры.. А ВЦ просто отдалился от консоля (может ето и к лучшему, типа, давно пора.. :)
но всеже преимуществ у него воз! :)
фар, конешно неплох, но не форева!
а коли мне приспичит подебажить *.баты (ну иль прога закрывает окно, непоказав че начириркала в консоле), дык я сразу за НЦ :)