Понедельник, 25 Ноября 2024, 16:07

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 6 из 7
  • «
  • 1
  • 2
  • 4
  • 5
  • 6
  • 7
  • »
Подскажите по языку Python
SaiteiДата: Четверг, 19 Ноября 2015, 00:08 | Сообщение # 101
старожил
Сейчас нет на сайте
Gudleifr, а можете высказать своё мнение "Почему С++ - это зло"? Как бы я интуитивно осознаю все его недостатки, но и абсолютным злом назвать не могу.
OpenGOOДата: Четверг, 19 Ноября 2015, 00:39 | Сообщение # 102
почти ветеран
Сейчас нет на сайте
Цитата Gudleifr ()
А теперь - возьмите C-код и засуньте в C++-компилятор.

В C, например, возможно существование переменной и ф-ии с одинаковым именем в одном пространстве имен.
Но эти формальные отличия ничто по сравнению с "идейными".
Есть три совершенно отличных стиля:
1. Честный C. С упором на однозначность кодирования и максимальным использованием адресной арифметики (а также макросов).
2. "С с //-комментариями". Тупо меняют struct на класс. Плодят тупые конструкторы. Радуются умным указателям. Макросы используются для согласования пространства имен.
3. Классическое ООП с семантическими моделями внешнего мира. В дикой природе не встречается.

Я тоже так могу.
Возьмем вот этот проект для примера An HTML5 parsing library in pure C99 И попробуем собрать его с ходу в MinGW (GCC 4.9 Series) с ключом -std=c99.
Кстати, есть такие компании которые не использует вообще классы, друге STL, третьи исключения и т.д. и с успехом решают свои задачи.


Мои проекты:
- Свободный и открытый клон World Of Goo
- TrueEngine2D (2D игровой фреймворк основанный на FreeBASIC)

[GameMaker: Studio v1.4.9999]
GudleifrДата: Четверг, 19 Ноября 2015, 01:06 | Сообщение # 103
почти ветеран
Сейчас нет на сайте
Цитата Saitei ()
"Почему С++ - это зло"?

C++, как FORTH или Python, вроде бы, предназначен для решения сложных задач методом написания проблемно-ориентированного языка. Но, в отличие от этих двух имеет жуткие ограничения на синтаксис. И проблемно-ориентировааный язык получается на нем тем же C++.
Т.к. большинство программистов терпеть не может сложных задач, то это свойство C++ остается невостребованным (см. того же Элджера - по сути, единственную толковую книгу по С++). С другой стороны, по требованию любителей простых задач в C++ было добавлено куча BASIC-фигни: библиотеки, обезьянники, парадигмы, управляемый код...
Более того, из-за своего корявого синтаксиса C++ в писании оказался гораздо неудобнее C. Поэтому большинство программ пишутся не на нем, а на "C с //-комментариями" (см. Максвелла). Я за более чем 30 лет практики не видел ни одной программы (кроме учебных), написанной в классическом ООП-стиле (Страуструп, Парнас, Элджер).
По сути, С++ - это тот же самый старый добрый PL/1 - единый язык на все случаи жизни, считающий себя умнее программиста. Претендующий на роль единого средства ОС для любого программирования. Как Perl претендует на роль универсального языка скриптописания. Однако, так не бывает, набор простых языков всегда гораздо удобнее. А где набор, там и средства его пополнения. А C++ на это способен все меньше и меньше.

Цитата OpenGOO ()
Кстати, есть такие компании которые не использует вообще классы, друге STL, третьи исключения и т.д. и с успехом решают свои задачи.

