GCC Developers Summit

Ну и на голом C можно SIGSEGV перехватить.

Причем здесь компилятор?

>область действия переменной, объявленной в операторе цикла

Это они в семерке (.NET) пофиксили.

NikS.

/GX == /EHs + /EHc, если не ошибаюсь.

гы...я не вкурсе что такое /GX - просто когда я попытался собрать просто с /WX он выдал кучу ворнингов и предложил использовать /GX. маразм

>при обращении по адресу, не попадающему в выделенную процессу область.

Да согласен я с этим, согласен. Речь о другом. О "предпроверках". Повторяю: речь шла о проверке неинициализированных указателей, а не об адресной арифметике. А книжку почитайте про виртуальные машины. Есть ли в C# и Java проверка инициализации объекта? А адресная арифметика? Поинтересуюсь, что такое unsafe?

NikS.

PS. Ну "вылет" JVM под Linux в отличие от JVM Windows и JVM zOS сам лично видел. Заказчики реальные и не админом localhost'а я работаю. Так в чем же причина? В кривизне ОС? По AIX и Solaris тоже таких проблем нет.

>Причем здесь компилятор?

При том что и ОС работает либо криво, либо работает для mission-critical приложений. При том, что компилятор (хорошо, часть компилятора, отвечающая за лексический анализ) должен выявлять некоторые вещи на этапе компиляции (пресловутый /WX). При том, что язык программирования должен быть свободным от "побочных эффектов". Вывод - увидите как через код кое-кто начнет свою кампанию c F# - и пользователи будут это покупать. Еще как будут.

NikS.

>На main без return ICC должен ругаться. >Хотя, насчет ошибки от MS я и сам был неправ -- можно иметь main без >явного return, как можно иметь любую функцию без явного return. >Если в main нет return, то реализация должна обеспечить return 0. Боюсь ошибится, но по-моему в последнем варианте стандарте C++ это не допускается. По крайней мере в g++ v3.3 (pre из SuSE 8.2) void main() {...} и int main() {...} без return у меня не скомпилилось (ошибка со ссылкой на стандарт). Сейчас, к сожалению, проверить не могу.

>Повторяю: речь шла о проверке неинициализированных указателей

Гарантированная проверка невозможна. Вопрос закрыт.

>g++ v3.3

Да это так, я с Вами согласен, GCC 3.3 работает ближе к стандарту.
(В 2.96 это было не так)

Проверьте, пожалуйста, если у Вас компайлер g++3.3 под 
рукой, "блокирование" при _"синтаксическом разборе"_, скажем:

main()
{
    int *p;
    *p = 0;
}

Мелкософт это блокирует.


NikS.

>Боюсь ошибится, но по-моему в последнем варианте стандарте C++ это не допускается.

Я последнего варианта не видел. В ISO/IEC 14882:1998 это явно допускается.

>Вопрос закрыт.

Абсолютно! (Для любого unsafe кода.)

Заказчик очень не любит когда ему хотят сделать систему на С/C++. Пускай такие тормоза, как Жаба, но адресной арифметики заказчики боятся как черт ладана. Если у кого другой опыт общения с заказчиками, то интересно было бы выслушать.

NikS.

> main()
> {
> int *p;
> *p = 0;
> }
>
> Мелкософт это блокирует.

если cl начнет блокировать /* Bill Gates suxx */ то NikS будет считать это прописной истиной и эталоном.

> Заказчик очень не любит когда ему хотят сделать систему на С/C++. Пускай такие тормоза, как Жаба, но адресной арифметики заказчики боятся как черт ладана. Если у кого другой опыт общения с заказчиками, то интересно было бы выслушать.

Заказчики отлично пользуются C/C++ кодом если им покажут что есть 100% покрытие.

> если cl начнет блокировать /* Bill Gates suxx */ то NikS будет считать это прописной истиной и эталоном.

Не иронизируйте. Здесь свободный обмен идеями, а обмен двумя идеями удваивает опыт в отличиее от обмена двумя яблоками. До наших Юронимуса и Бурзума (Луговского и Рута) надеюсь дело не дойдет.-)

