structure of arrays - локальность данных лучше

Второй вариант вообще не вариант.

Какиe будут ваши за и против?

Бенчмарки.

Второй вариант прогрессивней, быстрее, удобней и просто иллитней. У тебя набор не связанных друг с другом подсистем. Надёжность, удобность, простота в реализации каждой.

Второй же вариант - убожество для домохозяек. Ни единой объективной причины, кроме скудоумия адептов, ваять так не существует.

Structure of arrays

o_O

И вместо foo(user) делать foo(allUsers, userIndex)?

Без контекста второй вариант - лютый говнокод.

Бенчмарки чего. Зачем нужны бенчмарки в предсказуемом коде?

Хотя ладно, адептам этого не дано. Да и кто их делать? Автора который в код не может - от слова «никак», что даже эквивалент запилить не может. Либо ещё какая некомпетентная балаболка.

А уж рассуждения о бенчмарках без конкретных юзкейсов просто не имеют смысла.

«внезапно», зависит от задачи..

во всяких финансово-биржевых прикладах логичны structure of arrays - данные так прилетают и в подобном-же виде требуется выхлоп.

Ни то, ни другое вообще не c++, это какой-то гребаный си с классами.

И вместо foo(user) делать foo(allUsers, userIndex)?

Чё?

Чё?

Что делать, если в функцию нужно послать одного юзера?

Чаво? Какой второй именно?

А как правильно?

первый же вариант - убожество для домохозяек. Ни единой объективной причины, кроме скудоумия адептов, ваять так не существует.

fix

Почему?

Я не смог распарсить, можно пожалуйста перефразировать мысль?

Что делать, если в функцию нужно послать одного юзера?

Зачем?

Это совершенно разные подходы, а то, что берёшь какую-то ненужную херню их другого подхода и пытаешься на основании неё приводить какие-то доводы - убого.

Эти подходы не взаимозаменяемы - нужен юзер - пиши с юзером. Правда в 80-90% случаев весь юзер нахрен не нужен, даже 50% от него не нужно. И в основном это чистая профанация и блажь, а не довод.

Правильно например хранить объекты в контейнере по значению. И если уж ты используешь контейнеры в первом случае, то почему у тебя во втором какая-то непонятная безразмерная #ерня во все поля?

Второй вариант вообще не вариант.

+1

Какиe будут ваши за и против?

1. Наглядность
2. Прекратите в С++ использовать указатели там, где они не нужны!

16 byte overhead for each vector? each vector performs each own allocation?

А как лучше?

Зависит от задачи, но вообще вариант vector<user> наглядней и практичней в подавляющем числе случаев. И у тебя должна быть веская причина использовать вектор указателей.

Это совершенно разные подходы, а то, что берёшь какую-то ненужную херню их другого подхода и пытаешься на основании неё приводить какие-то доводы - убого.

Можешь привести пример, где не убого применять для пользователей структуру массивов?

А если мне понадобится суммировать money для всех active users?

Structure of arrays - быстрее и удобней. У тебя набор не связанных друг с другом подсистем. Надёжность и простота в реализации каждой.

Быстрее потому, что быстрее в 80% юзкейсов.

Удобней по причине того, что удобнее писать поиск/выборки и прочее + каждое «поле» отдельная подсистема написанная и существующая сама по себе, а это писать удобнее.

Надёжность и простота в реализации следует из предыдущего пункта.

Array of structures - убожество для домохозяек. Ни единой объективной причины, кроме скудоумия адептов, ваять так не существует.

Убожество - везде пихается этот юзер, а в следствии тотальная избыточность в реализации. Всё остальное на нём завязано. Вместо несколько отдельных подсистем ты получаешь адскую жопаболь во всём.

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

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

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

Спасибо. А можно разананимится? Уж очень хочется знать с кем говорю.

Может тебе эта.. для начала книжку какую по плюсам почитать и тупо делать как в ней предлагают? А то же наверняка знаешь пословицу про учение людей богу молиться.

Это кому?

без конкретных юзкейсов

Вот это — в точку.

Можешь привести пример, где не убого применять для пользователей структуру массивов?

Да все.

Выборки по полям, операции над полями - все основные операции. Т.е. операции, которые и подразумевает массив структур, как множество объектов и операции над ними.

Только вот проблема в том, что операции над «объектами» нахрен никому не нужны - везде операции над полями этих объектов.

