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

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

VE>>Достаточно нуля проблем. Я свою точку зрения доказал. Гнать надо вас в шею за такой код.
CC>А ты, VoidEx, откуда вдруг нарисовался?
CC>И какую это ты точку зрения доказал?
CC>А не виртуал ли ты, мил человек?
CC>Твой второй логин на RSDN часом не criosray?

Нет, мой второй логин thesz

Автор: Andrei F.
Дата: 07.07.09

.
Вроде писал прямо цитатами, а всё равно видимо непонятно, что это сарказм. По крайней мере двоим.

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

VE>Нет, мой второй логин thesz

Автор: Andrei F.
Дата: 07.07.09

.
[записывает в секретный блокнот]

VE>Вроде писал прямо цитатами, а всё равно видимо непонятно, что это сарказм. По крайней мере двоим.
Для цитат тэг [ q ] придуман
Или в кавычки берут

О чем и речь. Неумение пользоваться инструментом.

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

CC>Лично мне например нравится такой стиль:
CC>

CC>TreeNode *node = root.GetNode ("Foo");
CC>if (node)
CC>{
CC>}

CC>node = root.GetNode ("Bar");
CC>if (node)
CC>{
CC>}
CC>

Этот код хоть и немного лучше оригинала, но все-равно откровенно плох. Выражение if подразумевает логическое, а не целочисленное значение. Да, когда-то в С (без плюсов) не было типа boolean, потому логические правду и ложь представляли в виде целочисленных 1 и 0. В С++ для совместимости с С это оставили, хотя и ввели наконец полноценный тип bool. Вышеприведенный код это гремучая смесь из С и С++. Все тот же индусокод.

CC>Да, лично я предпочитаю не писать присвоение в условии. Но это вопрос стиля, мне так больше нравится.
CC>Но и не считаю что присвоение в условии неправильно.

CC>Зелёному новичку разумеется надо вбить в голову что присвоение в условии это полный капец и так делать нельзя. Во избежание. Ибо сдуру и по неопытности он наворотит говнокода.
CC>Когда подрастёт — можно объяснить что иногда на самом деле так делать всё таки можно.
CC>Впрочем когда подрастёт — сам должен понять.
Когда действительно подрастет, то поймет почему ТАК писать нельзя.

TreeNode *node = root.GetNode("Foo");
if (node != NULL)
{
}

node = root.GetNode("Bar");
if (node != NULL)
{
}

Ага. И вместо

 //Handle user input. 0 - quit, 1, 2, 3, 4  - do different stuff
 while (i = get_user_input()) {
    process_action(i);
 }

городить что?

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

V>Ага. И вместо


V>

V> //Handle user input. 0 - quit, 1, 2, 3, 4  - do different stuff
V> while (i = get_user_input()) {
V>    process_action(i);
V> }
V>

V>городить что?
while — не if, но и в этом случае гораздо правильнее будет:

 //Handle user input. 0 - quit, 1, 2, 3, 4  - do different stuff
 while ((i = get_user_input()) != NULL) {
    process_action(i);
 }

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

V>>городить что?
C>while — не if, но и в этом случае гораздо правильнее будет:

C>

C> //Handle user input. 0 - quit, 1, 2, 3, 4  - do different stuff
C> while ((i = get_user_input()) != NULL) {
C>    process_action(i);
C> }
C>

Ну что за непоследовательность?! В деле Правильного Кода полутона недопустимы:

for(int i = get_user_input(); NULL != i; i = get_user_input()){...}

И да восславится Правильный Код!

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

G>Вроде существуют способы сделать 100% транзакционность в распределенной среде.

Нет.

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


KV>Ой, а можно с контр-аналогией встряну? Спасибо.

KV>Когда в ПДД, водителей мотоциклов обязали едить в шлеме, травматизм в стране резко вырос. Стали разбираться че за фигня. И вопреки очевидному мнению, что люди стали ездить небрежнее, чувствуя себя в большей защищенности, выяснилась несколько другая вещь. Травматизм действительно вырос, т.к. раньше люди тупо убивались насмерть и портили статистику моргам, а не отделениям травматологии.

KV>"Так-то" (с)

Хм... А я слышал эту байку только в варианте про первую мировую и стальные шлемы пехотинцев...

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

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

