Objective C в С++? , Возможна ли смена парадигмы-принципа без смены компилятора?

Цитата Qraizer @ 12.03.15, 13:13

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

А ты ему банку дай и сможет

Цитата Qraizer @ 12.03.15, 13:13

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

А чего тут холиварного? Что с чем холиварит? Человек тащит идеологию одного языка в другой, при этом реализует всё криво и приправляет графоманскими длиннющими опусами ни о чём.

Сообщение отредактировано: MyNameIsIgor - 12.03.15, 15:14

Ну вот же, MyNameIsIgor, началось же.

Не, нафиг, лучше не надо...

Цитата Kray74 @ 12.03.15, 12:09

Цитата SectorbzC @ 12.03.15, 10:27

Новую переменную?
Тогда добавить в структуру такой конструкт: (не проверял, но работать должно, т.е. технически это легко решаемо)

Напоминаю, что изначально вы задумывали сделать C++ более удобным (если я правильно понял). Приведенный конструкт как-то этой цели не способствует.
К тому же в C++ всегда была важна производительность, а у вас выделения динамической памяти при создании простейшего объекта.

Вы считаете, что не способствует. Аргументируйте.
Например, каким образом производительности будет способствовать перенос с ID + intptr_t на IRootLib (виртуалистику).
Если и то и другое требует сравнения по ID и является периодом исполнения.
При этом виртуальную базу без перекомпиляции библиотеки зачастю изменить невозможно...

P.S. Кстати. Я не знаю, что такое ODR, отвечая понадеялся на компетентность Qraizer.
А вот то, что знаю точно (кстати, у автора данной статьи тоже графомания или кто-то о себе пишет?)
И если это знать с самого начала - может сберечь уйму времени и нервов.
+ Если MyNameIsIgor считает мою реализацию кривой, то пусть покажет свою, прямую.
А воевать с Qraizer он может сколько ему хочется и где ему хочется.

Цитата SectorbzC @ 12.03.15, 16:42

Я не знаю, что такое ODR

One Definition Rule - правило одного определения.
Чтобы все определения какой-то сущности в разных частях программы гарантированно совпадали, эти определения должны быть не просто копиями - они и реально должны быть одним единственным текстом, ссылки на который можно вставлять из разных мест программы. За идентичностью копий сложно следить.

Цитата SectorbzC @ 12.03.15, 16:42

Если MyNameIsIgor считает мою реализацию кривой, то пусть покажет свою, прямую.
А воевать с Qraizer он может сколько ему хочется и где ему хочется.

MyNameIsIgor считает кривой саму идею пытаться в C++ применять неприспособленные для C++ методологии Objective-C. А воевать с Qraizerом он вряд ли будет. В этих вопросах они в основном сходятся. MyNameIsIgor скорее будет воевать с тобой.

Цитата Qraizer @ 12.03.15, 13:13

Добавлено 12.03.15, 13:39

Цитата Kray74 @ 12.03.15, 12:09

К тому же в C++ всегда была важна производительность...

Скорее принцип нулевой стоимости. Вот кстати да, как с этом у Objective C?

Дело не в стоимости (GNU Step вроде как бесплатен). И имеет и такой компилятор и сякой (платны мегафреймворки).
А VC++ не сказать, чтобы совсем бесплатен...
И не в производительности (потому, что если эта производительность за счёт труда программиста, то это отнюдь не всегда производительность, а скорее наоборот).

А в подходах, которые позволяют что-то сделать без неприемлемых трудозатрат, потери времени, переусложнения после которого теряется способность читать код.
Как уже было сказано. То есть в нахождении баланса между читаемостью-доступностью кода, трудозатратами и производительностью.
В целях поиска таких подходов стоило бы изучить и Си и Obj C повнимательнее.
И причём тут я вообще-то? А winAPI - что другой подход? Qt? sf::Event SFML? - Везде сигнал-слот->рефлексия из Obj C/Smalltalk.
Может не единственный подход, но хороший. И гораздо лучше чем без него.

Коротко: трудозатраты должны соответствовать приросту производительности
Иначе получится как в этом диалоге:
http://www.gamedev.ru/code/forum/?id=141595

Система частиц на основе стратегий Александреску.
И мнение разработчика:
Говоря просто - да, я предпочитаю динамический полиморфизм статическому. Какие бы крышерсывающие возможности не давали бы шаблоны, плата за них всегда очень велика (время компиляции, размер кода, требования к подготовке специалистов и т.п.). Но самое главное - динамический полиморфизм позволяет собирать "из кирпичиков" сцену непосредственно художником, без привлечения программистов.

Собирать сцену из кусочков...
Objective-C

software IC. Под этой концепцией понимается возможность собирать программы из готовых компонентов (объектов), подобно тому как сложные электронные устройства могут быть легко собраны из набора готовых интегральных микросхем...

