Окей, подождите, хорошо, умный указатель.. а че с new/delete этот

код каким-то не рабочим становится или с ошибкой или что?

Память у тебя улетит где-нибудь, потом будешь бегать искать.

а у тебя есть гарантии, что в FStruct'е который ты создал, нет ничего контролируемого GC, например

А умные указатели в анриле как-то учитывают наличие GC?

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

Я думаю на это всё-таки было бы неплохо всегда рассчитывать. Без фанатизма, конечно, но учитывать. Даже не столько расширение, сколько просто поддержку.

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

окей, пасиба, понял не знал, что это возбраняется

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

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

Ты же можешь указывать пути к ассетам и сабклассы через I I

Привет) Можно пример?)

Я думал, что бы злой двойник Кермита, а ты он и есть, оказывается :)

а, через ini, всё понял)

Ты всегда должен понимать, что: а) не все йогурты одинаково полезны б) говнокод есть у всех. у гугла. у майкрософта. у всех есть свой говнокодец. в) наличие говнокода и bad practice может быть обусловлено легаси, а может быть культурой Если легаси - то тут как бы вопрос хочешь ты с этим жить и работать, или нет. Если культурой - то вопрос аналогичный, но имхо бежать подальше, т.к. учит плохому. В тестовых все тоже придумывают свое. Они тестят насколько ты подходишь им, а ты - насколько они подходят тебе. Процесс обоюдный.

д ну да) я сменил ник)

по последнему обзацу: я понимаю, но я претендовал на джуна, мне кажется подобные практики человек должен получать уже в компании. В ином случае откуда он их возьмет? Если только вот таких тестовых штук 10 переделает.

надоел мне Кермит, если честно. а MSTR у меня еще лет 10 назад появился)

В случае с умными указателями, это всё-таки базовая практика в С++, это не специфичный момент.

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

я читал умные книги, как раз которые ты советовал (Столярова) - вот у него как раз всё через голые указатели в плюсах =) сейчас еще кое-что почитать нашел

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

ну это разве плохо?

Не плохо, это один из подходов для старта. Главное вовремя осознать это и изучить другие стороны языка

Нет, конечно. Но если ты не работаешь с UObject framework, то только умные указатели. Но в них можно и UObject складывать, они их не трогают никак. А сборщик мусора почистит.