C++.Coding.Standards.1918.Rules.Guidelines [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

C++.Coding.Standards.1918.Rules.Guidelines [Electronic resources] - نسخه متنی

Herb Sutter, Andrei Alexandrescu

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید


Discussion


Using inheritance when it is not needed betrays a misplaced faith in the power of object orientation. In C++, you need to do specific things when defining base classes (see also Items 32, 50, and 54), and very different and often contrary things when designing standalone classes. Inheriting from a standalone class opens your code to a host of problems, very few of which will be ever flagged by your compiler.

Beginners sometimes derive from value classes, such as a

string class (the standard one or another), to "add more functionality." However, defining free (nonmember) functions is vastly superior to creating

super_string for the following reasons:

  • Nonmember functions work well within existing code that already manipulates

    string s. If instead you supply a

    super_string , you force changes throughout your code base to change types and function signatures to

    super_string .

  • Interface functions that take a

    string now need to: a) stay away from

    super_string 's added functionality (unuseful); b) copy their argument to a

    super_string (wasteful); or c) cast the

    string reference to a

    super_string reference (awkward and potentially illegal).

  • super_string 's member functions don't have any more access to

    string 's internals than nonmember functions because

    string probably doesn't have

    protected members (remember, it wasn't meant to be derived from in the first place).

  • If

    super_string hides some of

    string 's functions (and redefining a nonvirtual function in a derived class is not overriding, it's just hiding), that could cause widespread confusion in code that manipulates

    string s that started their life converted automatically from

    super_string s.


So, prefer to add functionality via new nonmember functions (see Item 44). To avoid name lookup problems, make sure you put them in the same namespace as the type they are meant to extend (see Item 57). Some people dislike nonmember functions because the invocation syntax is

Fun(str) instead of

str.Fun() , but this is just a matter of syntactic habit and familiarity. (Then there's the sound bite, attributed to the legendary Alan Perlis, that too much syntactic sugar causes cancer of the semicolon.)Item 54) and so any copying of a

super_string to a

string will silently chop off all of the carefully maintained extra state.Item 50). This undefined behavior might seem to be tolerated by your compiler and memory allocator, but it leaves you in the dark swamp of silent errors, memory leaks, heap corruptions, and porting nightmares.


/ 521