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 1 of 2  [1] 2  Next page →

#12991 — Why doesn't this multiple virtual inheritance code compile?

My intention is to
 - Create an abstract base class "Shape" that must be an "Observer"
 - Create an class "Square" that is a "Shape" and also an
"ObserverImp"

I thought I could do this like so:

struct Observer
{
  virtual void Notify() = 0;
};

struct ObserverImp : public Observer
{
  void Notify() {}
};

struct Shape : public virtual Observer
{
};

struct Square : public Shape, public ObserverImp
{
};

Shape* ShapeFactory()
{
  return new Square;
}

$ g++ -Wall -c test.cpp
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()
test.cpp:22:1: warning: control reaches end of non-void function

Q: How can I do this using c++?

Thank you,

Chris

[toc] | [next] | [standalone]

#12997

Chris Stankevitz <chrisstankevitz@gmail.com> wrote in news:785a07d6-7cf7-
4249-a123-f7d7b4aaa8b3@l24g2000yqm.googlegroups.com:

> 
> My intention is to
>  - Create an abstract base class "Shape" that must be an "Observer"
>  - Create an class "Square" that is a "Shape" and also an
> "ObserverImp"
> 
> I thought I could do this like so:
> 
> struct Observer
> {
>   virtual void Notify() = 0;
> };
> 
> struct ObserverImp : public Observer

You could try to make this 'public virtual Observer'. In order to have 
any real use of virtual inheritance, the 'virtual' keyword must be 
present in all inheritance tree branches for the shared base class.

That said, I'm not at all convinced that virtual inheritance is the right 
approach here. I have not yet encountered a need for virtual inheritance 
in my daily work.

hth
Paavo

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

#13005

On Jan 2, 1:36 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> You could try to make this 'public virtual Observer'.

Thank you, yes I overlooked this.  Although this does not help the
compile problem.

> That said, I'm not at all convinced that virtual inheritance is the right
> approach here.

Me too -- if it doesn't compile, it probably is not the correct
approach!

How would you go about accomplishing this with C++, if it is possible:
 - Create an abstract base class "Shape" that must be an "Observer"
 - Create an class "Square" that is a "Shape" and uses "ObserverImp"
to implement the "Observer" behavior.

Thank you,

Chris

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

#13007

On 01/ 3/12 11:41 AM, Chris Stankevitz wrote:
> On Jan 2, 1:36 pm, Paavo Helde<myfirstn...@osa.pri.ee>  wrote:
>> You could try to make this 'public virtual Observer'.
>
> Thank you, yes I overlooked this.  Although this does not help the
> compile problem.
>
>> That said, I'm not at all convinced that virtual inheritance is the right
>> approach here.
>
> Me too -- if it doesn't compile, it probably is not the correct
> approach!
>
> How would you go about accomplishing this with C++, if it is possible:
>   - Create an abstract base class "Shape" that must be an "Observer"
>   - Create an class "Square" that is a "Shape" and uses "ObserverImp"
> to implement the "Observer" behavior.

If you don't actually require dynamic binding, you could make Observer a 
template with Imp as it's parameter:

template <typename Imp> struct Observer
{
   void Notify() { Imp::notify(); }
};

struct Imp
{
   void Notify() {}
};

struct Shape : Observer<Imp>
{
};

struct Square : Shape
{
};

-- 
Ian Collins

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

#13013

"Chris Stankevitz" <chrisstankevitz@gmail.com> wrote in message 
news:d86e4d32-6781-4cf9-a85a-b806c4325764@r5g2000yqc.googlegroups.com...
On Jan 2, 1:36 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>> You could try to make this 'public virtual Observer'.

>Thank you, yes I overlooked this.  Although this does not help the
>compile problem.

>> That said, I'm not at all convinced that virtual inheritance is the right
>> approach here.

>Me too -- if it doesn't compile, it probably is not the correct
>approach!

>How would you go about accomplishing this with C++, if it is possible:
> - Create an abstract base class "Shape" that must be an "Observer"
> - Create an class "Square" that is a "Shape" and uses "ObserverImp"
>to implement the "Observer" behavior.

I don't see the problem here , maybe I am missing something.....

<code>
class observer{
public:
virtual void Notify()=0;
};

class observerImp:public observer{
public:
 virtual void Notify(){;}
};

class Shape:public observerImp{};
class Square: public Shape{ };

int main(){
 Shape* shp = new Square;
 shp->Notify();
  return 0;
}
</code>