Это следствие избыточной универсальности языка. Поэтому я и писал о ненужности изучать C++ заранее - т.к. в каждой фирме свой (упрощенный) стандарт на него. Но никогда ни один C++ программист не пишет на C. Это совершенно разные языки - с разными целями и задачами. Конечно, C++-программист может попытаться написать что-то в C-стиле. Но эти попытки постоянно служат источником неприличного ржача C-шников. Причем, забавное наблюдение: программы на C обычно получаются короче программ на C++.
C, если угодно, вообще не язык программирования. Это просто очень удобный макроассемблер. И, самое главное, внутренний инструмент 'nix-ов. Даже "его библиотеки", на самом деле, не его, а операционной системы. Это только с переносом C на DOS библиотеки стали "довеском к языку".


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Четверг, 19 Ноября 2015, 01:26
AlexRabbitДата: Четверг, 19 Ноября 2015, 01:31 | Сообщение # 104
старожил
Сейчас нет на сайте
Цитата Gudleifr ()
см. того же Элджера - по сути, единственную толковую книгу по С++)

Gudleifr, а почему из списка "толковых" по Вашему мнению выпал Страуструп? Просто когда я начинал писать на плюсах был только он (в напечатанном на матричном принтере толстенном варианте) и Элджера я увидел уже сильно позже (насколько я помню она и вышла то только в 1998 году). Сорри за оффтоп.
OpenGOOДата: Четверг, 19 Ноября 2015, 10:17 | Сообщение # 105
почти ветеран
Сейчас нет на сайте
Цитата Gudleifr ()
Цитата OpenGOO ()
Кстати, есть такие компании которые не использует вообще классы, друге STL, третьи исключения и т.д. и с успехом решают свои задачи.

Это следствие избыточной универсальности языка. Поэтому я и писал о ненужности изучать C++ заранее - т.к. в каждой фирме свой (упрощенный) стандарт на него. Но никогда ни один C++ программист не пишет на C. Это совершенно разные языки - с разными целями и задачами. Конечно, C++-программист может попытаться написать что-то в C-стиле. Но эти попытки постоянно служат источником неприличного ржача C-шников. Причем, забавное наблюдение: программы на C обычно получаются короче программ на C++.
C, если угодно, вообще не язык программирования. Это просто очень удобный макроассемблер. И, самое главное, внутренний инструмент 'nix-ов. Даже "его библиотеки", на самом деле, не его, а операционной системы. Это только с переносом C на DOS библиотеки стали "довеском к языку"

С++ программисту и не надо писать в стиле С (К&R), ведь С++ лучше С.


Мои проекты:
- Свободный и открытый клон World Of Goo
- TrueEngine2D (2D игровой фреймворк основанный на FreeBASIC)

[GameMaker: Studio v1.4.9999]
GudleifrДата: Четверг, 19 Ноября 2015, 11:13 | Сообщение # 106
почти ветеран
Сейчас нет на сайте
Цитата AlexRabbit ()
Gudleifr, а почему из списка "толковых" по Вашему мнению выпал Страуструп?
На самом деле, я долго выбирал слово, чтобы охарактеризовать то, что отличает книгу Элджера от других. Остановился на "толковой" в смысле "растолковывающей", "толкующей". Я не знаю другой книги по C++, которая бы настолько глубоко погрузилась бы в специфику языка.
Страуструп? Первое издание просто никуда не годилось. Какое-то пречисление "а у меня вдруг вот так получилось", абсолютно без системы. Во втором, он, правда, исправился и ввел пару глав про то, "зачем все это надо" и "как надо". А затем, оказалось, что "нафиг не надо" и пошли просто справочники.
Цитата OpenGOO ()
С++ программисту и не надо писать в стиле С (К&R), ведь С++ лучше С.
Кому как. Я пользуюсь C++ только в случае производственной необходимости. Все хотел привести забавную табличку из Кернигана и Пайка. Задача: генератор бессмысленных сообщений на основе марковских цепочек:

Язык ::: 250MHz R10000 © ::: 400MHz Pentium II © ::: Строки исходного кода
С ::: 0.36 ::: 0.30 ::: 150
Java ::: 4.9 ::: 9.2 ::: 105
C++/STL/deque ::: 2.6 ::: 11.2 ::: 70
C++/STL/list ::: 1.7 ::: 1.5 ::: 70
Awk ::: 2.2 ::: 2.1 ::: 20
Perl ::: 1.8 ::: 1.0 ::: 18

