inhibit use of class/struct as auto variabel

[42Bastian Schick]

Hi,

is there a way to inhibt the use of a struct/class as auto or static
variable other than code-review. Means enforce usage of new() to
allocate an object ?

If this is common knowledge, please excuse, but I come from assembler


TIA

 

[Victor Bazarov]

is there a way to inhibt the use of a struct/class as auto or static
variable other than code-review. Means enforce usage of new() to
allocate an object ?

If this is common knowledge, please excuse, but I come from assembler

It is common knowledge. Read up on Factory Method and private
constructors. And next time do specify whether the question you're
asking is for a job interview or a homework. Makes it easier for us to
give you the right answer.

V

 

[Alf P. Steinbach /Usenet]

* 42Bastian Schick, on 29.11.2010 15:07:

Hi,

is there a way to inhibt the use of a struct/class as auto or static
variable other than code-review. Means enforce usage of new() to
allocate an object ?

If this is common knowledge, please excuse, but I come from assembler

The easiest and most practical way is to make the destructor 'protected' and
define a single for-all-types 'destroy' template function, unless you're
targeting C++0x only in which case better standardize on the one for unique_ptr.

The most well known way is, however, to make all constructors 'protected' (or
'private') and define corresponding factory functions.

And apparently paradoxically, most programmers prefer the factories way. It
doesn't make sense in economic terms (more work for same effect, more code to
maintain). But I think it has to do with their feeling of accomplishment, simply
that the protected destructor way is so easy that they feel they haven't really
done anything. Same reason as people use raw arrays instead of std::vector &
friends, and so on. Most programmers prefer The Hard Way...


Cheers & hth.,

- Alf

 

[42Bastian Schick]

It is common knowledge. Read up on Factory Method and private
constructors.

Ok. I'll check this out.

And next time do specify whether the question you're
asking is for a job interview or a homework.

Neither. But 99% of my time I program in pure assembly and since
"factory" is nothing I bring into relation with C++ it is hard to
google for it.

 

[42Bastian Schick]

* 42Bastian Schick, on 29.11.2010 15:07:

The easiest and most practical way is to make the destructor 'protected' and
define a single for-all-types 'destroy' template function, unless you're
targeting C++0x only in which case better standardize on the one for unique_ptr.

Ok, I tried it, and to be honest, I do not understand, why if I make
the destructor privat, I ...

Oh, clear, now I got it. The compiler wants to call the destructor at
the end of the function but can't !

Cool.

 

[42Bastian Schick]

It is common knowledge. Read up on Factory Method and private
constructors.

Meanwhile tried the factory thing and it works.

Now I have to check which method (factory or Alf's) does suit my needs
better.

Thanks for you time.

 

[James Kanze]

* 42Bastian Schick, on 29.11.2010 15:07:

The easiest and most practical way is to make the destructor
'protected' and define a single for-all-types 'destroy'
template function,

Can you expound on that? I don't see how making the destructor
protected will make it accessible to a single for-all-types
destroy function.

Generally, if the class is designed to be a base, I'd make the
destructor protected; otherwise, I'd make it private. But more
generally... any given class has specific semantics. And users
use the class in accordance with its semantics. If the
semantics require it to be dynamically allocated, I've yet to
encounter programmer who would attempt to allocate it on the
stack. It's one of those errors that are so rare, they aren't
worth bothering with.

 

[42Bastian Schick]

Can you expound on that? I don't see how making the destructor
protected will make it accessible to a single for-all-types
destroy function.

... If the
semantics require it to be dynamically allocated, I've yet to
encounter programmer who would attempt to allocate it on the
stack. It's one of those errors that are so rare, they aren't
worth bothering with.

The real-world problem is a message passing RTOS, where messages a
piece of memory overlaid with structs. Though one can tell the
programmer not to "allocate" such message on a stack, a enforcement by
the compiler is much better then doing a code-review.

 

[Alf P. Steinbach /Usenet]

* James Kanze, on 29.11.2010 19:47:

Can you expound on that? I don't see how making the destructor
protected will make it accessible to a single for-all-types
destroy function.

C++ has a wonderful solution for that, James. It's called "friend". I suggest
reading about C++ "friend" in your textbook.

Instead of directly using "friend" in every such class, you can use another
wonderful language feature called "inheritance". This one's really cool! You can
"inherit" in all kinds of functionality, including destroy functionality.

I think you'll find that your textbook also covers the concept of "inheritance".

Generally, if the class is designed to be a base, I'd make the
destructor protected; otherwise, I'd make it private. But more
generally... any given class has specific semantics. And users
use the class in accordance with its semantics. If the
semantics require it to be dynamically allocated, I've yet to
encounter programmer who would attempt to allocate it on the
stack. It's one of those errors that are so rare, they aren't
worth bothering with.

If you're learning C++ coming from Python, say, then you're in for a little
shock! The philosophy in languages like Python is to provide other programmers
with as much access to things as possible, so that they can do whatever they
want. This was and is also the philosophy of the language called "C". But it
turned out that for larger programs it's Really Helpful to have the compiler
catch errors, instead of having to try to reproduce errors at run time. And in
order to enable the compiler to catch errors, C++ provides all kinds of means
for *restricting* what the programmer can do (that's the "++" in "C++"), telling
the compiler that if the programmer does that, or that, hey, diagnose that as an
error, please. It's a completely different philosophy.

It might seem strange at first, but consider the Unix idea of files as simply
streams of bytes. This *restriction* on what a file can be, enabled a lot of
useful functionality where different programs could be fitted together; they
could more easily work with each others' data.

So, somewhat paradoxically, good restrictions help both to catch errors
automatically, and help to enable functionality. Bad restrictions are, however,
bad -- some intelligence and thoughtfulness is required in order to choose the
good restrictions and don't choose the bad ones. C++ lets you enforce good
restrictions, but, thereby, it also lets you enforce bad ones: take care!


Cheers & hth.,

- Alf