Do you really need Shape to be abstract?




--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#13015

On Jan 2, 3:56 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:
> class Shape:public observerImp{};

Paul,

I do not want all Shapes to be observerImps.  I want all shapes to be
observers.  I suspect what I want is not possible with c++.

Thank you,

Chris

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

#13024

On 03.01.2012 05:25, Chris Stankevitz wrote:
> I do not want all Shapes to be observerImps.  I want all shapes to be
> observers.  I suspect what I want is not possible with c++.

What you are going to do is to have a helper class OberserImp that 
implements the observer interface independently of the outer class. And 
you want to be able to use this helper class down in the class tree not 
only at the level of the interface reference in the class Shape.

I know two solution for this in C++.

1. The Java way.
The equivalent of interfaces in Java and .NET are virtual abstract base 
classes in C++. If you want the Java behavior you always need to derive 
virtual from all interface like C++ classes.
That was your approach except for the missing virtual at class Shape.

2. An template implememtation helper.
template <typename BASE>
   class ObserverImp : BASE
   {
     void Notify() {}
   };
   class Square : public ObserverImp<Shape>
   {
   };

#1 has the disadvantage that it always requires another level of 
indirection to access interface members at run time, even if this is not 
required. And in real life this is required quite rarely.
The performance impact of this indirection is usually no big deal, but 
the reduced possibilities for optimization and especially inlining could 
be relevant.


Marcel

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

#13028

"Chris Stankevitz" <chrisstankevitz@gmail.com> wrote in message 
news:235e3940-7a03-4ad6-8eea-905a2b776d1f@p16g2000yqd.googlegroups.com...
On Jan 2, 3:56 pm, "Paul" <pchrist<nospam>o...@yahoo.co.uk> wrote:
> class Shape:public observerImp{};

Paul,

I do not want all Shapes to be observerImps.  I want all shapes to be
observers.  I suspect what I want is not possible with c++.

------------------------------------------------------
ok then this raises the question.... Where does the imlementation come from 
for those Shapes that are not observerImps? 



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#13019

Chris Stankevitz <chrisstankevitz@gmail.com> wrote in
news:d86e4d32-6781-4cf9-a85a-b806c4325764@r5g2000yqc.googlegroups.com: 

> On Jan 2, 1:36 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>> You could try to make this 'public virtual Observer'.
> 
> Thank you, yes I overlooked this.  Although this does not help the
> compile problem.

Strange, compiles fine with my MSVC2010 and gcc (though MSVC issues a 
strange warning):

x64: tmp>cat test2.cpp

struct Observer
{
  virtual void Notify() = 0;
};

struct ObserverImp : public virtual Observer
{
  void Notify() {}
};

struct Shape : public virtual Observer
{
};

struct Square : public Shape, public ObserverImp
{
};

Shape* ShapeFactory()
{
  return new Square;
}

int main() {
  Square sq;
  sq.Notify();
}

x64: tmp>g++ test2.cpp -Wall
x64: tmp>g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-
999/configure --verbose --program-suffix=-3 --prefix=/usr --exec-
prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --
libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --
enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-
included-gettext --enable-version-s
pecific-runtime-libs --without-x --enable-libgcj --disable-java-awt --
with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-
threads=posix --enable-java-gc=boehm --d
isable-win32-registry --enable-sjlj-exceptions --enable-hash-
synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

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

#13020

On Jan 3, 8:20 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> Chris Stankevitz <chrisstankev...@gmail.com> wrote innews:d86e4d32-6781-4cf9-a85a-b806c4325764@r5g2000yqc.googlegroups.com:
>
> > On Jan 2, 1:36 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> >> You could try to make this 'public virtual Observer'.
>
> > Thank you, yes I overlooked this.  Although this does not help the
> > compile problem.
>
> Strange, compiles fine with my MSVC2010 and gcc (though MSVC issues a
> strange warning):

AFAICanSee, what Paavo suggested is __the__ solution for your
conundrum. Comeau also (obviously) compiles this. Chris, what is the
compiler error?

Goran.

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

#13027

