Айтишники на пенсии

[Komissar]

аццко, закругляй флудить в моем топеге. Лучше расскажи, где у вас в ТХ девочки в коротких шортиках стайками носятся?

[M. Ridcully]

Насчет умных вас обманули.
Девушки любят молодых мальчиков с деньгами. Можно даже старых, но с очень большими деньгами.

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

А умение "писать на С громандный энтерпрайз код со всеми наворотами, мыслимыми и немыслимыми, включая собственную threading library" - среди критериев имеется?

[ksi]

Вы несёте такую феерическую чушь, что я даже не знаю, с чем именно поспорить. Неверно ровно всё и ещё чуть-чуть. Двоечка за CS 101

У вас просто знания и представления остались немного школьные. А в реальности все сложнее. И mutex ставить вредно, поскольку просыпание thread занимает много времени и убивает перфоманс и скалабилити. Искусство написание серьезного параллельного кода состоит в том, что бы сделать его по возможности lock free. Никто никого не должен ждать. А достичь этого возможно только если нет объектов которые шерятся между разными threads на запись. Все как в жизни кстати.

Но вообще Комми прав - лучше вернуться к благодатной теме длинных ножек и коротких юбок .

[M. Ridcully]

ksi,

скажите честно, не в лом ковырять "громадный энторпрайз код", написанный на C, с собственной multithreading library, да ещё и с, как выясняется, с lock free синхронизацией?
Звучит как огроменная куча дымящегося говна.
Есть живые люди, видевшие, как это работает?

PS: я примерно так себе представляю себе ад, в который попадают айтишники уже после пенсии.

[ksi]

ksi,

скажите честно, не в лом ковырять "громадный энторпрайз код", написанный на C, с собственной multithreading library, да ещё и с, как выясняется, с lock free синхронизацией?
Звучит как огроменная куча дымящегося говна.
Есть живые люди, видевшие, как это работает?

PS: я примерно так себе представляю себе ад, в который попадают айтишники уже после пенсии.

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

[adda_]

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

Давно пора прикрыть этот high frequency trading основная идея которого заключается в том, чтобы сделать деньги в момент когда большие дяди типа Чейса или какого нибудь мучал фонда закупают или продают кучу стоков сразу. И ведь известно как это сделать, просто увеличить немного респонс тайм чтобы эти козлы поставившие компьютеры рядом с датацентром не успевали отработать транзакции которые проходят в момент пока выясняется конкретная цена на данный момент. И самое главное это отчасти сделано и книжка по этому поводу написана даже.
Ан нет, нихрена не хотят и кормят этих паразитов.

[Alexander Troyansky]

Мне на ножки наплевать Не отвлекаемся от указателей.

Какую книжку по С посоветует общественность?

Если исключительно по C, то https://en.wikipedia.org/wiki/The_C_Pro ... g_Language

[Физик-Лирик]

Но вообще Комми прав - лучше вернуться к благодатной теме длинных ножек и коротких юбок .

аццко, закругляй флудить в моем топеге. Лучше расскажи, где у вас в ТХ девочки в коротких шортиках стайками носятся?

Возвращаемся к теме.
Комми, о чем вы думаете, когда глядите на кирпич?

[Kolbasoff]

Так, шортики отставить. Физик-Лирик и Снежная Королева едут в Тайланд и там устраивают математический замес на пляже. А мы продолжаем тему:

Южная Юропа: Греция, Черногория, Болгария и даже Кипр весьма дешевы по сравнению с Северной и тем более с Америкой, при этом приятны для пенсов. Но делать там кроме как лежать на пузе, плескаться в море, бухать отличное молодое вино, кушать овощи/фрукты за 50 центов/кило, и смотреть на местных пифцов и пивичек просто нечего.

Я думал об этом, но как бы не все понятно как это осуществить. Логистика и прочее. Проблемы зверения от безделья у меня нет.

Проблемы логистики как раз нет. Есть проблема зверения от безделья, которая возникает не сразу, а где-то на третьем месяце безделья. Особенно если привык напрягать моск, и он требует тренировки. Тема перехода в преподы обсосана изрядно. Какие еще eсть идеи?

[OtecFedor]

Так, шортики отставить. Физик-Лирик и Снежная Королева едут в Тайланд и там устраивают математический замес на пляже. А мы продолжаем тему:

