powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / Анализ исходного кода. Разбор IOCCC 1985 august
25 сообщений из 281, страница 9 из 12
Анализ исходного кода. Разбор IOCCC 1985 august
    #38827408
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov,
впрочему, Фуль, или Пфуль (не помню), был скорее примером в мою пользу, чем в вашу :p
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38827448
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Саш.

Ох как-же я люблю цитировать сам себя... Ну что мне снова найти
фразу где я говорю об исключительности функции strcpy и ассемблере?
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38828151
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonСаш.

Ох как-же я люблю цитировать сам себя... Ну что мне снова найти
фразу где я говорю об исключительности функции strcpy и ассемблере?

Марк, как давно появилась эта операция в ассемблере ?Примерно
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38828155
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Смотря в каком ассемблере. В true-RISC - нет и не должно быть.
Про Z80 - не в курсе, в x86 - изначально было rep movs и два специальных регистра для поддержки. Даже три, если считать регистр цикла. Хотя сильно оптимизированная версия будет использовать load/double shift/store в общем случае.
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38828170
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
До моего рождения. Речь идёт скорее всего об одной из первых версий С для разработки Unix.
C 1973 года.
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38828171
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это к тому, что я не уверен в том, что именно этот пример представлен в книге из-за связи с какими-то расширенными командами процессора (причём RISC процессоры отпадают(как я предполагал, а выше подтвердили)).

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

В любом случае, я не занимаюсь демагогией, и я вас прекрасно понимаю, если отладчик работает так как он работает, то такой код может добавить проблем при отладке. Полностью согласен.

Но вот у меня такой вопрос. Как вы считаете, в данном конкретном случае:
1. Программист должен ограничивать себя, из-за несовершенства отладчика ?
2. Правильно ли, что программист должен ограничивать себя из-за несовершенства отладчика ?
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38828185
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryпричём RISC процессоры отпадают(как я предполагал, а выше подтвердили)Отпадают не RISC, а true-RISC.
Скажем, у вполне RISC-овых IBM Power, насколько я знаю, команда пересылки невыровненной цепочки байт - есть.
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38828189
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury1. Программист должен ограничивать себя, из-за несовершенства отладчика ?
2. Правильно ли, что программист должен ограничивать себя из-за несовершенства отладчика ?программист должен ограничивать себя, чтобы писать понятный, легкочитаемый и сопровождаемый код. Совершенство/несовершенство отладчика в данном случае - вопрос 800ой очерёдности.
Недавно топик был про v[ i++ ] = i++; - явление такого же порядка. Слишком много побочных эффектов для одной строчки кода, что потенциально может привести к появлению трудноуловимых ошибок.
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38828201
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury1. Программист должен ограничивать себя, из-за несовершенства отладчика ?
Тут речь идёт о другом. Скорее всего ты ограничиваешь своих коллег. Ты заставляешь их
делать code-review следующей какашки.

Код: plaintext
1.
while (isalnum(c = *s++ = getc(in)) || c == '_');



Если ты реализуешь "некоторую логику" то должно следовать ЯСНОЕ и ЧЁТКОЕ доказательство
ее корректности в ОБЩЕМ СЛУЧАЕ. Тоесть функция не должна вызывать ни у кого вопросов
или неоднозначных толкований. Цикл ВСЕГДА содержит выражения инициализации, итерационное
выражение и тело цикла. 3 сущности. Они должны быть чётко обозначены. В строгих ЯП типа
Pascal специально созданы жёсткие синтаксические конструкты. Декларации. Выражения инкремента.
Тело цикла. Там нет возможности сделат финт или написать что-то неоднозначное.

И не надо говорить про несовершенство отладчика. Он - простой и ясный инстумент для
хождения по СТРОКАМ исходника. И если ты намисал ВСЁ приложение в 1 строчку
то ты сам себе злобный буратино! Не пиши так! Не ходите дети... в Африку гулять.

Выражение

Код: plaintext
1.
WHILE((*S++=*T++)!='\0');



