Войти
ФлеймФорумОбщее

Что лучше для геймдева?с, с++ или с#? (4 стр)

Страницы: 13 4 5 616 Следующая »
#45
11:04, 10 фев. 2011

Sbtrn. Devil
> Укажи решение указанной проблемы, не влекущее за собой граблей и последствий, с
> высоты великого знания языка. И только потом критикуй моё обоснованное мнение.

1) Я СиШарп знаю поверхностно.
2) Тебе предложили заменить на класс.
3) Как я понимаю суть проблемы, то просто возвращается ГРУБО ГОВОРЯ константный референс на объект (не совсем так, но чемто похоже). Расскажи как бы ты решил это на Си++, глядишь и на СиШарпе сделаешь.


#46
11:12, 10 фев. 2011

Zakus
> - Завтра захочется написать игру для телефонов на андроиде,
> и придется писать на Java, послезавтра на WP7, и нужно будет писать С#,
> а потом на симбиан к примеру, и нужен будет С++, через неделю javascript и
> HTML.
> Все просто - умей делать игры/программы на всем или "умри".
+500

#47
11:13, 10 фев. 2011

Executor
> то просто возвращается ГРУБО ГОВОРЯ константный референс на объект (не совсем
> так, но чемто похоже)
Насколько я понимаю возвращается копия объекта. Референс вернется в случае класса. Кастую очередную реинкарнацию нихтмареза в тред. Или он уже здесь?

#48
11:58, 10 фев. 2011

Executor
> 1) Я СиШарп знаю поверхностно.
Вот и не критикуй. :)

> 2) Тебе предложили заменить на класс.
Я написал, какие грабли это за собой влечёт. Для копирования объекта (а оно потому и структура, что подразумевается его частое копирование) придётся вводить ручками специальную фукнцию, что повлечёт за собой необходимость прописывать ручками её вызов и во всех случаях, когда этот объект будет агрегированным в другие, которые мы желаем сделать копируемыми, и т. д.

> 3) Как я понимаю суть проблемы, то просто возвращается ГРУБО ГОВОРЯ константный
> референс на объект (не совсем так, но чемто похоже).
Нет, суть проблемы в том, что оператор [] из List<объекты> возвращает ссылку на элемент, как и ожидалось, а оператор [] из List<структуры> возвращает копию элемента. Которая, соответственно, не является lvalue и не подлежит поэлементной модификации. Такова, видите ли, семантика value-type типов.
Родственная проблема - foreach над контейнером на предмет изменения некоторых элементов по заданному критерию. Тут о ней уже вопрошали, и в ответ тоже не смогли предложить ничего более путного, чем преобразовать структуру в объект. Ещё одна родственная проблема: в .нете есть синхронизационный класс Monitor и связанная с ним конструкция lock (объект) { ... } - суть критическая секция доступа к "объект"-у. Применять это можно только над объектами, а не над структурами, т. к. попытка применения над структурой приведёт где-то внутрях Monitor-а к её копированию, и секция будет создана не над самой структурой, а над её копией, а потом будет фейл, когда в конце секции, в попытке её разлочить, будет создана секция над ещё одной копией. При этом - ахтунг! - о том, что этого нельзя делать, должен помнить сам программизд, а с точки зрения компилятора такое можно. Ибо классы и reference-типов, и value-типов, при всех своих фундаментальных различиях, считаются производными от одного и того же базового класса object. О какая логика.
Там ещё много основанных на этом граблей, которые приходится затыкать посредством диких полулогичных ограничений (вроде невозможности у структуры конструктора по умолчанию), или которые так и остаются незаткнутыми.
При этом, например, оператор [] из массива работает так, как и ожидается (с точки зрения описанного случая с поэлементным изменением). И при этом же выражения лист[...] и массив[...] считаются семантически одинаковыми. Каково?

> Расскажи как бы ты решил
> это на Си++, глядишь и на СиШарпе сделаешь.
На C++ такой противоестественной проблемы не возникает в принципе. Каждый тип - класс, у него возможны как инстансы, так и указатели/ссылки на него, переменной (объектом) может быть и то, и другое, и что именно нам нужно, мы всегда недвусмысленно указываем при декларации типа переменной. Оператор присваивания всегда имеет смысл замещения содержимого одного инстанса содержимым другого. Если мы пишем "xxx = чё-то", то всегда очевидно, что xxx имеет семантику неконстантной ссылки на объект, который и изменяется.  Если мы пишем "xxx.yy = чё-то", а xxx - выражение, подразумевающее добычу мутабельного элемента, очевидно, что это xxx.yy имеет семантику неконстантной ссылки. Никаких исключений из правила. Причём оператор = при необходимости (захотели новый тип ссылок-указателей) можно ещё и перегружать.
Всё очень просто, более гибко, и для этого привлекается меньше различных сущностей и неявно подразумеваемых махинаций.

#49
12:10, 10 фев. 2011

Sbtrn. Devil
> Вот и не критикуй. :)

