Так что тут нужно стараться в язык добавлять только самые необходимые вещи
Так самые необходимые вещи, это как известно, операции "сдвиг влево/вправо" и "чтение/запись в ячейку".
По RAII просто почитайте в той же Вики, что это за подход.
Да я уж прочел. Только "проходной" блок finally используется не только для осовобождения ресурсов. Нет так нет, я просто поинтересовался у знающих плюсы.
Извините за немного сторонний вопрос: В новейших стандартах C++ реализовали ли properties для объектов?
Есть ли обязательный блок (по типу finally в некоторых языках) для исключений?
А вот это уже неожиданно. Обычно же "родные" команды короче, а под чужую разрядность — с префиксом. Не приходилось писать на асм под x86-64, но под x86/IA32 писал очень много. Пришла пора подтянуться и попрактиковаться. Вот так один дилетантский вопрос может сподвигнуть к практике.
Нет. Вы написали "утверждать, что перрон вечен и непреложен (=никогда не уйдет) — это очень смело" как контр-аргумент, будто бы ваш оппонент это утверждал ("утверждать...- очень смело"), тогда как утверждения о вечности с его стороны не было. Это выдуманный абсурдный и разоблаченный аргумент.
За сим откланяюсь — это очень скучная перепалка о словах, не привносящая ничего нового.
Лучше на англоязычных сайтах. Malware analysis. Читать, читать, читать. Еще wasm.ru и osdev. Тогда не будет таких… детских статей.
Любой порядочный антивирус посчитает подозрительным выделение памяти с RWE одним махом.
Значит, компилятор имеет полное право разместить переменную в 64 битном регистре, поскольку старшие биты не будут иметь значения в случае хранения 32 битного значения.
Верно. Почему разместив 32 битную переменную в младшей части, код производит вычисления с 64 битной переменной, невзирая на мусор в старшей части?
Комментарий, на который я отвечал, именно это и утверждал:
Нет, не утверждал. "остается" не значит "остается навсегда". Речь шла о том, что технологии и связанные с ними практические навыки меняются много чаще и быстрее, чем теория. Остается пока не открыто что-то новое, более точное. Вот вы едете в поезде, он стоит у перрона, за окном — человек. Поезд тронулся, мы говорим, что люди мимо окна проплывают и "уходят" один за одним, а перрон остается. Это не значит, что перрон будет тянуться за окном вечно, это всего лишь сравнение мимолетности появления людей и перрона.
Вы же подменили это контрастное "остается" на
считать её вечной и непреложной — это очень смело.
Раздел 2.3, где описаны спинлоки, называется «Взаимодействие процессов»… При чтении у меня складывается впечатление, что все описанные вещи — примитивы синхронизации, но в разных системах и на разных уровнях примитивами являются те или иные объекты, над которыми уже достраивается остальное
Это и так и не так. Мы сталкиваемся здесь с трудностями перевода. Дело в том, что в оригинале, в англоязычном издании, данный раздел называется Interprocess Communication. И в предисловии вы можете увидеть рассуждение о том, что communication, собственно, состоит из разных частей/проблем: как передать само сообщение физически от процесса к процессу (т.е. всякие send/receive message, доступ к address space другого процесса и т.п.), как обеспечить синхронизацию и еще один пункт.
Поэтому весь раздел в целом говорит о communication, а синхронизация, которую мы обсуждаем — только один из его аспектов. Как я назвал выше — реализация, деталь реализации.
Почему вы называете мьютекс примитивом, если он прекрасно определяется через семафор?
Да, логически можно определить мьютекс как частный случай семафора. Но изначально они введены в разное время для разных задач (producer/consumer для семафора, с множественными записью/чтением и просто разделяемый ресурс для мьютекса), к тому же мьютекс используется много чаще. Скажем так, это настолько часто используемая и важная вариация семафора, что выделяется как отдельный вид.
Кстати, в свете разговора выше о спинлоке и мьютексе: забавно, что у того же Танненбаума по этому поводу сказано:
They are(мьютексы)
easy and efficient to implement, which makes them especially useful in thread
packages that are implemented entirely in user space.
Because mutexes are so simple, they can easily be implemented in user space
proVided that a TSL or XCHG instruction is available. The code for mutex lock and
mutex_unlock for use with a user-level threads package are shown in Fig. 2-29.
The solution with XCHG is essentially the same.
mutex_lock:
TSL REGISTER,MUTEX
CMP REGISTER,#O
JZE ok
CALL thread_yield
JMP mutex_lock
ok: RET
mulex_unlock:
MOVE MUTEX,#O
RET
Figure 2·29. Implementation of mutex_lock and mutex_unlock
Вот тебе и "мьютекс или спинлок" и "каноничная реализация мьютекса".
я бы предложил взять такой критерий как прибыль с разработчика
Совершенно абстрактно: берем двух людей, один выдает кое-как работающий, нерасширяемый продукт за 1 единицу времени, второй — за 2, но надежный и расширяемый. Зарплата второго выше — выше ведь его квалификация, а вот прибыль выше с первого. Пока выше с первого, потому что его продукт можно уже продать, а ему заплатить пол-копейки. А что будет завтра, когда его продукт будет взломан? Потеряет пользовательские данные?
чтобы было у кого поучиться
Это, конечно, здорово. Но может быть следствием того, что все остальные, кто будут учиться у N — вообще профнепригодные дятлы.
чтоб мозг не сношал пустиками
"Не сношать моз пустяками" как-то не поддается формализации.
чтоб его код не пришлось переделывать
Это уже лучше. Не кажется ли вам, что переделывать чей-то код придется реже, если этот кто-то обладает знаниями и изначально принимает более правильные решения? По применению алгоритмов или структур данных, прости господи, в частности.
Сколько ей лет — неважно. Научный метод же — пока не опровергли, придумали что-то новое, включающее старое, как частный случай, — используется.
Может статься, все сегодняшние знания
Дальше можно не конкретизировать. Это очень, до боли, напоминает реплики приверженцев альтернативной науки — "мы еще мало знаем, очень может статься, что в будущем мы откроем новое, и закон сохранения энергии не будет работать, и повсюду будут вечные двигатели".
Ветряная мельница: создаем чучело (будто бы кто-то утверждает, что нечто — вечная истина и всегда, отныне и вовек будет верным), а потом смело разоблачаем.
Но что тогда мешает утверждать, что умение работать с указателями/памятью/подставьте сами также является необходимым, чтобы называться программистом с большой буквы.
Никто. Более того, это так и есть, если речь идет о низкоуровневом (условно) программировании. С алгоритмами другая история — их придется использовать и при написании ОС или драйверов, так и при написании какого-нибудь высокоуровневого пакета.
не к одним алгоритмам сводится минимальный набор знаний, навыков и паттернов мышления.
Это то же самое: "не к одним" — отрицание достаточности условия. Об этом речи и не шло.
Тема алгоритмов, поднятая (в последний раз, недавно) статей "нужно ли программистам знание алгоритмов" говорит о знании а. как о необходимом условии. Эта же статья:
Я утверждаю, что знание алгоритмов и даже наличие системного образования не делает вас хорошим разработчиком
говорит о том, что знание а. не является достаточным. Это не контр-аргумент и не опровержение.
Весь спор шел как раз о том, необходимо ли знание алгоритмов. А уж "знания теории без практики мало для реальной работы" (данная статья об этом) — просто трюизм.
Как и RTTI и куча других вещей, ну да ладно.
Так самые необходимые вещи, это как известно, операции "сдвиг влево/вправо" и "чтение/запись в ячейку".
Да я уж прочел. Только "проходной" блок finally используется не только для осовобождения ресурсов. Нет так нет, я просто поинтересовался у знающих плюсы.
Все суть синтаксический сахар, кроме машинного кода — начиная от if then else. Однако, удобно.
То-есть, нет. Спасибо. Я, конечно, посмотрю, но почему именно в С++ не нужно? Я ж не срача ради, а познания для.
Нет, я вижу сбоящую игру на CGA.
Есть ли обязательный блок (по типу finally в некоторых языках) для исключений?
Не знал, спасибо за разъяснение.
За сим откланяюсь — это очень скучная перепалка о словах, не привносящая ничего нового.
Любой порядочный антивирус посчитает подозрительным выделение памяти с RWE одним махом.
Верно. Почему разместив 32 битную переменную в младшей части, код производит вычисления с 64 битной переменной, невзирая на мусор в старшей части?
Или автор статьи не разместил этот кусок инициализации и старшая часть rcx сбрасывается где-то раньше?
Нет, не утверждал. "остается" не значит "остается навсегда". Речь шла о том, что технологии и связанные с ними практические навыки меняются много чаще и быстрее, чем теория. Остается пока не открыто что-то новое, более точное. Вот вы едете в поезде, он стоит у перрона, за окном — человек. Поезд тронулся, мы говорим, что люди мимо окна проплывают и "уходят" один за одним, а перрон остается. Это не значит, что перрон будет тянуться за окном вечно, это всего лишь сравнение мимолетности появления людей и перрона.
Вы же подменили это контрастное "остается" на
Это и так и не так. Мы сталкиваемся здесь с трудностями перевода. Дело в том, что в оригинале, в англоязычном издании, данный раздел называется Interprocess Communication. И в предисловии вы можете увидеть рассуждение о том, что communication, собственно, состоит из разных частей/проблем: как передать само сообщение физически от процесса к процессу (т.е. всякие send/receive message, доступ к address space другого процесса и т.п.), как обеспечить синхронизацию и еще один пункт.
Поэтому весь раздел в целом говорит о communication, а синхронизация, которую мы обсуждаем — только один из его аспектов. Как я назвал выше — реализация, деталь реализации.
Да, логически можно определить мьютекс как частный случай семафора. Но изначально они введены в разное время для разных задач (producer/consumer для семафора, с множественными записью/чтением и просто разделяемый ресурс для мьютекса), к тому же мьютекс используется много чаще. Скажем так, это настолько часто используемая и важная вариация семафора, что выделяется как отдельный вид.
Кстати, в свете разговора выше о спинлоке и мьютексе: забавно, что у того же Танненбаума по этому поводу сказано:
Вот тебе и "мьютекс или спинлок" и "каноничная реализация мьютекса".
Совершенно абстрактно: берем двух людей, один выдает кое-как работающий, нерасширяемый продукт за 1 единицу времени, второй — за 2, но надежный и расширяемый. Зарплата второго выше — выше ведь его квалификация, а вот прибыль выше с первого. Пока выше с первого, потому что его продукт можно уже продать, а ему заплатить пол-копейки. А что будет завтра, когда его продукт будет взломан? Потеряет пользовательские данные?
Это, конечно, здорово. Но может быть следствием того, что все остальные, кто будут учиться у N — вообще профнепригодные дятлы.
"Не сношать моз пустяками" как-то не поддается формализации.
Это уже лучше. Не кажется ли вам, что переделывать чей-то код придется реже, если этот кто-то обладает знаниями и изначально принимает более правильные решения? По применению алгоритмов или структур данных, прости господи, в частности.
Это не показатель — мы же о разработке ПО, а не о фондовых рынках или зарабатывании денег.
Про миры я отметил, чтобы напомнить о том, что критерии необходимх навыков зависят от отрасли/подотрасли, где занят человек.
Дальше можно не конкретизировать. Это очень, до боли, напоминает реплики приверженцев альтернативной науки — "мы еще мало знаем, очень может статься, что в будущем мы откроем новое, и закон сохранения энергии не будет работать, и повсюду будут вечные двигатели".
Ветряная мельница: создаем чучело (будто бы кто-то утверждает, что нечто — вечная истина и всегда, отныне и вовек будет верным), а потом смело разоблачаем.
Во-первых, "пять миров Спольски".
Во-вторых, как мы определим вот это "неплохой"? Каковы формальные критерии?
Никто. Более того, это так и есть, если речь идет о низкоуровневом (условно) программировании. С алгоритмами другая история — их придется использовать и при написании ОС или драйверов, так и при написании какого-нибудь высокоуровневого пакета.
Это то же самое: "не к одним" — отрицание достаточности условия. Об этом речи и не шло.
говорит о том, что знание а. не является достаточным. Это не контр-аргумент и не опровержение.
Весь спор шел как раз о том, необходимо ли знание алгоритмов. А уж "знания теории без практики мало для реальной работы" (данная статья об этом) — просто трюизм.