Все дело в том, что у конкурентов (M$) очень грамотно поставлен маркетинг. И надо грамотно ему отвечать. Когда на прошлой презентации в пятницу ибиэмовец (не буду называть фамилию) и выступающий "технический" бизнес-партнер несли явное фуфло про SOAP и WSDL, то это только дискредитировало идею Linux-серверов приложений.

NikS.

>если им покажут что есть 100% покрытие

(Сейчас уже могу говорить.) В пенсионном фонде РФ "покрытия" не получилось. Там технологии более надежных языков программирования. (Про текущих заказчиков промолчу, но интерес у них к Java, C# и ,традиционно "там", COBOL)

MS если вы сходите к ним на курсы, дают свой VC/MFC/ATL "делай раз, делай два, ни шага в сторону, (а вообще переходи на .NET)".

NikS.

НУ ты, NikS, и мудак

Такой топик испоганил своими детскими вопросами ....

>Такой топик испоганил своими детскими вопросами

А anonymous ни на один вопрос не ответил и лажанулся не по-детски с main(){} в VC++.

NikS.

>Там технологии более надежных языков программирования.

Начинается очередной религиозный флейм. Мля.

> В пенсионном фонде РФ "покрытия" не получилось.

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

> Там технологии более надежных языков программирования.

А за базар ответить? На C пишут уже лет 30, видимо специально выбрали язык поненадежнее и ипутся стока времени.

>main()
>{
> int *p;
> *p = 0;
>}

>Мелкософт это блокирует.

твою мать...
man gcc
/-Wuninitialized

в начале у тебя было int* p=NULL;
если подобное блокировать, то за компанию заблокируются скажем все программы реального режима, пишущие в таблицу прерываний.

может ты таки научишься отличать ошибки времени компиляции от ошибок времени выполнения?

Никс! Чем тратить время на тупняк в форум (да ещё и лажаясь на каждом шаге, плюс, правильно люди говорят, поганя тему, в которой ожидали найти что-то интересное) Так вот, лучше пойди в книжный и купи себе пару-тройку книжечек, по языку, архитектуре и по психологии что-нибудь

З.Ы. Если говорят тебе что ты долбаёб, не бычь сразу, посмотри сначала на себя со стороны

__erDiZz__

Насчет
main()
{
int *p;
*p = 0;
}

$ gcc -O3 -Wall test.c
test.c:2: warning: return type defaults to `int'
test.c: In function `main':
test.c:5: warning: control reaches end of non-void function
test.c:3: warning: `p' might be used uninitialized in this function
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i586-alt-linux/3.2.1/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,f77,objc,java --program-suffix=-3.2 --enable-objc-gc --with-system-zlib --without-included-gettext --host=i586-alt-linux --build=i586-alt-linux --target=i586-alt-linux
Thread model: posix
gcc version 3.2.1 (ALT Linux, build 3.2.1-alt2)

Аналогично с
#include <iostream>

typedef struct tagA
{
int x;
}
A;
void f(A *a) throw (A)
{
a->x = 1;
}

int main(int argc, char *argv[])
{
A *a;
f(a);
std::cout << a->x << std::endl;
return 0;
}

Ну а если ты инициализировал NULL'ом, то почему тебе компилятор должен препятствовать получить желаемый сигнал?

Кстати, такой вопрос насчет вышеупомянутого test.c
main()
{
int *p;
*p = 0;
}

$ gcc test.c; ./a.out
ошибок нет
$ gcc -O test.c; ./a.out
Segmentation fault

А на что указывают указатели по-умолчанию при отсутствии оптимизации?

>>Боюсь ошибится, но по-моему в последнем варианте стандарте C++ это не допускается.

>Я последнего варианта не видел. В ISO/IEC 14882:1998 это явно допускается.

Пардон, я несколько напутал.
Сейчас проверил в g++ v3.3 pre (SuSe 8.2)

int main(){} - все ок

void main(){}
error: 'main' must return 'int'

main(){}
warning: ISO C++ forbids declaration of 'main' with no type

Так что, вероятно, что-то в стандарте изменили ( void main() не был ранеьше запрещен).

>Так что, вероятно, что-то в стандарте изменили ( void main() не был ранеьше запрещен).

void main() явно запрещен даже в драфте от 1996 года. И в самом стандарте естественно.

AC:
>void main() явно запрещен даже в драфте от 1996 года. И в самом >стандарте естественно.
Не знал, спасибо за информацию. Буду изучать стандарт (ссылка уже пробегала)

NikS:-\ Лучше спроси надо-ли оно
кому, в том числе и себя самого. Ато нашел хрень, уцепился и
держишся как за нечто очень полезное. Такие ошибки в проход-другой
отсеиваются.

Да F# до окамла еще как... что, в прочем, его автор и не сильно отрицает -)

"Certain other operations are described in the International Standard as undefined (for example, the effect of dereferencing the null pointer). [Note: this International Standard imposes no requirements on the behavior of programs that contain undefined behavior.]"

International Standard ISO/IEC 14882, Programming Languages - C++ (page 5)

> International Standard ISO/IEC 14882, Programming Languages - C++ (page 5)

да, собственно, он слил намного раньше (: но в качестве последнего гвоздя в крышку его гроба смотрится отлично :-D

Никс отдыхай: -Werror Treat all warnings as errors не говоря уже что у gcc есть куча опций включающих дополнительные ворнинги типа -Wall -ansi -pedantic и тд и тп... Вообщем иди пиши на своем c# а в C/C++ не лезь - не для твоего это умишка :)

Какую нафиг статистику ? Иди собирай статистику падения своего масдая :)

2NikS: /EHs идет туда же куда и VC++ - в глубочайшую задницу !

>>Мелкософт это блокирует. main() { int *p; *p = 0; } спорим на ящик пива что и 2.95 на это ругнется ?!! :)

>>адресной арифметики заказчики боятся как черт ладана Хе-хе... Они боятся таких "специалистов" как ты :)

>>давайте перейдем на общий форум по программированию ты блин во второй класс для начала перейди !

2NikS: /EHs идет туда же куда и VC++ - в глубочайшую задницу !

>>Мелкософт это блокирует.
main()
{
int *p; *p = 0;
}
спорим на ящик пива что и 2.95 на это ругнется ?!! :)

>>адресной арифметики заказчики боятся как черт ладана
Хе-хе... Они боятся таких "специалистов" как ты :)

>>давайте перейдем на общий форум по программированию
ты блин во второй класс для начала перейди !

Хмм, ну если Вы, многоуважаемый Никс, так же сведущи в в С/C++ как и в истории норвежской блэк-металл сцены, то правы здешнее скопище ананимусов, нищадно посылающих Вас на хуй. Бурзум - название группы. (От Burz - темный(черный), на черном наречии Мордора, например Lugburz - черная крепость. Суффикс um, как в английском ness- делает из прилагательного существительное. Таким отбразом Burzum- тьма, чернота. Все естественно по Толкиену.) Еуронимус - человек, некогда вокалист The True Mayhem. Якобы заваленный Варгом(Христианом) Викернессом (он же Граф Гишнак). Поэтому Бурзум+Евронимус = Рут+Антик сааавсем не тождественны.

>Заказчик очень не любит когда ему хотят сделать систему на С/C++.

Ну это конечно не так.

>Пускай такие тормоза, как Жаба, но адресной арифметики заказчики боятся
>как черт ладана. Если у кого другой опыт общения с заказчиками, то

Заказчики не ЗНАЮТ НИЧЕГО и НЕ ДОЛЖНЫ ЗНАТЬ об адресной арифметике.

>интересно было бы выслушать.

Мне довелось в последние полтора года поучаствовать в двух проектах
по "асучиванию" довольно крупных юридических контор в Штатах. Я уже
упоминал ранее в трепе Java vs. C++ о том, что одним из главных
требований была скорость (надежность подразумевается как само собой
разумеющееся). Сейчас мы ПЕРЕДЕЛЫВАЕМ ( уже второй проект ) софт для
одной конторы, который был сделан на Java - главная проблема ( со
слов заказчика ) очень хреновая масштабируемость при увеличении числа
рабочих мест, (докупать железо наладно т.к. это стоит денег и требует
расходов на всякого рода админов ) ну и некоторое расширение функциональных возможностей.

>(Сейчас уже могу говорить.) В пенсионном фонде РФ "покрытия" не
>получилось

Я бы помолчал об xUSSR и конкретно о гос.организациях. Все, кто
поработал здесь, прекрасно знают, что протолкнуть проект в этом
ДЕРЬМЕ стоит ДЕНЕГ а не УМА, ОПЫТА или КВАЛИФИКАЦИИ. Т.о. Ваш пример
не показателен.

>Там технологии более надежных языков программирования.

Если уж говорить о НАДЕЖНОСТИ то это Ada. Для того, чтобы сделать
^^^^
проект на С++ нужна квалификация. Я за десять леть работы с C++
достаточно посидел с debugger'ом вылавливая плавающие ошибки, для
того, чтобы теперь этих ошибок не делать. И я знаю что куча людей
кричат что C++ это дерьмо, только потому, что не владеют и боятся
его.

Успех Java это не отсутствие адресной арифметики и gc, а СТАНДАРТНАЯ
библиотека классов. Заметьте не хорошая а СТАНДАРТНАЯ и почти
всеобъемлющая.
В конце концов gc есть и для C и C++, а адресной арифметикой в
С++ можно не пользоваться - если не уверен.

(В С# стоит заметить эти недостатки С++ присутствуют as is
в виде UNSAFE блоков, однако Вы относите его к БЕЗОПАСНЫМ языкам.)


>> делай раз, делай два, ни шага в сторону

Ага, я уже встречал "программистов", которые после постановки им
тривиальной задачи, спрашивают ничтоже сумняшися какой pattern
им лучше применить в этой ситуации, или лезут в книжки по pattern'ам.
Мудаки блин!


Captain Nemo.

>>Против: >> >>main() >>{ >> int *p = (int*) 1; >> *p = 10; >>} >> >>приемов не знаю. .... Есть приемы: int *p=dynamic_cast<int *>(1);

Как заставить GCC не делать ДВА(!!!) перехода в простом цикле? Пример: цикл по к даже при -O3 оптимизации требует jle и потом еще jmp для обхода fxch, хотя в программе - ничего сложного. Простите, но даже CBuilder умеет оформить цикл только с одним переходом. А так как в GCC - падение скорости в два раза. Я не говорю, что CBuilder - это хорошо. CBuilder не умеет выравнивать данные и код в принципе. Любое обращение к double практически гарантирует промах в строку кэша или шину из-за нарушения 8-байт выравнивания плюс прочие приколы. Хочу перейти на GCC. Подскажите, как сказать GCC, что не стоит добавлять команду перехода и fxch для замены fld и fstp. static void dpoqdu_2d(int lcol, int acol, int arow, Square_2d L[], int ldl, Square_2d H[], int ldh, Square_2d A[], int lda, int delta) { int i, j, k, abeg, alen; Square_2d *pl0, *ph0, *pf0; alen = lda; for(abeg=i=0; i<acol; i++) { for(j=0; j<lcol; j++) { ph0 = &H[j*ldh+i]; pl0 = &L[j*ldl]; pf0 = &A[abeg]; for(k=arow; k>0; k--, pf0++, pl0++) { /* здесь будет два перехода !!! */ pf0->v00 -= pl0->v00*ph0->v00 + pl0->v01*ph0->v01; pf0->v01 -= pl0->v00*ph0->v10 + pl0->v01*ph0->v11; pf0->v10 -= pl0->v10*ph0->v00 + pl0->v11*ph0->v01; pf0->v11 -= pl0->v10*ph0->v10 + pl0->v11*ph0->v11; } } alen -= delta; abeg += alen; } } /* end dpoqdu */ Получил: _dpoqdu_2d: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $44, %esp movl 40(%ebp), %eax movl 12(%ebp), %edx movl $0, -20(%ebp) movl %eax, -32(%ebp) cmpl %edx, -20(%ebp) movl $0, -28(%ebp) jge L145 L143: movl 8(%ebp), %eax testl %eax, %eax jle L147 movl -20(%ebp), %eax movl 28(%ebp), %edx sall $5, %eax movl $0, -36(%ebp) leal (%edx,%eax), %esi movl 32(%ebp), %edx sall $5, %edx movl 24(%ebp), %eax sall $5, %eax movl %edx, -44(%ebp) movl %eax, -40(%ebp) movl 8(%ebp), %eax movl %eax, -24(%ebp) .p2align 4,,7 L142: movl -36(%ebp), %eax movl 20(%ebp), %ebx addl %eax, %ebx movl 36(%ebp), %ecx movl -28(%ebp), %eax movl 16(%ebp), %edi sall $5, %eax addl %eax, %ecx testl %edi, %edi jle L149 fldl (%esi) fldl 16(%esi) fldl 8(%esi) .p2align 4,,7 L141: fldl 16(%ebx) fxch %st(3) fmull (%ebx) fldl (%ecx) fxch %st(3) fmul %st(4), %st fldl 24(%esi) fxch %st(2) decl %edi faddp %st, %st(1) fxch %st(4) fmul %st(1), %st fxch %st(3) fsubp %st, %st(4) fxch %st(3) fstpl (%ecx) fmull (%ebx) movl (%esi), %eax movl 4(%esi), %edx faddp %st, %st(1) fsubrl 16(%ecx) fstpl 16(%ecx) movl %eax, -56(%ebp) movl %edx, -52(%ebp) fldl 24(%ebx) movl 16(%esi), %eax movl 20(%esi), %edx fldl -56(%ebp) fldl 8(%ebx) movl %eax, -56(%ebp) movl %edx, -52(%ebp) fldl -56(%ebp) fld %st(3) fxch %st(2) fmul %st(3), %st fxch %st(2) fmul %st(1), %st fxch %st(4) fmulp %st, %st(5) fxch %st(1) faddp %st, %st(3) fxch %st(2) fsubrl 8(%ecx) fstpl 8(%ecx) movl 8(%esi), %eax movl 12(%esi), %edx movl %edx, -52(%ebp) movl %eax, -56(%ebp) fldl -56(%ebp) fldl 8(%ebx) addl $32, %ebx fmul %st(1), %st faddp %st, %st(4) fxch %st(3) fsubrl 24(%ecx) fstpl 24(%ecx) addl $32, %ecx testl %edi, %edi jle L151 ; переход!!! fxch %st(2) jmp L141 ; еще переход!!! .p2align 4,,7 L151: fstp %st(0) fstp %st(0) fstp %st(0) L149: movl -36(%ebp), %eax movl -40(%ebp), %edx movl -44(%ebp), %edi addl %edx, %eax addl %edi, %esi movl %eax, -36(%ebp) decl -24(%ebp) jne L142 L147: movl 44(%ebp), %eax movl -32(%ebp), %esi subl %eax, %esi movl -20(%ebp), %ecx movl %esi, -32(%ebp) movl -28(%ebp), %ebx incl %ecx movl -32(%ebp), %edx addl %edx, %ebx movl %ecx, -20(%ebp) movl 12(%ebp), %eax movl %ebx, -28(%ebp) cmpl %eax, -20(%ebp) jl L143 L145: addl $44, %esp popl %ebx popl %esi popl %edi popl %ebp ret

Что-то у меня не получилось...
Вот еще вариант...

static void
dpoqdu_2d(int lcol, int acol, int arow, Square_2d L[], int ldl,
Square_2d H[], int ldh, Square_2d A[], int lda, int delta)
{
int i, j, k, abeg, alen;
Square_2d *pl0, *ph0, *pf0;

alen = lda;
for(abeg=i=0; i<acol; i++) {
for(j=0; j<lcol; j++) {
ph0 = &H[j*ldh+i];
pl0 = &L[j*ldl];
pf0 = &A[abeg];

for(k=arow; k>0; k--, pf0++, pl0++) {
pf0->v00 -= pl0->v00*ph0->v00 + pl0->v01*ph0->v01;
pf0->v01 -= pl0->v00*ph0->v10 + pl0->v01*ph0->v11;
pf0->v10 -= pl0->v10*ph0->v00 + pl0->v11*ph0->v01;
pf0->v11 -= pl0->v10*ph0->v10 + pl0->v11*ph0->v11;
}
}
alen -= delta;
abeg += alen;
}

} /* end dpoqdu */

На асме:

_dpoqdu_2d:
pushl %ebp
movl %esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl $44, %esp
movl 40(%ebp), %eax
movl 12(%ebp), %edx
movl $0, -20(%ebp)
movl %eax, -32(%ebp)
cmpl %edx, -20(%ebp)
movl $0, -28(%ebp)
jge L145
L143:
movl 8(%ebp), %eax
testl %eax, %eax
jle L147
movl -20(%ebp), %eax
movl 28(%ebp), %edx
sall $5, %eax
movl $0, -36(%ebp)
leal (%edx,%eax), %esi
movl 32(%ebp), %edx
sall $5, %edx
movl 24(%ebp), %eax
sall $5, %eax
movl %edx, -44(%ebp)
movl %eax, -40(%ebp)
movl 8(%ebp), %eax
movl %eax, -24(%ebp)
.p2align 4,,7
L142:
movl -36(%ebp), %eax
movl 20(%ebp), %ebx
addl %eax, %ebx
movl 36(%ebp), %ecx
movl -28(%ebp), %eax
movl 16(%ebp), %edi
sall $5, %eax
addl %eax, %ecx
testl %edi, %edi
jle L149
fldl (%esi)
fldl 16(%esi)
fldl 8(%esi)
.p2align 4,,7
L141:
fldl 16(%ebx)
fxch %st(3)
fmull (%ebx)
fldl (%ecx)
fxch %st(3)
fmul %st(4), %st
fldl 24(%esi)
fxch %st(2)
decl %edi
faddp %st, %st(1)
fxch %st(4)
fmul %st(1), %st
fxch %st(3)
fsubp %st, %st(4)
fxch %st(3)
fstpl (%ecx)
fmull (%ebx)
movl (%esi), %eax
movl 4(%esi), %edx
faddp %st, %st(1)
fsubrl 16(%ecx)
fstpl 16(%ecx)
movl %eax, -56(%ebp)
movl %edx, -52(%ebp)
fldl 24(%ebx)
movl 16(%esi), %eax
movl 20(%esi), %edx
fldl -56(%ebp)
fldl 8(%ebx)
movl %eax, -56(%ebp)
movl %edx, -52(%ebp)
fldl -56(%ebp)
fld %st(3)
fxch %st(2)
fmul %st(3), %st
fxch %st(2)
fmul %st(1), %st
fxch %st(4)
fmulp %st, %st(5)
fxch %st(1)
faddp %st, %st(3)
fxch %st(2)
fsubrl 8(%ecx)
fstpl 8(%ecx)
movl 8(%esi), %eax
movl 12(%esi), %edx
movl %edx, -52(%ebp)
movl %eax, -56(%ebp)
fldl -56(%ebp)
fldl 8(%ebx)
addl $32, %ebx
fmul %st(1), %st
faddp %st, %st(4)
fxch %st(3)
fsubrl 24(%ecx)
fstpl 24(%ecx)
addl $32, %ecx
testl %edi, %edi
jle L151 ; ПЕРЕХОД!!
fxch %st(2)
jmp L141 ; ЕЩЕ ПЕРЕХОД!!
.p2align 4,,7
L151:
fstp %st(0)
fstp %st(0)
fstp %st(0)
L149:
movl -36(%ebp), %eax
movl -40(%ebp), %edx
movl -44(%ebp), %edi
addl %edx, %eax
addl %edi, %esi
movl %eax, -36(%ebp)
decl -24(%ebp)
jne L142
L147:
movl 44(%ebp), %eax
movl -32(%ebp), %esi
subl %eax, %esi
movl -20(%ebp), %ecx
movl %esi, -32(%ebp)
movl -28(%ebp), %ebx
incl %ecx
movl -32(%ebp), %edx
addl %edx, %ebx
movl %ecx, -20(%ebp)
movl 12(%ebp), %eax
movl %ebx, -28(%ebp)
cmpl %eax, -20(%ebp)
jl L143
L145:
addl $44, %esp
popl %ebx
popl %esi
popl %edi
popl %ebp
ret

>Есть приемы: int *p=dynamic_cast<int *>(1);

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

> (Сейчас уже могу говорить.) В пенсионном фонде РФ "покрытия" не
> получилось. Там технологии более надежных языков программирования.
> (Про текущих заказчиков промолчу, но интерес у них к Java, C#
> и ,традиционно "там", COBOL)

В ПФ РФ бляцкая программа писанная на Delphi от сволочной фирмы КАСИС. Не лечи.

> НаКаждогоМудрецаДовольноПростаты.exe

ПростАта - это человеческий орган. Иди в школу доучивайся.

почитал, поплохело... особенно throw(A)...

насчет jmp и jle - не знаю насчет защищенного режима, но в реальном режиме условные переходы были возможны только на 128 байт. у тебя кусок явно побольше. jmp же мог прыгать на 65535. поэтому циклы с большим телом реализовывались именно так, как реализовал их gcc.

Привет Captain Nemo!

Спасибо за замечания и обсуждение по существу. Не совсем соглашусь со стандартной библиотекой классов, как matrix успеха Java - в конце-концов MFC весьма "стандартна".

Что же касается C#, то unsafe там прописывается явно: как в коде так и ключе компиляции. "Стандартность" С# и .NET - это ECMA стандарты. Да и скорость весьма приличная.

Что же касалось моего "детского" вопросика (оставленного, кстати, анонимусом без ответа) то ответ прост:

#pragma warning (error:4700)

- и все - надежность по отношению к неинициализированным указателям в VC++ гарантирована. Но ответа я, к сожалению, не получил, так что повторюсь:

"Юпитер, ты сердишься - ergo ты не прав!"

Так что анонимусу действительно надо сходить в первый класс - в "Специалист.ру".

> спрашивают ничтоже сумняшися какой pattern им лучше применить в этой ситуации, или лезут в книжки по pattern'ам

Смотря над чем они работают. MFC/ATL/.NET вполне хватает для _практических_ задач, за которые платят _нормальные_ деньги. А для этого вполне хватает знаний MCP 016. Что же касается "непризнанных гениев", то помню я сдачу экзаменов по OS/2 (IBM решила устроить бесплатную сертификацию в рекламных целях), когда "супер-пупер гуру", "монстры ФИДО" получали 25% баллов! (Второй раз за собственные деньги "гуру" уже не пошли - не было у них денег.) Специалистов без сертификата, будем реалистами, серьезные работодатели не рассматривают; хоть лоб расшиби, доказывая свою гениальность - в этом Артур прав.

NikS.

>Есть приемы: int *p=dynamic_cast<int *>(1); 

Увы!

#include <iostream>

using namespace std;

main()
{
    int *p = dynamic_cast<int *>(0); ;
    *p = 0;
}

C:\Demo\cl\cl>cl /GX cp12.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

cp12.cpp
cp12.cpp(7) : error C2680: 'int *' : invalid target type for dynamic_cast
        target type must be a pointer or reference to a defined class

C:\Demo\cl\cl>

Так что способ один:

#include <iostream>

using namespace std;

main()
{
    try 
    {
       int *p = 1; ;
       *p = 0;
       cout << "pointer" << endl;
    }
    catch (...)
    {
	cout << "Sorry!!!" << endl;
    }

    cout << "Hi!" << endl;
}

C:\Demo\cl\cl>cl /GX c1.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

c1.cpp
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:c1.exe
c1.obj

C:\Demo\cl\cl>c1
Sorry!!!
Hi!

Но анонимус-знаток исключений и здесь облажался - 
не царское это дело про "merde" VC++ в MSDN читать.


NikS.

Последня фраза относится к нашему анонимному знатоку-матершиннику, облажавшемуся вчера с return в main() и не ответившему по поводу #pragma warning (error:4700), а не к господину, предложившему динамическое преобразование.

int *p = dynamic_cast<int *>(0); , безусловно некорректно, но ошибочный код - не повод перехода на личности.

NikS.

jle,jne,jge и пр. в защищенном режиме могут прыгать на 32000.
Идея в том, что оптимизатор GCC пытается везде где можно впихнуть
fxch вместо fld. При -О1 оптимизации было:

L132:
fldl (%edx)
fmull (%ecx)
fldl 16(%edx)
fld %st(0)
fmull 16(%ecx)
faddp %st, %st(2)
fxch %st(1)
fsubrl (%eax)
fstpl (%eax)
fldl (%edx)
fmull 8(%ecx)
fxch %st(1)
fmull 24(%ecx)
faddp %st, %st(1)
fsubrl 16(%eax)
fstpl 16(%eax)
fldl 8(%edx)
fmull (%ecx)
fldl 24(%edx)
fld %st(0)
fmull 16(%ecx)
faddp %st, %st(2)
fxch %st(1)
fsubrl 8(%eax)
fstpl 8(%eax)
fldl 8(%edx)
fmull 8(%ecx)
fxch %st(1)
fmull 24(%ecx)
faddp %st, %st(1)
fsubrl 24(%eax)
fstpl 24(%eax)
decl %ebx
addl $32, %eax
addl $32, %edx
testl %ebx, %ebx
jg L132 ; ПЕРЕХОД

При -О3 стало ДВА перехода!!
Типа переход и fxch проще, чем fld...
Ясное дело, что неохота проверять каждый кусок кода
и выяснять в асме, что там натворил оптимизатор.
Чтото там не стыкуется между -О1, -О2 и -О3.

> В ПФ РФ бляцкая программа писанная на Delphi от сволочной фирмы КАСИС. Не лечи

Сходите на "Савеловскую", поговорите с народом про AS/400, а потом снова сюда вылезайте.

NikS.

Оказывается, Анонимус-матершинник "main(){/*noreturn;*/}и с Intel 7 облажался, клоун:

C:\Demo\intel>type empty.cpp
#include <iostream>

void main()
{
    std::cout << "Intel 7" << std::endl;
}
C:\Demo\intel>icl -WX empty.cpp
Intel(R) C++ Compiler for 32-bit applications, Version 7.0   Build 20021018Z
Copyright (C) 1985-2002 Intel Corporation.  All rights reserved.

empty.cpp
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:empty.exe
empty.obj

C:\Demo\intel>empty
Intel 7


C:\Demo\intel>type empty1.cpp
#include <iostream>

int main()
{
    std::cout << "Intel 7" << std::endl;
}
C:\Demo\intel>icl -WX empty1.cpp
Intel(R) C++ Compiler for 32-bit applications, Version 7.0   Build 20021018Z
Copyright (C) 1985-2002 Intel Corporation.  All rights reserved.

empty1.cpp
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:empty1.exe
empty1.obj

C:\Demo\intel>empty1
Intel 7

"На каждого мудреца довольно простоты"

NikS.

PS. Кстати, проверьте старую версию, ту где "вручную" запускался специальный сервер лицензий. Гы!;-)

>Оказывается, Анонимус-матершинник "main(){/*noreturn;*/}и с Intel 7 облажался,

Да можно, можно main без return, успокойтесь. Можно ваще любую функцию без return.

>Так что способ один:

Этот "способ" непереносим. Соответственно, никуда не годится.
Единственнный реальный способ -- это пользоваться, где возможно, хорошо продуманным смарт-пойнтерным типом.

давай посмотрим что будет при -О3:
процессор выбирает команды по одной, условные переходы проверяются в момент выполнения.
процессор выполняет jle - оно в большинстве случаев не выполняется - переходить не надо. нет cache miss, работаем оптимально.
продолжаем выбирать команды, для предварительной обработки: видим безусловный переход - можно начинать выбирать команды уже по новому адресу. опять оптимально.

в случае же -О1:
проверяем jg и в большинстве случаев идем наверх, т.е. имеем cache miss, т.к. предсказать - куда именно передаст управление jg мы можем только непосредственно перед jg.