» Забавные вещи

---

К примеру, недвано заметил различие при вычислении арифметического выражения в компиляторах из gcc 3.3.3 под Линуксом и cl из Microsoft Visual C++ Toolkit 2003.
Выражение в данном коде:
Код: int x = 5;
cout << (x=x)*(x-=3) << endl;

SaDFromSpb

Цитата:

cout << (x=x)*(x-=3) << endl;

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

Цитата:

*((int*) &a) = 4;

вполне нормальный хак если нет виртуальных функций. Почитай саттера - там есть другие интересные методы. На С++ и не такие вещи делают.

Цитата:

Turbo Pascal 7.0

нормальный глючный компилятор (я с таким тоже сталкивался)
Дым из винчестера (который HDD) забавляет намного больше
---
Из того что удивило, могу вспомнить только Александреску и boost - переодически чувствую себя полным болваном с вопросом "как они до этого додумались?". Но это не язык, это люди...
---
P.S. imho тема тухлая - загнется не приходя в сознание

WiseAlex
Цитата:

Но это не язык, это люди...

Здесь это тоже пойдет

Цитата:

imho тема тухлая - загнется не приходя в сознание

Я тоже так подумал (тут еще и программистов не особо много, мне кажется), но создать все равно решил. Не подскажешь, кстати, сайт Андрея Александрески, а то я что-то с ходу не нашел.

Цитата:

Если я компилировал прогу с ним, то она работала одним образом, а если я этот закоментированный кусок удалял, то другим!

Ничего удивительного, если активно исползовалась динамическая память+bugs или не инициализировались переменные.
У меня в TP при компиляции программы, содержащей имя процедуры Parser, происходила в внутренняя ошибка компилятора.

Из недавних удивительных фактов. Простейщая и распространенная операция скалярное умножение двух вектров. При анализе зависимости времени выполнения от размерности вектора обнаружилось резкое увеличение времени счета >10 раз. Причем это увеличение можно было бы списать на исчерпание кэша L2, если бы при дальнейшем увеличении размерности (не на один или два, а в несколько раз) не происходило уменьшение времени и спад примено соответствовал росту.

Цитата:

Из того что удивило, могу вспомнить только Александреску и boost

Переведи для непосвещенных.

ItsJustMe
boost (http://www.boost.org/) - это известная библиотека (набор библиотек) для C++ с реализацией решений большого числа часто встречающихся задач. К примеру, там есть удобная библиотека для измерения времени выполнения программы в миллисекундах.
Так же там есть реализация нахождения максимального и минимального значения в массиве из n элементов при максимальном количестве сравнений меньшем чем 2*n (по-моему за 2*n/3-1). (интересно, как это у них вышло)
И много всего другого...
Андрей Александреску - программист, сделавший кое-что полезное для всего программирующего на С/С++ человечества (про него лучше в гугле поиши). Вот WiseAlex мне его сайт подсказал: http://erdani.org/

Simbr
Цитата:

Причем это увеличение можно было бы списать на исчерпание кэша L2, если бы при дальнейшем увеличении размерности (не на один или два, а в несколько раз) не происходило уменьшение времени и спад примено соответствовал росту.

Всмысле сначала время резко увеличивается а потом опять спадает?
Цитата:

..при компиляции программы, содержащей имя процедуры Parser, происходила в внутренняя ошибка компилятора

Да... это еще веселее, чем удаление коментария...

SaDFromSpb
Да. Если интересно могу выслать результаты

Simbr
Скажи, на чем это все делается (какой проц, ОС, на каком языке (ты вообще библиотечную функцию имеешь ввиду?)) и на какую размерность приходится скачoк.

SaDFromSpb
Спасибо за исчерпывающий ответ. Надо будет заглянуть...
Simbr
Я думаю, что вставить в прогу Parser мы, наверное, и сами сможем Или этот глюк не во всех случаях всплывает? А вот пример с комментом интересен. Дело в том, что я общаюсь с людьми, для которых работа с BP является, в некотором смысле, профессиональным занятием. Им это будет весьма интересно.

SaDFromSpb
_http://forum.sources.ru/index.php?showtopic=119792 (там мой nickname PAV)
Странное поведение только для F_MM_C, ее особенность -- скалярное произведение вычисляется отдельной п/п. Появление ступеньки зависит от размера L2 и типа процессора. В частности,
на CPU_brand_Str=Intel(R) Pentium(R) 4 CPU 2.80GHz
T_Cache_L1= 12K-uops, 8-way set associative
D_Cache_L1=8-KB, 4-way set associative, sectored cache, 64-byte line size
Cache_L2= 512-KB, 8-way set associative, sectored cache, 64-byte line size
Начало ступеньки при размерности матрицы ~170, окончание ~230. Навершине ступеньки время выполнения матричного умножениея возрастает в ~ 3 раза.

SaDFromSpb

Цитата:

Я думаю, что вставить в прогу Parser мы, наверное, и сами сможем

А кто Вам запрещает? Дело в том, что BP7 ругался на имя моей procedure Parser; как internal error, по документации это имя допустимо!

Да нет, никто не запрещает. Это я неправильно истолковал твою фразу "Если интересно могу выслать результаты". Просто я не заметил, как тема из обсуждения глюков в BP превратилась в обсуждение особенностей работы L2 cache.

Незнаю как BP - он DOS и до сих пор даты файлов устанавливает корректно, а вот всякие архиваторы типа WinAce, WinZip, WinRar этого не умеют делать на NTFS! Вроде как виндовая файловая система, а таскаемые этими архиваторами файлы всё время прибавляют по две секунды - забавно, когда сравниваешь файлы набравшие 6 секунд.
Интересно на каком софте они пишут файловые функции, я вот делаю слип на 40 миллисекунд после закрытия файла и никогда отличий в дате не видел. Так что получается BP поточнее будет.

Pinocchio
Ты это о чем? Какие 6 секунд? Я тебя ващще не понял. Выразись точнее: что за 6 секунд, и где ты их увидел.

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

Pinocchio
>Интересно на каком софте они пишут файловые функции
если так поступает и WinZip (написан на MS VC6) и WinRar (Borland C++), то проблема в WinApi если не глубже

может и в NTFS, как и в FAT32/16 дата файла хранится с точностью до 2х сек...

но однако это ж как надо извращаться чтоб смотреть у файла дату до секунд )
а, понял, компареры)

