кто его знает что он в релизе сделает

а про оптимизацию не забыли?

Да, я оптимизации выключил

хмм

о, придумал

Да, реально не совсем корректный тест получился

Щас нормальный будет

и потом это только для одного компилятора

для другого может быть другой

Короче глянул. Есть основной регистр и регистр который держит в себе переполнения

Забавная система

Щас еще один тест проведу и покажу нормальным скриншотом что происходит

http://image.prntscr.com/image/d6e22e5d370a4e2d86cc083da18b7bb8.png

Надеюсь понятно)

Предупреждаю - Телеграмм шакалит изображения в собственном просмоторщике, поэтому если вам кажется много шакалов - переходите по ссылке

Мне почему то кажется что с оптимизациями будет так же

Я их включить не могу, потому что число не используется, а volatile отключит любые оптимизации, даже если они включены глобально

я хз где число применить))

хотя можно сделать какой нибудь глупый syscall ради этого

типа DrawText с нуллптрами и этим числом. Тогда не уберет

щас даже сделаю

можно просто как код возврата из main

с приведением

вот скот, он на стадий компиляции все подсчитал!

Хмм

щас добавлю с другим числом. И другое число будет volatile

http://image.prntscr.com/image/d6e22e5d370a4e2d86cc083da18b7bb8.png

что за IDE ?

Visual Studio 2015 Community

хмм

с оптимизациями... чето жесткого, у мну мозг взорвался

чегой там в 13 лучше?

??!

почему 13, а не 12? в 12 вроде меньше дерьма.

эээ

мне 2015 нормально

у меня 2013 есть еще

точняк, но это скорее по необходимости

мне 2015 нормально

15 засрёт тебе весь код

в 2015 профайлер хороший. Особенно мне нравится что показывает время выполнения строчки кода в дебаге

15 засрёт тебе весь код

Примеры? У меня такого не было

кому как но в 15 более полная поддержка 11 стандарта

А я часто лезу в Disasm

кому как но в 15 более полная поддержка 11 стандарта

И 14 стандарта. И даже чуток нового

хотя не

вру

не весь 14 стандарт

пардон

14 там можно сказать тестовый

http://image.prntscr.com/image/20606eb4ac0c4fc5b980a7000af32184.png

Даже без adc смог. Кстати логично, ведь adc медленее чем add

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

Это кстати забавно видеть. Т.е. он понимает, что там все равно ждет конвертация из int64 в int32 и даже не пытается делать полную арифметику

А 2015 и 2013 студия генерит такой же код в целом. Хотя CRT у 2015 кое где сдобрили телеметрией, но это уже даже Microsoft вырезали

Если лезешь в дизасм компиль mingw

И всякого треша не будет

Изи

Если лезешь в дизасм компиль mingw

даже с оптимизацией?

Там же gcc, как хочешь, так и оптимизируй

Я неправильный разработчик

И делаю неправильные проги

gcc не юзаю

mingw не юзаю

от линукса держусь подальше, ибо неудобен

ERROR: S client not available

юзаю только IDE от Microsoft ну еще Notepad++

Непонятно как только никто меня еще не убил за это :D

А вообще я игры делаю

UE4, Unity все дела

Но и не брезгную низкоуровневым программированием

Там же gcc, как хочешь, так и оптимизируй

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

Да я про количество мусора от рантайма студии которая она пихает в каждую пешку

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

Ну или просто глянуть дизасемблированый код в студий прямо на месте

без всяких лишних компиляции

Но и не брезгную низкоуровневым программированием

Ну и зря. Современные компиляторы C++ оптимизируют намного лучше, чем хардкорный ассемблерщик с 20 летним стажем.

А я и не пишу на ассемблере

Под низкоуровневым программированием я подразумевал WinAPI и всякие платформозависимые фичи

Ассемблер кстати интересная штука

Что то пишут щас на нем крайне редко

но вот знать его - просто обязан

наверно потому что на нем что-то писать надо года два

щас даже всякие специфичные команды вроде cpuid - и то лучше писать на инстринктах

Что то пишут щас на нем крайне редко

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

наверно потому что на нем что-то писать надо года два

На самом деле писать ЧИСТО на ассемблере - это глупо. Раньше часто делали ассемблерские вставки для специфичных случаев

Написанная на ассемблере программа должна быть переписана практически с нуля на другую архитектуру. А на плюсах всё отлично пересоберётся под что угодно.

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

Даже не это является главной проблемой. Главная проблема - ассемблерские вставки в x64 запрещены, можно лишь ассемблерные obj файлы и все

а это неудобно

На самом деле писать ЧИСТО на ассемблере - это глупо. Раньше часто делали ассемблерские вставки для специфичных случаев

Раньше и не было такого зоопарка архитектур, как сейчас: x86, x86_64, MIPS, MIPSEL, ARMv6, ARMv7, AARCH64 и т.д.

Написанная на ассемблере программа должна быть переписана практически с нуля на другую архитектуру. А на плюсах всё отлично пересоберётся под что угодно.

1. Кроссплатформенность? Нахуй вашу кроссплатформенность :D . Хотя конечно с точки зрения бизнеса - не нахуй.... 2. Код нужно все равно править если собираешь под другую платформу. В 80% случаев с моей точки зрения

1. Кроссплатформенность? Нахуй вашу кроссплатформенность :D . Хотя конечно с точки зрения бизнеса - не нахуй.... 2. Код нужно все равно править если собираешь под другую платформу. В 80% случаев с моей точки зрения

Используй фреймворки, например Qt. И всё будет компилироваться хоть под десктоп, хоть под планшет без каких-либо правок вообще.

Используй фреймворки, например Qt. И всё будет компилироваться хоть под десктоп, хоть под планшет без каких-либо правок вообще.

Фреймворки имеют свой недостатки. Некоторые еще требуют лицензию и прочую херню

И QT мне не нравится

начиная от лицензии

заканчивая архитектурой