LINUX.ORG.RU
ФорумTalks

C++ не годится для рогаликов?


0

0

Как вы думаете, почему так мало рогаликов(игр типа ADOM, Nethack) написанных на C++ и с другой стороны так много (почти все из них) написанных на C.

С чем это связано? Ведь модель такой игры должна хорошо ложиться в принципы ООД?

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

Какие еще есть мнения у аналитиков ЛОРа?

Перемещено Die-Hard из Development


Ответ на: комментарий от anonymous

Re^4: Кусочек Сахару Троллям ☺

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

std::string имеет функцию c_str(). Это Вам о чём-нибудь говорит?

gaa ★★
()

Меня поражает агрессия Си-шников и их убежденность, что С++ - это язык "быдлокодеров", а вся парадигма ООП, реализованная на базе Си - не более, чем костыли.
А теперь о том, почему Си, а не Си++.
1. Си - прост и прозрачен ввиду отсутствия ООП-шности
2. Программисты, которые не могут осилить ООП, или которым просто лень, считают так: обходились без него и дальше обойдемся. Они уверены, что ООП - никак не увеличит их производительность и качество кода
3. Бытует мнение, что ООП - это прерогатива проектировщиков, которые и не ведают о том, что такое - программирование.

Однако, это всё глупо, и очень сильно напоминает мне не так давно ушедшие в прошлое баталии Си-шников (Паскалистов и т.д.) и Ассемблеристов. Последние били себя пяткой в грудь: "Да ваши высокоорувневые языки - отстой!"
А что касается, костылей. А чем же явился Си, как не костылём для Ассемблера? - ведь многие низкоуровщевики думают именно так.

Я хочу использовать все приемущества Си и ООП в одном - Си++. некрасиво? На вкус и цвет товарища нет. Но лично меня это вполне устраивает (как и многих других). Да и вообще - я привык к Си++ так же, как многие программисты игр к Си. Консерватизм.....

DenXi
()
Ответ на: комментарий от sergey_feo

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

google://c++ name mangling

Sectoid ★★★★★
()
Ответ на: комментарий от sergey_feo

>Так можно отбить всё желание освоить С++ :-)

осваивать C++ - полезно. вредно знать только C++, и ничего более. но с другой стороны последнее замечание относится в принципе к любому ЯП. кроме LISP'а ;)

>Почему-то все на нём пишут, но все говорят, какой он плохой...

некоторые ещё ищут альтернативы. а некоторые их даже находят :)

>Или не все пишут? Ж:-)

не все

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

> Могу ошибаться, но мне кажется, что С++ и Ява немного перпендикулярны в смысле областей применения

Всякие бизнес-приложения раньше писали на Си++, сейчас - почти исключительно на Яве (или C#)

tailgunner ★★★★★
()
Ответ на: комментарий от sergey_feo

> То есть Си, Си++, дальше по вкусу - формула необязательная?

Си++ сейчас необязателен. Есть более интересные технически и финансово языки.

tailgunner ★★★★★
()
Ответ на: Re^4: Кусочек Сахару Троллям ☺ от gaa

>Второе: За счёт применения char* вместо std::string можно офигительно снизить количество ненужных аллокаций и копирований.

А если применить шаблоны выражений можно еще снизить по сравнению с char*. Хотя шаблоны, конечно, далеко не всесильны. Слабоваты они для полноценного метапрограммирования.

Sectoid ★★★★★
()
Ответ на: комментарий от jtootf

> Tk как раз на C. причём, если мне не изменяет память, на K&R C ;)

Я предпочитаю отделять C от glanguage. А там говорилось про либу, написанную на этом г-языке.

gaa ★★
()

я тут смотрю GObject не раз упомянули и никто не сказал про Objective C.

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

Вообще, если кому интересно, можете глянуть тут http://ru.wikipedia.org/wiki/Objective-C ,там достаточно хорошо описаны все свойства этого языка.

Deleted
()
Ответ на: комментарий от Sectoid

