Здравствуйте, Northaunt, Вы писали:

N>Я начинающий программист на С++, ищу работу. Часто просят отослать пример кода. Вот только, после того как я пересылаю его, на другой стороне полная тишина. Я каждый раз объяснял, что сложных, хорошо написанных и спроектированных программ у меня нет (мои проекты связаны с 3D графикой, я акцентировал усилия только на ней, к сожалению) и просил тестовое задание, но не помогало. Посмотрите, пожалуйста, кто-нибудь код и укажите на самые фатальные ошибки, из-за которых меня сразу же посылали в черный список. Всего два класса. Все действия, которые там есть, это: инициализировать нужные ресурсы, установить различные состояния для отрисовки, посчитать и отрендерить, что нужно, затем удалить навсегда.

N>

N>#include "..\..\- Mein\GameApp.h"
N>#include "..\..\Service\Service.h"
N>

Я бы дальше читать не стал. По ссылкам черти откуда черти куда видно, что в проекте полный бардак (некоторые "профессионалы", впрочем, так и пишут — поубивал бы!)

Конструктор копирования (канонический) принимает константную ссылку, а не указатель. Кстати, в данном случае CCamera::CCamera( const CCamera * pCamera ) ничего не берет от pCamera, а просто сбрасывает свои внутренности (так и задумывалось?). И, раз уж он принимает указатель, может быть, нужно его сделать explicit.

Ну, и дизайн.. SetViewport, будучи публичным, принимает тонну параметров, среди которых указатель на d3d-устройство. Много параметров в публичном методе -- это нездорово: во-первых, люди их попросту путают, а потом мучительно разбираются, в чем дело; во-вторых, не смотря на то, что их много, впоследствии их все равно может оказаться мало, и сломается дизайн -- поэтому более кошерно в данном случае было бы объявить интерфейсную структуру и передавать указатель на нее. Наконец, pDevice -- это вполне себе конкретный девайс, которого лучше бы представить доп.интерфейсом, чтобы можно было работать не только с d3d, но и с чем-нибудь еще. Это устройство, как видно, получает указатель на Viewport данной камеры. Вопрос в том, совпадает ли этот pDevice с теми, что передаются в качества параметров методам UpdateRenderXXX? Не следовало ли спрятать указатель на конкретное устройство (разумеется, представленное абстрактным интерфейсом) внутрь CCamera, поскольку связь между CCamera и тем устройством все равно устанавливается?
И последнее. Если я правильно понимаю, CCameraFirstPerson, видимо, предполагает, что если точек наблюдения будет пять, то для каждой придется делать свой класс, наследуемый от CCamera? Как-то это нездорово.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>На мой взгляд, значительно лучше. Правда, обработка ошибок так и не появилась. Или это в графических приложениях не принято?

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

Здравствуйте, Northaunt, Вы писали:

N>Я начинающий программист на С++, ищу работу. Часто просят отослать пример кода. Вот только, после того как я пересылаю его, на другой стороне полная тишина.

N>#include "..\..\- Mein\GameApp.h"
N>#include "..\..\Service\Service.h"
После этих строк — пришлось заставлять себя смотреть исходники дальше (впрочем, уже совершенно поверхностно), естественно, при реальном разборе — сразу "нет". В основном из-за пробела, но и вообще включение чего-то из .. — ? Плохо спроектированные модули, как минимум. (при этом то же самое как "Main/GameApp.h" — гораздо лучше уже)

Здравствуйте, Northaunt, Вы писали:

N>Да уж, отсылать это было ошибкой. Спасибо тем, кто заставил себя просмотреть все.

N>#include "\Mechanic\CPlayer.h"
Можете пояснить, что именно здесь включается?

Здравствуйте, Northaunt, Вы писали:

К уже сказанному добавлю, что передаваемые параметры нужно проверять. Вот в этом месте (и в некоторых других) всё упадёт, если переданный указатель окажется невалидным:

