Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > typedef or derive?

Reply
Thread Tools

typedef or derive?

 
 
eiji
Guest
Posts: n/a
 
      03-07-2006
Hi folks,

I found this code in a project:

> class TestList : public std::vector<Test> { /*empty!!!*/ };


Basicly this ends up in the same result like

> typedef std::vector<Test> TestList; ?


So is there a real benefit of the first version, and I have no idea?
I think the first ends up in slower code!?
Does a good compiler optimize the first case into the second?

And last but not least, have a look at this:

somePtr t* = new somePtr( );
....
delete t;
t = NULL;

I know, NULL is windows style, but is that necessary?

Thanks a lot!!

Regards,
Sascha

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      03-07-2006
eiji wrote:
> I found this code in a project:
>
>
>> class TestList : public std::vector<Test> { /*empty!!!*/ };

>
>
> Basicly this ends up in the same result like
>
>
>> typedef std::vector<Test> TestList; ?

>
>
> So is there a real benefit of the first version, and I have no idea?


Yes. The types 'TestList' and 'std::vector<Test>' are different in that
case.

> I think the first ends up in slower code!?


No.

> Does a good compiler optimize the first case into the second?


No.

> And last but not least, have a look at this:
>
> somePtr t* = new somePtr( );
> ...
> delete t;
> t = NULL;
>
> I know, NULL is windows style, but is that necessary?


It's not "windows style". 'NULL' is a macro defined in <cstdlib> (and
possibly other headers) and usually expanding to 0. As for the necessity,
it's up to you. Do you need 't' to be set to null pointer after deleting
the object? Then it does not matter whether you write

t = 0;

or
t = NULL;

except in the latter case you need to include a header that defines the
'NULL' macro.

V
--
Please remove capital As from my address when replying by mail
 
Reply With Quote
 
 
 
 
TB
Guest
Posts: n/a
 
      03-07-2006
eiji skrev:
> Hi folks,
>
> I found this code in a project:
>
>> class TestList : public std::vector<Test> { /*empty!!!*/ };

>


This creates a new type,

> Basicly this ends up in the same result like
>
>> typedef std::vector<Test> TestList; ?


and this introduces just another name.

>
> So is there a real benefit of the first version, and I have no idea?


Type constraining.

> I think the first ends up in slower code!?
> Does a good compiler optimize the first case into the second?
>
> And last but not least, have a look at this:
>
> somePtr t* = new somePtr( );
> ...
> delete t;
> t = NULL;
>
> I know, NULL is windows style, but is that necessary?


No, it's not "windows style", NULL is a part of the Standard, and
no, it's not necessary to assign NULL to the pointer after delete.

--
TB @ SWEDEN
 
Reply With Quote
 
Tomás
Guest
Posts: n/a
 
      03-07-2006
eiji posted:

> Hi folks,
>
> I found this code in a project:
>
>> class TestList : public std::vector<Test> { /*empty!!!*/ };

>
> Basicly this ends up in the same result like
>
>> typedef std::vector<Test> TestList; ?

>
> So is there a real benefit of the first version, and I have no idea?


Benefit? Depends on what your aim is. However, there's definitely a
difference though:

template<class T>
void SomeFunction(TestList const &); //Defined elsewhere

int main()
{
std::vector<Test> object;

SomeFunction(object); // <---- Will it compile?
}


It _will_ compile if you used "typedef".

It _won't_ compile if you inherited.


> somePtr t* = new somePtr( );
> ...
> delete t;
> t = NULL;



Typical code from an unambitious (otherwise known as "not overly competent"
programmer). I bet the same person uses "i++" all over the place when "++i"
would suffice.

I wouldn't write such code for fear of being interpreted as mentally
retarded. I'm not retarded enough to mess with a pointer after I've deleted
what it was pointing to. If someone is stupid enough to do that, then Java
is right down their road.

You could fill a warehouse with the disgraceful code that Microsoft write. A
few examples:

1)

#define UINT unsigned int

rather than:

typedef unsigned UINT;

2)

SomePOD object;
ZeroMemory( &object, sizeof(object) );

rather than:

SomePOD object = {};

3)

The list is lloonngg...


-Tomás
 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      03-07-2006