"Paavo Helde" <myfirstname@osa.pri.ee> wrote in message 
news:Xns9FCF5F1311FE9myfirstnameosapriee@216.196.109.131...
> Chris Stankevitz <chrisstankevitz@gmail.com> wrote in
> news:d86e4d32-6781-4cf9-a85a-b806c4325764@r5g2000yqc.googlegroups.com:
>
>> On Jan 2, 1:36 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>>> You could try to make this 'public virtual Observer'.
>>
>> Thank you, yes I overlooked this.  Although this does not help the
>> compile problem.
>
> Strange, compiles fine with my MSVC2010 and gcc (though MSVC issues a
> strange warning):
>
> x64: tmp>cat test2.cpp
>
> struct Observer
> {
>  virtual void Notify() = 0;
> };
>
> struct ObserverImp : public virtual Observer
> {
>  void Notify() {}
> };
>
> struct Shape : public virtual Observer
> {
> };
>
> struct Square : public Shape, public ObserverImp
> {
> };
>
> Shape* ShapeFactory()
> {
>  return new Square;
> }
>
> int main() {
>  Square sq;
>  sq.Notify();
> }
>
> x64: tmp>g++ test2.cpp -Wall
> x64: tmp>g++ -v
> Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
> Configured with: /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-
> 999/configure --verbose --program-suffix=-3 --prefix=/usr --exec-
> prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --
> libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --
> enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-
> included-gettext --enable-version-s
> pecific-runtime-libs --without-x --enable-libgcj --disable-java-awt --
> with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-
> threads=posix --enable-java-gc=boehm --d
> isable-win32-registry --enable-sjlj-exceptions --enable-hash-
> synchronization --enable-libstdcxx-debug
> Thread model: posix
> gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

Yes this compiles fine for me too. There is another thread here about the 
MSVC warning..

http://stackoverflow.com/questions/469508/visual-studio-compiler-warning-c4250-class1-inherits-class2member-via-d 



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

#13043

On Jan 2, 11:20 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> Strange, compiles fine with my MSVC2010 and gcc (though MSVC issues a
> strange warning):

Paavo,

Thank you for your help and for posting the valid source in its
entirety.  I have it compiling now.  The mistake I made was: missing
"virtual" in the declaration for class Shape.  "Virtual" must appear
in the class declarations for "Shape" and "ObserverImp".  Apparently I
had trouble parsing people's "english" description of my mistake but I
had no trouble parsing the c++ code in its entirety.

The code that compiles and the g++ invocation appear below.

Thank you again,

Chris

===


struct Observer
{
  virtual void Notify() = 0;
};

struct ObserverImp : public virtual Observer
{
  void Notify() {}
};

struct Shape : public virtual Observer
{
};

struct Square : public Shape, public ObserverImp
{
};

Shape* ShapeFactory()
{
  return new Square;
}

====

$ g++ -Wall -c test.cpp

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

#13003

On Mon, 2 Jan 2012 12:16:31 -0800 (PST), Chris Stankevitz
<chrisstankevitz@gmail.com> wrote:

>
>My intention is to
> - Create an abstract base class "Shape" that must be an "Observer"
> - Create an class "Square" that is a "Shape" and also an
>"ObserverImp"
>
>I thought I could do this like so:
>
>struct Observer
>{
>  virtual void Notify() = 0;
>};
>
>struct ObserverImp : public Observer
>{
>  void Notify() {}
>};
>
>struct Shape : public virtual Observer
>{
>};
>
>struct Square : public Shape, public ObserverImp
>{
>};
>
>Shape* ShapeFactory()
>{
>  return new Square;
>}
>
>$ g++ -Wall -c test.cpp
>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()
>test.cpp:22:1: warning: control reaches end of non-void function
>
>Q: How can I do this using c++?


Instantiating Square requires instantiating both an Observer and
ObserverImp under the hood.  The latter is not a problem, but Observer
has a pure virtual function, thus cannot be instantiated without
providing an implementation.  The obvious solution is to add an
implementation of the required function to Square:

  void Observer::Notify() {};

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

#13006

On Jan 2, 2:23 pm, Robert Wessel <robertwess...@yahoo.com> wrote:
> Instantiating Square requires instantiating both an Observer and
> ObserverImp under the hood.

Yes, apparently so.  I naively thought using "virtual inheritance"
would make it so that both base classes need not be instantiated.

> The obvious solution is to add an
> implementation of the required function to Square:

I am trying to avoid that particular obvious solution as it involves
me typing the same code in all of my Shape implementations.  Plus I've
already written that code: it's in ObserverImp.

Thank you,

Chris

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

#13011

