KP>Исхожу исключительно из своего опыта: 99% разработчиков, которых я могу действительно назвать стоящими имеют что показать.

У меня, напротив, несколько иной опыт: 99% тех, кто горд своими open source и прочими публичными проектами, в работе оказываются так себе. Потому что им, однако, интереснее продолжать пиарить свой open source и проекты.

Не претендую на всеобщность, просто такая подборка опыта вышла.

AS>Может я чего-то не понимаю, но ИМХО такие вещи надо делать генератором в ДКА. Описание в json/xml/yaml и генератор кода на питоне + утильный функционал писаный на кондовом С. И никаких радостей, всё скучно и однотипно.

Тогда это может даже и не на 2 дня быть, а больше. Особенно для тех, кто раньше не занимался подобным.

E__>В том-то и дело, что ТС этот вопрос ставит в один ряд с "переверните строку". А это умения и знания радикально разного уровня.

Собственно, об этом я и написал. Но ТС продолжил настаивать на своей версии "volatile нужен для того, чтобы писать в регистры устройств". Немного понимая подоплеку этого высказывания (embedded же), а также увидев цифры "40к. в месяц", можно сделать вывод — ищут недавнего студента, который в состоянии заучить несколько страниц из Страуструпа. И тестовое задание нужно ровно для того же, понять, способен ли претендент хоть что-то написать.

В таком варианте все встает на свои места. Первый же, кто такое собеседование пройдет, вполне удовлетворит компанию ТС, ибо им и не надо звезд с неба.

Здравствуйте, Eugeny__, Вы писали:

E>>- #define MAX(a,b) — как написать, чем чревато?

E__>Дефайны для всего, кроме констант — фтопку. Именно из-за вот таких возможных побочных эффектов.

для констант есть const/constexpr

Здравствуйте, enji, Вы писали:

H>>Ну понятно, что можно сделать 50 dynamic_cast и после удачного каста сделать delete. Ответ на 100% верный, но тот кто так делает страдает легким дебилизмом.
E>Вариант с dynamic_cast вообще не рабочий — надо в точке удаления знать все возможные типы и класс должен быть виртуальным.
E>Я вообще-то имел в виду boost::shared_ptr или просто хранить вместе с объектом "удалятель"

shared_ptr. В embedded? Мьсе знает толк.
Не говоря уже о том, что наличие shared_ptr эквивалентно знанию конкретного типа.

Здравствуйте, vshemm, Вы писали:

V>Не нужно особенности архитектуры выдавать за свойство volatile.

Если особенности архитектуры имеют место быть, они и являются свойством volatile.
Пусть и побочным, не относящимся к прямому назначению этого квалификатора и тому,
как его действие описано в стандарте. Я привел один из примеров для x86 — архитектуры, с
которой работаю 99.9% своего рабочего времени.

V>Барьера нет, если нужен именно такой порядок, следует вставить wmb. А уже его реализация для данной архитектуры
V>может быть пустой, что избавляет от оверхеда.

Здесь MSDN, в числе прочего, рассказывает про применение volatile и приводит пример его
использования (см. Fixing a Race Condition).
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686355(v=vs.85).aspx

With Visual Studio 2005, the compiler uses acquire semantics for read operations on volatile
variables and release semantics for write operations on volatile variables (when supported by the CPU).
Therefore, you can correct the example as follows:

И дальше исправленный код, где все исправление сводится к добавлению volatile.
И он будет работать корректно, без явных MemoryBarrier() или _mm_mfence().

А в соответствующем документе от Microsoft ("Multiprocessor Considerations for Kernel-Mode Drivers",
http://msdn.microsoft.com/en-us/library/windows/hardware/gg487433.aspx) про volatile написано следующее:

Microsoft CL 14.0.0 and later versions tighten the restrictions on the types of
reordering that can occur around volatile variables. In these compilers, reads
from volatile locations are treated as acquires and writes to volatile locations are
treated as releases on hardware architectures that support these semantics.

В обоих случаях отмечается, что эффект volatile зависит от CPU/архитектуры.
Что такое, по-Вашему, acquire и release semantics ?
Ответ здесь:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff540496(v=vs.85).aspx

An operation has acquire semantics if other processors will always see its effect before any
subsequent operation's effect. An operation has release semantics if other processors will
see every preceding operation's effect before the effect of the operation itself.

Подытоживая вышесказанное — на x86/amd64 чтение/запись из/в volatile ставит acquire/release барьер.
Что и было написано в моем исходном сообщении.

V>Уже говорил: слабый потому, что влияет только на volatile переменные. Все барьеры компилятора не влияют на
V>hardware reordering заранее известным способом, поэтому никаких предположений лучше не делать.

Да, для кросс-платформенной разработки это так. Там вообще используется std::atomic и остальное.

V>Пример кода вы привели сами — посмотрите на ассемблерный выхлоп, там не будет инструкций ни явно влияющих на
V>реордеринг (вроде mfence), ни влияющих неявно (вроде cmpxchg).

Что характерно для данной дискуссии — я нигде не утверждал иное.

V>Кстати, попробуйте написать лок Деккера с использованием только volatile или других барьеров компилятора — для
V>мультипроцессорных систем не получится, т.к. там понадобятся барьеры памяти, которые volatile не обеспечивает.

Насколько я помню, Деккер требует full memory barrier, который volatile, естественно, поставить не может.
Но в определенных случаях volatile можно использовать и это будет дешевле, чем звать lock или fence,
которая, если не ошибаюсь, и не на всех архитектурах-то поддерживается.

V>Например, линейка GeodeGX/LX/NX. Последний построен на базе атлона, поэтому, в отличие от первых двух, не
V>поддерживает store reordering.

Вот за это спасибо, не знал.

H>>2)
C>

