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

[adda_]

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

Я еще не сказал, но готовлюсь сказать. В смысле на финишной прямой. Что делать я продеставляю глядя на своих сверсников (или тех кто чуть старше), которые на пенсии. И в России и здесь.

[fleshold]

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

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

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

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

Ну K&R же посоветовали, по моему не лучший вариант для "на заре карьеры". Если для начинающего в С, то тут, опять же на мой взгляд, подойдёт Стефан Кочан или Стивен Прата.

[ksi]

Скажите, а вас не смутила моя фраза "только не рассказывайте мне, что к массиву ВСЕГДА надо обращаться по двойному указателю"? То, что вы имеете в виду было понятно, и кое-где отсталыми умами еще использовалось лет 30 назад.

Нет, конечно. Обращаетесь как обычно.

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

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

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

Массивами пропитаны любой код, это самое распространенное что бывает. Насчет того как хранить, как аллоцировать - у вас опять странные знания. Конечно, никто не делает инкремент на один элемент если ожидает, что это будет часто. Это отдельная наука. Насчет того что массив должен быть массив а не linked list - я думая, что у вас просто мало практического опыта работы с этим объектом. Массив зовется как arr[k]. Вы не можете этого сделать с linked list как бы не старались. Доступ к элементу linked list медленный по дизайну и чем длинней списое тем он медленнее. И очень неудобно работать в дебагере, трудно ловить ошибки и т.п. Недостатки перевешивают достоинтства практически всегда.

Серебряной пули тут нет, именно поэтому в С++ 11 и ввели другие типа контеньеров а не только Vector. Вы похоже тут тоже немного под столом, не все понимаете

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

Аццко, к multithreading вас точно нельзя допускать, я чувствую вы там такое наваяете, что даже страшно. Я же вам 100 раз говорил, даже ссылку дал, что шерить данные в multithreading это всегда игра с огнем. А вы готовы прошерить первый попавгийся массив. Это локальная переменная в функции, нет в этой функции никакого multithreading, как вообще другой Thread о ней что-то может узнать ? Я не заострял на этом вопрос, но вы сами напрашиваетесь, повторяя какой-то малосмысленный аргумент раз от разу.

Мне кажется, что вы никогда не писали multithreaded, может быть только простейший на уровне 2x2. Сорри, мне кажется вы не очень хорошо понимате, какие там стоят проблемы. Одновременный доступ к данным, когда хотя бы один из Thread имеет write access туда, - это плохая штука и большая проблема. Очень лего ошибиться и трудно разобраться в ошибках, которые возникают спорадикалли, как тайминг сложится.

[Alexander Troyansky]

ksi, вы мне чем-то напоминаете ребёнка, которому родители купили игрушечную лопатку После получасовой игры песочнице, вы делаете вид, что вы на экскваторе рыли ямы несколько лет

[Nostradamus]

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

[АццкоМото]

Скажите, а вас не смутила моя фраза "только не рассказывайте мне, что к массиву ВСЕГДА надо обращаться по двойному указателю"? То, что вы имеете в виду было понятно, и кое-где отсталыми умами еще использовалось лет 30 назад.

Нет, конечно. Обращаетесь как обычно.

ORLY?

Code: Select all

Data *data = malloc(100*sizeof(Data));
Data *selected = findSelection(data);
updateDataAsKsiProposed(&data);
updateSelected (selected); // PROFIT! SegmentationFault and leg shot

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

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

Давайте передергивать не будем, ага? В вашем примере функция добавляет новый элемент, реаллоцируя, если нужно, массив. И я точно знаю, что минимум останется либо тем же, либо это будет последний элемент массива, ферштейн? К тому же минимум тут вообще иррелевантен. См выше - пусть это будет абстрактный selected, whatever that is.

Массивами пропитаны любой код, это самое распространенное что бывает. Насчет того как хранить, как аллоцировать - у вас опять странные знания. Конечно, никто не делает инкремент на один элемент если ожидает, что это будет часто. Это отдельная наука. Насчет того что массив должен быть массив а не linked list - я думая, что у вас просто мало практического опыта работы с этим объектом. Массив зовется как arr[k]. Вы не можете этого сделать с linked list как бы не старались. Доступ к элементу linked list медленный по дизайну и чем длинней списое тем он медленнее. И очень неудобно работать в дебагере, трудно ловить ошибки и т.п. Недостатки перевешивают достоинтства практически всегда.

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

Аццко, к multithreading вас точно нельзя допускать, я чувствую вы там такое наваяете, что даже страшно. Я же вам 100 раз говорил, даже ссылку дал, что шерить данные в multithreading это всегда игра с огнем. А вы готовы прошерить первый попавгийся массив. Это локальная переменная в функции, нет в этой функции никакого multithreading, как вообще другой Thread о ней что-то может узнать ? Я не заострял на этом вопрос, но вы сами напрашиваетесь, повторяя какой-то малосмысленный аргумент раз от разу.

Мне кажется, что вы никогда не писали multithreaded, может быть только простейший на уровне 2x2. Сорри, мне кажется вы не очень хорошо понимате, какие там стоят проблемы. Одновременный доступ к данным, когда хотя бы один из Thread имеет write access туда, - это плохая штука и большая проблема. Очень лего ошибиться и трудно разобраться в ошибках, которые возникают спорадикалли, как тайминг сложится.

