Дорогая, мы убиваем выходные. Сезон 2.

Дорогая, мы убиваем выходные

Не так.. «Дорогая, мы убиваем глаза»

бахните ссылку в первый пост

И в профиль ссылку на linkedin, раз уж такой деанон получился :D

у меня пунктик против using

Так можно же в начале функции написать

Utils::Logger& logger = Utils::Logger::getInstance();

а я там без фапабельной фоточки, так что не нужно

при этом пунктике мое чувтсво прекрасного не страдает :)

как инструмент отладки еще куда ни шло, хотя тут можно и поспорить в сторону уровней логгирования и ассертов.

вот был бы годный кубик Рубика под сенсор, мне бы было хоть чем на н900 заняться

ООП головного мозга заставило для такой простой вещи родить 25 классов

А ФП головного мозга заставило бы 25 функций. Какая, к черту, разница.

разница в том, что ООП головного мозга это задаток для карьерного роста, а ФП головного мозга это задаток для психиатрического лечения.

как инструмент отладки еще куда ни шло, хотя тут можно и поспорить в сторону уровней логгирования и ассертов.

И уровни логгирования тоже прячутся в макрос. Очень удобно. http://boost-log.sourceforge.net/libs/log/doc/html/log/tutorial.html#log.tuto...

ФП головного мозга заставило бы 25 функций.

Нет, оно бы заставило бы создать 25 типов.

Не увидел в коде C++11, this-> не оценил. Синглтон синглтоном, но размер строки надо экономить, чтобы читабельно было, а то Utils::Logger::getInstance() как бэ намекает не только на синглтон, но и на неймспейсы головного мозга с боязню использовать using namespace.

#define log((x)) Utils::Logger::getInstance().log((x))

АААА! МОИ ГЛАЗА!!! сделайте меня развидеть это!

неймспейсы головного мозга с боязню использовать using namespace

на мой личный взгляд — using не плох [если он делается локально внутри другого namespace]... а вот using namespace — это ужасно :)

делая using namespace — мы можем неожиданно встретить коллизию имён почти на ровном месте: вчера программа компилировалась, а сегодня уже нет (или у одного человека компилируется, а у другого возникает коллизия имён).

лучше уж вручную прописать все требуемые: using ClassNameA; using ClassNameB; using ClassNameC; ...

делая using namespace — мы можем неожиданно встретить коллизию имён почти на ровном месте: вчера программа компилировалась, а сегодня уже нет (или у одного человека компилируется, а у другого возникает коллизия имён).

спасибо кэп!

но если сесть, и подумать, когда коллизия имён может встретится на практике? много ли человек переписывают функции из std? много ли проектов, в которых под отдельными неймспейсами есть сущности с одинаковым интерфейсом?

да, я тоже когда то давно слышал в университете теоретическую туфту, зачем пихать неймспейсы всюду. практически же, я _никогда_ не видел ситуации, где возникла коллизия. я за простой читабельный код - KISS: Keep It Simple Stupid, не в ущерб производительности конечно же.

я за простой читабельный код

// ...

using namespace NameSpaceA;
using namespace NameSpaceB;
using namespace NameSpaceC;

// ...
// ...
// ...

func_d();
func_e();
func_f();
func_g();

// ...

и вот теперь объясни мне — func_d/func_e()/func_f()/func_g() — из каких пространств имён? :-)

и это ты называешь читабельным кодом?

код должен быть таким, чтобы непосвящённому в код человеку можно было бы по проще разобраться (а не «кидаем всё в одну кучу, а затем оттуда берём») — в этом случае как раз и получим KISS. :)

------------------------------------------------------------------------------------------------------------------------

например — вот так становится более понятно что откуда растёт:

// ...

using NameSpaceA::func_e;
using NameSpaceB::func_f;
using NameSpaceB::func_g;
using NameSpaceC::func_d;

// ...
// ...
// ...

func_d();
func_e();
func_f();
func_g();

// ...

(дополнение)

заметим также — что если вообще НЕ использовать using (ни using, ни using namespace) — то код становится ЕЩЁ более читабельным для непосвящённого в него человека... но в этом случае его труднее писать!

использование using (но НЕ using namespace) — это своего рода баланс между удобством написания кода, и удобством его чтения! :)

Годно. сам заморачивался но не осилил повороты сторон. Может твой проект мне поможет?

Удалено. Причина: C++ в netbeans

достаточно годно с соотв. плагином. Или Вам по душе больше проприетарный eclipse?

Я всё сказал.

а пароль?

и вот теперь объясни мне — func_d/func_e()/func_f()/func_g() — из каких пространств имён? :-)

Дай мне Ctrl+Click и я скажу, откуда эти функции.

Вам по душе больше проприетарный eclipse?

Лолшто?

думаю поможет, спрашивай ответы

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

размер строки надо экономить, чтобы читабельно было

Трогательная экономия ради экономии и потенциальных читателей с 15" мониторами в 2013 году такая трогательная...

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