C>>>>>>Я-то прекрасно знаю, как работает оператор присваивания и конструкция if — именно потому и говорю. В 9 из 10 случаев в С/С++ исходниках можно увидеть if (NULL == something) {} вместо if (something == NULL) {}. Это наверно от хорошей жизни, да?
V>>>>>За 11 лет — видел только в индусских рекомендациях. Это от индуизма.
M_>>>>а вот тут не согласен: расположение константы впереди защищает от описки, которую не сразу и заметишь.
CC>>>От описки защищает правильно настроенные опции компилятора
M_>>в смысле, очередной варнинг? Или запрет присвоения в условии?
M_>>Если ты про варнинг, то.... В нашем проекте этих варнингов столько, что новые часто не замечаются. Мозилла вся насквозь пропитана варнинговым кодом. Поэтому предупреждение — не выход.
CC>Ну, по хорошему в проекте должно стоять "Treat warning as error".


CC>Что в общем то сразу отбивает охоту писать присвоения в if Так что проблема решается как бы сама собой.
ага... и превращает опенсорц код в нечто неюзабельное
для примера попробуй взять мозиллу тандерберд 2 и собрать с этой опцией.... Сумеешь — памятник тебе поставлю!

На самом деле не смешно нифига... Было уже пару раз, что пропускал серьезный варнинг в этой куче предупреждений от любого хедера мозиллы.... А ничего не поделаешь, там вся идеология такая, что волосы дыбом встают

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

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

CC>Лично мне например нравится такой стиль:
CC>

CC>TreeNode *node = root.GetNode ("Foo");
CC>if (node)
CC>{
CC>}

CC>node = root.GetNode ("Bar");
CC>if (node)
CC>{
CC>}
CC>

не нравится количество повторяющихся строк. Ибо это — неизбужный копипаст. А в копипасте главное — меньший объем, чтобы увереннее его проверить.

CC>Да, лично я предпочитаю не писать присвоение в условии. Но это вопрос стиля, мне так больше нравится.
CC>Но и не считаю что присвоение в условии неправильно.
Разрешено синтаксисом языка, значит может применяться.

CC>Зелёному новичку разумеется надо вбить в голову что присвоение в условии это полный капец и так делать нельзя. Во избежание. Ибо сдуру и по неопытности он наворотит говнокода.
CC>Когда подрастёт — можно объяснить что иногда на самом деле так делать всё таки можно.
CC>Впрочем когда подрастёт — сам должен понять.
Гм. Это смотря как вбить. Новичок после этого может и не развиться, останется в этих рамках, даже не умея объяснить, что здесь неправильно. Ибо это как правило "не выходи на улицу без шапки — сонлнце голову напечет"...

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

CC>>Что в общем то сразу отбивает охоту писать присвоения в if Так что проблема решается как бы сама собой.
M_>ага... и превращает опенсорц код в нечто неюзабельное
Это только в минус опенсорц коду.

M_>для примера попробуй взять мозиллу тандерберд 2 и собрать с этой опцией.... Сумеешь — памятник тебе поставлю!
Дык сразу писать надо ровными ручками а не как попало.

M_>На самом деле не смешно нифига... Было уже пару раз, что пропускал серьезный варнинг в этой куче предупреждений от любого хедера мозиллы.... А ничего не поделаешь, там вся идеология такая, что волосы дыбом встают
Идеология значит неправильная.
В нормальном проекте варнингов быть не должно.
Если варнинг все же не существенен но не лечится — тогда его локально давят с комментом почему задавили

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

M_>не нравится количество повторяющихся строк. Ибо это — неизбужный копипаст. А в копипасте главное — меньший объем, чтобы увереннее его проверить.
Зато строки проще. Да и в конкретном случае это несущественно.

CC>>Но и не считаю что присвоение в условии неправильно.
M_>Разрешено синтаксисом языка, значит может применяться.
Именно

M_>Гм. Это смотря как вбить. Новичок после этого может и не развиться, останется в этих рамках, даже не умея объяснить, что здесь неправильно. Ибо это как правило "не выходи на улицу без шапки — сонлнце голову напечет"...
А это уже зависит от интеллекта новичка. Если развиться не сможет, значит пусть хоть через табу будет убережён от тупых ошибок.
Ты вспомни как даётся та же химия в школе и в универе: в школе все на очень простой модели, в универе: "забудьте все чему вас учили в школе" и пошли рассказывать как оно на самом деле работает.

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

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

G>>Вроде существуют способы сделать 100% транзакционность в распределенной среде.

DOO>Нет.

Дальше википедии читать не умеем?

Эта задача решается доверенным надежным посредником (координатором).

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

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

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

G>>>Вроде существуют способы сделать 100% транзакционность в распределенной среде.

DOO>>Нет.

G>Дальше википедии читать не умеем?
Умеем. Если я привел ссылку на википедию это не значит, что я только ее там прочитал. Задача упомянута в книге Танненбаума "Компьютерные сети", если что.

G>Эта задача решается доверенным надежным посредником (координатором).
Во-первых, это будет уже другая задача.
Во-вторых, у тебя возникает та же самая задача при общении с твоим надежным посредником.