Где это не работает - это хранение во «внешней» памяти(т.е. памяти с высокой летенси) и прочее. Т.е. какие-то юзкейсы с минимум операций и больше как архивное хранение с редкими выборками отдельных юезеров по индексу, при этом если индекс не прямо, то вся индексация так же строится на «структурамассиве».

Придумать же каких-то реальных юзкейсов, где массив структур будет выигрывать я даже так сходу и не назову.

Ты мне лучше прямо отвечай на вопрос - нахрена в функцию передавать юзера. Какое у неё реальное применение требующие сего действия? Или прямо отвечать у балаболов не принято?

Это кому?

Автору темы, вестимо.

Ясно, а какую именно почитать? Там где что нибудь похожее и рассматривается.

Я итак не «анонимлюсь», ибо мне не нужна идентификация ввиде учётки. Я итак идентифицируюсь прямо по тексту.

А то, что у меня нет учётки - скажи спасибо модераторам.

Правильно так, как принято. А принято массив структур. Всё проверенно - всё работает, примеры и паттерны есть.

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

Стоит ли оно того? Без явной уверенности точно не стоит.

Да и кто их делать? Автора который в код не может - от слова «никак», что даже эквивалент запилить не может. Либо ещё какая некомпетентная балаболка.

Ты не можешь в русский язык.

Ты мне лучше прямо отвечай на вопрос - нахрена в функцию передавать юзера.

Это удобно.
Например: print_user_info(user);

Основания данного высера в студию.

Это удобно.

Меня это не интересует. Что там и кому «удобно».

Например: print_user_info(user);

Как всегда балабол ничего, кроме убогой и бесполезной брехни привести не может.

А чтобы сделать вид, что он не сбрехал - надо просто не копипастить вопрос полностью.

Какое у неё реальное применение требующие сего действия?

Мне нужно реальное применение, а не мистические куллстори.

Т.е. не «мне так удобно», «не пример, который я только придумал и которые просто не имеет смысла за рамками хелворда» и прочей херни.

Второй вариант хорош для алгоритмов на GPU, например. Именно он дает возможность эффективного параллельного чтения/записи данных из/в глобальную память. С «удобным» первым вариантом это, увы, невозможно.

Ок, процитирую тебя ещё раз:

Да и кто их делать? Автора который в код не может - от слова «никак», что даже эквивалент запилить не может. Либо ещё какая некомпетентная балаболка.

Ты мне лучше прямо отвечай на вопрос - нахрена в функцию передавать юзера.

Теперь я точно уверен, что ты ничего никогда не писал. Вообще ничего.

Какое у неё реальное применение требующие сего действия? Или прямо отвечать у балаболов не принято?

Ты же сам писал, что

А уж рассуждения о бенчмарках без конкретных юзкейсов просто не имеют смысла.

Так какой, черт побери, пример реального применения ты тут хочешь?

Второй вариант люто специфичный. Минусы:
1. Удаление и добавление юзера.
2. Логика требующая использования нескольких связанных полей в случае многопоточности превратится в адовый говнокод.
3. Если не лезет в ОЗУ, то начнутся извращения, для того, чтобы раскидать на несколько серверов потребуется блочить всю структуру.

И то и другое говно - вонючие голые указатели, все плохо тупо. Но 1-ое еще терпимо, а второе совсем ужас - например чтобы получить всю инфу пользователя, надо брать индекс и по нему отовсюду инфу получать.

Это эталонного тупняка тред?

От этого треда странное ощущение.

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

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

Потом ещё раз смотришь и думаешь: да нет, хрень какая-то.

В конце концов мозги опухают и ты идёшь спать.

ППКС :)

А как лучше?

Массив структур.
Если ты про указатели, то в 99% применима stl, которая берет управление памятью на себя. В твоем случае, судя по всему, std::vector (хотя я не знаю как и для чего используются твои переменные, может там список, или map, или что-то еще).

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

Скорее всего топикстартер не понимает что такое ООП и как его использовать. И скорее всего в этой ситуации нужен std::map, а не вектор/массив структур. Второй вариант влечет за собой тонны говнокода и утечку памяти.

Ну если там айди сделать порядочным номером в массиве, то будет почти SQL бд.

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

В ООП по-моему все же главная вещь это наследование

На этом можно вырастить отдельную, так сказать, дискуссию :)

:)