Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #12991 > unrolled thread

Why doesn't this multiple virtual inheritance code compile?

Back to article view | Back to comp.lang.c++

Contents

  Why doesn't this multiple virtual inheritance code compile? Chris Stankevitz <chrisstankevitz@gmail.com> - 2012-01-02 12:16 -0800
    Re: Why doesn't this multiple virtual inheritance code compile? Paavo Helde <myfirstname@osa.pri.ee> - 2012-01-02 15:36 -0600
      Re: Why doesn't this multiple virtual inheritance code compile? Chris Stankevitz <chrisstankevitz@gmail.com> - 2012-01-02 14:41 -0800
        Re: Why doesn't this multiple virtual inheritance code compile? Ian Collins <ian-news@hotmail.com> - 2012-01-03 11:54 +1300
        Re: Why doesn't this multiple virtual inheritance code compile? "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-02 23:56 +0000
          Re: Why doesn't this multiple virtual inheritance code compile? Chris Stankevitz <chrisstankevitz@gmail.com> - 2012-01-02 20:25 -0800
            Re: Why doesn't this multiple virtual inheritance code compile? Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-01-03 12:46 +0100
            Re: Why doesn't this multiple virtual inheritance code compile? "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-03 16:34 +0000
        Re: Why doesn't this multiple virtual inheritance code compile? Paavo Helde <myfirstname@osa.pri.ee> - 2012-01-03 01:20 -0600
          Re: Why doesn't this multiple virtual inheritance code compile? Goran <goran.pusic@gmail.com> - 2012-01-02 23:52 -0800
          Re: Why doesn't this multiple virtual inheritance code compile? "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-03 15:42 +0000
          Re: Why doesn't this multiple virtual inheritance code compile? Chris Stankevitz <chrisstankevitz@gmail.com> - 2012-01-03 13:35 -0800
    Re: Why doesn't this multiple virtual inheritance code compile? Robert Wessel <robertwessel2@yahoo.com> - 2012-01-02 16:23 -0600
      Re: Why doesn't this multiple virtual inheritance code compile? Chris Stankevitz <chrisstankevitz@gmail.com> - 2012-01-02 14:43 -0800
    Re: Why doesn't this multiple virtual inheritance code compile? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-03 00:46 +0100
      Re: Why doesn't this multiple virtual inheritance code compile? Chris Stankevitz <chrisstankevitz@gmail.com> - 2012-01-02 20:38 -0800
        Re: Why doesn't this multiple virtual inheritance code compile? Spike <invalid@invalid.invalid> - 2012-01-03 09:35 +0100
          Re: Why doesn't this multiple virtual inheritance code compile? Chris Stankevitz <chrisstankevitz@gmail.com> - 2012-01-03 13:39 -0800
      Re: Why doesn't this multiple virtual inheritance code compile? Leigh Johnston <leigh@i42.co.uk> - 2012-01-03 21:51 +0000
        Re: Why doesn't this multiple virtual inheritance code compile? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-04 02:14 +0100
          Re: Why doesn't this multiple virtual inheritance code compile? Leigh Johnston <leigh@i42.co.uk> - 2012-01-04 01:19 +0000
            Re: Why doesn't this multiple virtual inheritance code compile? Ian Collins <ian-news@hotmail.com> - 2012-01-04 15:15 +1300
              Re: Why doesn't this multiple virtual inheritance code compile? Leigh Johnston <leigh@i42.co.uk> - 2012-01-04 02:58 +0000
          Re: Why doesn't this multiple virtual inheritance code compile? jgk@panix.com (Joe keane) - 2012-01-04 20:45 +0000
    Re: Why doesn't this multiple virtual inheritance code compile? Juha Nieminen <nospam@thanks.invalid> - 2012-01-03 06:26 +0000
    Re: Why doesn't this multiple virtual inheritance code compile? jgk@panix.com (Joe keane) - 2012-01-03 14:12 +0000

Page 2 of 2 — ← Prev page 1 [2]

#13055