Поэтому, если ты считаешь, что решение есть — приведи хоть какое-то его описание — посмотрим, что же оно решает на самом деле.

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

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

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

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

G>>>>Вроде существуют способы сделать 100% транзакционность в распределенной среде.

DOO>>>Нет.

G>>Дальше википедии читать не умеем?
DOO>Умеем. Если я привел ссылку на википедию это не значит, что я только ее там прочитал. Задача упомянута в книге Танненбаума "Компьютерные сети", если что.

G>>Эта задача решается доверенным надежным посредником (координатором).
DOO>Во-первых, это будет уже другая задача.
Читай до просветления "Вроде существуют способы сделать 100% транзакционность в распределенной среде."

DOO>Во-вторых, у тебя возникает та же самая задача при общении с твоим надежным посредником.
Читай выделенное до просветления "Эта задача решается доверенным надежным посредником".

DOO>Поэтому, если ты считаешь, что решение есть — приведи хоть какое-то его описание — посмотрим, что же оно решает на самом деле.
WS-Atomic, MS DTC.

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

G>Читай выделенное до просветления "Эта задача решается доверенным надежным посредником".

Напомнило анекдот "Фы меня фигней не грузите, я стратегией занимаюсь". Как обеспечить НАДЕЖНОГО посредника в случае распределенной системы?

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

G>>>Эта задача решается доверенным надежным посредником (координатором).
DOO>>Во-первых, это будет уже другая задача.
G>Читай до просветления "Вроде существуют способы сделать 100% транзакционность в распределенной среде."
Дальше что?

Прагматичный подход к решению задачи предполагает не полное устранение ненадежности канала, а её сведение к допустимому уровню.

DOO>>Во-вторых, у тебя возникает та же самая задача при общении с твоим надежным посредником.
G>Читай выделенное до просветления "Эта задача решается доверенным надежным посредником".
Не наступает просветления — у нас канал ненадежен. Посредник может хоть мамой клясться, но на канал он не влияет.

DOO>>Поэтому, если ты считаешь, что решение есть — приведи хоть какое-то его описание — посмотрим, что же оно решает на самом деле.
G>WS-Atomic, MS DTC.
Это описание? По-моему, это названия конкретных систем, реализующих очень простой и примитивный механизм: есть кто-то, кто дает отмашку — причем непонятно, получили ли эту отмашку все участники. Вся их надежность заключается в том, что они ничего не забывают — т.е. рано или поздно ситуация придет в норму. Но в промежуток — все плохо.


Ситуация с банкоматом:
банкомат и сервер должны совместно выполнить транзакцию по списыванию и выдаче денег. Пусть ее ведет твой надежный координатор. Типа того же DTC.
Банкомат и сервер подтвердили готовность. Координатор дал отмашку. Банкомат выдал деньги и тут упала сеть. Что делать? Координатор не знает получена ли его отмашка банкоматом — т.е. он не знает выданы деньги или нет. То, что система придет в нормальное состояние, когда сеть восстановится — я понимаю, но в промежуток ничего не понятно — если ты транзакцию откатишь, а банкомат деньги выдал, то пользователь снимет те же самые деньги в соседнем банкомате, если ты транзакцию подтвердишь, а банкомат денег не выдал, то ты спишешь деньги со счета пользователя и он не сможет их взять в другом банкомате. Если ты будешь ждать и на это время заморозишь операции со счетом — то пользователь тебе придет бить морду.

Вот такие они "надежные" распределенные транзакции.

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

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

G>>>>Эта задача решается доверенным надежным посредником (координатором).
DOO>>>Во-первых, это будет уже другая задача.
G>>Читай до просветления "Вроде существуют способы сделать 100% транзакционность в распределенной среде."
DOO>Дальше что?
DOO>

DOO>Прагматичный подход к решению задачи предполагает не полное устранение ненадежности канала, а её сведение к допустимому уровню.

Я ен говорю про конкретно задачу двух генералов, я говорю о решении общей проблемы.
Если ты хочешь свести её к задаче двух генералов, то у тебя 100% гарантии не будет.

DOO>>>Во-вторых, у тебя возникает та же самая задача при общении с твоим надежным посредником.
G>>Читай выделенное до просветления "Эта задача решается доверенным надежным посредником".
DOO>Не наступает просветления — у нас канал ненадежен. Посредник может хоть мамой клясться, но на канал он не влияет.
Ты слово "надежный" понимаешь?