//-------------------------------------------------------------------------
//    ClearTexture
//-------------------------------------------------------------------------
void Fluid3D::ClearTexture(IDirect3DTexture9* texture)
{
    texture->GetSurfaceLevel(0, &RenderSurface);
    Device->SetRenderTarget(0, RenderSurface);
    Device->Clear(0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER | D3DCLEAR_STENCIL, 0x00000000, 1.0f, 0);
    
    Device->SetRenderTarget(0, BackBuffer);
}

Здравствуйте, Handie, Вы писали:

H>Возможно код будет кому-то в тему, но в общем случае я бы продпочел "чистый" код без идиотических API типа DirectX.

+1 Я думаю, выложенный код плохо подходит для демонтсрации навыков и стиля программирования. API DirectX действительно идиотический, впрочем более чем все API идиотические.

Здравствуйте, Nuseraro, Вы писали:

Ytz>>Это предсказуемо, так как много кода непонятного назначения. Вот у меня сразу вопрос — какую задачу решает код? Поэтому:
Ytz>>1. Выкинь свой код
N>...

N>К сожалению Ytz прав, таких людей чтобы заценили сложность программирования решения уравнений Навье-Стокса немного.

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

Код на Си с искуственно вставленными классами, с заинлайненными операциями перемножения матриц и без использования контейнеров мало кому понравится.

Что-то тут все мусолят, то не то, это не то.
А помоему ненадо так глубоко копать, проблемма то в том, что этот демонстрационный код — демонстрирует использование Microsoft Direct3D, а не умение программировать 3D графику. аля DirectX SDK Sample.

Здравствуйте, Denis Mingulov, Вы писали:

N>>#include "\Mechanic\CPlayer.h"
DM>Можете пояснить, что именно здесь включается?

Класс, который представляет игрока в сцене и все что с ним связано. Он назван CPlayer, поскольку указатель на его экземпляр хочется назвать Player (указатель я юзаю чаще, чем имя класса, следовательно, идентификатор у него должен быть лаконичней), наверняка, решение не из лучших, но поиск по «Class and Variable same name» не дал результатов. Вроде ответил, но у меня такое ощущение, что вы про другое спрашивали?


Про обработку ошибок. Например, в случае использования DirectX. Если я не ошибаюсь, каждую библиотечную функцию, которая может меня подвести, не создав текстуру либо шейдер, нужно обернуть подходящей проверкой. Следовательно, получиться набор клонов библиотечных функций, но с проверкой. Много времени не займет, но это целый новый неймспейс, а в моем случае, целый новый неймспейс ошибок. В общем если я прав насчет схемы и это существенно улучшит общую картину, нужно сделать? Но я, конечно же, ошибаюсь, подскажите, пожалуйста, как сделать правильно.

Насчет использования API. В ближайшее время я напишу что-нибудь без сторонних библиотек, полностью для демонстрации. Ну а на данный момент, это все, что у меня есть. Тем более, я пока еще пытаюсь попасть в геймдев. Возможно, они иногда обращают внимание на работу с библиотеками (хотя не на что там смотреть)
Кстати, как минимум в одной компании мой код не вызывает жалость и слезы, хотя, наверняка, просто исходники криво прилепись к письму и никто не смог их прочитать, к счастью. Завтра узнаю.

Здравствуйте, Northaunt, Вы писали:

N>>>#include "\Mechanic\CPlayer.h"
DM>>Можете пояснить, что именно здесь включается?
N>Вроде ответил, но у меня такое ощущение, что вы про другое спрашивали?
Да. В общем-то спрашивал, почему на '\' начинается.

Здравствуйте, Denis Mingulov, Вы писали:

DM>Да. В общем-то спрашивал, почему на '\' начинается.

Да, виновен. Это из-за моих верхних конечностей, бывают ложные срабатывания, Ctrl+Z в данном случае.