Если компания гигантская, с гигантским накопленным опытом, то она может позволить себе частицы на шаблонах... в противном случае...
Ложка хороша к обеду, т.е. каждый инструмент к своему случаю.
Иначе программист оказывается перед задачей строить небоскрёб в одиночку или небольшой группой.

Цитата SectorbzC @ 12.03.15, 17:27

Дело не в стоимости (GNU Step вроде как бесплатен).

Имеется в виду не цена в фантиках США. А то, что неиспользованные возможности языка и библиотек не должны загружать процессор и увеличивать размер программы. По возможности. Так в C++ если ты не пользуешься к примеру виртуальными функциями, то анализируя откомпилированный код программы ты даже не узнаешь, что такая возможность в языке присутствует.

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

Цитата SectorbzC @ 12.03.15, 18:09

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

У динамического полиморфизма плата не менее велика. И как ты выразился:

Цитата SectorbzC @ 12.03.15, 18:09

Ложка хороша к обеду, т.е. каждый инструмент к своему случаю.

Поэтому использовать везде динамический полиморфизм - глупости и непрофессионализм, тогда проще взять Java и не пурдить мозги людям.

Добавлено 12.03.15, 18:27

Цитата SectorbzC @ 12.03.15, 18:09

плата за них всегда очень велика (время компиляции

Никогда не понимал этого аргумента. Да хоть ночь оно будет компилиться - и что ? Это как то повлияет на конечный продукт? Ах да, извините, придется вместо 5 секунд, ждать 20 секунд, это же не приемлимо для "кул-спецов".

Добавлено 12.03.15, 18:30
Вот у меня был продукт, с частью которого я работал - время его компиляции, только клиента занимала около 2-х часов. Шаблонов там не то что бы было много, там их было столько сколько нужно - даже в разы меньше, чем нужно было. И компилилось все это долго не потому что там в каком то файле затесался шаблон, а потому что продукт был большой. Ну было бы там много шаблонов, и че? Пусть будет компилится оно вместо 2-х часов - 3 часа, да я на ночь как ставил компиляцию свежей версии, так и ставил бы, и ничего это не изменило бы. Но всегда найдется профи с геймдева который обязательно укажет на эту ну просто мега великую плату зп шпблоны!!!!111один

Сообщение отредактировано: Qraizer - 12.03.15, 19:13

to KILLER

1. По ссылке-то? А он там и пишет в каких случаях перименяются шаблоны (применительно к системам частиц).
2. Это повлияет на время отладки в случае поиска ошибки, например.
Или знание машинного кода программисту C++ - прилагается по умолчанию?
Но тогда с машинного кода и нужно начинать обучение С++.
3. На время разработки если для записи в файл/чтения из файла или в GUI каждый раз потребуется программист.

4. А почему столько негатива? У вас ваш случай, у него свой. На Obj C с 1983 уже больше 30 лет пишут коммерческие продукты.
Это факт. Меня например слегка удививший. WinAPI вот. Qt (не последнее GUI?) Тоже применяется. Везде применяется и так мало известно что это-откуда это.

5. Новый интересный подход-инструмент, вполне реализуемый средствами языка это же не причина для негативных эмоций?
Побольше бы таких подходов - разработка стала бы более интересным занятием. Новая переменная классу - пожалуйста. Функция - пожалуйста. Идентификация по ID - пожалуйста. Хоть пер. комп., хоть пер. исп. Хочешь - делай быстрым, но статичным на шаблонах. Хочешь не заморачивайся. Нужны ID + void* - intptr_t - вперёд. Ничто не "застатичивает" возможности. Максимальный набор инструментов и возможностей. Обучить новичков простой отладке на исключениях/2-3 макросах препроцессора и их обучение резко ускорится. Без заний машинного кода. А они придут по мере накопления опыта.

Сообщение отредактировано: SectorbzC - 12.03.15, 19:33

Цитата SectorbzC @ 12.03.15, 16:42

А вот то, что знаю точно (кстати, у автора данной статьи тоже графомания или кто-то о себе пишет?)

Первый пример ровно про ODR, второй... не знаю, насколько он сейчас актуален, статья очень старая про настолько древние компиляторы, что они ни одному Стандарту языка не удовлетворяют.

Добавлено 12.03.15, 19:19

Цитата SectorbzC @ 12.03.15, 18:09

Коротко: трудозатраты должны соответствовать приросту производительности

М-м-м... не соглашусь. Трудозатраты должны окупаться в сапорте. Производительность – лишь один из факторов, да и не самый важный.

Добавлено 12.03.15, 19:26

Цитата amk @ 12.03.15, 18:20

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

Вот, точно. Неиспользуемые в программе возможности языка не стоят для неё ничего. Если я захочу динамический полиморфизм, код потеряет чуть в производительности и разрастётся в размере, но я сознательно на это иду, ибо получаю с этого адекватную, как я оценил, отдачу. Если бы я платил за динамический полиморфизм в программах, его не использующих, то я бы скорее предпочёл Дельфи, там платить за всё сразу и авансом за пять проектов вперёд суть нормальная практика.
Я задавал вопрос касательно принципа стоимости в Objective C. Если я возьму C-программу и откомпилю в Obj-C, сколько придётся заплатить лишнего? А если я не буду расширять интерфейс класса в ран-тайм, насколько более эффективным получится объектный код, если маршалинг сообщений заменить на простые статичные вызовы методов?

Цитата SectorbzC @ 12.03.15, 19:16

1. По ссылке-то? А он там и пишет в каких случаях перименяются шаблоны (применительно к системам частиц).

Применительно к ссылке-то! Он там пишет вообще, а не применительно к системам частиц.

Цитата SectorbzC @ 12.03.15, 19:16

2. Это повлияет на время отладки в случае поиска ошибки, например.

Как?

Цитата SectorbzC @ 12.03.15, 19:16

Или знание машинного кода программисту C++ - прилагается по умолчанию?
Но тогда с машинного кода и нужно начинать обучение С++.

Не совсем понял о чем ты.

Цитата SectorbzC @ 12.03.15, 19:16

3. На время разработки если для записи в файл/чтения из файла или в GUI каждый раз потребуется программист.

Для чего? Я не въезжаю о чем ты. Причем тут шаблоны и статический/динамический полиморфизм?

Цитата SectorbzC @ 12.03.15, 19:16

4. А почему столько негатива?

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

Цитата SectorbzC @ 12.03.15, 19:16

Это факт. Меня например слегка удививший. WinAPI вот.

И чем он тебя удивил?

Цитата SectorbzC @ 12.03.15, 19:16

5. Новый интересный подход-инструмент, вполне реализуемый средствами языка это же не причина для негативных эмоций?
Побольше бы таких подходов - разработка стала бы более интересным занятием. Новая переменная классу - пожалуйста. Функция - пожалуйста. Идентификация по ID - пожалуйста. Хоть пер. комп., хоть пер. исп. Хочешь - делай быстрым, но статичным на шаблонах. Хочешь не заморачивайся. Нужны ID + void* - intptr_t - вперёд. Ничто не "застатичивает" возможности. Максимальный набор инструментов и возможностей. Обучить новичков простой отладке на исключениях/2-3 макросах препроцессора и их обучение резко ускорится. Без заний машинного кода.

Каких негативных эмоций? Где вы их увидели?
Я писал исключительно в контексте того - что процитировал.

Добавлено 12.03.15, 19:38

Цитата SectorbzC @ 12.03.15, 19:16

Нужны ID + void* - intptr_t - вперёд.

Зачем они нужны? Да проще с шаблонами чем с этими ID+void* - intptr_t.

to Qraizer

На счёт этого точно не знаю (сколько заплатить по объёму). Но. Когда компилировал библиотеки под wxWidgets (кроссплатформенные), они все dll, которые лежат в папке win (условно говоря, у неё вроде как свои) линковали к *.exe (т.к. запускаться должно было на любой системе). И получалось окно с *.exe 50-100 мб... или таскать окло 10 dll в папке со всеми ексешниками. А дело было на win XP SP 1, где никаких фреймворков тогда не было (они откуда-то взялись в более поздних версиях win).
Вот я смеялся...

А в Mac OS вроде как некий фреймворк. По аналогии с win. Откуда всё берётся готовое.
Как-то так. Но тут специалист не большой.

Сообщение отредактировано: SectorbzC - 12.03.15, 19:48

Цитата SectorbzC @ 12.03.15, 19:44

На счёт этого точно не знаю (сколько заплатить по объёму). Но. Когда компилировал библиотеки под wxWidgets (кроссплатформенные), они все dll, которые лежат в папке win (условно говоря, у неё вроде как свои) линковали к *.exe (т.к. запускаться должно было на любой системе). И получалось окно с *.exe 50-100 мб... или таскать окло 10 dll в папке со всеми ексешниками.
Вот я смеялся...

А что тут смешного? Есть статическая линковка, есть динамическая. Java программа тоже не будет работать без JVM, А C# программа без .NET Framework. И если первая весит в районе сотни метров, то последней нет предела, можешь тоже посмеятся

Цитата SectorbzC @ 12.03.15, 19:44

А в Mac OS вроде как некий фреймворк. По аналогии с win. Откуда всё берётся готовое.

Ключевое слово тут: вроде как некий фреймворк

Добавлено 12.03.15, 20:04

Цитата SectorbzC @ 12.03.15, 16:42

А вот то, что знаю точно (кстати, у автора данной статьи тоже графомания или кто-то о себе пишет?)

Шырокие у вас познания проблем STL Имеем 2 проблемы - одна высосанная из пальца, вторая устарела морально.