ItsJustMe
Я таскаю файлы в zip архиве с работы домой и обратно, надеюсь это понятно?
Так вот когда архивируешь файлы, в архиве сохраняется дата модификации файла.
Когда разархивируешь то на разархивированном файле устанавливается его дата из архива. Но современные архиваторы дают осечку приблизительно в две секунды. После трех таких "осечек" дата отличается на 6 секунд. А компараторы директории считают что файл изменился, следовательно я всегда сталкиваюсь с ненужной мне работой. Но что прикольно, что мой BP-шный архиватор такую осечку не даёт.
А вот разбираться - успела ли ntfs закрыть и проиндексировать файл я не буду. Делаю sleep(40) и тогда смело устанавливаю дату в мультизадачной системе, которая физически ещё не закрыла файл, но уже вернула мне управление.

Pinocchio

Цитата:

Я таскаю файлы в zip архиве с работы домой и обратно, надеюсь это понятно?

А тот факт, что ты их таскаешь с работы домой и обратно, а, предположим, не от одного своего знакомого к другому своему знакомому очень важен? Иначе разве ты бы стал так рьяно настаивать на понимании данного момента?

Цитата:

Но современные архиваторы дают осечку приблизительно в две секунды. После трех таких "осечек" дата отличается на 6 секунд.

Проделал все тоже самое, используя в качестве архивов форматы RAR и ZIP. Количество итераций > 20. Результат: дата модификации файла, округленная до секунд, осталась неизменной.

Цитата:

А вот разбираться - успела ли ntfs закрыть и проиндексировать файл я не буду.

Какое горе! Он не будет разбираться Все, Конец Света наступит в ближайшие 24 часа.
A_V
Ты прав. Но мои эксперименты не подтверждают его утверждение о том, что архиватор WinRAR дает ошибку в дате изменения файла не менее, чем на одну секунду. Архиваторы WinZIP и WinACE я не тестировал. Но его ошибочное утверждение насчет WinRAR'а дает повод сомневаться и в остальных его утверждениях. Предлагаю тебе также (если тебе, конечно, это интересно) провести такой эксперимент. Выступишь в качестве независимого эксперта и скажешь, чьи результаты ты считаешь наиболее объективными.
PS: А ты прав. WinRAR действительно написан на BCB. И, скорее всего, на шестом.

ItsJustMe
Pinocchio не врет, просто у него WinRAR старый.
вот, откопал WatsNew от WinRAR 3.20:
http://www.softline.ru/product.asp?catalog%5Fname=SoftLine&category%5Fname=&product%5Fid=Software%2D11951&view=release%5Finfo%5Fru

Добавлено:
а спецификация zip стопудов не поддерживает таких дат, так что архиверы не виноваты

Pinocchio
не понял, что значит, что BP ставил даты корректно. это как ты проверял, я не понял? и как можно поставить дату у файла _некорректно_ или он тоже архивы умел делать ?

ItsJustMe

Цитата:

к другому своему знакомому очень важен? Иначе разве ты бы стал так рьяно настаивать на понимании данного момента?

Незаметил, что рьяно отстаивал, но ситуация интерестее, когда обменных каталогов на обдном из компьютеров не два, а три. Один для работы, второй для сопоставления, а третий для интернета. Хотя и это фигня если понять единственное - дата файла это тоже информация, а архиватор вроде должен заботится о сохранности информации, чего я не наблюдаю (rar у меня действительно старый, пользую в редчайших случаях).

Цитата:

Проделал все тоже самое