Нет, оно бы заставило бы создать 25 типов.

Причём зависимых.

проприетарный eclipse

Я думал в Москве тяжелые всё ещё наркотики запрещены ...

//me погуглил
//me почитал англовики
/me осознал какой бред написал про проприетарность
//me все еще ждет ответа на вопрос

> и вот теперь объясни мне — func_d/func_e()/func_f()/func_g() — из каких пространств имён? :-)

Дай мне Ctrl+Click и я скажу, откуда эти функции.

ты щаз только что написал подтверждение того что активное использование функций IDE — приводит к созданию плохого кода. :-)

А НЕ ДАМ Я ТЕБЕ Ctrl+Click! а теперь определяй :)

А НЕ ДАМ Я ТЕБЕ Ctrl+Click! а теперь определяй :)

Тогда всё закончится банально: я буду писать код, учитывающий фичи современных IDE и прочих инструментов, а вы будете писать несопровождаемое нечто и убеждать всех, что это классно.

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

Тем временем вы будете допивать третью бутылку, купленную на последние сбережения с проданной квартиры.

Как вам эта история успеха?

ну вот что я скажу..

писать человеко-читаемый код [а не тот код который может соправождаться только до тех пор пока его автор не забыл что он там накодировал] — это определённое исскуство.

если вы НЕ обладаете этим исскуством — то возможно оно Вам и не требуется, например Вы пишете одноразовые программы, и при чём не в команде :)

используйте какие хотите фишки IDE и запутвай код — как хотите. получайте свои миллионы. ведь я же совершенно не против! :-)

депутаты вот например — вообще зарабатывают миллионы — даже не обладая знаниями C/C++ ! :-) :-)

using using blablabla

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

Вот например мысли коллеги по этому поводу: «У меня есть более-менее лимит на прочтение N-символов в день, соответственно если читать код который полон по сути лишними вещами - я устаю быстрее, и работаю менее эффективно.»

нет, ну да. пространства имён — не самая главная проблема! здесь я согласен! :-)

Трогательная экономия ради экономии и потенциальных читателей с 15" мониторами в 2013 году такая трогательная...

Я не религиозен по вопросам размера строки 80 символов, потому что сейчас это не актуально, но меньше текста - меньше проблем. Я за баланс смысл/размер.

используйте какие хотите фишки IDE и запутвай код — как хотите. получайте свои миллионы. ведь я же совершенно не против! :-)

То есть вы таки утверждаете, что убирать излишние префиксы — значит запутывать код?

потенциальных читателей с 15" мониторами

те люди которые обладают широкими мониторами (тоесть это примерно 80% людей) — думаю предпочитают использовать пространство по бокам — с_пользой_дела (а не для чтения длинных строчек :))

нет, ну да. пространства имён — не самая главная проблема! здесь я согласен! :-)

QtCreator. Внушительный проект, около 20 постоянных разработчиков, using namespace используются повсеместно за исключением заголовков и ситуаций, когда пользы не принесёт.

Никаких конфликтов.

То есть вы таки утверждаете, что убирать излишние префиксы — значит запутывать код?

смотря каким способом!

если вы убраете лишние префексы через using namespace (а не через просто using) — то да — это запутывание кода...

...хотя товарищ выше — уже намекнул что кроме namespace есть и куча других способов запутать код :)

около 20 постоянных разработчиков, using namespace используются повсеместно за исключением заголовков и ситуаций, когда пользы не принесёт.

ну в принципе — хорошо что у вас получается работать даже в такой сложной ситуации!

я рад видеть что с трудом можно побороть даже эти трудности! :)

Вы, видимо, посты до конца не читаете? Конфликтов не возникает.

да. я чуток не внимательный :)

с_пользой_дела

«польза дела» - cубъективненько же :)

Все правильно говорят. Грани не параллельны даже с учетом перспективы. Нужно увеличить угол обзора камеры и размеры объекта.

ОК. Если речь идёт про netbeans vs eclipse то они - звери приблизительно одного типа. Всё упирается в то, какая стоит задача и насколько хороши плагины для неё. Вот например в Eclipse есть плагины для haskell и ocaml. В netbeans их вроде ещё нет. Зато в нём (кажется) чуток лучше со всякими там html и javascript.

Разговор был вроде как о C++. Пользователь утверждал, что писать на С++ в netbeans — извращение. Лично я никакого изврата не вижу, даже более того мне кажется netbeans весьма кошерной IDE. Просто раньше почему то считал Eclipse проприетарным ПО, что служило жирном "-" в ее сторону. Сейчас я немного переосмыслил эту позицию, но я все так же не вижу изврата в программировании на C++ в netbeans с соответствующим плагином.

Да в общем-то в этом плане разницы между ними не вижу.

С простым кодом они оба неплохо работают. А со сложным (шаблоны на шаблонах да со всеми новомодными вывертами синтаксиса) оба серьёзно затыкаются.