написано профессионалами. Они его миллион раз оттестировали. Они соптимировали
код для коротких ассемблерных реализаций. Они не нуждались в дебаггере потому-что
здесь дебаггер уже никогда не будет нужен. Эта функция - атом.

В отличие от твоего кода. Который будет еще over 9000 раз исправлен. Дополнен условиями и кейсами.

Вобщем ты можешь писать как угодно. Но как только ты выносишь код на суд, в форум.
В паблик SVN. Просишь критиковать. Обсуждать. То тут уж - извини. Я оттянусь по полной. .

Кстати я всегда прислушиваюсь к чужим советам и по поводу своего
кода. Бывает что и глаз замылен. И лень-паттерн...
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38828212
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonИ лень-паттерн... нашевсё
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38828213
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonЯ оттянусь по полной. .


всегда рад :)

maytonКстати я всегда прислушиваюсь к чужим советам и по поводу своего
кода. Бывает что и глаз замылен. И лень-паттерн...

прислушиваюсь всегда к чужим советам.

Basil A. Sidorov,egorych, mayton, всем спасибо за критику и предложения:)Все мнения учтены, и все они у меня в голове.
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38836303
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Саша дуй сюда Физики есть?
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38853729
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.
Праздникам конец.

Не помню говорил ли, но реализация алгоритма М (выполнение макрозамен в коде программы) завершена, ещё в прошлом году.
Однако, мне не нравится моя реализация. Потому занимаюсь изменением алгоритма.(кстати, а есть ли для этого словосочетания слово аналогичное слову "рефакторинг" ? ). Да, собственно потому, то что сделал не выложил. Потому что не доволен этим.

Первый шаг алгоритма M0 предлагаю сделать таким: считать весь код программы в heap. Адрес объекта например char* code.
В дальнейшем алгоритм будет работать только с этим объектом.
В настоящее время, токенизация происходит из файла.

Причины такого решения:
1. Как можно быстрее освободить файл, вследствие чего предотвратить возможные ошибки. Например, во время работы с файлом с ним что-то произойдёт и он будет прочитан не полностью. Если время в течении которого мы с ним работаем больше, то вероятность того что это случится выше.
2. Предполагаю, что за счёт этого я не потеряю в производительности больше чем незначительно, даже в том случае если причина1 неверна. При возможных небольших потерях в производительности, выигрываю в простоте кода.

Минусы:
1. Выделение памяти, хотя незначительное. Допустим код программы содержит 10^6 символов<2^(3.4*6) Байт<2^21 Байт=2 Мб
Не так много, но на старых машинах прилично.
2. Возможные издержки во времени

Возникающие проблемы:
Как мне узнать сколько памяти в куче выделить на конкретный файл? Нужно выделить столько, сколько нужно + небольшой задел, мало-ли, ошиблись.
Искать конец файла, или считать количество символов не считаю правильным, ибо долго. Должна где-то храниться информация о размере файла, и её вероятно как-то можно прочитать. Верно ?


Подскажите пожалуйста, имеют ли место быть рассуждения выше ? Делали ли бы вы шаг М0 ?
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38853744
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury1. Как можно быстрее освободить файл, вследствие чего предотвратить возможные ошибки. Например, во время работы с файлом с ним что-то произойдёт и он будет прочитан не полностью. Если время в течении которого мы с ним работаем больше, то вероятность того что это случится выше. Зачем??? Не шмогли значит не шмогли. Выдал ошибку что мол файл неожиданно закончился, или заблокирован, или что там еще с ним случилось и отменил всё. Какой смысл предотвращать ошибку файлового типа на этапе компиляции?
И если ты ее даже предотвратишь: была версия файла номер N. Ты начал с ней работать, а в это время пришел злодей-юзер, подправил файл и стала там версия N+1. А у тебя в это время продолжается компиляция версии N. Откомпилировали, запустили - видим что программа работает не правильно. Но мы же знаем что мы эту ошибку только что исправляли?!


