Я начинающий программист на С++, ищу работу. Часто просят отослать пример кода. Вот только, после того как я пересылаю его, на другой стороне полная тишина. Я каждый раз объяснял, что сложных, хорошо написанных и спроектированных программ у меня нет (мои проекты связаны с 3D графикой, я акцентировал усилия только на ней, к сожалению) и просил тестовое задание, но не помогало. Посмотрите, пожалуйста, кто-нибудь код и укажите на самые фатальные ошибки, из-за которых меня сразу же посылали в черный список. Всего два класса. Все действия, которые там есть, это: инициализировать нужные ресурсы, установить различные состояния для отрисовки, посчитать и отрендерить, что нужно, затем удалить навсегда.
Возможно код будет кому-то в тему, но в общем случае я бы продпочел "чистый" код без идиотических API типа DirectX.
По сути:
1) Обилие "волшебных" констант в коде. Код изобилует захаркоденными цифрами:
Position = D3DXVECTOR3(-20.0f, 10.0f, 15.0f) + D3DXVECTOR3 (18.0f, -5.0f, -3.0f);;
Яркий пример кода написанного начинающим. По сути я на бейсике в школе писал проги
типа moveTo(120,450); lineTo(230,480); lineTo(520,170)
2) Местами выравнивание доминирует над кодом
3) Несколько операторов в строке. Может новичкам кажется это круто, но опытных программеров чаще раздражает.
_x = x; _y = y; _z = z; (кстати подчерки в переменных класса некрасивы)
4) Отсутствие консистентного стиля.
HRESULT Result = 0;
ID3DXBuffer* errorBuffer = 0;
А не пофиг что одна переменная названа c большой буквы а вторая с маленькой.
В одном классе
float VolumeSize;
float Viscosity;
В другом
float _x, _y, _z;
D3DCOLOR _color;
5) отсутствие общей идеи кода. Ну понятно что это аналог бейсика moveTo/lineTo
Навскидку. Если D3DXCreateEffectFromFile обломится в конструкторе, то объект окажется в не пойми каком состоянии. Пустым конструктором нужно сделать минимальную инициализацию, а загрузку откуда-нибудь (например, из файла) -- отдельными методами. Сейчас же, если на стеке завести несколько экземпляров Fluid3D, они все полезут в один и тот-же файл. Ну, и показывать "коробки" посреди конструктора тоже не очень правильно, -- обработка ошибок -- вопрос клиентского кода.
"- Mein" — так извращаться в названиях директорий не стоит.
И вообще, Mein — это не Main с ошибкой случайно?
Лучше настроить, чтобы путь к заголовкам указывался при сборке, а в коде писать так:
#include"GameApp.h"#include"Service.h"
Вообще, заголовки, которые используются другими модулями программы, обычно кладут куда-нибудь в include в корне проекта, а не в директорию с реализацией.
if (true || ::GetAsyncKeyState(VK_SPACE))
Какой смысл у данной конструкции?
Закомментированный код я бы из демонстрационного примера убрал, чтобы он никого не смущал.
Здравствуйте, Northaunt, Вы писали:
N>Я начинающий программист на С++, ищу работу. Часто просят отослать пример кода. Вот только, после того как я пересылаю его, на другой стороне полная тишина. Я каждый раз объяснял, что сложных, хорошо написанных и спроектированных программ у меня нет (мои проекты связаны с 3D графикой, я акцентировал усилия только на ней, к сожалению) и просил тестовое задание, но не помогало. Посмотрите, пожалуйста, кто-нибудь код и укажите на самые фатальные ошибки, из-за которых меня сразу же посылали в черный список. Всего два класса. Все действия, которые там есть, это: инициализировать нужные ресурсы, установить различные состояния для отрисовки, посчитать и отрендерить, что нужно, затем удалить навсегда.
Из бросающегося в глаза:
— using std::string — не знаю, кому как, но я не люблю такие вещи. Либо уж std::string variable;, либо using namespace std;
— Почти полное отсутствие осмысленных комментариев, некий намёк на них есть только там, где очень длинный код разбивается на блоки. Правда, для этого лучше разбить код на относительно короткие функции;
— ИМХО, самый серьёзный недостаток: нет толковой обработки ошибок (например, пачка вызовов Device->CreateTexture);
— Зачем-то неровно оттабулированы парные скобки в объявлениях методов. С пробелами между параметрами и скобками вообще бардак какой-то: что-то отогнано чуть ли не за правую границу экрана, что-то навалено одно на одно;
— Сумасшедшая длина метода InitVertexBuffers.
Ну и, конечно, закомментированный код из демонстрационного примера лучше бы убрать. Не то, чтобы его не бывает в реальном продуктовом коде (бывает, ещё как бывает), просто здесь у тебя своего рода театр, так хоть сцену подмети.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, RedUser, Вы писали:
RU>[/ccode]"- Mein" — так извращаться в названиях директорий не стоит.
IMHO, это не баг, это фича —
главная директория тогда получается первая по порядку, если стоит сортировка по алфавиту.
RU>И вообще, Mein — это не Main с ошибкой случайно?
Я думаю это на немецком ("Mein" = "My"). Может либа имеет немецкие корни?
RU>Лучше настроить, чтобы путь к заголовкам указывался при сборке, а в коде писать так: RU>
RU>#include"GameApp.h"
RU>#include"Service.h"
Вообще, заголовки, которые используются другими модулями программы, обычно кладут куда-нибудь в include в корне проекта, а не в директорию с реализацией.
IMHO, то что он написал — вполне нормально.
Вдруг у тебя два файла с одинаковым именем в разных INCLUDE-папках? Получишь проблему на ровном месте.
— Довольно длинная D3DXVECTOR3 передаётся по значению. Скорее всего, это не страшно в данном случае, если бы не остальные наблюдения;
— Параметры типа string передаются по значению (const std::string & отменили?);
— В единственном месте, где string передаётся по ссылке эта ссылка должна быть константной, чтобы не морочить голову пользователю.
Кстати, автор знает про существование ключевого слова const?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Northaunt, Вы писали:
N>Я начинающий программист на С++, ищу работу. Часто просят отослать пример кода. Вот только, после того как я пересылаю его, на другой стороне полная тишина.
Это предсказуемо, так как много кода непонятного назначения. Вот у меня сразу вопрос — какую задачу решает код? Поэтому:
1. Выкинь свой код
2. Возьми стандарт кодирования серьезной организации (например от Qt), вызубри его и четко следуй тому, что там написано, а то от смешения стилей и дикого форматирования волосы шевелятся
3. Напиши например реализацию 2-3 дерева
4. Задокументируй открытые методы своего контейнера в стиле Doxygen
5. Напиши юнит-тесты и короткую демонстрационную программу, чтобы люди сразу видели как с этим работать.
После этого все будет выглядеть аккуратно и на слабое знание языка люди закроют глаза, так как будут думать, что парень толковый и аккуратный — научится.
Думаю, мало кому из работодателей понравится замысловатый код, предназначенный, скажем, для обработки
видеопотока данных или шифрования, даже если он чрезвычайно эффективен. Лучше смотрится реализация
относительно простых алгоритмов, но выполненная в качественном стиле, с согласованными именами,
комментариями. Про юнит-тесты вообще молчу.
Ytz>Это предсказуемо, так как много кода непонятного назначения. Вот у меня сразу вопрос — какую задачу решает код? Поэтому: Ytz>1. Выкинь свой код
...
К сожалению Ytz прав, таких людей чтобы заценили сложность программирования решения уравнений Навье-Стокса немного.
Да уж, отсылать это было ошибкой. Спасибо тем, кто заставил себя просмотреть все. Если я правильно понял, основные проблемы это: ужасный стиль, комментарии и непонятно что тут вообще делается. Я, скорее всего, последую советам Ytz, но это займет время. А в качестве временного варианта я откопал старый код, маленький класс управления камерой в 3D. Я постарался учесть все ошибки (константы, передачи по ссылкам, изврат в конструкторах, форматирование и т.д.), но, конечно же, наделав много новых. Это, надеюсь, последний раз, постараюсь больше не напрягать.
Здравствуйте, Northaunt, Вы писали:
N>Кстати, глюки со смещением, не моих рук дело, в окне Visual Studio все ровно. Это при отправке сообщения строчки начинает косить
Твоих. Ты явно выравниваешь колонки табуляциями, чего делать нельзя (расползется при другом размере табуляции).
Табуляции допустимы только для отступов, и то спорно (я вот использую пробелы вообще везде).
Здравствуйте, Northaunt, Вы писали:
N>Кстати, глюки со смещением, не моих рук дело, в окне Visual Studio все ровно. Это при отправке сообщения строчки начинает косить
Твоих, твоих. Ctrl-R,W — посмотри, где у тебя табуляции, где пробелы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Northaunt, Вы писали:
N>Я начинающий программист на С++, ищу работу.
Одна проблема — приведенный код — это не C++ код. В лучшем случае это с натяжкой можно назвать "C с классами".
Если хочешь найти работу именно на C++, нужно придумать пример именно C++ кода.
Здравствуйте, Northaunt, Вы писали:
N>Да уж, отсылать это было ошибкой. Спасибо тем, кто заставил себя просмотреть все. Если я правильно понял, основные проблемы это: ужасный стиль, комментарии и непонятно что тут вообще делается. Я, скорее всего, последую советам Ytz, но это займет время. А в качестве временного варианта я откопал старый код, маленький класс управления камерой в 3D. Я постарался учесть все ошибки (константы, передачи по ссылкам, изврат в конструкторах, форматирование и т.д.), но, конечно же, наделав много новых. Это, надеюсь, последний раз, постараюсь больше не напрягать.
На мой взгляд, значительно лучше. Правда, обработка ошибок так и не появилась. Или это в графических приложениях не принято?
Насчёт code convention... Я, лично, не думаю, что сам по себе стиль кодирования играет большую роль при приёме на работу, за исключением, наверное, мешанины из пробелов с табуляциями — её может быть просто неудобно читать. То есть, предпочитаешь ты венгерку, Camel, или, там, stl-like — не суть важно. Это всё управляется внутрифирменными соглашениями, потому при необходимости может быть "перенастроено". Скорее, важно другое: на сколько последовательно ты сам придерживаешься выбранного тобой стиля. Если уж переменные-члены класса именуются с большой буквы, шут с ним, пусть именуются с большой буквы, но везде. Если ты отделяешь скобки пробелами — тоже, отделяй тогда уж везде. На практике, разумеется, не всегда всё шоколадно, но тут тебя никто не торопит с подготовкой примеров, можно отсмотреть и повнимательнее.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Northaunt, Вы писали:
N>Я начинающий программист на С++, ищу работу. Часто просят отослать пример кода. Вот только, после того как я пересылаю его, на другой стороне полная тишина. Я каждый раз объяснял, что сложных, хорошо написанных и спроектированных программ у меня нет (мои проекты связаны с 3D графикой, я акцентировал усилия только на ней, к сожалению) и просил тестовое задание, но не помогало. Посмотрите, пожалуйста, кто-нибудь код и укажите на самые фатальные ошибки, из-за которых меня сразу же посылали в черный список. Всего два класса. Все действия, которые там есть, это: инициализировать нужные ресурсы, установить различные состояния для отрисовки, посчитать и отрендерить, что нужно, затем удалить навсегда.
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"
Можете пояснить, что именно здесь включается?
К уже сказанному добавлю, что передаваемые параметры нужно проверять. Вот в этом месте (и в некоторых других) всё упадёт, если переданный указатель окажется невалидным:
Здравствуйте, 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>Вроде ответил, но у меня такое ощущение, что вы про другое спрашивали?
Да. В общем-то спрашивал, почему на '\' начинается.
Здравствуйте, 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>Деструкторы не виртуальные.
Здравствуйте, 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.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Northaunt, Вы писали:
N>Я начинающий программист на С++, ищу работу. Часто просят отослать пример кода. Вот только, после того как я пересылаю его, на другой стороне полная тишина. Я каждый раз объяснял, что сложных, хорошо написанных и спроектированных программ у меня нет (мои проекты связаны с 3D графикой, я акцентировал усилия только на ней, к сожалению) и просил тестовое задание, но не помогало. Посмотрите, пожалуйста, кто-нибудь код и укажите на самые фатальные ошибки, из-за которых меня сразу же посылали в черный список. Всего два класса. Все действия, которые там есть, это: инициализировать нужные ресурсы, установить различные состояния для отрисовки, посчитать и отрендерить, что нужно, затем удалить навсегда.
Начать стоит хотя бы с того, чтобы правильно написать фамилии авторов: Navier-Stokes
Здравствуйте, Handie, Вы писали:
ГВ>>А чтобы не засирать глобальное пространство имён (если уж это становится проблемой), есть простой выход — завести свой собственный namespace.
H>Генадий, видимо Вы еще не дошли до разработки крупных систем.
Странное дело: разве до разработки крупных систем надо как-то специально "доходить"? Это просто работа, которая либо на тебя сваливается, либо ты сам её "пикапишь". Кстати, коль зашла такая пьянка: что ты имеешь в виду под крупными системами?
H>Я всегда предпочитаю forward declaration вместо включения файла
H>если строка
H>
H>class SuperClass;
H>
H>позволяет избежать
H>
H>#include"SuperClass.h"
H>
H>я всегда предпочту первый вариант
Да, это бывает полезно, если в проекте творится кавардак: все всех подозревают, левая рука не ведает, что творит правая, нет единообразного подхода к дизайну, толкового распределения задач и т.п. Короче говоря, когда все ото всех решительно изолируются самостоятельно. То есть, в общем, кое-какой шухер сбить такой подход позволяет. С другой стороны, ты лишаешься возможности включить экземпляр SuperClass-а по значению:
class SuperClass;
class MyClass : public SuperClass {...} // Болт!...class MyClass1
{
...
SuperClass superMember_; // ...с левой резьбой!
};
Придётся писать что-то в духе pImpl и т.п. Не то, чтобы это было плохо само по себе, но будучи принятым на уровне некоего "правила", сильно ограничивает разработчика.
Извини, что объясняю столь детально.
H>если из неймспеса мне нужно пару сущьностей, я возьму только их:
H>
H>using std::map;
H>using std::string;
H>
H>вместо засирания неймспейса
H>
H>using namespace std;
H>
Кстати, соответствующий инклюд всё равно придётся вставлять, если, конечно, ты не обходишься без использования значений соответствующих типов.
H>Не надо свое невежество выдавать за рекомендации гуру
Я не случайно оговорился в самом начале, что "я не люблю...". Всё вышесказанное как раз иллюстрирует отчасти вкусовой характер этой проблемы — для принятия точных решений нужна статистика использования типов той же STL. Не спорю, может быть, в твоём случае (да и в случае топикстартера тоже) вполне можно обойтись using-type, мне это обычно здорово мешало: писать по полтора десятка using-ов на каждом углу как-то шумновато.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Заверните что нить эдакое с интерфейсами\наследованием\темплейтами.
Покажите что понимаете области видимости, что такое константные обьекты\методы\мутабл,
исключения как работают, оператор перегрузите ну и т.д.
Вообщем возьмите учебник по С++, пройдитесь по разделам, и найдете много чего что можно
показать в своем демонстрационном коде по С++.
Здравствуйте, 8bit, Вы писали:
8>Вообщем возьмите учебник по С++, пройдитесь по разделам, и найдете много чего что можно 8>показать в своем демонстрационном коде по С++.
Представляешь, как встанут волосы дыбом у собеседователей, если последовать такому совету?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, 8bit, Вы писали:
ГВ>>Представляешь, как встанут волосы дыбом у собеседователей, если последовать такому совету?
8>Всмысле?
В прямом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, 8bit, Вы писали:
8>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Представляешь, как встанут волосы дыбом у собеседователей, если последовать такому совету?
8>Всмысле?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, 8bit, Вы писали: 8>Вообщем возьмите учебник по С++, пройдитесь по разделам, и найдете много чего что можно 8>показать в своем демонстрационном коде по С++. ГВ>>>Представляешь, как встанут волосы дыбом у собеседователей, если последовать такому совету? 8>>Всмысле? ГВ>В прямом.
От чего волосы-то дыбом?
Если что, я не имел ввиду переписать себе код из книжки или написать примеры для всего и вся
Здравствуйте, 8bit, Вы писали:
ГВ>>Представляешь, как встанут волосы дыбом у собеседователей, если последовать такому совету? 8>Всмысле?
В прямом смысле. По примеру кода (не скажу, что все, но почти все, с кем мне приходилось сталкиваться, да и я сам тоже) пытаются сделать вывод о том, как человек будет писать код в повседневных условиях. Не тогда, когда он специально готовится к показу своей крутизны, а как он будет день за днём лопатить килобайты своего и чужого кода. То есть здесь на самом деле важны не столько продвинутые техники, сколько нюансы вроде std::string, переданных по значению без особой нужды, последовательности в стиле оформления, стиль комментирования, подход к обработке ошибок, прочие подобные характеристики, которые "проходят через весь код". Потому что такие моменты человек вписывает полуавтоматически, чуть ли не на спинномозговых реакциях. Опять таки, могут быть применены и шаблоны, и исключения, и, не побоюсь этого слова, виртуальные деструкторы — но всё должно быть к месту и в меру. Потому, кстати, часто просят пример продуктового кода. Это вовсе не для того, чтобы спереть очередную великую идею гениального велосипеда на тэтраидальных колёсах, а чтобы посмотреть на вот те самые нюансы. Понятно, что код примера будет несколько подчищен, но я тебе ручаюсь — всех нюансов без специальной подготовки (которая равна, по сути, повышению квалификации) всё равно не вычистить.
Вот теперь представь, что в такой контекст ты закидываешь для анализа что-то вроде упражнения по книге Александреску, или сборник приёмов по главам из ARM.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Northaunt, Вы писали:
N>>Кстати, глюки со смещением, не моих рук дело, в окне Visual Studio все ровно. Это при отправке сообщения строчки начинает косить
RO>Твоих. Ты явно выравниваешь колонки табуляциями, чего делать нельзя (расползется при другом размере табуляции).
RO>Табуляции допустимы только для отступов, и то спорно (я вот использую пробелы вообще везде).
Ложь, tab/spaces зависит от code-style принятого в проекте.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вот теперь представь, что в такой контекст ты закидываешь для анализа что-то вроде упражнения по книге Александреску, или сборник приёмов по главам из ARM.
вон оно что, понятно Ну так он же начинающий программист. Тут надо смотреть умеет ли он этим С++ вообще пользоваться.
А нюансы и тут видны будут.
Здравствуйте, 8bit, Вы писали:
ГВ>>Вот теперь представь, что в такой контекст ты закидываешь для анализа что-то вроде упражнения по книге Александреску, или сборник приёмов по главам из ARM.
8>вон оно что, понятно Ну так он же начинающий программист. Тут надо смотреть умеет ли он этим С++ вообще пользоваться. 8>А нюансы и тут видны будут.
Угу, о чём и идёт речь с самого начала. Немного в иносказательном стиле, но тем не менее.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, bnk, Вы писали:
bnk>Блэкджек и шлюхи отдыхают
Мда... Православный буст головного мозга в полный рост.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Угу, о чём и идёт речь с самого начала. Немного в иносказательном стиле, но тем не менее.
Так я и говорю, пусть напишет код как он знает С++, без перегибов конечно, и по нему и нюансы и знание С++ будет видно.
А сейчас у него три страницы DX кода и плюсов там совсем не видно.
Здравствуйте, 8bit, Вы писали:
ГВ>>Угу, о чём и идёт речь с самого начала. Немного в иносказательном стиле, но тем не менее.
8>Так я и говорю, пусть напишет код как он знает С++, без перегибов конечно, и по нему и нюансы и знание С++ будет видно. 8>А сейчас у него три страницы DX кода и плюсов там совсем не видно.
Не-не-не, ты не понял. Смотрят в примере не столько на знание C++ (это можно определить собеседованием), сколько на то, правильно ли он используется в разных закоулках. Вопросы вида: "А знает ли автор об XXXXX?" — это уже вторая производная от суммы наблюдений. Ну и ещё играет роль общая культура программирования, которая от языка не зависит. Это может быть даже DX-код, нет проблем. C++ — объёмный язык, а задачи, которые решает данный кандидат вполне могут не требовать применения каких-то аспектов самого C++ (к примеру — volatile-модификаторы нужны очень не всегда, да и виртуальные деструкторы, не к ночи будь помянуты, тоже).
Так что, код тописктартера, ИМХО, вполне подходит для демо-кода, разве что длинноват, имело бы смысл выбрать что-то покороче. Но справедливости ради, в конечном итоге ТС так и поступил.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vpchelko, Вы писали:
N>>>Кстати, глюки со смещением, не моих рук дело, в окне Visual Studio все ровно. Это при отправке сообщения строчки начинает косить RO>>Твоих. Ты явно выравниваешь колонки табуляциями, чего делать нельзя (расползется при другом размере табуляции). RO>>Табуляции допустимы только для отступов, и то спорно (я вот использую пробелы вообще везде).
V>Ложь, tab/spaces зависит от code-style принятого в проекте.
Табуляции не в начале строки неприемлемы ни при каких условиях. Единственное преимущество табуляций — возможность настроить их размер — в этом случае сводится на нет.
Здравствуйте, Cyberax, Вы писали:
C>Стоит использовать деструкторы и умные указатели, а не лепить явные Release.
Кстати, это не всегда так. Был у меня случай, когда исключения летели как раз из Release, а в последовательности деструкторов умных указателей копаться — ой, неудобно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
8>Так я и говорю, пусть напишет код как он знает С++, без перегибов конечно, и по нему и нюансы и знание С++ будет видно. 8>А сейчас у него три страницы DX кода и плюсов там совсем не видно.
Плюсов там ровно столько сколько нужно в реальном проекте и это топикстартеру только в плюс. Смарт пойнтеры только еще желательно было бы использовать.