int n
? Я пока только одно место вижу и оно не в шаблоне, поэтому я пока тебя не понимаю.class property : public C
, а если у C
этих property
50+ штук? Реальный пример, для одного из типов у меня порядка 60 свойств определено.decltype(C::n)
в шаблоне? Здравствуйте!
Опишите конструктор объекта по умолчанию (без аргументов), проинициализировав все данные
char* m = "Renault"
, тут "Renault"
имеет тип const char[N]
, который свести можно только к const char*
. Представленная строка не пройдет трансляцию т.к. тип справа невозможно привести к типу слева.char* marka;
относится сюда же. Это поле должно иметь тип const char*
.Car();
и Car(char* m = "Renault" ...)
вводят неоднозначность для случая Car example;
. Эту неоднозначность нужно убрать и я рекомендую выполнить задание так, как оно написано: т.е. ввести значения по умолчанию в секции инициализации полей конструктора по умолчанию, а от аргументов по умолчанию для конструктора с параметрами отказаться. expected identifier before string constant
a
реализует схему владения памятью. Владение у тебя, согласно деструктору типа a
и счетчику ссылок, реализовано совместное.delete_counter
для каждой инстанции a
является уникальным, а должно быть уникальным для каждого уникального значения bObj
. Да и в целом, счетчик сейчас работает неправильно. Он должен гарантировать удаление уникального bObj
только один раз за все совместное владение.*aobj1
, и локальный временный a(2)
, владеют одной памятью. Сразу после этого локальный временный a(2)
эту самую память удаляет в своем деструкторе, а *aobj1
начинает ссылаться на мусор.delete aobj1;
ты получаешь UB, т.к. деструктор для памяти по указателю aobj1->bObj
вызывается уже второй раз. в этот объект побайтно копируется содержимое временного объекта
long long c = 0;
не является кодом C++. Типа по умолчанию в C++ нет.Мне решение с map-классом представляется более гибким
то есть вы, как и rPman, предлагаете сваять генератор
Я не совсем понял этот момент, можете пожалуйста пояснить?
unsigned i;
, что тоже неоднократно отражалось в здешних вопросах. И таких вольностей у GCC много, всего не упомнишь.Я так понял, что под linux/windows предпочтительнее тоже использовать clang
То есть похоже, что Dolarun прав.
inline
[?] определяет спецификатор, которым помечаются сущности со слабым внешним связыванием. Связывание внешнее, поэтому для таких сущностей обязательным является требование ODR. В это же самое время связывание обозначено как слабое, это означает что проверка на соответствие ODR для таких сущностей проходит не в момент чтения определения сущности из объектного файла, а в момент встраивания этой сущности.inline
имеет далеко опосредованное отношение.Если бы всё было так просто - их просто скопировали бы на старте
К сожалению текст на твоих изображениях неразборчив и замылен. Его неприятно читать, поэтому желания отвечать на вопрос не появляется.
Я рекомендую тебе заменить все изображения с текстом ошибок на листинг ошибок из лога сборки, оформленный тегом <code>.