Южная Юропа: Греция, Черногория, Болгария и даже Кипр весьма дешевы по сравнению с Северной и тем более с Америкой, при этом приятны для пенсов. Но делать там кроме как лежать на пузе, плескаться в море, бухать отличное молодое вино, кушать овощи/фрукты за 50 центов/кило, и смотреть на местных пифцов и пивичек просто нечего.

Я думал об этом, но как бы не все понятно как это осуществить. Логистика и прочее. Проблемы зверения от безделья у меня нет.

Проблемы логистики как раз нет. Есть проблема зверения от безделья, которая возникает не сразу, а где-то на третьем месяце безделья. Особенно если привык напрягать моск, и он требует тренировки. Тема перехода в преподы обсосана изрядно. Какие еще eсть идеи?

Consulting.
Еше можно отркыть рога и копта и получать sbir гранты и ваять one-of-a-kind хню для физиков, военных etc.

[tau]

Меня всегда интересовало, куда же, блин, уходят умирать слоны.

[adda_]

Проблемы логистики как раз нет. Есть проблема зверения от безделья, которая возникает не сразу, а где-то на третьем месяце безделья. Особенно если привык напрягать моск, и он требует тренировки. Тема перехода в преподы обсосана изрядно. Какие еще eсть идеи?

Для меня как раз логистика непонятна.

[Komissar]

Проблемы логистики как раз нет. Есть проблема зверения от безделья, которая возникает не сразу, а где-то на третьем месяце безделья. Особенно если привык напрягать моск, и он требует тренировки. Тема перехода в преподы обсосана изрядно. Какие еще eсть идеи?

Для меня как раз логистика непонятна.

Ну как мне кажется: летом в России с сыном и внуками, иногда в Москву-Питер сгонять за культур-мультур. С октября по апрель в Южной Эйропе. В РФ купить свое жилье или снимать на лето, в Эйропе - как получится, либо свое, либо снимать. Для таскания тушки, наверное, свой автомобиль, в гейропе не такие уж большие расстояния. Непонятки с медстраховками и визами.

[АццкоМото]

Вы несёте такую феерическую чушь, что я даже не знаю, с чем именно поспорить. Неверно ровно всё и ещё чуть-чуть. Двоечка за CS 101

У вас просто знания и представления остались немного школьные. А в реальности все сложнее. И mutex ставить вредно, поскольку просыпание thread занимает много времени и убивает перфоманс и скалабилити. Искусство написание серьезного параллельного кода состоит в том, что бы сделать его по возможности lock free. Никто никого не должен ждать. А достичь этого возможно только если нет объектов которые шерятся между разными threads на запись. Все как в жизни кстати.

Но вообще Комми прав - лучше вернуться к благодатной теме длинных ножек и коротких юбок .

Все ровно наоборот. Вы насмотрелись на какую-то энторпрайз (sic!) систему, написанную на С (sic!) — мля, это точно свежий опыт или было 30 лет назад? И ещё несёте пургу про библиотеку на С (sic!), которая покруче буста будет. Я пацталом.
Скажите, вы слышали такое сокращение SMP, shared memory parallelism? Даже если нет, сама формулировка ни о чем не говорит? И это даже не про треды, а ажно цельные процессы. Да, в некоторых случаях лучше, чтобы параллельные треды не знали о чужой памяти. Да, в некоторых случаях можно освободить чужую память, трижды подумав и семь раз отмерив. Но это антипаттерны. И использование шаред мемори вовсе не подразумевает локи. Иногда — да. Иногда — нет.

Ну и так, ту пут ит ту перспектив. Мой сишный код работает или работал в сотнях миллионов дивайсов по миру. Думаю, около миллиарда уже набралось. Представления "немного школьные"? Выкладывайте свой и несите линейку. Микроскоп тоже может пригодиться.

[АццкоМото]

Меня всегда интересовало, куда же, блин, уходят умирать слоны.

Я только про танки знаю...

[АццкоМото]

аццко, закругляй флудить в моем топеге. Лучше расскажи, где у вас в ТХ девочки в коротких шортиках стайками носятся?

Как в таких случаях говорит моя жена (без обид, плиз) — твоё место только на кладбище. В том смысле, что личные темы на этом форуме есть только, кажется, у ммодел.

А про девочек... Ну, блин, 6я улица в Остине, например. Где каждую пятницу лишь солнце закатится... Могу зашарить фотоальбом с Хеллоуина, например.

Ну и какой-нибудь колледж Стейшн, например.

