- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
volatile bool b;
class BoolKeeper
{
bool &fb;
public:
BoolKeeper(bool &b)
{
while (b);
b = true;
}
~BoolKeeper ()
{
b = false;
}
}
void Thread1
{
BoolKeeper ololo(b);
// что-то делаем
}
void Thread2
{
// что-то делаем
BoolKeeper ololo(b);
// что-то делаем, причём в этом месте нам важен факт, что Thread1 не выполняется
}
Follow us!
http://www.youtube.com/watch?v=byzGCPwtZM0
volatile, емнип, сохраняют порядок только среди других volatile, но ничего не гарантируют для не volatile обращений, которые могут разползтись и до и после этого спинлока...
Да и барьеров, насколько я понимаю, обращение к volatile переменной не генерирует, со всеми вытекающими последствиями... Это я к чему - а к тому, что нет гарантии того, что переменные, модифицированные перед BoolKeeper в Thread1 высрутся из кеша текущего ядра в память, и нет гарантии того, что Thread2 после прохода через BoolKeeper будет читать эти значения из памяти, а не из кеша своего ядра. В результате кровь-кишки-распидорасило получим забавные и трудноуловимые гейзенбаги...
Даю гарантю, что не генерирует.
А вот джаваба или сишарпик сделает.
А то что ты написал - противоречит кодексу С++: 100500 заряженных ружий ради оптимизации не платишь за то, что не используешь.
>Double-checked locking can be implemented in Visual C++ 2005 and above if the pointer to the resource is declared with the C++ keyword volatile. Visual C++ 2005 guarantees that volatile variables will behave as fence instructions, as in J2SE 5.0
http://en.wikipedia.org/wiki/Double-checked_locking
> для прерываниеёбства
Ну и для сигналоёбства в никсах. Но к визуалке оба пункта слабо относятся.
В визуалке я тебе даже загрузочный сектор могу написать. А дальше можно уйти и в портоебство и в прыжкоебство и в прерываниебство. Но с сигналами по сути засада...
Она умеет 16 битные си или хотя бы 16битный инлайн асм? Или придется заниматься dbёбством до самого перехода в защищенный режим?
Вырезаешь утилитами ненужный мусор и ими же релокейтишь на нужный адрес, подходящий для загрузочного сектора точку входа. По сути будет COM-программа. В ней будут всякие edi вместо di, но это все теже обращения в рамках одного сегмента реального режима.
Дальше твой yoba-сектор загружает твою yoba-программу, где реализован crt по полной тобой или кем-то ещё и дальше можно упарываться полными возможностями крестов без ограничений. Единственное не знаю есть ли реализация доморощенных crt с поддержкой исключений и fpu, но думаю должны быть и такие.
С одной стороны, есть редко используемый «нереальный режим»: можно отобразить всё ОЗУ на виртуальное адресное пространство 1:1, переключиться в реальный режим... Вуаля! Инструкция mov ax, WORD PTR [esi] может адресовать 4 гигабайта.
С другой стороны, код из 32-битного сегмента может пользоваться инструкциями типа MOV eax, DWORD PRT [si], ограничивая себя 64 килобайтами, как в старые добрые времена.
Но вот беда: оба кода требуют префиксов адреса, т. е. нужна поддержка со стороны компилятора. Не патчить же код вручную, учитывая, что места для префикса может не найтись!
А что будет, если 32-битный код без префиксов посадить в реальный режим или 16-битный код без префиксов посадить в 32-битный сегмент? Барабанная дробь!
Комп распидорасило, пишу с утюга! А всё потому, что x86 придумали хитрожопые тролли, а поэтому один и тот же mod R/M в 16-битном режиме кодирует [BX+SI], а в 32-битном — [EAX]. Как думаете, сможет ли компилятор предугадать такой поворот событий?
Вот по этой причине в известных архивах Windows NT4/2000 source code отдельно лежит 16-битная версия Visual C.
Существует неофициальный генератор 16-битного кода для gcc для кросс-компиляции, но код он выдаёт ужасный.
Декодирование mod r/m вполне управляется префиксом разрядности адреса, который 67h. Но один хрен визуалка эти префиксы расставлять не будет. Разве что в тулзе, нарезающей экзешник на полоски добавить расстановку префиксов и фиксап смещений в jmp'ах после этого...
А теперь мы со всем этим говном попытаемся взлететь.
А еще визуалка, как и гцц, скорее всего любит заменять умножения и сложения на lea:Этот код скомпилится в 8D 44 80 05, который 16битный режим поймет как:
Бутсектор на насме, утиль для кастрации экзешника, и 32-х битная тестовая прога на си, которая умеет крутить по таймеру палочку в углу экрана и показывать коды нажатых клавиш...
Если интересно - могу вечером выложить на гитхаб.
я король а вы сосете
иди ебись в глаза кракен
http://liveworkspace.org/
P.P.S. volatile в IntKeeper можешь убрать, оно не имеет совершенно никакого отношения к многопоточности. Оно нужно для портоёбства.
Потоки - это такая злая вещь, в которой нельзя все баги отловить тестированием... Даже если все работает сейчас - не факт, что код корректен, и после года работы, при удачной фазе луны и присутствии рядом девственницы, не выдаст херню... Хорошим примером является паттерн double checked locking, который с первого, да и со второго, да и даже с третьего раза мало кто реализует корректно.
Да там везде в теории используется хуйня, которую я даже проверить не могу, потому что этих библиотек нет в мой студии, вот и приходится лепить из чего есть.
Ну если хочешь запилить свой кроссплатформенный мутекс - сделай переключаемую дефайнами обертку для pthread под никсами, и для критической секции под виндой. Бустовский насколько помню так и запилен.
у него же селерон 10 летней выдержки
он еще небось апдейты не ставит, потому что "sp3 для xp - говнище!"
"Тарас скорее всего расстроится, т.к. студия требует фреймворк"
>фреймворк 4.5 невозможно поставить на XP
Хороший повод отказаться от проприетарщины и пересесть на gcc.
А там глядь, и Тарас вовсе от ШИНДОШС откажется.
Я последний раз студию ставил лет 6 назад. Такого распухшего высера для быдлоынтырпрайза еще посикать. Сумневаюсь что они поувольняли всех индусов и VS 12 требует меньше ресурсов чем предшественники.
А я всего лишь три-четыре года ее не видел. Давно уже gcc/vim/QtCreator/eclipse.
Просто хотел собрать свой древний проектик, про который писал выше, ну и заодно посмотреть чего там сейчас в свежих визуалках по юзабилити.
Но как вспомню, сколько там качать и потом еще джва часа её ставить, то проще полезть и разобраться в сырцах, чем ставить это говно.
небось еще все галочки поставил (да-да, я хочу и басик, и шарп, и сыкал сервер, и кристал репорц, и да-да, поставьте мне мсдн на локальный диск)?
если на машинах в офисе стоит винда, АД, офис, на кой черт искать убогие глючные, но "свободные" редакторы (дебаггер то под виндой есть у мингв? а в 2005 году?)
Ну креатор дебажил, пока не начались пертурбации с нокией\троллями\дигией, и не поломали сдк к хуям. Сейчас там надо поплясать с бубном, чтобы gdb стартануло... А так быстро привыкаешь к хорошему - кутисдк, который качается и обновляется в пару кликов, да еще и работает...
GNU Emacs, в отличие от XEmacs, очень стабильный редактор. Его можно месяцами не закрывать, юзая каждый день по 12 часов. Время запуска ~ секунда.
Крэша или некорректной работы Vim я никогда не наблюдал. Максимум - если натыкаешь по ошибке не туда, но это уже сам дурак. Месяцами не юзал, ибо запускается долисекунды.
Вот Eclipse - бажный отстой. Idea неплоха, но тоже частенько глючит и жрёт память.
А вот такого убожества, как 2008 студия для сишарпика я никогда не видел. Приходится использовать её с решарпером на не особо мощной машине. Крэшится в дебаге через раз. Отображает текст в два раза медленнее, чем я печатаю. Интерфейс контринтуитивен.
И конечно, все перечисленные IDE адски сливают "убогим и глючным свободным редакторам", когда дело доходит до работы с текстом, темплейтами и макросами, а не "сгенери мне ToString".
не прижилось
ассист с нормальным редактором и мышью заруливает эти мазохистские редакторы, в которых надо постоянно что-то настраивать, умение перейти из окна output с выводом компилятора в строку, где найдена ошибка - вообще событие,
а уж о том, чтобы предложить в качестве аргумента функции только те доступные имена, которые подходят по типу и действительно сочетаются - в vi это за пределами моих смелых фантазий
не исключаю, что он это таки умеет (быть может, только с последними достижениями от clang), а у меня просто кривые руки и программист мышкой головного мозга, но в 2005 году vim по удобству и интуитивности проигрывал даже фару с колорером
причем, по ssh мне конечно приходится читать/редактировать что-нибудь в vi, но поддерживать им проекты на 1млн строк - нет, спасибо
у 2008 студии тоже есть сервис паки/обновления, как и очевидно, в решарпере (не пользуюсь), и чтобы она в дебаге крашилась - может причина в сишарпе или отключенных обновлениях?
на моей старой слабой машине с мегаубогим хардом любая студия дико тормозила, факт
С другой стороны, написать плагин для vc/eclipse/idea - задача не из лёгких, и я вряд ли решусь когда-нибудь на такой шаг.
Для "убогого" же emacs это обычно делается довольно просто (при наличии минимальных знаний elisp).
И, конечно, вкладки - отстой, буфера и окна рулят. А список *кликабельных* ошибок компиляции в емаксе легко получается по M-x compile/recompile, который привязывается к любимому сочетанию клавиш
>> И, конечно, вкладки - отстой
Вывод: вим - отстой.
Да. Вообще я долгое время сидел на древней VS6. Говно, знаю. Но привык к нему. Та студия не требовала гигафлопсов CPU и гигабайтов RAM.
05 поставил ради нового сишарпика - посмотреть чего там. Полтора часа установки меня насторожили.
>и сыкал сервер, и кристал репорц
Ну уж нет.
>дебаггер то под виндой есть у мингв
имхо, дебагеры не нужны.
>Вот Eclipse - бажный отстой. Idea неплоха, но тоже частенько глючит и жрёт память.
>А вот такого убожества, как 2008 студия для сишарпика я никогда не видел.
Согласен на 100%.
без дебаггера одним трейсом в лог на отладку (поиск гейзенбага) времени уходит больше, чем с дебаггером
Да дебажить такое сущий ад. Не пойму что тут облегчит дебагер? Он не спасет тебя от той лютой хуйни, что в ОП-посте.
Обычно вдумчивое всматривание в код и медитация над ним, которая со временем открывает его незримую суть приносят больше пользы.
Важнее того вдумчивое и осторожное написание многопоточного кода, а не изобретение кривых велосипедов, как это делает Тарас.
но, откровенно говоря, доводится этим заниматься нечасто
Интегрированный отладчик и подсветку ошибок в коде тоже было бы неплохо иметь.
Плюс дополнительная проблема - мне нужно писать на PHP, поэтому желательно иметь IDE под оба языка. Я рассматривал вариант emacs + ensime, но в emacs, говорят, проблемы с мультирежимами, а мне часто приходится поддерживать лапшу из PHP+SQL+HTML+CSS+JavaScript.
В итоге сейчас сижу на Eclipse. Поддержка Scala весьма хорошая (подсветка ошибок, полное автодополение, рефакторинги, брейкпоинты), но "микроредактирование" текста не такое удобное и некоторых плагинов vim'а очень не хватает. И еще очень раздражает, что все делается через тучу менюшек вместо одного файла конфигурации. *плак-плак*
Вот это http://scala-ide.org я тоже пробовал, но оно, хоть и поделка typesafe, совсем не впечатлило. Код иногда понимает чуть лучше, чем Idea, но когда дело доходит до рефакторинга, оно портит код. Во всяком случае, версия 2.0 портила. На в целом терпимо. Правда, тормознутость Eclipse отбивает любое желание этим пользоваться.
Ensime + Emacs тоже пробовал, в целом впечатлил объём работы, проведённый автором. Многое работало, включая дополнение кода и поиск. Правдо, отжирало много памяти и иногда Ensime крэшил емакс.
php редактирую в основном под страхом смерти. При работе с практически любым языком предпочитаю использовать или писать билдеры разметки/запросов, позволяющие минимизировать кол-во языков, одновременно использующихся в каждом конкретном исходнике.
Отладчик для настоящего хакера.
Легким движением руки я добавляю ключ -std=c++98 или -std=c89, и все лишние свистоперделки испаряются, остается только сила древних...
Реакция при вводе текста должна быть точно такой же. Автодополнение скорее всего такое же или быстрее, ну не будут же делать в новых версиях более медленный intellisence... Хотя тут надо проверить, это же мс, с них станется испортить его.
А фишки среды, скрытые в менюшках, типа интеграции с системами контроля версий, рефакторингом и анализом совсем не мешают, пока ты их не запустишь.
я дома пробовал vs2012, не релизную еще, там заметно тормозил ввод текста
плюс этот самый ввод выглядел убого с какими то дополнительными мусорными перемигиваниями, подсвечивания строки курсора и т.д.
а дома 12Гб памяти, например
а для всего остального есть мастеркард ливвёркспэйс
в релизной вроде бы всё плавно, ещё и рефакторинг для С++ добавили.
p.s. планки можно было с и манибеком взять (типа тоже посмотреть)
в отличие от мастарр калекшен или студио ултимейт рахитект тим лид едишан
http://cache2.allpostersimages.com/p/LRG/51/5103/Z6DEG00Z/posters/zombie-brains.jpg
когда равы весят по 30 метров, и в коллекции их надо пару сотен обработать
В таких объёмах да, конечно, сожрёт и не подавится.
Но в более приземлённой области не встречал. Не для простого это пользователя.
а что не держит? 4.7.2?
http://gcc.gnu.org/projects/cxx0x.html
p.s. какие неожиданности оказывается в фичах языка присутствуют "Minimal support for garbage collection and reachability-based leak detection".
ради посмотреть можно с торрентов утянуть ultimate
а ради поработать?
P.S. Экспресс хочу потому что он легче, и в нем нет фич, ненужных для беглого осмотра экспоната.
мне даже наоборот, чем хуже оптимизация под винду, тем лучше я буду видеть, где что будет на планшете
кушай шоколад "воздушный"
промахнулся
Не пугай гостя странными словами.
Слышало гумно, да не знает кто хочет подзалупного творожка отведать?
Хотя на мой вкус орлежка гораздо сочнее был.
Как и предсказывал defecate-plusplus
>возможно, когда-нибудь ты отвыкнешь от глобальных переменных и однопоточности
здесь http://govnokod.ru/11975#comment156837
Тарас начал изучать многопоточное программирование.
Как и подобает Тарасу он сказал "Нахуй стандартные языковые средства, я буду писать свои костыли".
После чего дискуссия пошла в сторону ide и отладчиков.
Проблема, повторюсь, решается не дебаггером и иде. Как раз они вас не спасут.
Проблема решается в корне: тем что просто не надо писать такие самокаты. А начать с того что изучить хотя бы одну книжку или десяток статей по теме.
PS> так мало того. еще на геймдеве насрали 38 страниц, пытаясь сделать из говна мьютекс. лень даже тратить время на прочтение.
Ну, кстати, уже на третьей странице Тарас запостил работоспособную версию своего мутекса через __sync_add_and_fetch. На глаз в ней не видно явных багов и расовых условий, хотя и смотрится она кривовато.
Ок, согласен. Настоящий мутекс без ядерной поддержки он все равно не запилит.
В ядерных спинлоках настоящих - сначало идет спинирование, а потом уход в ожидание события.
В случае если ядро одно, то сразу уход в ожидание событие.
Да, и наоборот. Мне там надо пару переменных-то лишь поменять (новые размеры буфера выставить), ради этого я буду лезть в ядро за мутексом? Нет, я лучше в цикле пару кругов намотаю.
Зачем так сделано? А тупо потому, что если за 10-15 тактов мутекс не отпустили, то скорее всего и не отпустят, и лучше уйти поспать. А для "поменять пару переменных" оно как раз будет работать как твой спинлок.
Если я конечно не туплю.
Но, поверь, там достаточно веревки чтобы выстрелить куда надо. Это, наверное, один из самых сложных способов писать многопоточный код. И то что в CASе не может быть дедлоков - миф.
Именно твоё __sync_ololo:
__sync_val_compare_and_swap
А вот расовое условие и проблему АБА словить можно только так. Может быть 3.14159265 их и имел в виду?
Достаточно 2 потока (или более, что ещё хуже) непрерывно касирующих одну переменную. Но время обработки данных у каждого потока разное. У одного много меньше, чем у другого. В результате один касирует редко, а второй часто. Так вот редко кассирующий попадает в дедлок, так как никак не может сохранить результат своих действий и продолжить работу, так как часто кассирующий постоянно меняет исходные данные.
Тоесть у касирующих алгоритмов есть следующая гарантия: хотябы один поток идет к прогрессу в расчетах, но нет гарантии, что данный конкретный поток хоть раз проведет успешный кас.
А это имхо не дедлок, имхо, а starvation, когда одному потоку не дают поработать.
А дедлок он все-таки мертвый и неустранимый кроме как убийством одного из тредов.
P.S. А еще есть live-lock, когда два потока активно дрочат синхронизацию, но при этом ни один не может продвинуться дальше.
Скорее это livelock. Только вот при использовании cas-алгоритмов - ты эту ситуацию никак урегулировать не можешь. Долгое время код работает нормально, а однажды это вылазит и приходится переписывать очень многое с lockfree на lockfull, так как переписыванием одно модуля понятное дело уже не обойдется (возможно даже весь проект переписать придется).
Урегулировать можно только в активные потоки вставлять слипы или критические секции, чтобы их утихомирить, но это сразу минус в эффективности и простоты управления
P.S. На самом деле такое CASодрочево возникнет только в одном случае - если один из потоков только и делает, что лезет к этой расшаренной структуре. Если же между операциями над структурой они занимаются какой-то достаточно долгой полезной работой - starvation маловероятен.
P.P.S. А схема с постоянным дрочевом одного и того же места в одной расшаренной структуре - это уже первый шаг к херовой производительности, и тут ни lock free ни lockful не спасут.
Я знаю определения этого термина, но ближе всего к нему, если искать среди *lock'ов:
> Скорее это livelock.
Но это не важно. Можно назвать голоданием.
Не в этом дело. Если все потоки занимаются достаточно долгой полезной работой, но период длительности обработки данных из одной и той же структуры разными потоками всегда стабильно отличается более чем в 2 раза, то происходит это самое голодание более slow потока. Это оновы concurrence
А что поделать? Зачастую именно такие места заменяют на локфри, так как производительности критических секций уже не хватает.
Устраняется легко без убийства. Анализ кода. Или throw или возврат локошибки из ожидания примитива. Только обработчики под эту ситуацию придется писать. Благо алгоритмы обнаружения возможности дедлоков известны и проработаны.
Да-да. Гумно правильно сказал. Именно это имелось ввиду. Когда тредов несколько это не так критично.
Но когда их несколько десятков CAS начинает сливать лочкам, потому что они начинают друг другу мешать и больше процессорного времени каждого тратится на повторения в цикле. Получается эффект переполненного метро (или банки с огурцами), когда никто не может вылезти из вагона, потому что мешают соседи.
В то время как мьютекс заставляет их высторится в очередь и ждать.
Хотя есть одна RC на самом деле и в касах. Удаление все ещё используемого элемента. В C# и Java этой проблемы нет, ибо сборщик мусора решае 1)и ABA 2)и RC при удалении памяти, используемой в другом потоке. Так что С++ для lockfree-алгоритмов уныл, так как требует ещё большей внимательности и концентрации при разработке, чем обычо
CAS'ы дорогие, поэтому любой уважающий себя алгоритм старается юзать минимально возможное количество CAS'ов. А от этого до race condition всего один шаг.
Да вроде ты всё верно говоришь. Хотя и в GC-языках я наступал на ABA с nullами. Не до конца подумав пытался секономить на пустых объектах - выстрелил себе в ногу.
Ибо CAS не видит разницы между nullами, а вот пустые объекты затратно, но безопастно.
В не GC надо организовать пул таких объектов - больше работы, но и выше производительность, потому берешь из пула, а не делаешь malloc & free.
>CAS'ы дорогие
ЛолШто? Наоборот, при низкой конкуренции CAS быстрее лочки, ибо он поддерживается на уровне железа.
По сравнению с обычными не атомарными командами же, не по сравнению с лочкой.
А. Ну это черезчур очевидно.
Скажем по стоимости и соответственно силе они идут так:
no sync<volatile<atomic(CAS)<lock(mutex)
Блядь, из-за гуглопидоров мне ещё и 10 статей читать, причём ещё и небось на английском? Не проще ли нагуглить функцию __sync_ololo_and_trololo, написать велосипед, запостить на пару сайтиков и отладить по комментам? Не кажется ли, что код из 10 строчек с непредсказуемыми эффектами как раз таки именно по комментам отлаживать и надо?
ты ведь понимаешь, что по тебе рисуют образ "типичный дельфи-программист"? какой пример ты подаешь молодёжи?
Если фреймворк требует от меня чтения поебени, дохуя далёкой от темы фреймворка, то этот фреймворк - говно.
Если эти пидоры из гугла умудрились сделать колбека в отдельном потоке, заставляя пользователя учить потоки, то это просто лютый бешеный пиздец, впрочем, про НДК и так все знают, что это так.
Но, к сожалению, они обычно медленней многопоточности и хуже масштабируются. Доступные машины с сотней-другой ядер (пока на видеокартах) уже есть. Товарищи из Tilera творят невероятные вещи, хоть их разработки пока довольно дороги.
По мне, самый удобный механизм работы с конкурентностью - акторы. Кстати, стейт-машины отлично на них ложаться.
На 1 ядре - очевидно нет.
Да и GUI для ресурсоёмких задач программировать без многопоточности - садизм.
И в то же время программировать гуй с многопоточностью - мазохизм.
А что они делают?
примитивов межпоточной и межпроцессной синхронизации не так много
уверен на педивикии даже на русском есть
после того, как ты ознакомишься с полным списком, надо его отфильтровать по поддерживаемыми платформой и выбрать подходящий
я сейчас, по моему, очевидные вещи говорю, не благодари
пока ты не решаешь эффективно задачи reader/writer, частичной блокировки сложного объекта или рекурсии, её хватит
я тебе про буст уже говорил, по крайней мере BoolKeeper писать не пришлось бы
> запостить на пару сайтиков и отладить по комментам?
>Запостил: LispGovno,
Пиздец. И сильно тебе помогли на гкоде?
По-моему, КПД неплохой.
Когда говно сдают на анализ в поликлинику, то заранее знают, что это говно и ищут только следы болезней.
А когда говно выкладывают на форум, то слово "говно" получается в переносном смысле и вопрос состоит не в нахождении симптомов полезней в этом "говне", а в вопросе о том, говно ли это вообще. Обычно этот тонкий нюанс не имеет роли, но именно в твоём случае он - самый важный. Поэтому твоё утверждение, применительно к коду, неверное.
Найди себе уже девушку наконец, а не виси над аналогиями
Каким образом можно применить std::move_if_noexcept?
http://en.cppreference.com/w/cpp/utility/move_if_noexcept
применять натощак, когда в твоем методе, а еще лучше, конструкторе, требуется гарантия, что move ничего не выкинет
даже по твоей ссылке это написано - используется вектором при ресайзе (расшифровываю - вектору хотелось бы знать, выкинет ли элемент исключение при перетаскивании его из старого буфера в новый, и если он на такое способен, то вектор от греха подальше будет пользоваться копированием всех существующих элементов в новый буфер, и лишь когда они скопируются нормально, поудаляет их в старом,
ну а если мув элементов обещает вести себя хорошо, то вектор их сразу будет мувом перемещать)
> По-моему, КПД неплохой.
Лучше бы ты пару статей прочитал и уже бы написал годный код, чем 4 дня висеть целый день на говнокоде и говнодеве и слушать инфу о том кто же все-таки ты такой на самом деле.
А на говнокод несколько раз за день зашёл на несколько минут, почитал комменты, всё понял, ушёл.
Читай больше английских текстов, и будет тебе счастье.
P.S. Последнее время разочаровался в статьях на русском. Обычно или переводчик надмозг (хоть и врубается в тему), и читать в оригинале намного легче, либо переводчик нихера не понимает в теме, и переводит текст как литературный.
> читать в оригинале намного легче
Верной дорогой! Когда-то и мне это казалось извратом - "чтение в оригинале, фу". Прикол в том что и индус, и болгарин, и китаец, и русский, и француз, и немец - все худо-бедно поймут сраный инглиш. И потому смогут ужится на одном форуме.
Да и огромное количество полезной инфы (спецификации, стандарты, документация, статьи), которую никто не собирается переводить именно на англицком.
Хороший, простой, доступный Тарасу пример: документация на сайте MS.
ps: Борманд ниже тоже цвет не разглядел.
Как ни попаду на сайт мс из гугла - так мне подсовывают быдломашинный перевод, который невозможно читать, а ссылку на оригинал каждый раз забываю где искать...
Ок. Ты сам на каком языке его читаешь?
> там тупо тенический текст
А статьи/книжки по многопоточности не тенический текст получается?
"волатиле", "ЦАС", "атомис", "лоск", "мутех"
>Плохой! Ужасный пример!
Что не так?
язык, на котором написана документация PSDK у MS
поэтому и китаец и якут и даже Тарас все прекрасно понимают
Потому что "Как ни попаду на сайт мс из гугла - так мне подсовывают быдломашинный перевод, который невозможно читать, а ссылку на оригинал каждый раз забываю где искать..."
UPD: Хм, зашел сейчас - вверху болтается радиобокс - перевод/оригинал. Ну уже прогресс, юзать можно.
Помню были разные варианты представления страницы, но возможность выбрать оригинал была всегда. Сменой страны на сайте например
fixed
На работе пытаюсь внедрять инглиш хотябы в комменты и документацию, хотя бы в проекты, за которые отвечаю я.
Думаю вот ещё уютненький бложик завести где-нибудь не пьянсва окаянного ради, практики инглиша для
Как то сами смыслы предложений всплывают на русском без каких либо усилий с моей стороны.
Ежели меня попросить перевести текст дословно, переводя каждое слово - перегрев и зависание.
На инглише пишу как неграмотное быдлогопник, незнающее времен и склонений.
Вот грамотно разговаривать на английском - это действительно сложно, даже когда значешь грамматику, но практики не хватает.