Давайте по-простому. Мультитрединг - это вообще всегда игра с огнем, особенно с вашим уровнем знаний.
И таки давайте вы достанете свой и мы приложим к нему пипкомерку. Я уже сказал, с моим Си-шным кодом в мире были проданы сотни миллионов дивайсов, скорее ближе к миллиарду. И они работают. Предьявите свои достижения, прежде чем развивать свои инсинуации про мой "простейший уровень"

[Alexander Troyansky]

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

Если так задуматься, то это и не так плохо: сохранять активную мозговую активность даже в самой старости - то, что доктор прописал.

[ksi]

Скажите, а вас не смутила моя фраза "только не рассказывайте мне, что к массиву ВСЕГДА надо обращаться по двойному указателю"? То, что вы имеете в виду было понятно, и кое-где отсталыми умами еще использовалось лет 30 назад.

Нет, конечно. Обращаетесь как обычно.

ORLY?

Code: Select all

Data *data = malloc(100*sizeof(Data));
Data *selected = findSelection(data);
updateDataAsKsiProposed(&data);
updateSelected (selected); // PROFIT! SegmentationFault and leg shot

Эта тоже самое, что с min. Если вы знаете, что массив меняется внутри updateDataAsKsiProposed(&data) то надо понимать, что может поменяться все что угодно. Поэтому надо позвать selected = findSelection(data) еще раз. Не звать - это очень плохой стиль. Потому что, даже если сейчас updateDataAsKsiProposed () имплементирована так, что selected не должен поменяться (предположим, что нет даже реаллокации внутри), то завтра придет другой программист, который ничего не знает об этом и поменяет функцию updateDataAsKsiProposed () так что selected уже может поменяться. А вы об этом даже не узнаете. Так нельзя писать, сорри .

Давайте по-простому. Мультитрединг - это вообще всегда игра с огнем, особенно с вашим уровнем знаний.
И таки давайте вы достанете свой и мы приложим к нему пипкомерку. Я уже сказал, с моим Си-шным кодом в мире были проданы сотни миллионов дивайсов, скорее ближе к миллиарду. И они работают. Предьявите свои достижения, прежде чем развивать свои инсинуации про мой "простейший уровень"

Бедный Аццко, ну неужели вы еще не выросли из возраста, когда в качестве главного аргумента в любом споре надо доставать пиписки и ими меряться ? Не говоря уж о том, что тут женщины, Снежная Королева, а вы уже второй день пипиской размахиваете! Давайте лучше по существу вопроса. А еще лучше - о девушках и ножках, а то Комиссар уже потерял терпение я думаю

[Komissar]

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

Я еще не сказал, но готовлюсь сказать. В смысле на финишной прямой. Что делать я продеставляю глядя на своих сверсников (или тех кто чуть старше), которые на пенсии. И в России и здесь.

а что делают Ваши сверстники на пенсии здесь? В РФ я знаю ситуацию.

[M. Ridcully]

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

Code: Select all

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

При чём тут это?
СК хотела понять, что такое указатели. Я постарался объяснить.
Зная основы научиться разбирать сложные выражения - ну, чиста, если вдруг потребуется поддержать разговор за рюмкой чая или тут на Привете - проблем не будет. Практической ценности данный скилл не имеет.

PS: вы, кстати, случайно по клаве били, пытаясь придумать выражение? А то "внутренние" размерности массивов как бы лучше не опускать.

[M. Ridcully]

Не говоря уж о том, что тут женщины, Снежная Королева, а вы уже второй день пипиской размахиваете!

Размахивать пипиской _в отсутствии_ женщин куда как более необычно, ИМХО.

[ksi]

Не говоря уж о том, что тут женщины, Снежная Королева, а вы уже второй день пипиской размахиваете!

Размахивать пипиской _в отсутствии_ женщин куда как более необычно, ИМХО.

Это точно! А Снежной Королевы вроде нет, не онлайн. Предлагаю отложить дуэль на пиписках пока она не появится, а то она пропустит самое интересное! Читать старые посты - это совсем не то, что наблюдать вживую бой на пиписках! И заоодно у спора появиться хоть какой-то смысл

[fleshold]

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

Code: Select all

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

При чём тут это?
СК хотела понять, что такое указатели. Я постарался объяснить.
Зная основы научиться разбирать сложные выражения - ну, чиста, если вдруг потребуется поддержать разговор за рюмкой чая или тут на Привете - проблем не будет. Практической ценности данный скилл не имеет.

PS: вы, кстати, случайно по клаве били, пытаясь придумать выражение? А то "внутренние" размерности массивов как бы лучше не опускать.

Это вряд ли "случайно по клаве", т.к. это школьный пример. Как раз "на заре" изучения указателей проходят. foo - массив из массив из указателей на указатели на функцию возвращающую указатели на массив из указателей на тип char. Вроде так.

[Komissar]

господа программисты, пройдите по указателям в другую тему

здесь ветераны индустрии обсуждают заслуженный отдых

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

Это точно! А Снежной Королевы вроде нет, не онлайн. Предлагаю отложить дуэль на пиписках пока она не появится, а то она пропустит самое интересное! Читать старые посты - это совсем не то, что наблюдать вживую бой на пиписках! И заоодно у спора появиться хоть какой-то смысл

Рыцарский бой в присутствии дамы ... как романтично. Пусть даже на пип ... на чём простите?
А говорят времена не те.