W>нигде не указано, что тип signed. W>Может быть подразумевался само собой unsigned (который в абстрактной машине С складывается по модулю).
Это не важно — код будет работать как с signed так и с unsigned.
Здравствуйте, eskimo82, Вы писали:
A>>a = 2147483647, b = 12345. Получаем overflow и пометку профнепригодности у эйчаров. E>Никакого overflow мы не получаем — Паскаль содержит целочисленую арифметику, аналогичную C/C++ — не влезающие биты просто отбрасываются. Код будет работать коректно (на 32 бит машине).
А кто сказал, что это Паскаль? Может это Ada или Eiffel.
тебе сороковник скоро, а ты все дрочишь на порядки присвоения переменных... а потом мы удивляемся, почему в среднем по индустрии около 90% написанного кода идет в мусорку... попробуй сменить цель с "написать что-нибудь крутое на тысячу строк" на "написать что-нибудь крутое на тысячу покупателей". Ну т.е. реально разобраться, что народу надо, и реализовать это настолько удобно, чтобы людям было не жалко денег это купить. Как втянешься — приход будет в 1000 раз сильнее, чем от просто закодить. Потом будешь вспоминать молодость и думать "фигасе я наивняк был..."
ARK>А кто сказал, что это Паскаль? Может это Ada или Eiffel.
И много у нас школьников решает "первую задачу по програмированию" на Ada или Eiffel ?
Надо конечно допускать возможность этих вариантов, но наиболее вероятно — это все же Паскаль.
Здравствуйте, bazis1, Вы писали:
B> тебе сороковник скоро, а ты все дрочишь на порядки присвоения переменных...
это вы дрочите, а я разгребаю говна, продираясь сквозь обфускацию, где код выполняется совсем не так, как это ожидается.
B> а потом мы удивляемся, почему в среднем по индустрии около 90% написанного кода идет в мусорку...
в мусорку не пишу
B> попробуй сменить цель с "написать что-нибудь крутое на тысячу строк" B> на "написать что-нибудь крутое на тысячу покупателей". Ну т.е.
написал. и далеко не на тысячу покупателей, среди которых много постоянных. но это не показатель
B> реально разобраться, что народу надо, и реализовать это настолько удобно, B> чтобы людям было не жалко денег это купить. Как втянешься — приход будет
моим покупателям денег не жалко, но деньги это мусор. ни хрена вы в жизни не разбираетесь. самое главное — фидбек от кастомеров и не только фидбэек, но и контрибуция (код, идеи)
B> в 1000 раз сильнее, чем от просто закодить.
в задрачивании над кодом я замечан не был. пишу довольно просто и без выкрутасов.
B> Потом будешь вспоминать молодость и думать "фигасе я наивняк был..."
мы с вами в разных плоскостях. от R&D я сначала переместился к R, а от R к CS и занимаюсь решением нерешенных проблем, потому как если проблема имеет решение, то это не для меня.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
vsb>a := a + b;
vsb>b := a - b;
vsb>a := a - b;
vsb>
vsb>горжусь этим кодом. Это была первая моя задача по программированию (обменять значения двух переменных без третьей), с которой я успешно справился. Думаю с неё началось моё увлечение программированием.
На самом деле, этот код хоть и будет работать правильно (в Паскале или C/C++) — он плохой:
1. Производительность.
Если компилятор догадается сделать a, b регистровыми переменными — будет 2 чтения-записи памяти и 3 арифметических операции над регистрами, если не догадается — все будет еще хуже.
Поэтому следующий код, вероятнее всего, будет работать быстрее (2 чтения-записи памяти, 1 move между регистрами)
register int tmp = a;
a = b;
b = tmp;
2. Защита от ошибок.
Использование арифметических операций тут — зло. Вася пупкин может может вместо интегрального целого подставить вместо a и b плавающую точку или вообще неинтегральный тип с переопределенными operator +/-. Поэтому лучше писать через xor — это может защитить в случае плавающей точки и — переопределяют operator ^ более редко чем +/-.
В остальном — в добавок тоже просадка по производительности.
3. Идеальный вариант по производительности — это вообще использовать платформеные инструкции (если есть), например для x86 — какую нибудь xchg (экономит 1 лишнюю mov, и 1 регистр, коих на x86 тупо мало). Но этот вариант слишком непортируем.
E>Если компилятор догадается сделать a, b регистровыми переменными — будет 2 чтения-записи памяти и 3 арифметических операции над регистрами, если не догадается — все будет еще хуже.
компилятор это в значительной степени распознаватель паттернов.
Распознать паттерн "перестановка переменных" раз плюнуть, далее компилятор свободен компилировать это концептуальное действие сколь угодно оптимально.
От поддержки соответствия между переменными и действиями в абстрактной машине и реальной компилятор как правило освобожден.
Здравствуйте, watchyourinfo, Вы писали:
E>>Если компилятор догадается сделать a, b регистровыми переменными — будет 2 чтения-записи памяти и 3 арифметических операции над регистрами, если не догадается — все будет еще хуже.
W>компилятор это в значительной степени распознаватель паттернов. W>Распознать паттерн "перестановка переменных" раз плюнуть
какой идиот станет реализовывать распознавание этого паттерна в череде арифм. операций? вот код с tmp однозначно превратится в банальное переименование идентифмикаторов и таким образом сам по себюе не породит ассемблерного кода вообще
Здравствуйте, abibok, Вы писали:
A>На последнюю просьбу пациента "дайте заменить арифметику на xor" предложить a = b = 1 и назначить младшим помощником золоторя при ассенизационном обозе.
не понял юмора. предполагается, что при a = b = 1 этот код не будет работать?
Здравствуйте, LuciferSaratov, Вы писали: LS>не понял юмора. предполагается, что при a = b = 1 этот код не будет работать? LS>
LS>a = a ^ b;
LS>b = a ^ b;
LS>a = a ^ b;
LS>
он не будет работать, когда a и b — ссылки на один и тот же обьект.
вообще, я людям, пишушим подобный код, тоже бы сначала предложил поработать младшим помощником ассенизатора
Здравствуйте, __kot2, Вы писали:
__>он не будет работать, когда a и b — ссылки на один и тот же обьект.
а, ну это понятно.
я по умолчанию пишу на С (как раз за такие неожиданности С++ и не любят).
__>вообще, я людям, пишушим подобный код, тоже бы сначала предложил поработать младшим помощником ассенизатора
MF>У вас есть код, которым вы гордитесь, чтобы показывать, когда работадатели просят его показать?
НЕТ
по-моему, гордиться каким-то кодом могут только жалкие кодировщики
настоящие программисты должны гордиться решенными ими трудовыми задачами
возможно, тем, что иную сложную задачу они решили просто, трудоемкую — быстро
или признанную кем-то нерешаемой — хоть как-то решили
изобретенный новый алгоритм — вот, пожалуй, самый лучший повод для гордости
(я как-то придумал парочку, но увы, они оказались уже не новыми
гордость шароварщиков, опенсорсников, один-на-всю-контору-программистов и просто пет-прожект-мейкеров за свои "родные" программулины я тоже вполне понимаю
но не за их код
vsb>>a := a + b;
vsb>>b := a - b;
vsb>>a := a - b;
vsb>>
vsb>>горжусь этим кодом. Это была первая моя задача по программированию (обменять значения двух переменных без третьей), с которой я успешно справился. Думаю с неё началось моё увлечение программированием. E>На самом деле, этот код хоть и будет работать правильно (в Паскале или C/C++) — он плохой:
E>1. Производительность. E>Если компилятор догадается сделать a, b регистровыми переменными — будет 2 чтения-записи памяти и 3 арифметических операции над регистрами, если не догадается — все будет еще хуже.
E>Поэтому следующий код, вероятнее всего, будет работать быстрее (2 чтения-записи памяти, 1 move между регистрами) E>
E>register int tmp = a;
E>a = b;
E>b = tmp;
E>
E>2. Защита от ошибок. E>Использование арифметических операций тут — зло. Вася пупкин может может вместо интегрального целого подставить вместо a и b плавающую точку или вообще неинтегральный тип с переопределенными operator +/-. Поэтому лучше писать через xor — это может защитить в случае плавающей точки и — переопределяют operator ^ более редко чем +/-. E>В остальном — в добавок тоже просадка по производительности.
E>3. Идеальный вариант по производительности — это вообще использовать платформеные инструкции (если есть), например для x86 — какую нибудь xchg (экономит 1 лишнюю mov, и 1 регистр, коих на x86 тупо мало). Но этот вариант слишком непортируем.
Задача звучала в виде "обменять значения a и b без дополнительных переменных". Паскаль я начал учить за полчаса до этого и не то, что про XOR, про переполнение понятия не имел. С пунктами согласен, но прелесть этого кода (для меня) не в этом.
Здравствуйте, vsb, Вы писали:
vsb>Паскаль я начал учить за полчаса до этого и не то, что про XOR, про переполнение понятия не имел.
Видимо поэтому и нападки: зачем работодателю, спрашивающему на интервью про код, которым ты гордишься, человек, который начал заниматься программированием за полчаса до собеседования?
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, bazis1, Вы писали:
B>> тебе сороковник скоро, а ты все дрочишь на порядки присвоения переменных... М>это вы дрочите, а я разгребаю говна, продираясь сквозь обфускацию, где код выполняется совсем не так, как это ожидается.
хм. возможно тогда не все так плохо. я в R&D встречал ситуации, где люди могут часами напролет дискутировать а-ля что кошерней: mingw или cygwin, в конце проекта получить "кошерное" решение 1 задачи из 100 изначально планируемых, и перескочить на новый проект. пусть типа в продакшне разбираются. продакшн, естественно, этот код даже не открывает.
B>> попробуй сменить цель с "написать что-нибудь крутое на тысячу строк" B>> на "написать что-нибудь крутое на тысячу покупателей". Ну т.е. М>написал. и далеко не на тысячу покупателей, среди которых много постоянных. но это не показатель
хм. вот это уже интересно. можешь описать в паре предложений, как там бизнес-модель работает? исключительно патентный анализ?
B>> реально разобраться, что народу надо, и реализовать это настолько удобно, B>> чтобы людям было не жалко денег это купить. Как втянешься — приход будет М>моим покупателям денег не жалко, но деньги это мусор. ни хрена вы в жизни не разбираетесь. самое главное — фидбек от кастомеров и не только фидбэек, но и контрибуция (код, идеи)
деньги — это один из немногих объективных показателей. фидбек можно дать из вежливости, или из желания проманипулировать. покупка лицензии говорит о полезности софта обычно больше.
B>> в 1000 раз сильнее, чем от просто закодить. М>в задрачивании над кодом я замечан не был. пишу довольно просто и без выкрутасов.
Хм. Возможно я неправильно проинтерпретировать комментарий выше.
B>> Потом будешь вспоминать молодость и думать "фигасе я наивняк был..." М>мы с вами в разных плоскостях. от R&D я сначала переместился к R, а от R к CS и занимаюсь решением нерешенных проблем, потому как если проблема имеет решение, то это не для меня.
я в свое время прошел немного по этой тропинке. из моего опыта получилось, что если проблема не имеет решения, то в 99% случаев она нафиг никому не нужна. в итоге можно сделать сколь угодно крутое решение, но пользоваться им никто не будет, ибо никому не надо.