SashaMercuryКак мне узнать сколько памяти в куче выделить на конкретный файл? Нужно выделить столько, сколько нужно + небольшой задел, мало-ли, ошиблись.
Искать конец файла, или считать количество символов не считаю правильным, ибо долго. Должна где-то храниться информация о размере файла, и её вероятно как-то можно прочитать. Верно ?Верно. Хранится она в FS (File System) и доступна когда ты читаешь директорию, или через stat()/fstat() функции, или через пару fseek()+ftell() которые выполняются очень даже быстро (потому что внутри используют fstat()).
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38853774
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
White Owl, спасибо.
Вы считаете, что не стоит менять текущий алгоритм в контексте токенизации из файла ? Вы бы не стали использовать предварительное чтение данных в кучу ?
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38854010
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryПервый шаг алгоритма M0 предлагаю сделать таким: считать весь код программы в heap. Адрес объекта например char* code.
В дальнейшем алгоритм будет работать только с этим объектом.
В настоящее время, токенизация происходит из файла.

Причины такого решения:
1. Как можно быстрее освободить файл, вследствие чего предотвратить возможные ошибки. Например, во время работы с файлом с ним что-то произойдёт и он будет прочитан не полностью. Если время в течении которого мы с ним работаем больше, то вероятность того что это случится выше.
2. Предполагаю, что за счёт этого я не потеряю в производительности больше чем незначительно, даже в том случае если причина1 неверна. При возможных небольших потерях в производительности, выигрываю в простоте кода.

Если у тебя файл с исходником могут (внезапно) украсть инопланетяне то в топку твою файловую
безопасность.

Если твои файлы лежат на сетевом диске NFS/SMB/ftp/webdav то копируй их себе в каталог проекта
или хоть в $TEMP/$TMP и наслаждайся эксклюзивом.

Если твой компиллятор просто так по приколу всё прогружает в хип то рано или поздно разгневанный
анонимос придёт к тебе в блог и выскажет своё мнение по поводу тебя и твоей драгоценной мамы
(дай бох ей здоровья).
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38854213
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,
:D спасибо, и вашей маме здоровья.

Эту идею никто не поддержал. Хорошо. Приму вашу точку зрения, оставлю всё как есть, по вопросу токенизации
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38854335
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury,

Не поддерживают, потому что не надо подстраивать алгоритм под невероятные сценарии
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38854653
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Посмотрите http://opencxx.sourceforge.net/ OpenC++ is C++ frontend library (lexer+parser+DOM/MOP) and source-to-source translator
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38854741
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владимир2012,
зачем ?
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38855582
Владимир2012
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury1. Я решил, что сначала мне нужно получить список всех замен (как бы это слово правильно назвать, макроподстановок? ) в тексте
Приведенная ссылка - это тот проект с чего началась PVS-Studio /согласно их мемуаров/.
Если вас интересует тема лексического разбора C++ ..., то этот проект по идее должен был бы быть
вам интересен.
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38855843
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovsky, пользуюсь вашим советом. В свете недавних решений касаемо алгоритма, в первую очередь нужно реализовать алгоритмы через объект Stream.
Изменил то, что вы предлагали. Подскажите пожалуйста, имею ли я право создавать такую структуру вообще, и подходит ли она мне в дальнейшем в таком виде ?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
struct Stream
{
	void* name;
	int (*get_symb)(struct Stream*);
	int (*unget_symb)(struct Stream*);
	int end_symb;
};
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38855844
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владимир2012,

мне нравится делать это самому. Не так много знаю, чтобы пользоваться готовыми решениями. Позже обязательно посмотрю. Спасибо )
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38855861
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryимею ли я право создавать такую структуру вообще, и подходит ли она мне в дальнейшем в таком виде ?
Имеете. Подходит.
...
Рейтинг: 0 / 0
Анализ исходного кода. Разбор IOCCC 1985 august
    #38857196
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.
Сегодня возник вопрос. Правильно ли я понимаю, что вызов функций через объект Stream, будет медленней чем вызов функций непосредственно ?
...
Рейтинг: 0 / 0
25 сообщений из 281, страница 9 из 12
Форумы / C++ [игнор отключен] [закрыт для гостей] / Анализ исходного кода. Разбор IOCCC 1985 august
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]