Т.е. мы видим выигрыш от применения STL (на C нам надо самим программировать списки).
Но, во-первых, он не сравним, с удобством специализированных "BASIC-ов", а, во-вторых, какой ценой!
Более того, в случае более сложной задачи "изготовление своих структур" будет занимать все меньшую долю. А в случае "очень сложных структур" их все равно придется делать самому.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Четверг, 19 Ноября 2015, 11:14
FlyOfFlyДата: Четверг, 19 Ноября 2015, 11:31 | Сообщение # 107
заслуженный участник
Сейчас нет на сайте
Цитата Gudleifr ()
C++/STL/deque ::: 2.6 ::: 11.2 ::: 70
C++/STL/list ::: 1.7 ::: 1.5 ::: 70

для тебя C++ это только STL ? C++ это C с ООП, а классы куда удобнее чем структуры


Сообщение отредактировал FlyOfFly - Четверг, 19 Ноября 2015, 11:31
GudleifrДата: Четверг, 19 Ноября 2015, 11:45 | Сообщение # 108
почти ветеран
Сейчас нет на сайте
Цитата FlyOfFly ()
классы куда удобнее чем структуры
Опять же, кому как. Я тут уже где-то писал, что есть три вида внедрения ООП. Какой из них Вам кажется удобным?

Кстати, с точки зрения гибкости замены структур на классы Python гораздо гибче.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
FlyOfFlyДата: Пятница, 20 Ноября 2015, 11:46 | Сообщение # 109
заслуженный участник
Сейчас нет на сайте
Цитата Gudleifr ()


Кстати, с точки зрения гибкости замены структур на классы Python гораздо гибче
Код

struct name{
int a;
};

легко меняется в C++ на
Код

class name{
public:
  int a;
};

ну это уже говнокод


Сообщение отредактировал FlyOfFly - Пятница, 20 Ноября 2015, 11:46
GudleifrДата: Пятница, 20 Ноября 2015, 11:52 | Сообщение # 110
почти ветеран
Сейчас нет на сайте
FlyOfFly, это к чему? Я спросил о целях такого преобразования:
1. Для построения иерархической семантической вселенной программы.
2. Для совместимости с OO-библиотеками
3. Для инкапсуляции отдельных фрагментов вычислений
На каком из этих путей Вы видите выгоды?


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
FlyOfFlyДата: Пятница, 20 Ноября 2015, 11:54 | Сообщение # 111
заслуженный участник
Сейчас нет на сайте
Цитата Gudleifr ()
FlyOfFly, это к чему? Я спросил о целях такого преобразования:
1. Для построения иерархической семантической вселенной программы.
2. Для совместимости с OO-библиотеками
3. Для инкапсуляции отдельных фрагментов вычислений
На каком из этих путей Вы видите выгоды?

Посмотри на что я ответил, ты ответил что на Pythone проще, я ответил что и на C++ не трудно
GudleifrДата: Пятница, 20 Ноября 2015, 12:04 | Сообщение # 112
почти ветеран
Сейчас нет на сайте
Цитата FlyOfFly ()
Посмотри на что я ответил, ты ответил что на Pythone проще
Не проще, а гибче. Там можно не тупо переименовать структуру в "обычный" объект, но изобрести нечто среднее между структурой и объектом. Или более сложное, чем объект.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
OpenGOOДата: Пятница, 20 Ноября 2015, 12:13 | Сообщение # 113
почти ветеран
Сейчас нет на сайте
Структура
Код
struct Name{
int a;
};

Класс
Код
struct Name{
Name(int val) : a(val) {}
int a;
};

А то что в питоне классы можно строить в рантайме, то это уже не заслуга питона )


Мои проекты:
- Свободный и открытый клон World Of Goo
- TrueEngine2D (2D игровой фреймворк основанный на FreeBASIC)

[GameMaker: Studio v1.4.9999]
kalumbДата: Пятница, 20 Ноября 2015, 14:03 | Сообщение # 114
почетный гость
Сейчас нет на сайте
Всё-таки для написания игр лучше, конечно, использовать компилируемый язык. С++ отлично для этого подходит.
8Observer8Дата: Пятница, 20 Ноября 2015, 14:28 | Сообщение # 115
заслуженный участник
Сейчас нет на сайте
Цитата kalumb ()
Всё-таки для написания игр лучше, конечно, использовать компилируемый язык. С++ отлично для этого подходит.