Хотя мне не очень понятно, чойто вас эти девки так интересуют, при том, что меня давно уже не особо. Не в том смысле, что переключился на мальчиков или стал импотентом. Просто ещё до 30 с друзьями была популярна шутка "если дать блондинке в рот, можно ли заразиться тупизной?". Консенсус был — лучше не рисковать

[DropAndDrag]

С multithreading нет никаких проблем - каждый thread c самого начала должен работать со своими собственными данными, поэтому race conditions не бьывает если вы придерживаетесь такой парадигмы. Тот массив "принадлежит" всегда одному thread Другой thread его не видит. Вы не можете в любом случае иметь доступ (по крайней мере write, да и read очень осторожно) к одним данным из разных thread.

Зря вы спорите. Я просто очень хорошо знаю как пишется на С громандный энтерпрайз код со всеми наворотами, мыслимыми и немыслимыми, включая собственную threading library. Very advanced так что вещи типа boost рядом не стоят. То, что я вам говорю - это как реально пишутся на С продукты экстремальные по своей сложности.

долго и громко ржал
p.s. про boost performance ничего сказать не могу

[fleshold]

Мне на ножки наплевать Не отвлекаемся от указателей.

Какую книжку по С посоветует общественность?

По указателям в С, насколько знаю, есть несколько книжек, я правда читал лишь две, и лучшая из них на мой взгляд by Richard Reese

[ksi]

Все ровно наоборот. Вы насмотрелись на какую-то энторпрайз (sic!) систему, написанную на С (sic!) — мля, это точно свежий опыт или было 30 лет назад? И ещё несёте пургу про библиотеку на С (sic!), которая покруче буста будет. Я пацталом.
Скажите, вы слышали такое сокращение SMP, shared memory parallelism? Даже если нет, сама формулировка ни о чем не говорит? И это даже не про треды, а ажно цельные процессы. Да, в некоторых случаях лучше, чтобы параллельные треды не знали о чужой памяти. Да, в некоторых случаях можно освободить чужую память, трижды подумав и семь раз отмерив. Но это антипаттерны. И использование шаред мемори вовсе не подразумевает локи. Иногда — да. Иногда — нет.

Ну и так, ту пут ит ту перспектив. Мой сишный код работает или работал в сотнях миллионов дивайсов по миру. Думаю, около миллиарда уже набралось. Представления "немного школьные"? Выкладывайте свой и несите линейку. Микроскоп тоже может пригодиться.

Аццко, у вас уровень разговора, как на рынке. Гопота какая-то, вы себя почитайте.

Правильное освобождение памяти не означает, что если вы в начале функции отвели память под какой-нибудь объект то потом должны освободить именно эту физическую область (вот именно те адреса, которые были вначале отведены) в конце функции. Вы отводите память под объект и освобождаете этот объект. Естественно, что объект поменялся, поэтому физически память освобождается другая. Но она все равно "своя" потому что принадлежит тому же объекту, которая функция аллоцировала вначале. Понятиe own относится к объектам, а не к конкретным адресам в памяти. Сорри, что приходится вам объяснять очевидные вещи из ооп. Вам там из "пацтала" хорошо слышно, вы не устали сидеть ?

Хотя С и не объектно-ориентированный язык, но любой сложный код на нем естественно должен пытаться эмулировать где возможно идеологию старшего брата С++. Массив с которого начался спор - это объект (или обычно часть гораздо большего объекта) внешней функции. Вы передаете этот объект во внутреннюю функцию (с помощью двойного пойнтера, так как только это дает возможность его модифицировать). Вас не интересует и не должно интересовать, что делает внутренняя функция внутри себя, как она модифицирует этот объект. Объект вернулся к вам - вы им пользуетесь и потом осбождаете в конце функции как обычно, не думаю о том, быд ли он не модифицирован или нет.

Насчет threading - ну это спор не о чем, пока не определенно для какого типа задач это используется. Если брать наиболее частую постановку, котрая состоив в том, что у вас много однотипных задач, которые вы можете делать параллельно, то вещи, которые стандартно поставляются даже встроенные в С++ (Mutex. COndition Variables,...) недостаточны для сложных проблем. Как я уже говорил, прямой обмен данных между threads через какик-то ообщие объекты всегда опасен race conditions и падающей перформанс из-за того, что мутекс и локи неизбежны обычно. Пишутся такие сложные вещи по-другому. Что-то типа такого из этой интересной дискуссии https://news.ycombinator.com/item?id=9905374

Totally agree. I also have written a lot of multithreaded code in the past years. At the beginning I really used locks and acted on various resources from multiple threads. It turned out to get into an unmaintainable mess where you have to think about dozens of invariants before each change. In the meantime I mostly implement things in a way that each data is owned by exactly on thread (or mostly event loops running on a thread or also in a thread pool) and provide thread-safe APIs on top of that by using queues and message (or function object) passing to exchange data and results between the calling thread and the resource-owning thread.

Вот этот API и его имплементация и есть ключ к успеху, Know-How.

Надеюсь, что я помог вам с вашим столом!

[M. Ridcully]

Мне на ножки наплевать Не отвлекаемся от указателей.

Какую книжку по С посоветует общественность?

По указателям в С, насколько знаю, есть несколько книжек, я правда читал лишь две, и лучшая из них на мой взгляд by Richard Reese

Жуть.
Если бы мне кто-нить, на заре карьеры, посоветовал бы _книгу_ по указателям - я бы, наверное, до сих пор бы их не понял.

Снежная Королева,
1. переменные располагаются в памяти;
2. положение в памяти однозначно определяется адресом. Ну, грубо - от нуля и дальше;
3. этот самый адрес (ака положение какого-то объекта в памяти) тоже можно записать в переменную;
4. конкретно в C два оператора, оба префиксные (пишутся до аргумента, e.g. &var, *ptr):
1) & - взять адрес переменной;
2) * - разыменовать указатель, то есть взять значение по адресу.

Всё. Внимательно прочитать написанное выше и подумать. Как угодно сложные выражения разбираются "как капуста", слой за слоем, следуя этим же простым правилам.

[Alexander Troyansky]

Мне на ножки наплевать Не отвлекаемся от указателей.

Какую книжку по С посоветует общественность?

По указателям в С, насколько знаю, есть несколько книжек, я правда читал лишь две, и лучшая из них на мой взгляд by Richard Reese

Жуть.
Если бы мне кто-нить, на заре карьеры, посоветовал бы _книгу_ по указателям - я бы, наверное, до сих пор бы их не понял.

Снежная Королева,
1. переменные располагаются в памяти;
2. положение в памяти однозначно определяется адресом. Ну, грубо - от нуля и дальше;
3. этот самый адрес (ака положение какого-то объекта в памяти) тоже можно записать в переменную;
4. конкретно в C два оператора, оба префиксные (пишутся до аргумента, e.g. &var, *ptr):
1) & - взять адрес переменной;
2) * - разыменовать указатель, то есть взять значение по адресу.

Всё. Внимательно прочитать написанное выше и подумать. Как угодно сложные выражения разбираются "как капуста", слой за слоем, следуя этим же простым правилам.

После прочтения будьте готовы разобрать "как капуста", слой за слоем следующее выражение:

Code: Select all

char *(*(**foo[][])())[];

[alex_127]

После прочтения будьте готовы разобрать "как капуста", слой за слоем следующие выражения:

Да ладно, можно попроще. В gcc это до 2011 года проходило без единого warning.

Code: Select all

struct AA {
 int &a;
 AA() : a(a) {
 }
};

Back to IT. Тут кстати есть хоть один IT-шник который на пенсии? Не перешел куда-то, не стал VP - а именно сказал "все, всем спасибо". И что они делают?

[Alexander Troyansky]

Хотя С и не объектно-ориентированный язык, но любой сложный код на нем естественно должен пытаться эмулировать где возможно идеологию старшего брата С++.

Троллите несчастных пенсионеров

[АццкоМото]

Аццко, у вас уровень разговора, как на рынке. Гопота какая-то, вы себя почитайте.

А ржут зато все над вами в голос, единодушно. Потому что вы с видом Преображенского порете чушь Шарикова

Правильное освобождение памяти не означает, что если вы в начале функции отвели память под какой-нибудь объект то потом должны освободить именно эту физическую область (вот именно те адреса, которые были вначале отведены) в конце функции. Вы отводите память под объект и освобождаете этот объект. Естественно, что объект поменялся, поэтому физически память освобождается другая. Но она все равно "своя" потому что принадлежит тому же объекту, которая функция аллоцировала вначале. Понятиe own относится к объектам, а не к конкретным адресам в памяти. Сорри, что приходится вам объяснять очевидные вещи из ооп. Вам там из "пацтала" хорошо слышно, вы не устали сидеть ?

