Аннотация:
Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.
Без указания версий компиляторов, а также без четкого указания с какими настройками запускались компиляторы, оценка оптимизации превращается в профанацию.
Re: Альтернативные средства разработки под Windows
Здравствуйте, Петр Каньковски, Вы писали:
ПК>Статья:
ПК>Авторы: ПК> Петр Каньковски
ПК>Аннотация: ПК>Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.
Не могу прочитать статью по заявленой ссылке.
Re[2]: Альтернативные средства разработки под Windows
Она пока только в бумажном виде (в журнале RSDN Magazine, 2003, #5)
Re[2]: Версии и настройки компиляторов
От:
Аноним
Дата:
18.02.04 15:30
Оценка:
Уважаемому DarkGray:
>Без указания версий компиляторов, а также без четкого указания >с какими настройками запускались компиляторы, оценка оптимизации >превращается в профанацию.
VC 6.0. В свойствах файлов Cl*.* указана версия 12.00.8168.0.
Intel Compiler 4.1.1.0
gcc version 3.2 (mingw special 20020817-1)
lcc-win32 version 3.8.
Borland C++ 5.5.1 for Win32
D Compiler Beta v0.63
Free Pascal Compiler version 1.0.10 [2003/06/27] for i386
Настройки или ключи командой строки: -O3 для gcc, -O2 для BCC
(хотя особой разницы между -O1 и -O2 я не обнаружил). Когда
проверял регистровую оптимизацию в BCC, пытался указать ему
опцию -r -- не помогло, оптимизировал именно так отвратительно,
как это описано в статье.
Ключи для Free Pascal: -OG -Or. В LCC и D Compiler есть только
одна опция: либо "оптимизировать", либо "не оптимизировать".
Естественно, я выбирал "оптимизировать"
Для компиляторов Microsoft и Intel тесты повторялись в режимах
с оптимизацией по скорости и по размеру. Если результаты в этих
режимах различаются, то об этом упомянуто в тексте статьи.
>Такую оптимизацию делать нельзя, потому что значение >в стеке может быть изменено самой функцией.
А компилятор может определить, было ли оно изменено,
или хотя бы, является ли оно константным или содержит
переменные.
В том примере, который я привожу в статье, s — это
константное выражение (адрес строки в памяти, который
остается неизменным во время выполнения программы).
>меняем переданный параметр
Извините, пожалуйста, но это неверно. В данном коде
Вы передаете указатель p по значению, а затем модифицируете
этот указатель внутри функции. В основной программе
указатель q не меняется и не может меняться, поскольку
это совсем другой указатель на строку из 5 символов
в памяти, которую Вы неявно создаете конструкцией:
char *q = "abcd";
Прогоните этот пример под отладчиком и убедитесь сами.
Вообще, проверяйте примеры, прежде чем отправить их
на форум или описать в своей статье. Со мною тоже такое
бывало: пишу вроде бы очевидный пример, а потом
оказывается, что он не работает.
Вот если бы Вы передавали этот параметр по ссылке, то
есть передавали указатель на указатель p, то сам указатель p
изменился бы. Понятно?
Ну хорошо, вот у нас функция, в которую передается параметр.
Как это выглядит на уровне ассемблера? Сначала вызывающая
функция загоняет в стек параметры, затем делает CALL
на код вызываемой функции. Та, в свою очередь, читает
эти параметры из стека. Она может изменять их как угодно.
Но когда выполнение функции закончится, параметры функции
и локальные переменные будут удалены из стека. В вызывающую
функцию они никак не попадут.
А когда нужно передать параметр по ссылке, в стек помещают
указатель на ячейку памяти, которая хранит значение параметра.
Функция читает и/или изменяет содержимое этой ячейки. Когда
ее выполнение закончится, значение сохранится в данной ячейке
памяти (здесь неважно, является ли эта ячейка глобальной
переменной или локальной переменной вызывающей функции).
Всего наилучшего, будьте здоровы и пишите еще.
Петр.
>>Такую оптимизацию делать нельзя, потому что значение >>в стеке может быть изменено самой функцией. А>А компилятор может определить, было ли оно изменено, А>или хотя бы, является ли оно константным или содержит А>переменные. А>В том примере, который я привожу в статье, s — это А>константное выражение (адрес строки в памяти, который А>остается неизменным во время выполнения программы).
Неважно, константное выражение или неконстантное.
Все равно, вызываемая функция может изменить значения передаваемых параметров в стеке.
А>Вот если бы Вы передавали этот параметр по ссылке, то А>есть передавали указатель на указатель p, то сам указатель p А>изменился бы. Понятно?
Причем тут это? Я говорю, что значение в стеке будет изменено после вызова функции, и поэтому его нельзя использовать повторно.
А>Ну хорошо, вот у нас функция, в которую передается параметр. А>Как это выглядит на уровне ассемблера? Сначала вызывающая А>функция загоняет в стек параметры, затем делает CALL А>на код вызываемой функции. Та, в свою очередь, читает А>эти параметры из стека. Она может изменять их как угодно. А>Но когда выполнение функции закончится, параметры функции А>и локальные переменные будут удалены из стека. В вызывающую А>функцию они никак не попадут.
Кем они будут удалены?
Ты же сам говоришь, что компилятор не должен чистить переданные параметры, а должен их использовать повторно.
Замечу, что строго говоря p не является локальной переменной функции func, поэтому после выхода из func значение (в том числе и измененное) p не будет удалено из стека самой функцией func.
Вот смотри:
push q
//на стеке лежит значение переменной q
call func
//переменная p маппится на стек (причем на то место, где лежит за-push-енное значение переменной q)
p = strchr(p, 'a');
//значения переменной q в стеке теперь нет, на том месте лежит новое значение переменной preturn//если мы сейчас сразу вызывем func, То func полученное испорченное значение.
Re[4]: Версии и настройки компиляторов
От:
Аноним
Дата:
19.02.04 12:01
Оценка:
Привет, DarkGray!
Дружок, прогони эту программу на своем любимом
компиляторе, а потом побеседуем:
А то сдается мне, что говорим мы о разных вещах.
>строго говоря p не является локальной переменной функции func
Правильно, p — это параметр функции func.
>Неважно, константное выражение или неконстантное.
Если оно константное, функция не сможет его изменить. Сам
язык Си не позволит. Попробуй откомпилировать такой пример:
char s[] = "abcd";
s = '2';
s = "23";
Ты получишь ошибку. О каком изменении строки s здесь может
идти речь?
>Я говорю, что значение в стеке будет изменено после вызова >функции, и поэтому его нельзя использовать повторно.
Значение чего? Указателя или переменной, на которую
указывает указатель?
Значение где? В твоем примере есть указатель q — локальная
переменная функции main(). И есть указатель p — формальный
параметр функции func(). Это не одно и то же, и находятся
эти два *разных* указателя в разных частях стека.
Посмотри на ассемблерный код, который выдает VC++
для примера выше:
func PROC NEAR
;p = strchr(p, 'b');
mov eax, DWORD PTR _p$[esp-4] ; Формальный параметр p помещаем в eax
push'b' ; Передаем функции strchr параметр 'b'push eax ; Передаем функции strchr параметр p
call _strchr
add esp, 8 ; Очищаем стек при возврате из процедуры
ret 0
func ENDP
_main PROC NEAR
;func(q);
push'b'push offset abcd
call _strchr
;func(q);
push'b'push offset abcd
call _strchr
ret 0
_main ENDP
Еще раз проверь свои предположения с компилятором в руках.
И если остались еще вопросы, пиши.
Данной программе соответствует, следующий ассемблерный листинг:
//func
push esi
mov esi,dword ptr [esp+8]
push esi
push offset string "1 - %s\n" (4120D4h)
call printf (401070h)
inc esi
push esi
push offset string "2 - %s\n" (4120C8h)
mov dword ptr [esp+18h],esi
call printf (401070h)
lea eax,[esp+18h]
push eax
call dummy (40100Fh)
add esp,14h
pop esi
ret
//main
push offset string "abcdef" (4120E0h)
call func (40100Ah)
push offset string "abcdef" (4120E0h)
call func (40100Ah)
add esp,8
Вспоминаем твою цитату из статьи:
ПК> Ни один компилятор не смог "догадаться", что после вызова strchr адрес строки s все еще находится в стеке, и не нужно заталкивать его еще раз
На основе этой цитаты, я делаю вывод, что ты считаешь, что, например, для данной задачи
в функции main можно убрать второй push offset "abcdef", а add esp, 8 заменить на add esp, 4.
Ну вот, теперь проблема понятна, примеры работают
(то есть наоборот, не работают, вызывают ошибку).
За фамильярность прошу прощения.
Решения могут быть следующими:
1) Определять, меняла ли функция входные параметры
(были ли в ее теле операторы p++, p-=2 или p=что-то-там).
Далеко не все функции это делают. Библиотечные
strchr, printf, о которых шла речь в статье,
этим делом не занимаются (я проверил, прогнав через
ассемблер листинг, в котором убрал лишний push).
Можно хранить в объектном файле с каждой функцией
флаг, показывающей, модифицирует ли она параметры.
Это очевидное, оптимальное и работоспособное решение.
Можно (хотя это плохое решение) ввести флаг типа "assume
no aliasing" (в VC++ программист должен сбросить
этот флаг, если он обращается к одной и той же
переменной и через указатель, и через имя переменной;
почти никто так не делает, поэтому этот флаг установлен,
и его установка помогает улучшить оптимизацию).
2) Проводить регистровую оптимизацию. Это не гарантирует
правильного выполнения программы, однако же хороший
компилятор будет переносить значение p из стека в регистр,
увеличивать его, но потом не возвращать в стек (зачем оно
там нужно после выполнения функции, когда стек уже будут
очищать?). Хотя здесь обнаруживается другое обстоятельство:
вызываемая функция printf может менять регистры, поэтому
параметр p придется записывать в стек. То есть если мы напишем
inc ebx ; Увеличить p
call printf
и дальше попытаемся использовать ebx, то в нем окажется
все что угодно, но не (p+1). Важное замечание: это не относится
к регистру esi, который (по крайней мере в VC++) принято
сохранять между вызовами процедур.
В твоем примере кроме того нужно находить адрес &(p+1),
для чего (p+1) нужно так или иначе записывать в память.
3) Здесь напрашивается третье решение. Мы практически ничего
не потеряем (ни скорости выполнения, ни размера программы),
если введем дополнительную локальную переменную:
//func
push esi
mov esi,dword ptr [esp+8]
push esi
push offset string "1 - %s\n" (4120D4h)
call printf (401070h)
mov eax, esi ; Вставляем всего одну инструкцию
inc eax
push eax
push offset string "2 - %s\n" (4120C8h)
mov dword ptr [esp+18h],eax
call printf (401070h)
lea eax,[esp+18h]
push eax
call dummy (40100Fh)
add esp,14h
pop esi
ret
Тогда в случае функции, меняющей свои входные параметры,
компилятор должен генерировать код с дополнительной локальной
переменной.
Суть твоего примера в том, что нам так или иначе нужна
дополнительная ячейка (локальная переменная или параметр)
в стеке. Нам приходится копировать переменную, так как
она изменяется (p++), а нам нужно получить ее исходное
значение.
Хотя в твоем примере есть другое решение. Сравни этот
код со своим:
//func
push esi
mov esi,dword ptr [esp+8]
push esi
push offset string "1 - %s\n" (4120D4h)
call printf (401070h)
inc esi
push esi ; Занесли в стек увеличенный p
push offset string "2 - %s\n" (4120C8h)
call printf (401070h)
;Теперь (p+1) уже лежит в стеке, зачем же заносить
;его туда снова? Просто находим &(p+1) и вызываем
;функцию:
lea eax, [esp+4] ; eax = то значение (p+1), которое мы передавали в printf
push eax
call dummy (40100Fh)
add esp,14h
pop esi
ret
и все будет работать нормально. Этот код я считаю почти лучшим
возможным для данного примера. Но компиляторы нескоро додумаются
до такого. Человек-ассемблерщик, конечно, всегда может дать лучший
код с нестандартными трюками. А для компилятора это слишком сложно:
определять, что находится в стеке, как он изменяется при выполнении
той или иной команды, где сохраняется увеличенное значение.
Кстати, насчет лучшего возможного кода. Знаешь, что выдал VC++
в режиме "Inline — Any Suitable"? Ты будешь долго смеяться:
Кажется, это радикальное решение проблемы: взять и заинлайнить все
функции .
Спасибо. Теперь когда до меня (старого тупого хама) наконец-то
дошло, о чем ты хотел сказать, я признаю, что это очень важное
замечание к статье. Спасибо еще раз.
Удачи!
Петр Каньковски.
Re[6]: Версии и настройки компиляторов
От:
Аноним
Дата:
20.02.04 06:31
Оценка:
Привет, DarkGray!
Дураков нам не надо, мы сами – дураки. Да, и хамство по отношению к читателю — страшнейший грех. Нам хамов не надо — мы сами и хамы тоже.
(Из внутренних документов журнала "Хакер";
насчет фамильярности)
Обнаружил ошибку в своем листинге под номером 3:
push esi
mov esi,dword ptr [esp+8]
push esi
push offset string "1 - %s\n" (4120D4h)
call printf (401070h)
mov eax, esi ; Вставляем всего одну инструкцию
inc eax
push eax
push offset string "2 - %s\n" (4120C8h)
mov dword ptr [esp+18h],eax
call printf (401070h)
lea eax,[esp+18h]
push eax
call dummy (40100Fh)
mov dword ptr [esp+2Bh],esi ; Нужно вставить еще одну инструкцию
add esp,14h
pop esi
ret
Всего доброго!
Петр.
Re[6]: Версии и настройки компиляторов
От:
Аноним
Дата:
20.02.04 07:55
Оценка:
Привет, DarkGray!
Вот уж воистинну, "Нам дураков не надо, мы сами дураки".
Точнее, я дурак. Терпеть не могу, когда мне присылают
непроверенные, непонятно как работающие исходники и пытаются
на основании их доказать что-то. А теперь оказалось,
что и я сам страдаю тем же.
Короче, вот ссылка на полностью проверенные и работающие
исходники для MASM:
При дальнейших рассуждениях можешь опираться на них.
Хотя мне по-прежнему кажется, что самый
простой и эффективный способ решить
проблему -- это найти и пометить специальным
образом функции, меняющие свои входные параметры.
И не выполнять оптимизацию для таких функций.
Петр Каньковски.
Re[2]: Альтернативные средства разработки под Windows
> ПК>Статья: > > > ПК>Авторы: > ПК> Петр Каньковски > > ПК>Аннотация: > ПК>Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки. > Не могу прочитать статью по заявленой ссылке.
я её успешно просмотрел
Posted via RSDN NNTP Server 1.8
Re: Альтернативные средства разработки под Windows
Здравствуйте, Петр Каньковски, Вы писали:
ПК>Аннотация: ПК>Бесплатные средства разработки, основанные на <..skipped..> Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.
а не было желания рассмотреть такую штуку, как Virtual Pascal (http://vpascal.com) с точки зрения оптимизации? помнится, писал как-то на нём (когда ещё на паскале сидел) — приятная штука была в смысле юзабельности и код он генерировал вроде ничего — поменьше Borland Pascal'ного точно...
Re: Альтернативные средства разработки под Windows
А можно спросить, почему функции стандартной библиотеки в DLL работают медленнее, чем статически подлинкованные? Я был уверен, что после загрузки DLL на старте, её функции неотличимы от тех, что определены в самом EXE файле
Евгений Коробко
Re[2]: Альтернативные средства разработки под Windows
Здравствуйте, Евгений Коробко, Вы писали:
ЕК>А можно спросить, почему функции стандартной библиотеки в DLL работают медленнее, чем статически подлинкованные? Я был уверен, что после загрузки DLL на старте, её функции неотличимы от тех, что определены в самом EXE файле
При использовании функции из dll — используется косвенный вызов, при использовании из либы — делается прямой вызов.
Re[2]: Альтернативные средства разработки под Windows
Довольно познавательная статья, не будешь же все время бороздить инет в поисках новых решений
Пара дополнений по поводу FPC. Во-первых, ранние версии порождали до крайности нестабильный код. Фактически, нельзя было надеяться, что компиляция будет проведена правильно. Впрочем, все багрепорты желающие могут сами увидеть на официальном сайте.
В целом, однако, компилятор мне нравится больше Delphi. Помнится, последние версии даже компилировали нормально код, на котором Delphi обломала зубы. Одно из мелких нововведений, отсутствие которых меня сильно бесило в Delphi — статические члены классов (вводятся ключевым словом static).
Насчет оптимизации по правилу 1-1-4 нельзя не заметить, что под P4 с его Trace Cache такая оптимизация способна замедлить выпонение кода, сам с таким сталкивался. Так что, если в качестве целевого процессора выставляли P4, возможно, компиляторы неспроста не занимались этим. Там другие правила оптимизации, с экономией на параллельном выполнении операций и т.п.. Было бы время, можно было бы посмотреть, насколько удачны эти решения в рассчете на P4.
С уважением,
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Re: Альтернативные средства разработки под Windows
Здравствуйте, Петр Каньковски, Вы писали:
[skip]
Что имелось ввиду под: Перегрузка арифметических операторов, операторов сравнения и присваивания."
в пункте относящемся к freepascal. Как это вообще выглядит на языке Pascal....если не сложно приведите небольшой пример класса....а то не нашел
P.S. Просто я последний раз кодировал на Object Pascal когда этого там не было
статья называется "средства разработки",
и именно это многим людям интересно.
т.е какие студии наиболее полезны,
какие компиляторы и как лучше стыкуются,
где взять отладчик,
взаимодейсвие с системой,
другие прикладные подробности.
А автор фанател по поводу оптимизций:
скорость нужна там где она нужна,
а сейчас нужна хорошая структуризация и архитектра,
а процессоры стали так быстры что это проблема почти полностью не актуальна.
Надо бы отделььныую статью про ассемблер, кому это важно.
Так как не нашел что было по названию интересно,
и прикладных подрробностей,
(хотя было очень интересно),
в связи с ее важностью, (обычно в мессагах можно было бы сказать что отлично, а тут статья)
я бы плохо оценил статью.
Прикладных аспектов (реально непосредственно полезных), маловато.
Наилучшие пожелания писать то что надо, а не другие развлечения.
Хе-е. Юмор.
Винтовку добудешь в бою!
Re: Альтернативные средства разработки под Windows
От:
Аноним
Дата:
04.08.04 23:27
Оценка:
Здравствуйте, Петр Каньковски, Вы писали:
ПК>Статья:
ПК>Авторы: ПК> Петр Каньковски
ПК>Аннотация: ПК>Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.
Интересная статья. Вот только утверждение: ПК>Вторая категория — устаревшие программы, которые раньше успешно продавались, а теперь фирмы-разработчики раздают их бесплатно (сюда относятся уже упомянутый Turbo Pascal, Watcom C++ и еще несколько компиляторов под DOS). Ни одного Windows-компилятора в этой категории вы не найдете.
Здравствуйте, <Аноним>, Вы писали:
А>Интересная статья. Вот только утверждение: ПК>>Вторая категория — устаревшие программы, которые раньше успешно продавались, а теперь фирмы-разработчики раздают их бесплатно (сюда относятся уже упомянутый Turbo Pascal, Watcom C++ и еще несколько компиляторов под DOS). Ни одного Windows-компилятора в этой категории вы не найдете.
А>- излишне категорично. А>http://www.openwatcom.com
К сожалению, даже последний Ваткомоский компилятор высоким соответствием нашей библии (Стандарту) похвалиться AFAIK не может — лучше уж MS C++ Toolkit 2003 "брать".
А А>VC 6.0. В свойствах файлов Cl*.* указана версия 12.00.8168.0. А>Intel Compiler 4.1.1.0 А>gcc version 3.2 (mingw special 20020817-1) А>lcc-win32 version 3.8. А>Borland C++ 5.5.1 for Win32 А>D Compiler Beta v0.63 А>Free Pascal Compiler version 1.0.10 [2003/06/27] for i386
а почему интел н присутствует в последней табличке?
---
С уважением,
Сергей Мухин
Re: Альтернативные средства разработки под Windows
ПК>Авторы: ПК> Петр Каньковски
ПК>Аннотация: ПК>Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.
тут кажется опечатка
В C/C++ (соглашение о вызовах _stdcall) принято проталкивать параметры в стек в обратном порядке и очищать стек в вызывающей функции. Если вызывается несколько функций подряд, стек между вызовами можно не очищать.
---
С уважением,
Сергей Мухин
Re[2]: Альтернативные средства разработки под Windows
От:
Аноним
Дата:
18.04.05 08:01
Оценка:
Здравствуйте, Сергей,
СМ>тут кажется опечатка СМ>
СМ>В C/C++ (соглашение о вызовах _stdcall) принято проталкивать параметры в стек в обратном порядке и очищать стек в вызывающей функции. Если вызывается несколько функций подряд, стек между вызовами можно не очищать.
А как должен выглядеть правильный вариант?
Петр.
Re[3]: Альтернативные средства разработки под Windows
СМ>>В C/C++ (соглашение о вызовах _stdcall) принято проталкивать параметры в стек в обратном порядке и очищать стек в вызывающей функции. Если вызывается несколько функций подряд, стек между вызовами можно не очищать.
с:
int __stdcall f1(int a,int b)
{
return a+b;
}
int __cdecl f2(int a,int b)
{
return a+b;
}
void t(void)
{
f1(1,2);
f2(1,2);
}
asm:
int __stdcall f1(int a,int b)
{
mov eax,dword ptr [esp+4] ; eax = a
add eax,dword ptr [esp+8] ; eax += b
retn 8 ; очистка стека в вызываемой подпрограмме
}
int __cdecl f2(int a,int b)
{
; return a+b;
mov eax,dword ptr [esp+4] ; eax = a
add eax,dword ptr [esp+8] ; eax += b
ret ; очистка стека в вызывающей подпрограмме
}
void t(void)
{
...
f1(1,2);
0042A03E push 2 ; параметры в "обратном" порядке
0042A040 push 1
0042A042 call f1 (42862Bh) ; f1 сама уберёт
f2(1,2);
0042A047 push 2 ; параметры в "обратном" порядке
0042A049 push 1
0042A04B call f2 (427E97h)
0042A050 add esp,8 ; чистка за f2
...
}
А>А как должен выглядеть правильный вариант?
В C/C++ (соглашение о вызовах _cdecl) принято проталкивать параметры в стек в обратном порядке и очищать стек в вызывающей функции.
Если вызывается несколько функций подряд, стек между вызовами можно не очищать.
Здесь много тонкостей. В стеке могут лежать аргументы для вызываемых функций, локальные переменные. Балланс нарушится.
Re[4]: Альтернативные средства разработки под Windows
От:
Аноним
Дата:
18.04.05 13:58
Оценка:
Здравствуйте, IceStudent,
В C/C++ (соглашение о вызовах _cdecl) принято проталкивать параметры в стек в обратном порядке и очищать стек в вызывающей функции.
да, Вы абсолютно правы: _cdecl, а не _stdcall. Извините, это опечатка. Соглашение о вызовах _stdcall используется при вызове процедур Win32 API, и оно не позволяет очищать стек сразу за несколько функций.
int __cdecl f2(int a,int b)
push 2
push 1
push 2
push 1
call f2
mov [somewhere], eax ; записали в глоб. переменную возвращенное значение
call f2
add esp,16 ; чистка за f2,f2
Именно это я и имел в виду, когда написал, что стек между вызовами можно не очищать. Есть и другой вариант:
push 2
push 1
call f2
mov [somewhere], eax ; использовали возвращенное функцией значение
push 2
push 1
call f2
add esp,16 ; чистка за f2,f2
Здесь много тонкостей. В стеке могут лежать аргументы для вызываемых функций, локальные переменные. Баланс нарушится.
Ну и что? Главное — после вызова всех функций окончательно очистить стек, и не вызвать его переполнения.
Петр.
Re[5]: Альтернативные средства разработки под Windows
Соглашение о вызовах _stdcall ... не позволяет очищать стек сразу за несколько функций.
Точнее, этого и не нужно
А>Ну и что? Главное — после вызова всех функций окончательно очистить стек, и не вызвать его переполнения.
... и не использовать его между вызовами.
... << RSDN@Home 1.1.4 beta 5 rev. 409>>
Re: Альтернативные средства разработки под Windows
Re: Альтернативные средства разработки под Windows
От:
Аноним
Дата:
16.12.08 15:19
Оценка:
Здравствуйте, Петр Каньковски, Вы писали:
ПК>[Кроме того, в бета-версии Dev-C++ мне не удалось отключить добавление отладочной информации (пришлось удалять ее с помощью шестнадцатеричного редактора).
так есть strip.exe в minGW ( откуда он у меня, minGW нет дистрибутива allinone )
а как cdeblocks.org vs dev++ ?
Re[2]: Альтернативные средства разработки под Windows
От:
Аноним
Дата:
17.12.08 01:56
Оценка:
А>а как cdeblocks.org vs dev++ ?
Codeblocks не пользовался, а впечатления от Dev++ отрицательные. Периодически вылетает с access violation, настройки компилятора устанавливает неправильно и т.п.