{"id":2999,"date":"2018-07-05T20:00:39","date_gmt":"2018-07-05T18:00:39","guid":{"rendered":"https:\/\/mariusbancila.ro\/blog\/?p=2999"},"modified":"2018-07-08T23:34:32","modified_gmt":"2018-07-08T21:34:32","slug":"c17-removed-and-deprecated-features","status":"publish","type":"post","link":"https:\/\/mariusbancila.ro\/blog\/2018\/07\/05\/c17-removed-and-deprecated-features\/","title":{"rendered":"C++17 removed and deprecated features"},"content":{"rendered":"

Along with the new features added to the language and the standard library in C++17, there are also existing features that have been either removed (after being deprecated in a previous version) or deprecated so they would be removed sometime in the future. Although not complete, the following tables list the most important of these removed or deprecated features. <\/p>\n

The following table lists features that were removed in C++17.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Feature<\/th>\nComments<\/th>\nAlternatives<\/th>\n<\/tr>\n
throw(typeid)<\/a><\/td>\nExplicit dynamic specification allowed specifying one or more types for exception that might be thrown by a function.<\/td>\nThis feature does not have an alternative. Instead, functions should only specify whether they could throw exceptions or not (without specifying their type). noexcept<\/tt> is the specifier use for this purpose. However, make sure you use it only when it’s guarantee that the invocation of the function cannot throw any error; otherwise, the program will terminate abnormally with a call to std::terminate()<\/tt>.<\/td>\n<\/tr>\n
operator++ for bool<\/a><\/td>\nThe pre-fix and post-fix operator++ was overloaded for type bool<\/tt>. In both cases, the return value for a bool<\/tt> argument is true<\/tt>. Since the bool<\/tt> type does not support the full set of arithmetic types, it is no longer considered an arithmetic type and these operators have been removed.<\/td>\nstd::exchange<\/a> for the rare cases where the post-fix operator has valid uses. See exchange() utility function, revision 3<\/a> for examples of these cases.<\/td>\n<\/tr>\n
Trigraphs<\/a><\/td>\nTrigraphs (short for three-character groups) are alternatives for some characters, introduced with two question marks (which is also the reason the question mark has to be escaped '\\?'<\/tt>). They were introduced for compatibility with C which had them for keyboards that did not support the ISO 646 character set<\/a>. Trigraphs are parsed before comments and string literals are recognized and can be a source of confusion for many programmers. For reason of deprecation see Comment on proposed trigraph deprecation<\/a>.<\/td>\nNone<\/td>\n<\/tr>\n
register storage specifier<\/a><\/td>\nWas a specifier for objects declared at block scope or in function parameter lists to indicate automatic storage duration as well as a hint to the compiler that these variables might be heavily used so that it can do optimization by storing it in a CPU register. Since the automatic storage duration for these kinds of variables is implicit and the hint was rarely used by the compilers this feature was deprecated in C++11 and removed in C++17.<\/td>\nNone<\/td>\n<\/tr>\n
std::auto_ptr<\/a><\/td>\nauto_ptr<\/tt> was the attempt to create a smart pointer to handle an object’s lifetime before move semantics were available. This smart pointer quietly steals ownership of the managed object in its copy constructor and copy assignment from the right-hand argument. As a result, the copy is not the same as the original smart pointer object. Because of these copy semantics, auto_ptr<\/tt> does not meet the requirements of being CopyConstructible<\/em>, and therefore cannot be used in standard containers. For more information about the deprecation of auto_ptr<\/tt> see N1856<\/a>.<\/td>\nFor most uses, std::unique_ptr<\/a> is the direct replacement of std::auto_ptr<\/tt>. In many cases, it can be a simple drop in replacement, although an explicit move might be necessary to be done. For more information on the topic see this discussion<\/a>.<\/td>\n<\/tr>\n
std::random_shuffle<\/a><\/td>\nThis algorithm reorders elements of a range so that each possible permutation of its elements has an equal probability of appearance. The problem with it is that it may depend on the rand<\/tt> family of C functions, that may be deprecated in the future. On the other hand, it may also have global state for seeding and others. For more information see std::random_shuffle is deprecated in C++14<\/a>.<\/td>\nThe replacement is std::shuffle<\/a>, that needs as the third argument a uniform random bit generator<\/a>. Although the replacement of the algorithm itself is trivial, you need to setup a URNG, several standard ones being available in the <random><\/tt> header.<\/td>\n<\/tr>\n
std::unary_function<\/a>, std::binary_function<\/a>\n <\/td>\nThese are former types used solely for defining some types (argument and result types). They used to be the base class for function objects that required these type definitions because they were necessary in some parts of the standard library. Such an function object was std::less<\/tt>. These restrictions have been lifted in C++11 because they were actually an overspecification.<\/td>\nIf needed, define the argument and result types in your class.<\/td>\n<\/tr>\n
std::pointer_to_unary_function<\/a>, std::pointer_to_binary_function<\/a>\n<\/td>\nFunction objects that act as wrappers around unary or binary functions. <\/td>\nstd::function<\/a> and std::ref<\/a>\n<\/td>\n<\/tr>\n
std::ptr_fun<\/a>\n<\/td>\nCreates instances of std::pointer_to_unary_function<\/tt> and std::pointer_to_binary_function<\/tt>.<\/td>\n<\/tr>\n
\nstd::mem_fun_t<\/a>,
\nstd::mem_fun1_t<\/a>,
\nstd::const_mem_fun_t<\/a>,
\nstd::const_mem_fun1_t<\/a>,
\nstd::mem_fun_ref_t<\/a>,
\nstd::mem_fun1_ref_t<\/a>,
\nstd::const_mem_fun_ref_t<\/a>,
\nstd::const_mem_fun1_ref_t<\/a><\/td>\n		These are function objects that wrap a pointer to a member function with no parameters or one parameter. For the former, the object whose member function to call is passed by pointer to the call operator; for the latter, it is passed as a reference. They are deprecated because they are limited to member functions with either none or just one argument and you need different functions and function objects for handling pointers or references to the class instance.<\/td>\nstd::mem_fn<\/a> is a variadic template that can handle member functions with any number of variables and not only references or pointers to objects but also smart pointers.<\/td>\n<\/tr>\n
std::mem_fun<\/a>, std::mem_fun_ref<\/a>\n<\/td>\nThese are helper functions that create the member function wrapper objects above.<\/td>\n<\/tr>\n
std::binder1st<\/a>, std::binder2nd<\/a><\/td>\nThese are function objects that bind an argument to a binary function.<\/td>\nLambdas, std::bind<\/a><\/td>\n<\/tr>\n
std::bind1st<\/a>, std::bind2nd<\/a><\/td>\nHelper functions that create instances of std::binder1st<\/tt> or std::binder2nd<\/tt>, binding a given argument to a first or second parameter of a given binary function object.
\nThese were remnants of utility functions in STL that did make it into C++98 but became obsolete with the introduction of lambdas in C++11, when they were deprecated.\n <\/td>\n<\/tr>\n
std::function<\/a> allocator support<\/td>\nSeveral constructors allow to specify an allocator used for allocating internal memory if needed. However, this was later considered poorly specified and inconsistently implemented (with some implementation not providing these overloads at all). Therefore, these constructor overloads were removed in C++17.<\/td>\nNone<\/td>\n<\/tr>\n
std::uses_allocator<std::function><\/a><\/td>\nA specialization of std::uses_allocator<\/tt> used for indicating that all objects of type std::function<\/tt> support uses-allocator construction. This was removed together with the allocator support for std::function<\/tt>.<\/td>\n<\/tr>\n<\/table>\n

The following table lists features that were deprecated in C++17 and removed in C++20.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Feature<\/th>\nComments<\/th>\nAlternatives<\/th>\n<\/tr>\n
std::uncaught_exception<\/a><\/td>\nThis function indicates whether the stack unwiding is already in progress. It assumes there’s only one active exception in a thread, although multiple can exist simultaneously. This function was sometimes wrongly used in destructors to detect if the destructor was called due to stack unwiding. But as explained in GotW #47: Uncaught Exceptions<\/a>, that is a bad pattern, because once unwinding of any exception, everything looks like unwiding regardless how many active exception exist. As a result, this function had no useful purpose and will be removed. For more information see N4152<\/a>.<\/td>\nstd::uncaught_exceptions<\/a> indicates the number of exceptions in the current thread that have been thrown\/rethrown and not yet entered their matching catch clauses.<\/td>\n<\/tr>\n
throw()<\/a><\/td>\nThis is the non-throwing version of the dynamic exception specification hat has been deprecated and now removed. This specifier has been replaced with noexcept<\/tt> a term that is more clear on its intent.<\/td>\nnoexcept<\/a><\/td>\n<\/tr>\n
std::unary_negate<\/a>, std::binary_negate<\/a>\n<\/td>\nThese are wrapper function objects that return the complement of the unary or binary predicate they hold.<\/td>\nLambdas, std::not_fn<\/a><\/td>\n<\/tr>\n
std::not1<\/a>, std::not2<\/a>\n<\/td>\nThese are helper functions used to construct std::unary_negate<\/tt> and std::binary_negate<\/tt> function objects.<\/td>\n<\/tr>\n
std::get_temporary_buffer<\/a>, std::return_temporary_buffer<\/a>, std::raw_storage_iterator<\/a><\/td>\nThese are remnants of the original STL implementation that where added into the standard together with other utilities but have little to no real usefulness nowadays (although they’re used internally by some standard algorithms like stable_partition()<\/tt>) and therefore have been deprecated and will be removed. See Why do I need std::get_temporary_buffer?<\/a> for more information on the utility of these functions.\n<\/td>\nNone<\/td>\n<\/tr>\n
std::is_literal_type<\/a>, std::is_literal_type_v<\/a><\/td>\nThe intention of this type trait was to ensure that a specific construction would produce constant initialization. However, the requirement that a type should have at least one constexpr constructor (that is not a copy or move constructor) it too week to ensure such guarantee. See Deprecate the is_literal Trait<\/a> for the rational of deprecating this feature.<\/td>\nNone<\/td>\n<\/tr>\n
std::result_of<\/a>, std::result_of_t<\/a><\/td>\nThis is a type trait used to deduce the return type of an invoke expression at compile time. In C++11, its behaviour is undefine when the invoke expression is ill-formed (if F<\/tt> is not a callable type, reference to function, or reference to callable type). In C++14, this was changed to SFINAE. Because of its limitations (for instance F<\/tt> cannot be a function type, but can be a reference to it, and F<\/tt> and any of its arguments cannot be an abstract class type, etc.) it has been replaced with std::invoke_result<\/tt>.<\/td>\nstd::invoke_result<\/a><\/td>\n<\/tr>\n
std::shared_ptr::unique<\/a><\/td>\nIndicates whether the current object is the only shared_ptr<\/tt> instance that manages the object. This function does not work properly in a multithreading environement, the use count of the object being only an approximation. This was initially intended as a debug only feature but to work properly it needs synchronization, which is not used in practice. See Why is std::shared_ptr::unique() deprecated?<\/a> for more information.<\/td>\nNone<\/td>\n<\/tr>\n<\/table>\n

The following table lists features that were deprecated in C++17.<\/p>\n\n\n\n\n\n
Feature<\/th>\nComments<\/th>\nAlternatives<\/th>\n<\/tr>\n
<codecvt><\/a> header<\/td>\nIs a part of the localization library, providing facets for converting between byte and wide character sets (such as UTF-8 and UTF-16). It was deprecated because it is not considered “the best way to address transcoding”, for several reasons, such as lacking of default error handling mechanisms for attacks through ill-formed UTF, obscure specifications, lack of portability, etc. For more information, see Deprecating <codecvt><\/tt>.<\/td>\nNone<\/td>\n<\/tr>\n
std::wbuffer_convert, std::wstring_convert<\/a><\/td>\nThese are utility types that perform conversion between a byte stream buffer and a wide stream buffer and, respectively, between a byte string and a wide string using conversion facets from <codecvt><\/tt> (the ones available are std::codecvt_utf8<\/tt> for UTF-8\/UCS2 and UTF-8\/UCS4 conversions and std::codecvt_utf8_utf16 for UTF-8\/UTF-16<\/tt> conversions). Since these go together with the deprecated standard facets from <codecvt><\/tt>, they have been also deprecated.<\/td>\nNone<\/td>\n<\/tr>\n
std::iterator<\/a><\/td>\nIs a base class that was provided in the first version of the standard to simplify the definition of iterator types by providing five type definitions (iterator_category<\/tt>, value_type<\/tt>, difference_type<\/tt>, pointer<\/tt>, reference<\/tt>). It is often used with a sequence of void<\/tt> arguments (such as in iterator<output_iterator_tag, void, void, void, void><\/tt>). Following the pattern with deprecating unary_function<\/tt> and binary_function<\/tt> and explicitly definiting the types in the class rather than having a base class for that, the iterator<\/tt> class has also been deprecated.<\/td>\nSpecify the necessary type definitions in your class.<\/td>\n<\/tr>\n<\/table>\n

For more changes between C++14 and C++17 see this document<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Along with the new features added to the language and the standard library in C++17, there are also existing features that have been either removed (after being deprecated in a previous version) or deprecated so they would be removed sometime in the future. Although not complete, the following tables list the most important of these removed or deprecated features. <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","advgb_blocks_editor_width":"","advgb_blocks_columns_visual_guide":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[7],"tags":[451,475,138,74],"class_list":["post-2999","post","type-post","status-publish","format-standard","hentry","category-c","tag-c","tag-c17","tag-library","tag-standard"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t