In article <(E-Mail Removed) .com>,
"eiji" <(E-Mail Removed)> wrote:

> Hi folks,
>
> I found this code in a project:
>
> > class TestList : public std::vector<Test> { /*empty!!!*/ };

>
> Basicly this ends up in the same result like
>
> > typedef std::vector<Test> TestList; ?

>
> So is there a real benefit of the first version, and I have no idea?


The two constructs above are not the same. Try this:

class TestList1 : public vector<int> { /*empty!!!*/ };

typedef std::vector<int> TestList2;

void fn1( const vector<int>& );
void fn2( const TestList1& );
void fn3( const TestList2& );

int main()
{
fn1( TestList1() );
fn3( TestList1() );

fn2( vector<int>() ); // invalid: vector<int> is not substitutable
// for TestList1
fn3( vector<int>() ); // but it is substitutable for a TestList2

fn1( TestList2() ); // TestList2 is substitutable for a vector<int>
fn2( TestList2() ); // invalid: TestList2 is not substitutable
// for TestList1
}

As you can see: vector<int> and TestList2 are the same type as far as
the compiler is concerned but TestList1 is not the same as a
vector<int>, there is only a one way conversion.


> I think the first ends up in slower code!?


I doubt it.

> And last but not least, have a look at this:
>
> somePtr t* = new somePtr( );
> ...
> delete t;
> t = NULL;
>
> I know, NULL is windows style, but is that necessary?


It's not "windows style", it is perfectly acceptable C++ code. It
protects you against accidental double deletes, and on many systems, the
OS will recognize an error if you try to dereference a NULL pointer,
where it wouldn't if you didn't NULL the pointer out.

Is it necessary? No, it's never *necessary* to initialize your
variables, but you should still do it.


--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
 
Reply With Quote
 
Markus Moll
Guest
Posts: n/a
 
      03-07-2006
Hi

Tomás wrote:

>> somePtr t* = new somePtr( );
>> ...
>> delete t;
>> t = NULL;

>
> Typical code from an unambitious (otherwise known as "not overly
> competent" programmer). I bet the same person uses "i++" all over the
> place when "++i" would suffice.


I have to disagree.
While I see this kind of code way too often, when it isn't necessary (either
because t will be out of scope right after the assignment, or because you
had better use some smart pointer in the first place), I have to say that
when playing around with raw pointers, it saves you hours of debugging!
Consider:

struct uses_some_pointer
{
int *x; // has to be a pointer for some reason...
uses_some_pointer() : x(0) {}
uses_some_pointer(const uses_some_pointer& usp) : x(new int(*usp.x)) {}
uses_some_pointer& operator= (const uses_some_pointer& usp)
{ delete x; x = new int(*usp.x); return *this; }
~uses_some_pointer() { delete x; }
void f(int a) { delete x; x = new int(a); }
void g() { /* x no longer needed! */ delete x; x = 0; }
};

(where f and g in reality would have other names and would actually do some
work)

> I wouldn't write such code for fear of being interpreted as mentally
> retarded. I'm not retarded enough to mess with a pointer after I've
> deleted what it was pointing to.


Do you really always know? What about exceptions?
Maybe you like memory leaks better?

> If someone is stupid enough to do that,
> then Java is right down their road.


Java has its own pitfalls...

> You could fill a warehouse with the disgraceful code that Microsoft write.


What has Microsoft got to do with that?

Markus

 
Reply With Quote
 
Tomás
Guest
Posts: n/a
 
      03-07-2006

> hours of debugging!


Then put it in the debug code. Something like

#ifdef DEBUG
p = 0;
#endif


-Tomás

 
Reply With Quote
 
Tomás
Guest
Posts: n/a
 
      03-07-2006
> No, it's never *necessary* to initialize your
> variables, but you should still do it.



for (int i; i < 10; ++i)
{

}

You've no guarantee that the loop will start at 0.
Futhermore, it's undefined behaviour to check its value.


-Tomás
 
Reply With Quote
 
Jim Langston
Guest
Posts: n/a
 
      03-08-2006

"Tomás" <(E-Mail Removed)> wrote in message
news:NjjPf.6856$(E-Mail Removed)...
> eiji posted:
>
>> Hi folks,
>>
>> I found this code in a project:
>>
>>> class TestList : public std::vector<Test> { /*empty!!!*/ };

>>
>> Basicly this ends up in the same result like
>>
>>> typedef std::vector<Test> TestList; ?

>>
>> So is there a real benefit of the first version, and I have no idea?

>
> Benefit? Depends on what your aim is. However, there's definitely a
> difference though:
>
> template<class T>
> void SomeFunction(TestList const &); //Defined elsewhere
>
> int main()
> {
> std::vector<Test> object;
>
> SomeFunction(object); // <---- Will it compile?
> }
>
>
> It _will_ compile if you used "typedef".
>
> It _won't_ compile if you inherited.
>
>
>> somePtr t* = new somePtr( );
>> ...
>> delete t;
>> t = NULL;

>
>
> Typical code from an unambitious (otherwise known as "not overly
> competent"
> programmer). I bet the same person uses "i++" all over the place when
> "++i"
> would suffice.
>
> I wouldn't write such code for fear of being interpreted as mentally
> retarded. I'm not retarded enough to mess with a pointer after I've
> deleted
> what it was pointing to. If someone is stupid enough to do that, then Java
> is right down their road.


That point could be argued. Setting a pointer to NULL or 0 after deleting
can have some advantages. The first advantage is if you try to delete a
NULL pointer nothing happens. It's safe to delete a null pointer. The
second advantage is you can compare a pointer to NULL to see if it's been
deleted.

Safely deleting a NULL pointer is not always a good thing, however. Most
the time I find that if I'm attempting to delete a NULL pointer (one that's
already been deleted and set to NULL) then my program is in error.

However, I do have one class that controls GUI windows. Depending on the
type of window it is it can have one or two bitmaps. I found it easiest in
my class to simply set the pointer to NULL if the bitmap was empty. The
code that uses the methods to get the bitmap pointers compare the pointers
to NULL to see if to display or not. Although this is not technically the
same as deleting a pointer than setting it to NULL, it is close. And I can
see a case where I would for some reason delete one of the loaded bitmaps
but keep the other so set it to NULL.


 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      03-08-2006
Markus Moll wrote:

> Hi
>
> Tom? wrote:
>
>>> somePtr t* = new somePtr( );
>>> ...
>>> delete t;
>>> t = NULL;

>>
>> Typical code from an unambitious (otherwise known as "not overly
>> competent" programmer). I bet the same person uses "i++" all over the
>> place when "++i" would suffice.

>
> I have to disagree.
> While I see this kind of code way too often, when it isn't necessary
> (either because t will be out of scope right after the assignment, or
> because you had better use some smart pointer in the first place), I have
> to say that when playing around with raw pointers, it saves you hours of
> debugging! Consider:
>
> struct uses_some_pointer
> {
> int *x; // has to be a pointer for some reason...
> uses_some_pointer() : x(0) {}
> uses_some_pointer(const uses_some_pointer& usp) : x(new int(*usp.x)) {}
> uses_some_pointer& operator= (const uses_some_pointer& usp)
> { delete x; x = new int(*usp.x); return *this; }


Are you sure this handles self-assignment correctly? If you do

a = a;

then the following happens:

a.x is deleted.
A new pointer is allocated and initialized from *(a.x).
Ouch.


> ~uses_some_pointer() { delete x; }
> void f(int a) { delete x; x = new int(a); }
> void g() { /* x no longer needed! */ delete x; x = 0; }
> };
>
> (where f and g in reality would have other names and would actually do
> some work)


Note the also sequences like

a.g();
b = a;

are plain bad. I concede, though, that you *could* have used it in getting
the assignment operator more correct.


[snip]


Best

Kai-Uwe Bux
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
CRTP-problem: How can the base class typedef a derived class' typedef? oor C++ 0 05-20-2008 12:39 PM
java needs typedef Steve Green Java 11 03-25-2005 09:52 AM
Typedef of a template? Richard van Wegen C++ 3 07-15-2003 07:22 AM
template typedef as return type Robert A. T. Kaldy C++ 1 07-09-2003 06:25 PM
typedef enum qazmlp C++ 2 07-02-2003 11:55 AM



Advertisments