DOO>>>Поэтому, если ты считаешь, что решение есть — приведи хоть какое-то его описание — посмотрим, что же оно решает на самом деле.
G>>WS-Atomic, MS DTC.
DOO>Это описание? По-моему, это названия конкретных систем, реализующих очень простой и примитивный механизм: есть кто-то, кто дает отмашку — причем непонятно, получили ли эту отмашку все участники. Вся их надежность заключается в том, что они ничего не забывают — т.е. рано или поздно ситуация придет в норму. Но в промежуток — все плохо.
Это общая суть транзакционности, внутри может быть все плохо, а вне транзакций состояние согласовано.


DOO>Ситуация с банкоматом:
DOO>банкомат и сервер должны совместно выполнить транзакцию по списыванию и выдаче денег. Пусть ее ведет твой надежный координатор. Типа того же DTC.
DOO>Банкомат и сервер подтвердили готовность. Координатор дал отмашку. Банкомат выдал деньги и тут упала сеть. Что делать? Координатор не знает получена ли его отмашка банкоматом — т.е. он не знает выданы деньги или нет. То, что система придет в нормальное состояние, когда сеть восстановится — я понимаю, но в промежуток ничего не понятно — если ты транзакцию откатишь, а банкомат деньги выдал, то пользователь снимет те же самые деньги в соседнем банкомате, если ты транзакцию подтвердишь, а банкомат денег не выдал, то ты спишешь деньги со счета пользователя и он не сможет их взять в другом банкомате. Если ты будешь ждать и на это время заморозишь операции со счетом — то пользователь тебе придет бить морду.

DOO>Вот такие они "надежные" распределенные транзакции.

В ситуации с банкоматом выдаватель денег не транзакционен. Если ты забрал из банкомата каким-либо образом хотябы одну бумажку вернуть ее не получится. Откат невозможен.
В ситуации с двумя генералами это аналогично тому что одной из армий вешестоящее командование прикажет атаковать, незавиимо от того дошло ли сообщение до дргуой армии.

Если все компоненты транзакционны, то есть транзакцию до завершения можно откатить, то существует способ организации распределенных транзакций по ненадежным каналам.

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

G>Я ен говорю про конкретно задачу двух генералов, я говорю о решении общей проблемы.
G>Если ты хочешь свести её к задаче двух генералов, то у тебя 100% гарантии не будет.
Это всегда будет сводиться к задаче о двух генералах.


DOO>>Не наступает просветления — у нас канал ненадежен. Посредник может хоть мамой клясться, но на канал он не влияет.
G>Ты слово "надежный" понимаешь?
Дальше что? канал ненадежен.




DOO>>Ситуация с банкоматом:
DOO>>банкомат и сервер должны совместно выполнить транзакцию по списыванию и выдаче денег. Пусть ее ведет твой надежный координатор. Типа того же DTC.
DOO>>Банкомат и сервер подтвердили готовность. Координатор дал отмашку. Банкомат выдал деньги и тут упала сеть. Что делать? Координатор не знает получена ли его отмашка банкоматом — т.е. он не знает выданы деньги или нет. То, что система придет в нормальное состояние, когда сеть восстановится — я понимаю, но в промежуток ничего не понятно — если ты транзакцию откатишь, а банкомат деньги выдал, то пользователь снимет те же самые деньги в соседнем банкомате, если ты транзакцию подтвердишь, а банкомат денег не выдал, то ты спишешь деньги со счета пользователя и он не сможет их взять в другом банкомате. Если ты будешь ждать и на это время заморозишь операции со счетом — то пользователь тебе придет бить морду.

DOO>>Вот такие они "надежные" распределенные транзакции.

G>В ситуации с банкоматом выдаватель денег не транзакционен. Если ты забрал из банкомата каким-либо образом хотябы одну бумажку вернуть ее не получится. Откат невозможен.
Откат невозможен всегда, когда уже прошел commit. Т.е. при отсутствии информации надо либо ждать ее появления (вариант 3), либо принимать какое-то решение без необходимой информации (варианты 1 и 2).

G>В ситуации с двумя генералами это аналогично тому что одной из армий вешестоящее командование прикажет атаковать, незавиимо от того дошло ли сообщение до дргуой армии.
Но поскольку атаковать надо все равно — поэтому и приходится совершать транзакцию без 100% уверенности в ее согласованности. И не может быть 100% уверенности.

G>Если все компоненты транзакционны, то есть транзакцию до завершения можно откатить, то существует способ организации распределенных транзакций по ненадежным каналам.
Всегда будет точка принятия решения. Либо commit, либо rollback — и может быть ситуация, что при принятии решения нужной информации нет — тогда надо либо ждать ее появления (посылать очередного гонца), либо принимать решение, исходя их каких-то общих правил — как делают банки — деньги со счета списать не зная наверняка получил ли их клиент.