On 02.01.2012 21:16, Chris Stankevitz wrote:
> My intention is to
>   - Create an abstract base class "Shape" that must be an "Observer"
>   - Create an class "Square" that is a "Shape" and also an
> "ObserverImp"
>
> I thought I could do this like so:
>
> struct Observer
> {
>    virtual void Notify() = 0;
> };
>
> struct ObserverImp : public Observer
> {
>    void Notify() {}
> };

Use virtual inheritance for the interface (that is for `Observer`).


> struct Shape : public virtual Observer
> {
> };
>
> struct Square : public Shape, public ObserverImp
> {
> };

Technically OK.


> Shape* ShapeFactory()

Please use different naming conventions for types and functions.


> {
>    return new Square;
> }

No. Forget the Java-isms. You don't need any 
factory-manager-singleton-envelope-blahblah complication.

Or at least, if you absolutely have to code Java in C++, then do it 
properly.

E.g., then return a smart pointer, not a raw pointer.


> $ g++ -Wall -c test.cpp
> 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()
> test.cpp:22:1: warning: control reaches end of non-void function
>
> Q: How can I do this using c++?

See above.

It then compiles nicely, and corresponds directly to Java-like 
implementation inheritance for an interface.

If you run into any problems then please post to a new thread with your 
exact code and compiler invocation.


Cheers & hth.,

- Alf

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

#13016

On Jan 2, 3:46 pm, "Alf P. Steinbach" <alf.p.steinbach
+use...@gmail.com> wrote:
> If you run into any problems then please post to a new thread with your
> exact code and compiler invocation.

Alf,

I attempted what you suggested (minus the style, factory, auto_ptr,
and new thread suggestions).  What I came up with did not compile.
(Compiler invocation appears below).  Would you please tell me how I
can modify this code so that it compiles and implements:
 - Create an abstract base class "Shape" that must be an "Observer"
 - Create a class "Square" that is a "Shape" and uses "ObserverImp" to
implement the "Observer" behavior.

Thank you,

Chris

//-----

struct Observer
{
  virtual void Notify() = 0;
};

struct ObserverImp : public virtual Observer
{
  void Notify() {}
};

struct Shape : public Observer
{
};

struct Square : public Shape, public ObserverImp
{
};

Shape* ShapeFactory()
{
  return new Square;
}

//-----

$ g++ -Wall -c test.cpp
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()
test.cpp:22:1: warning: control reaches end of non-void function

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

#13022

On 03/01/2012 05:38, Chris Stankevitz wrote:
> struct Shape : public Observer
> {
> };

struct Shape : public virtual Observer
{
};

Your code was missing one virtual modifier.

Also you need to declare the base classes destructors as virtual.
See http://en.wikipedia.org/wiki/Virtual_function#Virtual_destructors 
for an explanation.

HTH

-- 
http://www.econet-project.eu

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

#13044

On Jan 3, 12:35 am, Spike <inva...@invalid.invalid> wrote:
> Your code was missing one virtual modifier.
>
> Also you need to declare the base classes destructors as virtual.
> Seehttp://en.wikipedia.org/wiki/Virtual_function#Virtual_destructors
> for an explanation.

Spike,

Thank you.  I tried to dumb down my example to make the code easier to
understand.  My actual code has virtual destructors and, Alf will be
happy to hear, a consistent style that differentiates class names from
function names.

Chris

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

#13045

On 02/01/2012 23:46, Alf P. Steinbach wrote:
> On 02.01.2012 21:16, Chris Stankevitz wrote:
>> My intention is to
>> - Create an abstract base class "Shape" that must be an "Observer"
>> - Create an class "Square" that is a "Shape" and also an
>> "ObserverImp"
>>
>> I thought I could do this like so:
>>
>> struct Observer
>> {
>> virtual void Notify() = 0;
>> };
>>
>> struct ObserverImp : public Observer
>> {
>> void Notify() {}
>> };
>
> Use virtual inheritance for the interface (that is for `Observer`).
>
>
>> struct Shape : public virtual Observer
>> {
>> };
>>
>> struct Square : public Shape, public ObserverImp
>> {
>> };
>
> Technically OK.
>
>
>> Shape* ShapeFactory()
>
> Please use different naming conventions for types and functions.

Typical Alf nonsense.

This is a style issue and different people use different styles.

For good examples of using the same naming convention for both types and 
functions see the C++ standard library.

Personally I use the same naming convention for types and functions 
(under_scores) and a different one for variable/object names 
(prefixedCamelCase).

/Leigh

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

#13052

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.

Cheers & hth.,

- Alf

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web