Deprecated attribute in C ++ 14
- Transfer
- Tutorial
The normal development of any code is the obsolescence of its individual parts (functions, classes, etc.) and the systematic removal of them from the project to reduce complexity and improve code security. Just removing something is usually a bad idea - it could break some component that uses the deleted entity. It’s good practice to mark outdated code in some way that will enable programmers to use it to know that it is scheduled for removal. ( Note translator - Microsoft invented his bike for this , and people sometimes used #pragma message ).
New C ++ 14 standard introduces deprecated attributeto mark obsolete entities that are planned to be deleted in the future. The compiler can display warnings for any attempt to use them. The syntax is fundamentally new for C ++: attributes are supposed to be written in the form of a list, separated by commas, inside double square brackets. This is what the function labeled deprecated looks like:
Other possible attributes: noreturn, carries_dependency, alignas
The code above, being compiled by the last build of clang, displays the following message at compile time:
It is also possible to display your own message:
Attribute deprecated as applicable to the class, typedef-am, the variables are not static data members listed and templates. Here are a couple of examples:
For those who notice the conspicuous inconsistency of the placement of attributes (for example, their use after the class and enum keywords) I will say that this is to distinguish the mark of the type itself from the mark of a variable of this type. For example, the following declaration marks a variable, but not the class itself:
The deprecated attribute can be specified only in one definition of an entity; all the following declarations without this attribute do not remove the deprecated attribute . It is best to put the attribute in the header file - this will tell all users that the entity is outdated and will be deleted.
The attribute is supported since Clang 3.4 and GCC 4.9.
Translator Notes: the attributes that appeared in the C ++ 11 standard were very promising - a new opportunity to add metadata to functions, classes, and other things potentially opened up great opportunities for meta-programming, reflection, testing - in the end, C # and Python already proved real benefits of such language tools and personally I wanted to believe that C ++ would get something similar in the future. Unfortunately, the first attributes introduced ( noreturn , carries_dependency , alignas ) gave a little benefit, which spoiled the positive impression of the feature. deprecated is the first, in my opinion, really simple, understandable and necessary attribute for everyone. I would like to believe that this is a step on the way to further features of the language based on attributes.
New C ++ 14 standard introduces deprecated attributeto mark obsolete entities that are planned to be deleted in the future. The compiler can display warnings for any attempt to use them. The syntax is fundamentally new for C ++: attributes are supposed to be written in the form of a list, separated by commas, inside double square brackets. This is what the function labeled deprecated looks like:
[[deprecated]]
void foo() {}
int main() {
foo(); // в этом месте компилятор выведет предупреждение
}
Other possible attributes: noreturn, carries_dependency, alignas
The code above, being compiled by the last build of clang, displays the following message at compile time:
warning: 'foo' is deprecated [-Wdeprecated-declarations]
foo();
^
note: 'foo' has been explicitly marked deprecated here
void foo() {}
^
It is also possible to display your own message:
[[deprecated("use bar instead")]]
void foo() {}
This gives the following warning instead:
warning: 'foo' is deprecated: use bar instead [-Wdeprecated-declarations]
foo();
^
note: 'foo' has been explicitly marked deprecated here
void foo() {}
^
Attribute deprecated as applicable to the class, typedef-am, the variables are not static data members listed and templates. Here are a couple of examples:
// помечаем функцию
[[deprecated]]
void foo();
// помечаем переменную
[[deprecated]]
int x;
// помечаем только одну переменную в списке определяемых
int y [[deprecated]], z;
// помечаем параметр функции
int triple([[deprecated]] int x);
// помечаем класс или структуру
class [[deprecated]] my_class {
public:
// помечаем член класса
[[deprecated]] int member;
};
// помечаем перечисление
enum [[deprecated]] animals {
CAT, DOG, MOUSE
};
// помечаем typedef
[[deprecated]]
typedef int type;
// помечаем специализацию шаблона
template class templ;
template <>
class [[deprecated]] templ {};
For those who notice the conspicuous inconsistency of the placement of attributes (for example, their use after the class and enum keywords) I will say that this is to distinguish the mark of the type itself from the mark of a variable of this type. For example, the following declaration marks a variable, but not the class itself:
[[deprecated]] class C { } c;
The deprecated attribute can be specified only in one definition of an entity; all the following declarations without this attribute do not remove the deprecated attribute . It is best to put the attribute in the header file - this will tell all users that the entity is outdated and will be deleted.
The attribute is supported since Clang 3.4 and GCC 4.9.
Translator Notes: the attributes that appeared in the C ++ 11 standard were very promising - a new opportunity to add metadata to functions, classes, and other things potentially opened up great opportunities for meta-programming, reflection, testing - in the end, C # and Python already proved real benefits of such language tools and personally I wanted to believe that C ++ would get something similar in the future. Unfortunately, the first attributes introduced ( noreturn , carries_dependency , alignas ) gave a little benefit, which spoiled the positive impression of the feature. deprecated is the first, in my opinion, really simple, understandable and necessary attribute for everyone. I would like to believe that this is a step on the way to further features of the language based on attributes.