Gmail تقويم المستندات مجموعات ويب المزيد »
المجموعات التي قمت بزيارتها مؤخرا | مساعدة | تسجيل الدخول
الصفحة الرئيسية لمجموعات Google
Inherit, same named methods
هناك حالياً عدة مواضيع في هذه المجموعة يتم عرضها كأول موضوع. لجعل هذا الموضوع يظهر كأول موضوع، الرجاء إزالة هذا الخيار من المواضيع اﻷخرى.
وقع خطأ في معالجة طلبك. الرجاء حاول مجددا.
تمييز
  3‏ من الرسائل - طي الكل  -  ترجمة الكل إلى اللغة نص مترجم (عرض جميع المصادر الأصلية)
المجموعة التي تقوم بالإرسال إليها هيمجموعة Usenet. الرسائل المرسلة لهذه المجموعة ستجعل بريدك مرئيًا لأي فرد على شبكة الإنترنت
لم يتم إرسال رسالة الرد حتى الآن.
تم النشر الخاص بك بنجاح
 
من:
إلى:
نسخة إلى:
استجابةً إلى:
أضف "نسخة إلى" | أضف "استجابةً إلى" | تحرير الموضوع
الموضوع:
التحقق:
لغرض التحقق من الصحة، يرجى كتابة الحروف التي تراها في الصورة أدناه أو الأرقام التي تسمعها عند النقر فوق رمز وصول ذوي الاحتياجات الخاصة. استمع وإكتب الأرقام التي تسمعها
 
Michael D. Berger  
عرض ملف التعريف   ترجمة إلى اللغة نص مترجم (عرض المحتوى الأصلي)
 خيارات أكثر 4 نوفمبر, 19:20
مجموعات أخبار: comp.lang.c++
من: "Michael D. Berger" <m_d_berger_1...@yahoo.com>
التاريخ: 04 Nov 2009 17:20:01 GMT
محلّي: ‏الأربعاء 4 نوفمبر 2009 19:20‏
الموضوع: ‏Inherit, same named methods‏
Given:

class A : protected B
{
...

}

Can can the two classes have inline,
non-virtual methods with the same name?

What if the inheritance is public?

Thanks,
Mike.


يجب تسجيل الدخول قبل إرسال رسائلك.
لنشر رسالة يجب أولاً أن تنضم إلى هذه المجموعة.
يرجى تحديث اسم الشهرة الخاص بك على صفحة إعدادات الاشتراك قبل النشر.
لا يوجد لديك الإذن المطلوب للنشر.
Pete Becker  
عرض ملف التعريف   ترجمة إلى اللغة نص مترجم (عرض المحتوى الأصلي)
 خيارات أكثر 4 نوفمبر, 19:33
مجموعات أخبار: comp.lang.c++
من: Pete Becker <p...@versatilecoding.com>
التاريخ: Wed, 04 Nov 2009 12:33:27 -0500
محلّي: ‏الأربعاء 4 نوفمبر 2009 19:33‏
الموضوع: ‏Re: Inherit, same named methods‏

Michael D. Berger wrote:
> Given:

> class A : protected B
> {
> ...
> }

> Can can the two classes have inline,
> non-virtual methods with the same name?

Yes.

> What if the inheritance is public?

Doesn't matter. Try it.

--
   Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)


يجب تسجيل الدخول قبل إرسال رسائلك.
لنشر رسالة يجب أولاً أن تنضم إلى هذه المجموعة.
يرجى تحديث اسم الشهرة الخاص بك على صفحة إعدادات الاشتراك قبل النشر.
لا يوجد لديك الإذن المطلوب للنشر.
Kaz Kylheku  
عرض ملف التعريف   ترجمة إلى اللغة نص مترجم (عرض المحتوى الأصلي)
 خيارات أكثر 4 نوفمبر, 22:47
مجموعات أخبار: comp.lang.c++
من: Kaz Kylheku <kkylh...@gmail.com>
التاريخ: Wed, 4 Nov 2009 20:47:36 +0000 (UTC)
محلّي: ‏الأربعاء 4 نوفمبر 2009 22:47‏
الموضوع: ‏Re: Inherit, same named methods‏
On 2009-11-04, Michael D. Berger <m_d_berger_1...@yahoo.com> wrote:

> Given:

> class A : protected B
> {
> ...
> }

> Can can the two classes have inline,
> non-virtual methods with the same name?

In a sense yes, in a sense no.

Suppose B has one or more member functions called foo. (There may be more
than one due to overloading).

If A also introduces a member called foo, then this identifier will
shadow all of those functions in B.

So, as you correctly suspect, there is in fact a kind of conflict between same
names in a base and derived class, which is resolved by shadowing:  the
presence of a name in the derived class suppresses the inheritance of that
/name/ from the base class into the scope of the derived class.  (But it does
not suppress the inheritance of the /things/ which are named, just the names!
C++ has two kinds of inheritance going on: inheritance of class-scoped
identifiers from one class to another, and inheritance of actual entities like
member functions, data members, and member types).

So for instance if you have

  int B::foo(int);
  int B::foo(double);

and inside A you have

  int A::foo(unsigned long);

then when you call ``a.foo(3)'' on an A object a, only A::foo(unsigned long) is
considered by overload resolution. It's as if the two B::foo functions did not
exist; the expression simply does not see them.

But if A did not have a member called foo, then A::foo will nicely refer to the
set of overloaded functions from B. I.e. the B::foo name is inherited into A,
becoming visible in A's class scope.

In either case, the B functions are reachable via scope resolution:
a.B::foo(...).

You can promote the B functions into A with using directives, so that they are
considered together with A::foo(unsigned int) as candidates for overload
resolution:

   class A : public B {
   public:
      using B::foo; // This is as if A itself now defined those functions.
      int foo(unsigned long);
   };

You don't get to cherry-pick the foo's from B: using B::foo gets
you all of them (you're importing the name, not the functions,
which you have already inherited!)

There can't be a clash, either. If one of the B::foo function is
foo(unsigned long), you're out of luck. Or if B has a foo name which
refers to something other than a function, you're also out of luck: because
then you're asking to have an A::foo which refers to the function
int A::foo(unsigned long), as well as some non-function entity also,
which is a form of overloading not supported in C++.

> What if the inheritance is public?

These public, private and protected specifiers determine access control.
Access control does not determine what is visible and what is inherited,
but what is accessible.

Access control is a way of specifying that if when some visible identifiers are
referenced from certain scopes, then a diagnostic message is required from the
compiler. It's like a glass case: you can see something, but you can't
touch it.


يجب تسجيل الدخول قبل إرسال رسائلك.
لنشر رسالة يجب أولاً أن تنضم إلى هذه المجموعة.
يرجى تحديث اسم الشهرة الخاص بك على صفحة إعدادات الاشتراك قبل النشر.
لا يوجد لديك الإذن المطلوب للنشر.
نهاية الرسائل
« الرجوع إلى المناقشات « موضوع أحدث     موضوع أقدم »

إنشاء مجموعة - مجموعات Google - صفحة Google الرئيسية - شروط الخدمة - سياسة الخصوصية
©2009 Google