>> Второе: За счёт применения char* вместо std::string можно офигительно снизить количество ненужных аллокаций и копирований.

> А если применить шаблоны выражений можно еще снизить по сравнению с char*. Хотя шаблоны, конечно, далеко не всесильны. Слабоваты они для полноценного метапрограммирования.

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

gaa ★★
()
Ответ на: комментарий от gaa

>Я предпочитаю отделять C от glanguage

тогда прошу меня извинить, г-языка я не знаю :(

jtootf ★★★★★
()
Ответ на: комментарий от gaa

>Ну сохрани мне с помощью шаблонов выражений в одной и той же строке полный путь к файлу и имя файла, не потеряв возможности работать с обоими как со строками

можно пример на C, char* ? не понял задачи :(

jtootf ★★★★★
()
Ответ на: комментарий от gaa

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

Не понял задачу. Кто на ком стоял? Уточните ТЗ.

Sectoid ★★★★★
()
Ответ на: Re^2: C++ не годится для рогаликов? от gaa

>> Ложь + Виляния. Ты отлично знаешь что работоспособность Си-кода можно оценить на глаз если написано чисто. С++ - нельзя. И компилируемость на глаз оценить нельзя.

>Так что там с макросом MAX?

Таки да - почему в С++ он не работает если один из аргументов - int, а другой - short ?

Absurd ★★★
()
Ответ на: комментарий от Deleted

> Лично мне объектная модель Objective С гораздо больше нравится

А как там у него с шаблонами? Подобие STL для него возможно?

sergey_feo
()
Ответ на: комментарий от Sectoid

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

> Не понял задачу. Кто на ком стоял? Уточните ТЗ.

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

gaa ★★
()
Ответ на: комментарий от jtootf

>> Ну сохрани мне с помощью шаблонов выражений в одной и той же строке полный путь к файлу и имя файла, не потеряв возможности работать с обоими как со строками

> можно пример на C, char* ? не понял задачи :(

С char* это будут два указателя: один на начало полного пути, второй -- на начало имени файла. Код примерно такой:

char *lsl = full_name;
while (*lsl++) {}
lsl--;
while (lsl > full_name && *lsl != '/') {
lsl--;
}
if (*lsl == '/' && *(lsl+1) == '\0') {
*lsl = '\0';
is_dir = true;
while (lsl > full_name && *lsl != '/') {
lsl--;
}
}
if (*lsl == '/') {
lsl++;
}
name = lsl;

gaa ★★
()
Ответ на: комментарий от Absurd

>>> работоспособность Си-кода можно оценить на глаз если написано чисто

>> Так что там с макросом MAX?

> Таки да - почему в С++ он не работает если один из аргументов - int, а другой - short ?

Виляния.

gaa ★★
()
Ответ на: комментарий от gaa

>>>> работоспособность Си-кода можно оценить на глаз если написано чисто

>>> Так что там с макросом MAX?

>> Таки да - почему в С++ он не работает если один из аргументов - int, а другой - short ?

>Виляния.

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

Absurd ★★★
()
Ответ на: комментарий от gaa

>Задача: есть полное имя файла. Надо сохранить полное и короткое имя файла для последующего использования, заняв как можно меньше памяти.

>С char* это будут два указателя: один на начало полного пути, второй -- на начало имени файла. Код примерно такой:

>...

Это разные задачи -- в Вашем случае если изменится полное имя файла, короткое имя станет как минимум не валидным. И шаблоны выражений тут ни к чему.

Если вас такое поведение устраивает, что мешает хранить iterator'ы вместо указателей? Для std::string скорее всего все равно первые сделаны посредством вторых.

Sectoid ★★★★★
()
Ответ на: комментарий от Absurd

>Таки да - почему в С++ он не работает если один из аргументов - int, а другой - short ?

А как в общем случае определить какой тип возвращать?

Sectoid ★★★★★
()
Ответ на: комментарий от Sectoid

> Это разные задачи -- в Вашем случае если изменится полное имя файла, короткое имя станет как минимум не валидным. И шаблоны выражений тут ни к чему.

Да. При изменении полного имени -- перечитаю. Благо всё равно иначе никак.

> Если вас такое поведение устраивает, что мешает хранить iterator'ы вместо указателей? Для std::string скорее всего все равно первые сделаны посредством вторых.

Я же сказал "не потеряв возможности работать как со строками".

gaa ★★
()
Ответ на: комментарий от sergey_feo

> Почему не просто name = strrchr(full_name)+1 ?

Это вырвано из реального кода. Там в конце может оказаться слеш, который символизирует директорию и этот случай надо обработать.

gaa ★★
()
Ответ на: комментарий от Sectoid

К слову, насчёт итераторов.
Вот классическая фраза, красивая: ...sort(a.begin(),a.end())...
Но почему a.end относится не к последнему, как заявлено в названии, а к следующему, не существующему элементу? Если begin - это начальный элемент, то почему end - не конечный? :-(
Это туда же, куда if (a = b) - принципиальной интуитивной непонятности С и потомков.

sergey_feo
()
Ответ на: комментарий от Sectoid

>>Таки да - почему в С++ он не работает если один из аргументов - int, а другой - short ?

>А как в общем случае определить какой тип возвращать?

Честно говоря, меня это меньше всего. MAX или std::max - это вообще последнее, в чем могут быть проблемы. Особенно у меня, т.к я их не использую.

Absurd ★★★
()
Ответ на: комментарий от gaa

> Там в конце может оказаться слеш, который символизирует директорию и > этот случай надо обработать.
Ну так name = strrchr(full_name)+1 даёт name = "" - разве это не нормальная обработка?

sergey_feo
()
Ответ на: комментарий от sergey_feo

> Если begin - это начальный элемент, то почему end - не конечный? :-(

Так удобнее писать внутренности stl-я. И ещё, только таким образом можно организовать цикл for (smthg_t::iterator i = smthg.begin(); i != smthg.end(); ++i) {}

gaa ★★
()
Ответ на: комментарий от Absurd

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

Этот макрос -- хороший пример того, насколько нечитаемым может оказаться сишный код.

> А я его не использую, а использую либо if либо тернарный оператор.

Опять главный аргумент фетишистов "мне это не нужно" (c)[string reverse keeg]

gaa ★★
()
Ответ на: комментарий от tailgunner

>Всякие бизнес-приложения раньше писали на Си++, сейчас - почти исключительно на Яве (или C#)

Это не плюсовая ниша. Отсюда он уйдет, почти.

anonymous
()
Ответ на: комментарий от sergey_feo

>> Там в конце может оказаться слеш, который символизирует директорию и этот случай надо обработать.

> Ну так name = strrchr(full_name)+1 даёт name = "" - разве это не нормальная обработка?

В моём случае -- нет.

gaa ★★
()
Ответ на: комментарий от Valeriy_Onuchin

>Yes, C++ is one of the most widely used languages in the industry

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

Absurd ★★★
()
Ответ на: комментарий от sergey_feo

>> К слову, насчёт итераторов. 
>> Вот классическая фраза, красивая: ...sort(a.begin(),a.end())...
>> Но почему a.end относится не к последнему, как заявлено в
>> названии, а к следующему, не существующему элементу? Если begin -
>> это начальный элемент, то почему end - не конечный? :-( 

Тут просто надо привыкнуть. А вообще, это просто напросто к элементам
контейнера не относится. begin() - это начало массива например, а
end() - это его конец. Схематично это можно изобрать вот так:

     .-.-.-.-.-.-.-.-.
begin^               ^end

'-' - это элементы в контейнере, а '.' - это места, куда могут
указывать итераторы.

Deleted
()
Ответ на: комментарий от gaa

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

>Этот макрос -- хороший пример того, насколько нечитаемым может оказаться сишный код.

MAX - это фигня. Сравни код C++ stdlib и код ядра например.

Absurd ★★★
()
Ответ на: комментарий от Sectoid

>IMHO -- никак, он не поддерживает обобщенное программирование.

Нееее.. Тогда не нужен. :D

anonymous
()
Ответ на: комментарий от Absurd

>> Этот макрос -- хороший пример того, насколько нечитаемым может оказаться сишный код.

> MAX - это фигня.

Не фигня, а утиралка носа ц-филам.

> Сравни код C++ stdlib и код ядра например.

Не похожи. :)

gaa ★★
()
Ответ на: комментарий от anonymous

>Я тебе выше уже ответил. Для перехода на плюсы надо изменить способ мышления.

Гость из восьмидесятых? ООП уже используется в 99% языков(в Ц в том числе), и никакого "изменения сознания" тут не требуется, потому что крестовая реализация ООП далеко не фонтан. Или Вы о наборе костылей ака "темплейты и все что с ними связано"?

Sidrian
()
Ответ на: комментарий от sergey_feo

>Так можно отбить всё желание освоить С++ :-) Почему-то все на нём пишут, но все говорят, какой он плохой... Или не все пишут? Ж:-)

Вы наверное ДКЕшнег, если у Вас все вокруг написано на плюсах :)

Sidrian
()
Ответ на: комментарий от Sidrian

> Вы наверное ДКЕшнег, если у Вас все вокруг написано на плюсах :)

Может он просто из гонелиса не вылезает?

gaa ★★
()
Ответ на: комментарий от Absurd

>Честно говоря, меня это меньше всего. MAX или std::max - это вообще последнее, в чем могут быть проблемы. Особенно у меня, т.к я их не использую.

Вы уходите с темы. Вы высказали претензию к C++ -- "почему в С++ он не работает если один из аргументов - int, а другой - short ? ". Я задал Вам вопрос встречный вопрос: а какое на Ваш взгляд поведение в данной ситуации должно быть верным. Вы не ответили.

Sectoid ★★★★★
()
Ответ на: комментарий от gaa

>>> Этот макрос -- хороший пример того, насколько нечитаемым может оказаться сишный код.

>> MAX - это фигня.

>Не фигня, а утиралка носа ц-филам.

Фиговая утиралка носа - устроит?

>> Сравни код C++ stdlib и код ядра например.

>Не похожи. :)

Да, код ядра читать можно, C++ stdlib - нет.

Absurd ★★★
()
Ответ на: комментарий от DenXi

>Я хочу использовать все приемущества Си и ООП в одном - Си++. некрасиво? На вкус и цвет товарища нет. Но лично меня это вполне устраивает (как и многих других).

Проблема в том, что С++ удивительным образом совмещает недостатки Ц с далеко не самой лучшей реализацией ООП.

>Да и вообще - я привык к Си++ так же, как многие программисты игр к Си. Консерватизм.....

А какие Вы еще языки знаете?

Sidrian
()
Ответ на: комментарий от gaa

>> Если begin - это начальный элемент, то почему end - не конечный? :-(
> Так удобнее писать внутренности stl-я.

Мне не кажется, что удобность писать внутренности stl'я оправдывает это безобразие.
А что, если удобнее было бы, если б begin относился к элементу за 16 перед первым, а end вызывал бы exit(123)? Так бы и сделали?
STL надо написать один раз, а людям потом многократно пользоваться.

> И ещё, только таким образом
> можно организовать цикл for (smthg_t::iterator i = smthg.begin(); i
> != smthg.end(); ++i) {}

Изменение названия полностью решает вопрос.
...i != smthg.aft_end()...
Почему-то мне кажется, что оправданием было единообразие с конструкцией while ((c = fgetc(...)) != EOF).

sergey_feo
()
Ответ на: комментарий от gaa

>Задача: есть полное имя файла. Надо сохранить полное и короткое имя файла для последующего использования, заняв как можно меньше памяти.

Это чего, тонкий намек на copy on write? %)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.