Хотя С и не объектно-ориентированный язык, но любой сложный код на нем естественно должен пытаться эмулировать где возможно идеологию старшего брата С++. Массив с которого начался спор - это объект (или обычно часть гораздо большего объекта) внешней функции. Вы передаете этот объект во внутреннюю функцию (с помощью двойного пойнтера, так как только это дает возможность его модифицировать). Вас не интересует и не должно интересовать, что делает внутренняя функция внутри себя, как она модифицирует этот объект. Объект вернулся к вам - вы им пользуетесь и потом осбождаете в конце функции как обычно, не думаю о том, быд ли он не модифицирован или нет.

Скажите, а вас не смутила моя фраза "только не рассказывайте мне, что к массиву ВСЕГДА надо обращаться по двойному указателю"? То, что вы имеете в виду было понятно, и кое-где отсталыми умами еще использовалось лет 30 назад.
Главных проблемы тут две.
1) Вызывающая функция не знает, изменились ли адреса элементов массива или нет. Любая ссылка на, допустим, минимальный элемент массива может внезапно протухнуть. Да, можно хранить индекс и делать двойной дереференсинг каждый раз, но. Единственный смысл использовать С в наше время это когда даже оверхед использования С++ (который невелик, если использовать его с умом) уже неприемлем. И вводить лишний дереференсинг каждый раз просто глупо и расточительно. И в любом случае рано или поздно произойдет выстрел в ногу. Но гораздо хуже другая проблема
2) Единственный "объект" в С, который может относительно естественным способом расти (и, соответственно, "перемещаться") это массив. Исключим экзотику. И вот если вы каждый раз, как в массиве нет места для нового элемента, выделяете новый побольше и копируете в него старый.... то это просто п-ц. С таким подходом нужно забить на С и идти в Жабу, она все стерпит. То, что нужно делать - либо связанный список, либо связанный список массивов, либо массив указателей на массивы. Ну, что-то в этом духе в зависимости от допущений. И все юудет работать быстро, эффективно, в духе С, а никакие "объекты" никогда никуда не будут перемещаться

Насчет threading - ну это спор не о чем, пока не определенно для какого типа задач это используется. Если брать наиболее частую постановку, котрая состоив в том, что у вас много однотипных задач, которые вы можете делать параллельно, то вещи, которые стандартно поставляются даже встроенные в С++ (Mutex. COndition Variables,...) недостаточны для сложных проблем. Как я уже говорил, прямой обмен данных между threads через какик-то ообщие объекты всегда опасен race conditions и падающей перформанс из-за того, что мутекс и локи неизбежны обычно. Пишутся такие сложные вещи по-другому. Что-то типа такого из этой интересной дискуссии https://news.ycombinator.com/item?id=9905374

Спор очень даже о чем, потому что вы перемещаете объекты, которые могут быть использованы другими тредами.
А что до race conditions, то давно выработаны такие же простые правила, как и о выделении/освобождении памяти, как не выстрелить себе в ногу. Думаю, вы сможете их нагуглить

Надеюсь, что я помог вам с вашим столом!

Увы. я теперь бьюсь в такой истерике, что боюсь лоб об ножку расшибить

[АццкоМото]

Мне на ножки наплевать Не отвлекаемся от указателей.

Какую книжку по С посоветует общественность?

По указателям в С, насколько знаю, есть несколько книжек, я правда читал лишь две, и лучшая из них на мой взгляд by Richard Reese

Жуть.
Если бы мне кто-нить, на заре карьеры, посоветовал бы _книгу_ по указателям - я бы, наверное, до сих пор бы их не понял.

Снежная Королева,
1. переменные располагаются в памяти;
2. положение в памяти однозначно определяется адресом. Ну, грубо - от нуля и дальше;
3. этот самый адрес (ака положение какого-то объекта в памяти) тоже можно записать в переменную;
4. конкретно в C два оператора, оба префиксные (пишутся до аргумента, e.g. &var, *ptr):
1) & - взять адрес переменной;
2) * - разыменовать указатель, то есть взять значение по адресу.

Всё. Внимательно прочитать написанное выше и подумать. Как угодно сложные выражения разбираются "как капуста", слой за слоем, следуя этим же простым правилам.

Плюс к этому - типы именуются в обратном порядке (не совсем точно).
если var имеет тип Type, то &var будет иметь тип Type *, и наоброт, если ptr имеет тип Type *, то *ptr будет типа Type