On 04/01/2012 01:14, Alf P. Steinbach wrote:
> On 03.01.2012 22:51, Leigh Johnston wrote:
>>
>> For good examples of using the same naming convention for both types and
>> functions see the C++ standard library.
>
> The standard library operates under conditions that normal code does not:
>
> (a) It is guaranteed to be used a lot by everybody.
>
> (a1) all serious users become familiar with the names. This means that
> for the standard library it is more important to reduce typing effort
> (having short names) than to reduce interpretation and recognition
> effort (having self-describing names). Aiming for the latter would just
> be wasted effort.
>
> (a2) since much of it is template based code, short names and terse
> coding style help to reduce compile times. look at the code written pjp
> (e.g. for visual c++'s standard library). it is horrible by the
> standards of ordinary application programming, where clarity is the main
> concern, but it it is near ideal for fast compilation.
>
> (a3) bugs are much more likely to surface early and repeatedly, than
> with ordinary application code. again this reduced the need for clarity.
>
> (b) It can be and in some parts has to be system- and compiler-specific.
> If some particular piece of code is not part of the developers have
> aimed to make portable (to reduce the total effort), then it can be
> written in any compiler- and system-dependent way, whatever the
> developer regards as easiest. This is generally not so for ordinary
> application code.
>
> In short, do not look to the standard library for naming and formatting
> conventions for ordinary application code.
>
> The standard library is not ordinary application code: it operates under
> a totally different set of rules.

There can only be one response to the above verbiage: LOL!

HTH.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13056

On 01/ 4/12 02:19 PM, Leigh Johnston wrote:
> On 04/01/2012 01:14, Alf P. Steinbach wrote:
>> On 03.01.2012 22:51, Leigh Johnston wrote:
>>>
>>> For good examples of using the same naming convention for both types and
>>> functions see the C++ standard library.
>>
>> The standard library operates under conditions that normal code does not:
>>
>> (a) It is guaranteed to be used a lot by everybody.
>>
>> (a1) all serious users become familiar with the names. This means that
>> for the standard library it is more important to reduce typing effort
>> (having short names) than to reduce interpretation and recognition
>> effort (having self-describing names). Aiming for the latter would just
>> be wasted effort.
>>
>> (a2) since much of it is template based code, short names and terse
>> coding style help to reduce compile times. look at the code written pjp
>> (e.g. for visual c++'s standard library). it is horrible by the
>> standards of ordinary application programming, where clarity is the main
>> concern, but it it is near ideal for fast compilation.
>>
>> (a3) bugs are much more likely to surface early and repeatedly, than
>> with ordinary application code. again this reduced the need for clarity.
>>
>> (b) It can be and in some parts has to be system- and compiler-specific.
>> If some particular piece of code is not part of the developers have
>> aimed to make portable (to reduce the total effort), then it can be
>> written in any compiler- and system-dependent way, whatever the
>> developer regards as easiest. This is generally not so for ordinary
>> application code.
>>
>> In short, do not look to the standard library for naming and formatting
>> conventions for ordinary application code.
>>
>> The standard library is not ordinary application code: it operates under
>> a totally different set of rules.
>
> There can only be one response to the above verbiage: LOL!

Why?

I've worked on a lot of projects with almost as many coding standards 
and I don't think the standard library naming conventions would be 
acceptable under any of them.  All of my current clients have some form 
of different naming convention for types rule.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13060

On 04/01/2012 02:15, Ian Collins wrote:
> On 01/ 4/12 02:19 PM, Leigh Johnston wrote:
>> On 04/01/2012 01:14, Alf P. Steinbach wrote:
>>> On 03.01.2012 22:51, Leigh Johnston wrote:
>>>>
>>>> For good examples of using the same naming convention for both types
>>>> and
>>>> functions see the C++ standard library.
>>>
>>> The standard library operates under conditions that normal code does
>>> not:
>>>
>>> (a) It is guaranteed to be used a lot by everybody.
>>>
>>> (a1) all serious users become familiar with the names. This means that
>>> for the standard library it is more important to reduce typing effort
>>> (having short names) than to reduce interpretation and recognition
>>> effort (having self-describing names). Aiming for the latter would just
>>> be wasted effort.
>>>
>>> (a2) since much of it is template based code, short names and terse
>>> coding style help to reduce compile times. look at the code written pjp
>>> (e.g. for visual c++'s standard library). it is horrible by the
>>> standards of ordinary application programming, where clarity is the main
>>> concern, but it it is near ideal for fast compilation.
>>>
>>> (a3) bugs are much more likely to surface early and repeatedly, than
>>> with ordinary application code. again this reduced the need for clarity.
>>>
>>> (b) It can be and in some parts has to be system- and compiler-specific.
>>> If some particular piece of code is not part of the developers have
>>> aimed to make portable (to reduce the total effort), then it can be
>>> written in any compiler- and system-dependent way, whatever the
>>> developer regards as easiest. This is generally not so for ordinary
>>> application code.
>>>
>>> In short, do not look to the standard library for naming and formatting
>>> conventions for ordinary application code.
>>>
>>> The standard library is not ordinary application code: it operates under
>>> a totally different set of rules.
>>
>> There can only be one response to the above verbiage: LOL!
>
> Why?
>
> I've worked on a lot of projects with almost as many coding standards
> and I don't think the standard library naming conventions would be
> acceptable under any of them. All of my current clients have some form
> of different naming convention for types rule.

You have obviously never worked with MFC then (even if MFC is a bag of 
shite).

I would like to see you define a constructor or destructor with a 
different naming convention to that of the type to which it belongs; 
that would be truly impressive.  Perhaps ctors and dtors are special 
cases in these many coding standards you have been working with?  How 
convenient if so.

Perhaps by "function" you mean "free function"?  If so giving free 
functions a different naming convention to member functions seems rather 
arbitrary to me.

The LOL stands.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13089

In article <je096m$l1d$1@dont-email.me>,
Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
>The standard library operates under conditions that normal code does not:

c) It has a precise specification, that is more or less set in stone.

Often apps do not have much documentation [especially of internals], and
what there is may be inaccurate or out of date.  So it is important for
the code to explain itself.

I would not mind if the standard headers have -no- comments.  So long as
it works right...

[toc] | [prev] | [next] | [standalone]

#13018

Chris Stankevitz <chrisstankevitz@gmail.com> wrote:
> test.cpp: In function 'Shape* ShapeFactory()':
> test.cpp:21:14: error: cannot allocate an object of abstract type
> 'Square'
> test.cpp:16:1: note:   because the following virtual functions are
> pure within 'Square':
> test.cpp:3:16: note:    virtual void Observer::Notify()

  How about you try to read what the compiler is telling you? It's telling
to the exact reason why you cannot instantiate the class: You have a pure
virtual function in the base class that is not implemented in the derived
class.

[toc] | [prev] | [next] | [standalone]

#13025

In article <785a07d6-7cf7-4249-a123-f7d7b4aaa8b3@l24g2000yqm.googlegroups.com>,
Chris Stankevitz  <chrisstankevitz@gmail.com> wrote:
> - Create an abstract base class "Shape" that must be an "Observer"
> - Create an class "Square" that is a "Shape" and also an "ObserverImp"

So a 'Shape' is an 'Observer', and a 'Square' is a type of 'Shape'.

Now you want something that is an 'ObserverImp' [and it is square].
Wouldn't it make more sense to call it a 'SquareImp'?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web