Ну ну... У меня вчера/сегодня + дома/на работе архив zip (в него я положил дофига файлов с датой 00 секунд. Более одной третьей разархивировались с 02 (очень хорошо видно когда их много). И это мне знакомо уже давно.
A_V

Цитата:

а спецификация zip стопудов не поддерживает таких дат

Каких дат она не поддерживает? 00 секунд? Захожу и в WinZip и в WinAce, везде даты корректные. Разархивирую, две третьи имеют 00, одна третья файлов имеет 02 секунды.
Я говорю о тех датах которые уже лежат в архиве.

Цитата:

не понял, что значит, что BP ставил даты корректно. это как ты проверял, я не понял? и как можно поставить дату у файла _некорректно_ или он тоже архивы умел делать ?

Говорю про архиватор появившийся в 1994г по нажатию на F9. Написан он на BP70. Метод LZSS с использованием стандартного для BP оператора установки файловой даты после того как файл закрыт от модифицирования. Дата берётся и сохраняется в формате файловой даты используемой в системе FAT.

---

Ну если мне самому приходилось писать ручками sleep в своей проге с названием FileFunc перед установкой даты то наверное я не придумываю а? Планировалось преподнести это как курьёз, я как-то не умею. Я же чё объясняю - обладание определённым качеством это не опция, а параметр.

Pinocchio


Цитата:

Захожу и в WinZip и в WinAce, везде даты корректные. Разархивирую, две третьи имеют 00, одна третья файлов имеет 02 секунды.
Я говорю о тех датах которые уже лежат в архиве.

а... я тебя всетаки с начала не правильно понял, думал, они в архив с неправильными датами попадают, а не обратно

хотя я щас винраром зипы посоздавал, все гуд.

В Delphi иногда при трассировке курсор ходит не по строчкам, а между ними

Там же - кусочек кода из хелпа (или faq, не помню) c CreateProcess выдает Internal Error. Вставишь между определенными строчками кода совершенно левый код (но рабочий, не просто комментарий) - компилит нормально )

Вспомнил тут про отладку, думаю её можно отнести к программированию.
Если в процессе dеlрhi32.ехе приаттачить второй процесс dеlрhi32.ехе, а потом попытаться сделать это в приаттаченом процессе с первым процессом, то их взаимодействие в дальнейшем происходит без участия пользователя.

И что же именно они делают "без участия пользователя"? Страшно подумать...

Цитата:

И что же именно они делают "без участия пользователя"? Страшно подумать...

Я уже засмущался и покраснел )

Меня в программировании всегда удивляла моя способность порождать внутренние ошибки
компиляторов. (Начиная еще с ВМ1841). Анализ показывает, что производители компиляторов
удивительно несерьёзно подходят к заданию глубины стека разбора выражений.

Глупина стёка это что-то новое. Думаю даже дефрагментированность это не факт...
Всмысле даже не знаю, что и говорить. Только упомянутые производители это люди,
и даже очень милые люди, которым мы многим обязаны. Предпочитаю предсавлять
себе всё же реальных людей, даже когда речь идёт о библии.

В свое время улыбнул комрад Mark Crispin (автор imap toolkit) - любитель макросов типа
MICROSOFT_BRAIN_DAMAGE, NETSCAPE_BRAIN_DAMAGE и советами
"рекомендуеное решение проблемы с nsnotify - удаление исполняемых файлов
nsnotify ".
Он же придумал проблемы Y2038, Y2070, Y2098, Y2800, Y4K, Y20K, Y45K
особенно порадовала последняя

Цитата:

Y45K:

Greeks, Serbs, Russians, and other Eastern Orthodox have spent
the past 41,000 years laughing at westerners' increasingly futile
efforts to keep the Gregorian calendar in order. The day of reckoning
has come; the Orthodox calendar is now one day slow. The Patriarch of
Istanbul (nee Constantinople) has not made any statement about how this
will be fixed.

Так что 41000 лет дружно смеемся с буржуйского календаря

Одним словом Аффтар ЖЖОТ

Как-то давно я решил заценить возможность подключения дебаггером на лету к повисшему процессу. Использовал Visual С++ 6.0. Написал простейший код, что-то вроде:
Код: int x=0;
double y=34/x;

Не знаю насколько это глюк компилятора и вообще глюк ли это, но недавно заметил такой странный факт. На работе стоит комп на Pentium 4 2600 дома AMD Athlon XP 1800 на компах стоит WinXP(ставил с одного компакта) и Delphi 7, все настройки абсолютно одинаковые все версии компонент тоже одинаковые, но при компиляции проекта на AMD, екзешник получается меньше на несколько десятков килобайт, чем при компиляции на Пентиуме. Все настройки и оптимизации проверял по несколько раз все одинаковое.
Вот такие интересные факты из жизни

TeX
А сравнивать экзешники не пробовал? Может в конце файла ресурс сожержит иконки или битмапы которые давно уже конвертит сама GDI?