Здравствуйте, Northaunt, Вы писали:

N>Да уж, отсылать это было ошибкой.

в обоих примерах нет комментариев. и оба используют "С с классами", что не годится если ты претендуешь на general-purpose C++ программиста. сразу видно что ты не знаком с boost, синхронизацией и прочими богами мира C++

ГВ>- using std::string — не знаю, кому как, но я не люблю такие вещи. Либо уж std::string variable;, либо using namespace std;

Код

using std::string;
string str;

на порядок лучше кода

using namespace std;
string str;

В первом варианте четко видно что используется только std::string. Во втором глобальное простанство имен "засирается" сотнями или тысячами символов из std. Второй код как минимум привел бы к куче вопросов. Рекомендация "using namespace std;" крайне безграмотная и вредная

Здравствуйте, Northaunt, Вы писали:

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

Деструкторы не виртуальные.

Здравствуйте, pvirk, Вы писали:

P>Здравствуйте, Northaunt, Вы писали:

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

P>Деструкторы не виртуальные.


Протестую

virtual ~CCamera();

Здравствуйте, Northaunt, Вы писали:

P>>Деструкторы не виртуальные.

N>Протестую

Да это он не в прямом смысле наверное а в переносном

Автор: Denwer
Дата: 08.03.10

Здравствуйте, Handie, Вы писали:

ГВ>>- using std::string — не знаю, кому как, но я не люблю такие вещи. Либо уж std::string variable;, либо using namespace std;

[...]

H>В первом варианте четко видно что используется только std::string. Во втором глобальное простанство имен "засирается" сотнями или тысячами символов из std. Второй код как минимум привел бы к куче вопросов. Рекомендация "using namespace std;" крайне безграмотная и вредная

Медленно читаем написанное: "...не знаю, кому как, но я не люблю...". Объясню, почему мне это не нравится: по каждому чиху приходится писать дополнительный using type вместо одноразового включения хидеров всей STL куда-нибудь в .pch. Получается ворох совершенно не нужного мусора. Больше того, если в тексте программы написано "string x;", то опять таки, я "автоматически" предполагаю аналогичную доступность остальных типов, то есть я могу написать "ostringstream os;" без неожиданных эффектов в виде ошибок компиляции, ну, в крайнем случае, я готов добавить соответствующий include.

А чтобы не засирать глобальное пространство имён (если уж это становится проблемой), есть простой выход — завести свой собственный namespace.

ГВ>А чтобы не засирать глобальное пространство имён (если уж это становится проблемой), есть простой выход — завести свой собственный namespace.

Генадий, видимо Вы еще не дошли до разработки крупных систем.
Я всегда предпочитаю forward declaration вместо включения файла

если строка

class SuperClass;

позволяет избежать

#include "SuperClass.h"

я всегда предпочту первый вариант

если из неймспеса мне нужно пару сущьностей, я возьму только их:

using std::map;
using std::string;

вместо засирания неймспейса

using namespace std;

Не надо свое невежество выдавать за рекомендации гуру

Здравствуйте, Northaunt, Вы писали:

N>Я начинающий программист на С++, ищу работу. Часто просят отослать пример кода. Вот только, после того как я пересылаю его, на другой стороне полная тишина. Я каждый раз объяснял, что сложных, хорошо написанных и спроектированных программ у меня нет (мои проекты связаны с 3D графикой, я акцентировал усилия только на ней, к сожалению) и просил тестовое задание, но не помогало. Посмотрите, пожалуйста, кто-нибудь код и укажите на самые фатальные ошибки, из-за которых меня сразу же посылали в черный список. Всего два класса. Все действия, которые там есть, это: инициализировать нужные ресурсы, установить различные состояния для отрисовки, посчитать и отрендерить, что нужно, затем удалить навсегда.

Начать стоит хотя бы с того, чтобы правильно написать фамилии авторов: Navier-Stokes