A question of style?

[Lilith]

I've only recently started to learn Windows programming using VC++.
It's relatively easy to understand the basics fo attaching functions
to controls but I've been trying to learn Windows from the roots on
down. In looking at source code I'm finding a tendency for some
programmers to declare an object of their application type with a new
and subsequently use the pointer-member-of operator to access the
members of the class object. Considering it was obvious in these
instances that there was only going to be one application object, what
is the point of declaring a pointer and then go through the process of
allocating the object itself rather than simply declaring the object
and forgetting the allocation?

 

[Phlip]

I've only recently started to learn Windows programming using VC++.

Sample VC++ code is about the most wretched style you can find. The only
thing worse in our industry is Dr Dobb's Journal.

...In looking at source code I'm finding a tendency for some
programmers to declare an object of their application type with a new
and subsequently use the pointer-member-of operator to access the
members of the class object.

You just mean -> notation. Not pointer to member.

But, yes, these programmers are using 'new' because "all the other
programmers were doing it", not because they need an object to live longer
than the current scope.

Read books like /Design Patterns/ and /Effective C++/ to learn good style.

 

[Victor Bazarov]

I've only recently started to learn Windows programming using VC++.
It's relatively easy to understand the basics fo attaching functions
to controls but I've been trying to learn Windows from the roots on
down. In looking at source code I'm finding a tendency for some
programmers to declare an object of their application type with a new
and subsequently use the pointer-member-of operator to access the
members of the class object.

You mean -> operator, yes?

> Considering it was obvious in these
instances that there was only going to be one application object, what
is the point of declaring a pointer and then go through the process of
allocating the object itself rather than simply declaring the object
and forgetting the allocation?

The difference is where the object is allocated and _when_ it is
initialised. Statically allocated objects (objects with static storage
duration) are allocated potentially in a different place than those with
dynamic storage duration. Also, you may need to have control over the
time when your application object is initialised. Statically allocated
objects are initialised at some point before the 'main' function is
called, which is not necessarily the right time.

V

 

[BigBrian]

I've only recently started to learn Windows programming using VC++.

It's relatively easy to understand the basics fo attaching functions
to controls but I've been trying to learn Windows from the roots on
down.

This has nothing to do with the C++ language.

In looking at source code I'm finding a tendency for some
programmers to declare an object of their application type with a new
and subsequently use the pointer-member-of operator to access the
members of the class object. Considering it was obvious in these
instances that there was only going to be one application object, what
is the point of declaring a pointer and then go through the process of
allocating the object itself rather than simply declaring the object
and forgetting the allocation?

I'm not exactly sure what your question is, but it sounds like you're
asking "what the difference between creating an object with new and
just declaring it as an automatic variable?" If that's what you're
asking, new creates memory on the heap, declaring an automatic variable
puts the object on the stack. Another difference is that with a
pointer to an object created with new, you can use polymorphism.

 

[David White]

new creates memory on the heap, declaring an automatic
variable puts the object on the stack. Another difference is that
with a pointer to an object created with new, you can use
polymorphism.

You can use polymorphism with a pointer to an object on the stack as well.

DW

 

[Lilith]

This has nothing to do with the C++ language.

No, it was by way of a small introduction and an explanation of where
I'm coming from.

I'm not exactly sure what your question is, but it sounds like you're
asking "what the difference between creating an object with new and
just declaring it as an automatic variable?" If that's what you're
asking, new creates memory on the heap, declaring an automatic variable
puts the object on the stack. Another difference is that with a
pointer to an object created with new, you can use polymorphism.

No, I know the difference as regards to their creation. I was more
interested in the why of it in a particular instance. I didn't see
the purpose of creating the object dynamically when a statically
declared variable would have sufficed. I was also curious as to
whether or not there is a small impact on performance in using -> to
reference the members of the object.

 

[Lilith]

Sample VC++ code is about the most wretched style you can find. The only
thing worse in our industry is Dr Dobb's Journal.

So, my earlier issues aren't going to bring much on eBay? Seriously,
it was Dr Dobbs that got me over my impass at understanding C in the
first place.

You just mean -> notation. Not pointer to member.

Yes. I'm inclined to try to be concise in my wording and it sometimes
works against me.

But, yes, these programmers are using 'new' because "all the other
programmers were doing it", not because they need an object to live longer
than the current scope.

Someone had to start it. I see little reason for declaring a
single object dynamically but I can see the need for doing it for
arrays and as part of a linked list. But I'm not the expert
programmer that many on this are and wanted to make sure I'm not
missing a bet somewhere.

 

[Lilith]

You mean -> operator, yes?


The difference is where the object is allocated and _when_ it is
initialised. Statically allocated objects (objects with static storage
duration) are allocated potentially in a different place than those with
dynamic storage duration. Also, you may need to have control over the
time when your application object is initialised. Statically allocated
objects are initialised at some point before the 'main' function is
called, which is not necessarily the right time.

Many thanks,
Lilith

 

[Phlip]

No, it was by way of a small introduction and an explanation of where
I'm coming from.

Sorry. You mentioned "Windows" too high in your post. Knees jerked. We'll
try not to do it again.

 

[Alf P. Steinbach]

* Lilith:

In looking at source code I'm finding a tendency for some
programmers to declare an object of their application type with a new
and subsequently use the pointer-member-of operator to access the
members of the class object. Considering it was obvious in these
instances that there was only going to be one application object, what
is the point of declaring a pointer and then go through the process of
allocating the object itself rather than simply declaring the object
and forgetting the allocation?

Difficult to say without a concrete example, but one reason might be that
the single object is of a class that's derived from a class A that is
designed for dynamic allocation, e.g. an A-object will self-destroy when
a given "we're finished" message is processed. But that is speculation.
I've programmed extensively on the platform you mentioned and can not recall
ever needing to dynamically allocate an application object (window objects,
on the other hand...).

Perhaps Phlip's answer is the most likely, that they're doing this because
they see other programmers doing it (in various situations), and don't
understand the reasons but just copy what they think others do.

That's very common in general.

 

[Lilith]

Lilith wrote:

Sorry. You mentioned "Windows" too high in your post. Knees jerked. We'll
try not to do it again.

And I was aware that that could happen. But I anticipated that the
practice I was questioning might be a necessity of the environment I
was programming for or at least a convenience.