Нет. Лучше использовать движок, который написан на C++, а скрипты писать на JavaScript, Lua, Python, C# и т.д. C++ для скриптинга сложноват в сопровождении, так как требует повышенного внимания и осторожности.


Сообщение отредактировал 8Observer8 - Пятница, 20 Ноября 2015, 14:30
FlyOfFlyДата: Пятница, 20 Ноября 2015, 14:32 | Сообщение # 116
заслуженный участник
Сейчас нет на сайте
Цитата 8Observer8 ()
Нет. Лучше использовать движок, который написан на C++, а скрипты писать на JavaScript, Lua, Python, C# и т.д. C++ для скриптинга сложноват в сопровождении, так как требует повышенного внимания и осторожности.

Лучше(не для времени) написать свой движок на C++ с своим скриптовым языком .MYS и на нём делать игру
8Observer8Дата: Пятница, 20 Ноября 2015, 14:43 | Сообщение # 117
заслуженный участник
Сейчас нет на сайте
Цитата FlyOfFly ()
Лучше(не для времени) написать свой движок на C++ с своим скриптовым языком .MYS и на нём делать игру

Зависит от требований. Под мои требования подходит Unity. А есть, конечно, другой путь - написать свой движок, как сделали три программиста, которые написали XRay, на котором был сделан Сталкер.

Добавлено (20 ноября 2015, 14:43)
---------------------------------------------
Цитата FlyOfFly ()
с своим скриптовым языком .MYS и на нём делать игру

Просто до игры может дело не дойти. А если профиль широкий, то есть хочется писать под разные платформы и игры разных жанров, да и ещё нужно делать неигровые 3D-приложения, то однозначно готовый движок. Пока свой движок напишешь, то можно с голоду умереть.


Сообщение отредактировал 8Observer8 - Пятница, 20 Ноября 2015, 14:50
XakepДата: Пятница, 20 Ноября 2015, 15:49 | Сообщение # 118
めちゃくちゃちゃ
Сейчас нет на сайте
Цитата Gudleifr ()
3. Для инкапсуляции отдельных фрагментов вычислений

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

Цитата FlyOfFly ()
Лучше(не для времени) написать свой движок на C++ с своим скриптовым языком .MYS и на нём делать игру

если это не 2д игра, то нет, в целях образование да, очень даже полезно, на практике же лечше использовать хорошо отлаженный и гибкий движок.
8Observer8Дата: Пятница, 20 Ноября 2015, 15:58 | Сообщение # 119
заслуженный участник
Сейчас нет на сайте
Цитата Xakep ()
если это не 2д игра

Да даже если и 2D, то например, на Unity есть удобные инструменты, которые здорово экономят время: Mechanim (для анимаций), Sprite Editor (для наризки спрайтов), Curve Editor (если процессы по кривым идут), 2D-физика и API движка. У своего движка есть недостаток, что если один не справляешься и нужны напарники, то будет сложно научить работать на своём движке, а на готовый и популярный проще будет найти соратников.


Сообщение отредактировал 8Observer8 - Пятница, 20 Ноября 2015, 16:00
XakepДата: Пятница, 20 Ноября 2015, 16:00 | Сообщение # 120
めちゃくちゃちゃ
Сейчас нет на сайте
Цитата 8Observer8 ()
Да даже если и 2D, то например, на Unity есть удобные инструменты, которые здорово экономят время: Mechanim (для анимаций), Sprite Editor (для наризки спрайтов), Curve Editor (если процессы по кривым идут), 2D физика и API движка. У своего движка есть недостаток, что если один не справляешься и нужны напарники, то будет сложно научить работать на своём движке, а на готовый и популярный проще будет найти соратников.

ну да, только вот редактор карт ужасный, придется много докупить на AssetStore, хотя смотря какая игра.
  • Страница 6 из 7
  • «
  • 1
  • 2
  • 4
  • 5
  • 6
  • 7
  • »
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг