АццкоМото писал(а): Ср май 17, 2017 11:55 am
Скажите, а вас не смутила моя фраза "только не рассказывайте мне, что к массиву ВСЕГДА надо обращаться по двойному указателю"? То, что вы имеете в виду было понятно, и кое-где отсталыми умами еще использовалось лет 30 назад.
Нет, конечно. Обращаетесь как обычно.
АццкоМото писал(а): Ср май 17, 2017 11:55 am
Главных проблемы тут две.
1) Вызывающая функция не знает, изменились ли адреса элементов массива или нет. Любая ссылка на, допустим, минимальный элемент массива может внезапно протухнуть. Да, можно хранить индекс и делать двойной дереференсинг каждый раз, но. Единственный смысл использовать С в наше время это когда даже оверхед использования С++ (который невелик, если использовать его с умом) уже неприемлем. И вводить лишний дереференсинг каждый раз просто глупо и расточительно. И в любом случае рано или поздно произойдет выстрел в ногу. Но гораздо хуже другая проблема
Сорри, но если внутренняя функция как угодно работает с массивом, то естественно, что он может поменяться и любой конкретный элемент и минимум и все что угодно. Надо быть очень недалеким человеком, чтобы подсчитать минимум, потом долго работать с массивом в глубинах сибирских руд и затем надеяться, что минимум остался таким же. Вы так все же не делаете, правда?
АццкоМото писал(а): Ср май 17, 2017 11:55 am
2) Единственный "объект" в С, который может относительно естественным способом расти (и, соответственно, "перемещаться") это массив. Исключим экзотику. И вот если вы каждый раз, как в массиве нет места для нового элемента, выделяете новый побольше и копируете в него старый.... то это просто п-ц. С таким подходом нужно забить на С и идти в Жабу, она все стерпит. То, что нужно делать - либо связанный список, либо связанный список массивов, либо массив указателей на массивы. Ну, что-то в этом духе в зависимости от допущений. И все юудет работать быстро, эффективно, в духе С, а никакие "объекты" никогда никуда не будут перемещаться
Массивами пропитаны любой код, это самое распространенное что бывает. Насчет того как хранить, как аллоцировать - у вас опять странные знания. Конечно, никто не делает инкремент на один элемент если ожидает, что это будет часто. Это отдельная наука. Насчет того что массив должен быть массив а не linked list - я думая, что у вас просто мало практического опыта работы с этим объектом. Массив зовется как arr[k]. Вы не можете этого сделать с linked list как бы не старались. Доступ к элементу linked list медленный по дизайну и чем длинней списое тем он медленнее. И очень неудобно работать в дебагере, трудно ловить ошибки и т.п. Недостатки перевешивают достоинтства практически всегда.
Серебряной пули тут нет, именно поэтому в С++ 11 и ввели другие типа контеньеров а не только Vector. Вы похоже тут тоже немного под столом, не все понимаете
АццкоМото писал(а): Ср май 17, 2017 11:55 am
Спор очень даже о чем, потому что вы перемещаете объекты, которые могут быть использованы другими тредами.
А что до race conditions, то давно выработаны такие же простые правила, как и о выделении/освобождении памяти, как не выстрелить себе в ногу. Думаю, вы сможете их нагуглить
Аццко, к multithreading вас точно нельзя допускать, я чувствую вы там такое наваяете, что даже страшно. Я же вам 100 раз говорил, даже ссылку дал, что шерить данные в multithreading это всегда игра с огнем. А вы готовы прошерить первый попавгийся массив. Это локальная переменная в функции, нет в этой функции никакого multithreading, как вообще другой Thread о ней что-то может узнать

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