как вам кажется, должен ли компилятор предупреждать о том, что конструктор класса b не будет вызывать конструктор a с тем параметром, который он передает: struct a { int i; a(int i) : i(i) {std::cout << "a" << i;} }; struct b : virtual a { b() : a(10) {std::cout << "b" << i;} }; struct c : b { c() : a(20) {std::cout << "c";} }; int main() { struct c c; } ?

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

...алала, а я почему то был уверен что 28 - это пятница, и собирался идти на конфу Касперского только завтра. Ну, эх, чо

...алала, а я почему то был уверен что 28 - это пятница, и собирался идти на конфу Касперского только завтра. Ну, эх, чо

Будет видос же

А кто в проде конан пользует это же с локальным каким-то репозиторием, не с public? Artifactory например?

А кто в проде конан пользует это же с локальным каким-то репозиторием, не с public? Artifactory например?

Ага, artifactory

А рецепты копипастом или как?

Снэпшоты с исходниками по версиям наверное в том же artifactory?

как вам кажется, должен ли компилятор предупреждать о том, что конструктор класса b не будет вызывать конструктор a с тем параметром, который он передает: struct a { int i; a(int i) : i(i) {std::cout << "a" << i;} }; struct b : virtual a { b() : a(10) {std::cout << "b" << i;} }; struct c : b { c() : a(20) {std::cout << "c";} }; int main() { struct c c; } ?

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

так и предупреждают же, не?

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

Гцц кстати о порядке инициализации предупреждает

о неверном порядке

шланг тоже

Гцц кстати о порядке инициализации предупреждает

без флагов?

я просто всегда строго стараюсь соблюдать порядок в списке инициализации, поэтому не в теме)

с флагами

Угу

Но тем не менее

наверняка у вижуалки тоже флаги на это есть

ну в общем, по моему мнению, без флагов компилятор не должен о таком предупреждать

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

ну это много лишней работы для компилятора, тут трейдофф между скоростю компиляции и пользой ворнингов

ну это много лишней работы для компилятора, тут трейдофф между скоростю компиляции и пользой ворнингов

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

тоже верно

тут просто непонятно на каком уровне ошибок остановиться при компиляции без флагов

-Werror -Wall

Ну может ещё -Wextra

И сверху clang-tidy заполировать :)

кстати, кто-то пилил правила для автоисправления warning-ов через tidy?

кстати, кто-то пилил правила для автоисправления warning-ов через tidy?

Ох, я бы не доверял...

Ох, я бы не доверял...

не спорю, но есть задача на 100500 “проблем”, хотел автоматизировать этот процесс, что бы потом поревьювить и замерджить

не спорю, но есть задача на 100500 “проблем”, хотел автоматизировать этот процесс, что бы потом поревьювить и замерджить

А тот что есть автофикс работает по этой задаче, только отфильтровать?

ну, он не всё может

О, он вообще чудеса умеет :) например заменять в шаблонах typedef на using используя первый попавшийся тип, в контексте которого он эту "проблему" обнаружил :)

например for(int i = 0; i < vec.size(); i++ ){ vecA[i] = vecB[i * 2]; } тут понятно: сравнение signed <—> unsigned… автоисправить изи

а вот приведение float к int тут уже от контекста зависит

думал может кто-то писал правила(или плагин) для него

что бы можно было пройтись и потыкать варианты с автопревью

Ну это не совсем изи. Ибо заменив тип счётчика можно внутри цикла ещё больше проблем огрести.

ERROR: S client not available

Ну это не совсем изи. Ибо заменив тип счётчика можно внутри цикла ещё больше проблем огрести.

понятно, я ж и говорю, что бы автоматически “пофиксить”, а потом ревьювить, так удобнее

ну и + сделать более глубокий анализ на предмет безопасности действий можно таки

Ну for int ... size можно и регулярками "пофиксить" в студии например

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

используется ли std::launder под капотом у std::variant/std::optional?

используется ли std::launder под капотом у std::variant/std::optional?

да

например for(int i = 0; i < vec.size(); i++ ){ vecA[i] = vecB[i * 2]; } тут понятно: сравнение signed <—> unsigned… автоисправить изи

а на что исправлять?

а на что исправлять?

size_t

size_t

for(int i = 0; i < a.size(); i++ ) { if (i - 1 >= 0) a[i - 1] += a[i]; }

и хорошо если warning: expression is always true

?

Та не суть совершенно... это был «пример»

А рецепты копипастом или как?

Рецепты простенькие самописные, исходники в отдельных локальных репах

@zamazan4ik https://www.reddit.com/r/cpp/comments/8uq3hu/cppcast_sg15_tooling_group_with_titus_winters/?utm_source=reddit-android возможно будет интересно

как вам кажется, должен ли компилятор предупреждать о том, что конструктор класса b не будет вызывать конструктор a с тем параметром, который он передает: struct a { int i; a(int i) : i(i) {std::cout << "a" << i;} }; struct b : virtual a { b() : a(10) {std::cout << "b" << i;} }; struct c : b { c() : a(20) {std::cout << "c";} }; int main() { struct c c; } ?

А, это... Вижак вроде бы варнил ...

как вам кажется, должен ли компилятор предупреждать о том, что конструктор класса b не будет вызывать конструктор a с тем параметром, который он передает: struct a { int i; a(int i) : i(i) {std::cout << "a" << i;} }; struct b : virtual a { b() : a(10) {std::cout << "b" << i;} }; struct c : b { c() : a(20) {std::cout << "c";} }; int main() { struct c c; } ?

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

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

Я вот считаю, что наследование должно быть виртуальным по умолчанию

Я вот считаю, что наследование должно быть виртуальным по умолчанию

а как же "не плачу за то, что не использую"?