Ты же не знаешь и критикуешь, почему я не могу? :)

> На C++ такой противоестественной проблемы не возникает в принципе.

А как же stl vector?

> Если мы пишем "xxx = чё-то", то всегда очевидно, что xxx имеет семантику
> неконстантной ссылки на объект, который и изменяется. Если мы пишем "xxx.yy =
> чё-то", а xxx - выражение, подразумевающее добычу мутабельного элемента,
> очевидно, что это xxx.yy имеет семантику неконстантной ссылки. Никаких
> исключений из правила. Причём оператор = при необходимости (захотели новый тип
> ссылок-указателей) можно ещё и перегружать.

Совсем не очевидно. В Си++ это может не компилится.

#50
12:12, 10 фев. 2011

Sbtrn. Devil
Походу ты себе проблем на одно место напридумывал. Если очень надо перформанс, можно написать собственный специфический контейнер, прочем как и в С++...

#51
12:12, 10 фев. 2011

Sbtrn. Devil
судя по тому что ты говоришь ты знаешь с# менее чем поверхностно, узнай разницу между struct и class
class - это ссылочный тип, всегда передается по ссылке, а struct всегда по значению

list[x] в случае класса возвращает ссылку на него, а в случае структуры возвращает саму ее полностью
потому в случае структуры строчкой list[x].x = 1 ты пытаешься изменить временный объект на стеке

c# это не замена с++, это совсем другой язык, и у нему нужен другой менталитет программирования чуть менее чем полностью
если ты решил задачу на с++, то решать ее таким же методом на с# грубая ошибка

#52
12:58, 10 фев. 2011

>С++ кроссплатформенность, скорость, но затраты для разработки большие(скорость написания кода, время на изучение)
Я его изучил за 2 недели, ещё 2 недели потренировался, и уже стал почти всё понимать.

C# мне показался очень удобным. Я даже хотел сделать на нём движок, но у меня он уже был начат на C++ и, насколько я знаю, на C# есть только XNA, а он, по-моему, работает только на DirectX 9, поэтому нет никакой перспективности у такого движка.

#53
12:59, 10 фев. 2011

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

и так далее: типа покажите мне самые толстые деревья в вашем лесу)))...

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

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

#54
13:02, 10 фев. 2011

Sbtrn. Devil
> Укажи решение указанной проблемы, не влекущее за собой граблей и последствий, с
> высоты великого знания языка. И только потом критикуй моё обоснованное мнение.

МСДН советует делать так:

var item = list[i];
item.x = 5;
list[i] = item;

Проблема чемто похожа на проблему с property в Делфе/СиШарпе/Си++.
Как тут верно заметили, можно действительно просто написать свой контейнер.

#55
13:15, 10 фев. 2011

Sbtrn. Devil
Ты выдумываешь проблемы, которые реально не существуют.
В твоем примере стоит использовать классы вместо структур и все.
И в чем проблема собственно с копированием? Тяжело написать две строчки?

Генератор PDF на C#, CRM, сложное CRM подобное веб приложение с тонной
особых правил, и автоматических действий, 2D двиг на C# и XNA - со сценой,
колизией, GUI, анимацией и прочим, пару мелких утилиток.
И нигде не возникало проблем с классами и копированием. Да и копирования практически не было.
Конвертация из одного типа в другой - было много. Создание объекта с заполнением полей - было.
Копирование - на фоне всего остального, повторяю, практически не было.

И тут ты заявляешь, что плохой, плохой, кривой C#. Невозможно с ним работать из за лишнего Copy.
Может твоя ошибка в том, что ты взял С#, а пытаешься писать на С++?

Глупо ожидать что бы на языке N все было также как и на языке M, иначе это был бы один язык.

#56
13:20, 10 фев. 2011

gammaker
>насколько я знаю, на C# есть только XNA, а он, по-моему, работает только на DirectX 9, поэтому нет никакой перспективности у такого движка.
http://slimdx.org/ - DirectX 11.
А в крайнем случае, можно всегда написать врапер для dll ручками, за одно сделать доброе дело для других, что бы они не писали.
Тем более для многих игр DirectX 9 будет хватать ещё несколько лет.
Но хочешь DX11 - нет проблем, есть slimdx (врапер который написали добрые люди, потому что им не лень, и они не тратят свое время на холиварные форумные темы).

#57
13:56, 10 фев. 2011

Если руки правильно заточены - язык не важен.

#58
15:17, 10 фев. 2011

Я думаю что все издержки C# являются его светлой стороной, так как помогают писать более прозрачный код :)

Мне вот это больше нрав.

var item = list[i];
item.x = 5;
list[i] = item;
Чем это
list[i].x = 5;

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

#59
15:45, 10 фев. 2011

Исключительно Plain C с чем нибудь высокоуровневым. C++ не нужен, слишком много геммороя из воздуха.

Страницы: 13 4 5 616 Следующая »
ФлеймФорумОбщее

Тема в архиве.