H>>void reverse(char *string)
H>>{
H>>  char *p1= string;
H>>  char *p2 = string + strlen(string) -1 ;
H>>  while(p1<p2) {
C>

C>UB при пустой входной строке. Сравнение на больше/меньше указателей, не указывающих в один и тот же массив.

Неправда. strlen гарантирует что нулей между поинтерами нет.

Здравствуйте, StanislavK, Вы писали:

SK>Давайте проясним один вопрос. У меня сложилось впечатление, что все что вы пишете относится исключительно к случаю "Windows + майкросовтовской компилятор + x86". Я правильно понял?

Я стараюсь всегда отмечать, что речь идет про конкретную архитектуру, за исключением форумов,
где это подразумевается по умолчанию (например, в "WIN API").

Здравствуйте, Handie, Вы писали:

H>>>2)

H>>>void reverse(char *string)
H>>>{
H>>>  char *p1= string;
H>>>  char *p2 = string + strlen(string) -1 ;
H>>>  while(p1<p2) {

C>>UB при пустой входной строке. Сравнение на больше/меньше указателей, не указывающих в один и тот же массив.

H>Неправда. strlen гарантирует что нулей между поинтерами нет.

Каких таких нулей? strlen возвращает 0, после чего p2 указывает на один байт левее, чем p1. Формально это уже UB. Фактически проблема проявится, если нам посчастливилось исполняться на архитектуре, где нулевой адрес доступен для пользовательских программ и входная строка как раз окажется там; или же в случае, если арифметика адресов знаковая и входная строка оказалась по адресу -2^(n-1), где n — разрядность адресов.

Здравствуйте, enji, Вы писали:

Так С или C++?

E>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
E>И оценить как работу проги (написать простой автотестер, который скормит кривые пакеты, случайный мусор, а также правильные команды и посмотрит на ответы), так и исходный код, наличие тестов, сборочного скрипта, репозитария dvcs
Лучше напиши немног оговнокода и попроси исправить и отформатировать на ноуте.

E>Покритикуйте, плиз.
Домашние задания в топку.

Здравствуйте, okman, Вы писали:

O>Здравствуйте, StanislavK, Вы писали:

SK>>Давайте проясним один вопрос. У меня сложилось впечатление, что все что вы пишете относится исключительно к случаю "Windows + майкросовтовской компилятор + x86". Я правильно понял?
O>Я стараюсь всегда отмечать, что речь идет про конкретную архитектуру, за исключением форумов,
O>где это подразумевается по умолчанию (например, в "WIN API").
Ну и что именно вы тут отметили? "Windows + майкросовтовской компилятор + x86" или нет?
Даже если предположить, что вы имели ввиду это связку. Не понятно почему вы упоминаете барьеры без оговорок. В 2005 студии там да, все так как вы описали (http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.80).aspx):

Objects declared as volatile are not used in certain optimizations because their values can change at any time. The system always reads the current value of a volatile object at the point it is requested, even if a previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment.

Also, when optimizing, the compiler must maintain ordering among references to volatile objects as well as references to other global objects. In particular,

A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.

A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.

This allows volatile objects to be used for memory locks and releases in multithreaded applications.

Однако, в статье за 2012 уже все нескольно иначе (http://msdn.microsoft.com/en-us/library/12a04hfd.aspx). Подобное поведение сохранятся по-умолчанию (причем только на x86), но так же появляется совместимое с ISO, которое уже, как я понимаю, не подразумевает барьеров.

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, sysenter, Вы писали:

S>>Это если есть открытые исходники.

KP>Ну... Не хочу никого обидеть, но я не могу считать разработчика хорошим/стоящим разработчиком, если ему нечего показать в той или иной форме, будь то открытый код, профильные заметки, участие в публичном проекте, собственный проект в AppStore и т.п. Это довольно дико, на мой взгляд.
Не у всех людей есть желание публичного признания или пиара через yoba приложение в аппстор.

C>Каких таких нулей? strlen возвращает 0, после чего p2 указывает на один байт левее, чем p1. Формально это уже UB. Фактически проблема проявится, если нам посчастливилось исполняться на архитектуре, где нулевой адрес доступен для пользовательских программ и входная строка как раз окажется там; или же в случае, если арифметика адресов знаковая и входная строка оказалась по адресу -2^(n-1), где n — разрядность адресов.

Смотрите внимательней. Разыменование указателей идет только тогда, когда p1<p2. По нулевому адресу адрес располагаться не может, в C++ ясно прописано что (void*)0 не может ссылаться на объект. -2^(n-1) это нечто за гранью фантастики — никогда не видел поинтеров типа 0xFFFFFFFF.

Здравствуйте, Handie, Вы писали:

...

как минимум смотри в тело цикла — там уже косяк

Здравствуйте, StanislavK, Вы писали:

SK>Ну и что именно вы тут отметили? "Windows + майкросовтовской компилятор + x86" или нет?
SK>Даже если предположить, что вы имели ввиду это связку. Не понятно почему вы упоминаете барьеры без оговорок.

Виноват.
Все написанное относится к Windows-x86/x64, компилятор Visual C/C++ 2005 и выше.

SK>В 2005 студии там да, все так как вы описали (http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.80).aspx).
SK>Однако, в статье за 2012 уже все нескольно иначе (http://msdn.microsoft.com/en-us/library/12a04hfd.aspx). Подобное поведение сохранятся по-умолчанию (причем только на x86), но так же появляется совместимое с ISO, которое уже, как я понимаю, не подразумевает барьеров.

Как я понимаю, /volatile:iso — опция исключительно для ARM-ов, а программы для x86/x64 должны
поддерживать совместимость с существующими функциями вроде _InterlockedIncrement, которые
тоже "завязаны" на volatile. Поэтому трудно представить, что Visual C++ 2012, да и вообще
любой Windows-совместимый компилятор, использующий заголовки из SDK/Visual Studio, имел бы
иное поведение volatile. Видимо поэтому /volatile:ms для данных архитектур стоит по умолчанию.
Но это так, рассуждения вслух.

P>как минимум смотри в тело цикла — там уже косяк

Косяк и опечатка — несколько разные вещи.

Здравствуйте, okman, Вы писали:

O>Здравствуйте, vshemm, Вы писали:

V>>Не нужно особенности архитектуры выдавать за свойство volatile.

O>Если особенности архитектуры имеют место быть, они и являются свойством volatile.
O>Пусть и побочным, не относящимся к прямому назначению этого квалификатора и тому,
O>как его действие описано в стандарте. Я привел один из примеров для x86 — архитектуры, с
O>которой работаю 99.9% своего рабочего времени.

Стандарт языка не привязан к архитектуре, и полагаться на подобные особенности, — значит, получить грабли в дальнейшем.

O>В обоих случаях отмечается, что эффект volatile зависит от CPU/архитектуры.
O>Что такое, по-Вашему, acquire и release semantics ?
O>Ответ здесь:
O>http://msdn.microsoft.com/en-us/library/windows/hardware/ff540496(v=vs.85).aspx
O>

O>An operation has acquire semantics if other processors will always see its effect before any
O>subsequent operation's effect. An operation has release semantics if other processors will
O>see every preceding operation's effect before the effect of the operation itself.

O>Подытоживая вышесказанное — на x86/amd64 чтение/запись из/в volatile ставит acquire/release барьер.
O>Что и было написано в моем исходном сообщении.

Хмм, читаем внимательно: http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.80).aspx

A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.

A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.

Т.е. речь идет о acquire и release semantics применительно к кодогенерации, а не ко времени исполнения.
Это и есть барьеры компилятора, а не барьеры памяти.
И как быть с SSE инструкциями с memory-relaxed model тоже непонятно из документации.

А вот GCC выдвигает более строгие требования:
http://gcc.gnu.org/onlinedocs/gcc/Volatiles.html

Accesses to non-volatile objects are not ordered with respect to volatile accesses. You cannot use a volatile object as a memory barrier to order a sequence of writes to non-volatile memory.

Вот на это поведение и нужно рассчитывать, имхо.

V>>Пример кода вы привели сами — посмотрите на ассемблерный выхлоп, там не будет инструкций ни явно влияющих на
V>>реордеринг (вроде mfence), ни влияющих неявно (вроде cmpxchg).

O>Что характерно для данной дискуссии — я нигде не утверждал иное.

Так что же из этого следует?

V>>Кстати, попробуйте написать лок Деккера с использованием только volatile или других барьеров компилятора — для
V>>мультипроцессорных систем не получится, т.к. там понадобятся барьеры памяти, которые volatile не обеспечивает.

O>Насколько я помню, Деккер требует full memory barrier, который volatile, естественно, поставить не может.
O>Но в определенных случаях volatile можно использовать и это будет дешевле, чем звать lock или fence,
O>которая, если не ошибаюсь, и не на всех архитектурах-то поддерживается.

Думаю, что на "железных" acquire и release это сделать тоже можно. Правда, в х86 для них специальных инструкций нет.

Есть мнение, что для синхронизационных задач volatile вообще не нужен (ну, кроме триков а-ля Александреску, но
там модификатор используется для других целей).

Здравствуйте, Handie, Вы писали:

C>>Каких таких нулей? strlen возвращает 0, после чего p2 указывает на один байт левее, чем p1. Формально это уже UB. Фактически проблема проявится, если нам посчастливилось исполняться на архитектуре, где нулевой адрес доступен для пользовательских программ и входная строка как раз окажется там; или же в случае, если арифметика адресов знаковая и входная строка оказалась по адресу -2^(n-1), где n — разрядность адресов.

H>Смотрите внимательней. Разыменование указателей идет только тогда, когда p1<p2.

Да фу, мне что, Священный Стандарт цитировать?

5.7 Additive operators [expr.add]

5: When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integral expression. In other words, if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i + n-th and i − n-th elements of the array object, provided they exist. Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

То есть даже не сравнение p1 < p2, а уже само формирование p2 = "" + 0 — 1 даёт UB. О разыменовании указателей в никуда я не говорю — его тут действительно нет (кроме того патологического случая, когда "" == reinterpret_cast<char*>(0)).

H>По нулевому адресу адрес располагаться не может, в C++ ясно прописано что (void*)0 не может ссылаться на объект.

Нулевой указатель не обязан быть побитово равен нулю, он может быть произвольным битовым паттерном. Если наша реализация представляет нулевой указатель как 0xDEADBEEF0FC0FFEE, то reinterpret_cast<char*>(0) потенциально может указывать на реальный объект.

Здравствуйте, Abyx, Вы писали:

E>>>- #define MAX(a,b) — как написать, чем чревато?

E__>>Дефайны для всего, кроме констант — фтопку. Именно из-за вот таких возможных побочных эффектов.

A>для констант есть const/constexpr

Тем более.
У меня имеется опыт разбора чужого кода с хитровывернутыми дефайнами. Нафиг-нафиг.

Здравствуйте, vshemm, Вы писали:

V>Стандарт языка не привязан к архитектуре, и полагаться на подобные особенности, — значит, получить грабли в дальнейшем.

Не всякая программа, особенно завязанная на многопоточность, может быть написана исключительно
стандартными средствами. std::atomic не всемогущ. К тому же, он только в C++11.
Тогда и _mm_mfence нестандартен, и InterlockedIncrement, и еще куча всего.

V>Хмм, читаем внимательно: http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.80).aspx
V>

V>A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.

V>A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.

V>Т.е. речь идет о acquire и release semantics применительно к кодогенерации, а не ко времени исполнения.
V>Это и есть барьеры компилятора, а не барьеры памяти.

А Вы заметили, что в обоих топиках, ссылки на которые я давал выше, были явно
упомянуты CPU и architecture ?

Да вот еще.
http://blogs.msdn.com/b/kangsu/archive/2007/07/16/volatile-acquire-release-memory-fences-and-vc2005.aspx
http://social.msdn.microsoft.com/Forums/en/csharplanguage/thread/eb80048a-e74f-42b8-8cd9-4436c6f4ce1f
http://blogs.msdn.com/b/oldnewthing/archive/2008/10/03/8969397.aspx

V>>>Пример кода вы привели сами — посмотрите на ассемблерный выхлоп, там не будет инструкций ни явно влияющих на
V>>>реордеринг (вроде mfence), ни влияющих неявно (вроде cmpxchg).

O>>Что характерно для данной дискуссии — я нигде не утверждал иное.

V>Так что же из этого следует?

Что мне не удалось Вас убедить.


V>Есть мнение, что для синхронизационных задач volatile вообще не нужен (ну, кроме триков а-ля Александреску, но
V>там модификатор используется для других целей).

Да, я встречал это мнение раньше.
Вот, например, была здесь такая тема несколько лет назад — http://www.rsdn.ru/forum/cpp/978815.flat.aspx

Автор: Vet
Дата: 09.01.05

Там тоже все остались при своем мнении.