Size: a a a

2021 July 03

AG

Alex Green 𓆏 in supapro.cxx
Тогда дело в пет-проектах и теории(книгах) ?
источник

LA

Liber Azerate in supapro.cxx
Да
источник

Е

Егор in supapro.cxx
дело в умении программировать на С++
источник

A

Alex in supapro.cxx
да, сделай 3-5 своих полноценных приложения и будет тебе счастье
источник

AG

Alex Green 𓆏 in supapro.cxx
Спасибо за ответы
источник

K

Kelbon in supapro.cxx
не только...
источник

A

Alex in supapro.cxx
софт скиловый shit лучше даже не вспоминать
источник

K

Kelbon in supapro.cxx
не вспоминай, только в любом случае в каком то виде это нужно
источник

K

Kelbon in supapro.cxx
и не только оно
источник

K

Kelbon in supapro.cxx
просто в разных местах под этим разное понимают, иногда совершенно разное
источник

A

Alex in supapro.cxx
то что манагеры называют софт скилами по сути просто нормальное воспитание, не думаю что это нужно прям как-то качать, если ты конечно не преступник-психопат
источник

K

Kelbon in supapro.cxx
если бы всё было так просто
источник

Е

Егор in supapro.cxx
ребята лучше во флудилку
источник

LA

Liber Azerate in supapro.cxx
Да, у всех у них есть ООП. А если хочется прямо совсем ООП, то бери Гради Буча
источник

AM

Alisher Magametiliev in supapro.cxx
Там с uml диаграмками ,же ?
источник

AS

Anatoly Shirokov in supapro.cxx
их несколько изданий, так не во всех будет uml, а его предтеча, например в первом (1991) и втором (1994) нет еще UML
источник

VS

Vlad Serebrennikov in supapro.cxx
в первую очередь хочу отметить, что ни раньше, ни сейчас речь не шла о частичных специализациях — только о полных. у меня есть представление, как они работают, но нам сейчас они вообще не нужны.

у вас столько вопросов, что, полагаю, есть смысл разобрать следующий пример:
#include <iostream>

template<typename T>
struct X {
 void foo() {
   std::cout << "foo in-class";
 }

 // deleted __definition__
 // declaration would be void bar()
 void bar() = delete;

 void baz() {
   std::cout << "baz in-class";
 }

 void qux() = delete;
};

// specialization 1
template<>
void X<int>::foo() {
 std::cout << "foo spec";
}

// specialization 2
template<>
void X<int>::bar() {
 std::cout << "bar spec";
}

int main() {
 X<int> x; // 1
 x.foo();  // 2
 x.bar();  // 3
 x.baz();  // 4
 x.qux();  // 5
}

// specialization 3, IFNDR
template<>
void X<int>::qux() {
 std::cout << "qux spec";
}

0) к моменту компиляции main() компилятору известно следующее: определение шаблона класса A с определением всех членов, и declared specializations A<int>::foo() и A<int>::bar(), которые являются определяющими объявлениями (basic#def-2)

1) в точке 1 требуется определение специализации X<int>. в явном виде эта специализация ни объявлена, ни определена, поэтому определение генерируется согласно temp.spec#temp.inst-2 и следующего за ним пункта 3:
template<>
class X<int> {
 // declaration from spec 1
 void foo();
 // declaration from spec 2
 void bar();
 // 3.1, declaration
 void baz();
 // 3.2, (deleted) definition
 void qux() = delete;
};
зато в точке 1 компилятор знает о существовании специализаций 1 и 2 (их объявления требует temp.spec#temp.expl.spec-7.sentence-1), и использует их объявления в специализации класса. temp.spec#temp.inst-3 для них не работает ввиду temp.spec#temp.inst-11.sentence-1 (*)

2) в точке 2 нужно сначала разрешить перегрузку. множество кандидатов состоит из одного-единственного объявления X<int>::foo() в X<int>. выбор очевиден, полагаю.

3) после разрешения перегрузки требуется определение специализации X<int>::foo(). известно, что эта декларация пришла из declared specialization, поэтому определение берется оттуда.

4) с x.bar() ситуация полностью аналогична x.foo(), несмотря на то, что в шаблоне класса она является удаленной функцией.

5) в точке 4 про X<int>::baz() известно только объявление. так как оно было неявно сгенерировано в отсутствие declared specialization, то и определение будет неявно сгенерировано согласно temp.spec#temp.inst-4

6) в точке 5 про специализацию 3 ничего не известно, что нарушает требование, о котором шла речь в первом пункте. в ее отсутствие вызов в этой точке является ill-formed, потому что перегрузка разрешается в удаленную функцию X<int>::qux() = delete

7) на момент, когда о специализации 3 становится известно, определение X<int>::qux() = delete уже сгенерировано (п. 1), поэтому она является переопределением и нарушает ODR

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

VS

Vlad Serebrennikov in supapro.cxx
о, даже в одно сообщение влезло
источник

K

Kelbon in supapro.cxx
это докторская по отрывку кода?
источник

VS

Vlad Serebrennikov in supapro.cxx
предлагаю зарепортить еще один constexpr баг в gcc. который, по-видимому, распространяет действие  temp.expl.spec#13 на явные специализации функций-членов, хотя function template это только про свободные функции, насколько я могу судить по другим пунктам, где этот термин используется
https://godbolt.org/z/3PzfdK9x6
источник