Винда ж😄

а как надо?

пробовал?

Мне лень

Qt creator пишет ошибку undefined reference to имя класса конструктор класса, в чем может быть проблема?

привет. у нас тут небольшой спор касательно пространств имен и стиля программирования. предположим, у нас есть библиотека, пусть она занимается юзерами, группами, политиками и доменами. пример от балды вообще. пусть она вся обёрнута в namespace lib { }; и она оперирует некими сущностями (структуры + функции, работающие с ними), которые важны настолько, что удостоились отдельных вложенных неймспейсов. например, структуры — USER, GROUP, POLICY, DOMAIN. они могут включать в себя другие структуры из этого набора, например, GROUP включает в себя USER* со списком юзеров. неймспейсы, соответственно, lib::user, lib::group, lib::policy, lib::domain. примеры функций - lib::user::init( USER *user ), lib::user::fini( USER *user ), lib::group::add( GROUP *group, USER *user ) собственно, спор о двух подходах к оформлению этого дела. первый подход: сама структура и её функции находятся внутри неймспейса этой сущности: // user.h namespace lib::user { struct USER { }; int init( USER *user ); }; // group.h #include "user.h" namespace lib::group { // здесь приходится указывать неймспейс для юзеров struct GROUP { user::USER *users; } // и здесь тоже int add( GROUP *group, user::USER *user ); }; второй подход: структура находится в неймспейсе верхнего уровня, её функции - в нейсмпейсе сущности: // user.h namespace lib { struct USER { }; namespace user { int init( USER *user ); }; }; // group.h #include "user.h" namespace lib { // здесь НЕ приходится указывать неймспейс для юзеров struct GROUP { USER *users; } namespace group { // и здесь тоже не нужно int add( GROUP *group, USER *user ); }; }; какой подход лучше и почему?

Кмк лучше третий подход, когда всё вложено в неймспейс класса

привет. у нас тут небольшой спор касательно пространств имен и стиля программирования. предположим, у нас есть библиотека, пусть она занимается юзерами, группами, политиками и доменами. пример от балды вообще. пусть она вся обёрнута в namespace lib { }; и она оперирует некими сущностями (структуры + функции, работающие с ними), которые важны настолько, что удостоились отдельных вложенных неймспейсов. например, структуры — USER, GROUP, POLICY, DOMAIN. они могут включать в себя другие структуры из этого набора, например, GROUP включает в себя USER* со списком юзеров. неймспейсы, соответственно, lib::user, lib::group, lib::policy, lib::domain. примеры функций - lib::user::init( USER *user ), lib::user::fini( USER *user ), lib::group::add( GROUP *group, USER *user ) собственно, спор о двух подходах к оформлению этого дела. первый подход: сама структура и её функции находятся внутри неймспейса этой сущности: // user.h namespace lib::user { struct USER { }; int init( USER *user ); }; // group.h #include "user.h" namespace lib::group { // здесь приходится указывать неймспейс для юзеров struct GROUP { user::USER *users; } // и здесь тоже int add( GROUP *group, user::USER *user ); }; второй подход: структура находится в неймспейсе верхнего уровня, её функции - в нейсмпейсе сущности: // user.h namespace lib { struct USER { }; namespace user { int init( USER *user ); }; }; // group.h #include "user.h" namespace lib { // здесь НЕ приходится указывать неймспейс для юзеров struct GROUP { USER *users; } namespace group { // и здесь тоже не нужно int add( GROUP *group, USER *user ); }; }; какой подход лучше и почему?

которые даже отдельных неймспейсов удостоились

ДАЖЕ В КОНСТАНТАХ

Лучше в основном, чтобы не повторяться

я вообще венгр!

pUser, pGroup же тогда

ДАЖЕ В КОНСТАНТАХ

т.е. структуры будут частью верхнеуровнего namespace lib { }

логично сделать ее не заходя в функцию

Товарищи, есть вот такая штуковина: template <char... Chars> struct metastring { }; Как её проще вывести в stream - через создание array или рекурсией посимвольно?

Если не скомпилируется, то так void print_impl(ostream& os, char... chars) { (os << ... << chars); }

@antoshkka смотрю твой доклад в Иннополисе и глубоко завис на моменте с set<string, less<>> https://i.imgur.com/kQPH2VQ.png какой в этом профит по сравнению с find_if(begin, end, [&](auto &&s) { return s == p.name; })? про "иначе примера не получилось бы" понятно, интересует прирост общей производительности и каких-нибудь хитроумных оптимизаций в потрохах стдлибы потому что честно, find_if выглядит гораааздо понятнее спецификации less<> и двух дополнительных компараторов на нужный тип

линейный find_if и бинарный set::find?

@antoshkka смотрю твой доклад в Иннополисе и глубоко завис на моменте с set<string, less<>> https://i.imgur.com/kQPH2VQ.png какой в этом профит по сравнению с find_if(begin, end, [&](auto &&s) { return s == p.name; })? про "иначе примера не получилось бы" понятно, интересует прирост общей производительности и каких-нибудь хитроумных оптимизаций в потрохах стдлибы потому что честно, find_if выглядит гораааздо понятнее спецификации less<> и двух дополнительных компараторов на нужный тип