Pointers vs. Static Objects

[greg]

Hi All,

Could anyone tell me when one should use objects and when pointers?

Thanks,
Greg

 

[Victor Bazarov]

Could anyone tell me when one should use objects and when pointers?

FAQ 8.6 answers a similar question. Did you read it?

V

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Hi All,

Could anyone tell me when one should use objects and when pointers?

Pointers and objects are kind of orthogonal concepts, since pointers
points to objects (static or not), so you can't really have pointers
without objects (if you consider the built-in types to be objects).

Are you perhaps referring to when to pass parameters as pointers or when
to pass by value. My answer should be, use references when you can, by
value where it makes sense and pointers only when you have to.
Pointers are very powerful but they are also the source of many errors
and much can be done without them in safer ways, which is generally
preferable. Learn the differences between these methods and it's often
quite clear which is the best to use.

 

[joe cipale]

So I have had an application that I have been using for over 5 years
developed under Gnu C++ 2.96 on fedora core 2. I recently updated to
fedora core 6 and now this same application is breaking.

Here is the typical message:
/home/joec/develop/c_source/SMARTrain_cmd/main.cpp:139: undefined
reference to `TSettings::TSettings()'
/home/joec/develop/c_source/SMARTrain_cmd/main.cpp:140: undefined
reference to `TRider::TRider()'
/home/joec/develop/c_source/SMARTrain_cmd/main.cpp:146: undefined
reference to `TBike::init_bike(TBike**)'
/home/joec/develop/c_source/SMARTrain_cmd/main.cpp:147: undefined
reference to `TDaily::init_date(TDaily**)'
/home/joec/develop/c_source/SMARTrain_cmd/main.cpp:148: undefined
reference to `TMaint::init_maint(TMaint**)'

Here is a simple class declaration:
/*-------------------------------------------------------------------*/
class TSettings {
private:

public:
char vstr[2];
char date_fmt[2];
char dist_fmt[2];
char alm_set[2];
char hrm_set[2];
char upd_on[2];
char fil_sve[2];

TSettings();
void Display_settings();
TSettings* System_set(TSettings *uset, bool file);
TSettings* Edit_settings(TSettings *uset, char fmt[4]);

};
/*----------------------------------------------------------------------------------*/
class TBike {
private:
public:
char Type[2 * BYTE]; // This is the keyword entry for this
linked list.
char Bike[2 * BYTE];
char Wheels[4 * BYTE];
char Grouppo[3 * BYTE];
bool track;
TBike* nxt_Bike;

TBike* init_bike(TBike **pBike);
TBike* bike_profile(TBike **pBike);
void print_bike(TBike *pBike);
int cnt_bike_list(TBike *pBike);
};
/*----------------------------------------------------------------------------------*/

Here are where the above classes are first declared in main.cpp:

TSettings uset;
TRider rider;

I heard that changes were made for the new(er) version of g++ (FC6 uses
gcc version 4.1.1), but I didnt think that it would break my code as it
has.

A little help, please...

You can reply directly to my email if you wish to call me a noron for
not updating sooner.

J. Cipale

 

[Neelesh Bodas]

So I have had an application that I have been using for over 5 years
developed under Gnu C++ 2.96 on fedora core 2. I recently updated to
fedora core 6 and now this same application is breaking.

Here is the typical message:
/home/joec/develop/c_source/SMARTrain_cmd/main.cpp:139: undefined
reference to `TSettings::TSettings()'
/home/joec/develop/c_source/SMARTrain_cmd/main.cpp:140: undefined
reference to `TRider::TRider()'
/home/joec/develop/c_source/SMARTrain_cmd/main.cpp:146: undefined
reference to `TBike::init_bike(TBike**)'
/home/joec/develop/c_source/SMARTrain_cmd/main.cpp:147: undefined
reference to `TDaily::init_date(TDaily**)'
/home/joec/develop/c_source/SMARTrain_cmd/main.cpp:148: undefined
reference to `TMaint::init_maint(TMaint**)'

Here is a simple class declaration:
/*-------------------------------------------------------------------*/
class TSettings {
private:

public:
char vstr[2];
char date_fmt[2];
char dist_fmt[2];
char alm_set[2];
char hrm_set[2];
char upd_on[2];
char fil_sve[2];

TSettings();
void Display_settings();
TSettings* System_set(TSettings *uset, bool file);
TSettings* Edit_settings(TSettings *uset, char fmt[4]);

};

/*-------------------------------------------------------------------------­---------*/
class TBike {
private:
public:
char Type[2 * BYTE]; // This is the keyword entry for this
linked list.
char Bike[2 * BYTE];
char Wheels[4 * BYTE];
char Grouppo[3 * BYTE];
bool track;
TBike* nxt_Bike;

TBike* init_bike(TBike **pBike);
TBike* bike_profile(TBike **pBike);
void print_bike(TBike *pBike);
int cnt_bike_list(TBike *pBike);};

/*-------------------------------------------------------------------------­---------*/

Here are where the above classes are first declared in main.cpp:

TSettings uset;
TRider rider;

I heard that changes were made for the new(er) version of g++ (FC6 uses
gcc version 4.1.1), but I didnt think that it would break my code as it
has.

The error messages are pretty clear and easy to understand: undefined
reference to so-and-so function. In simpler language, this means that
the function definition is not found.

As an aside, I doubt if the compiler proper would give such messages.
The kind of error messages you have quoted is a linker's job.


-N

 

[greg]

I guess my question was: how do we know when to allocate stuff on the
heap and when on the stack?

Thanks,
Greg

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

I guess my question was: how do we know when to allocate stuff on the
heap and when on the stack?

The differences in lifetime for objects on the heap vs. those on the
stack (automatic storage) usually makes the choice easy, if you only
need the object as long as the current function, or any function called
by it, is running then automatic storage is usually the way to go. If
you need the object for a longer period of time then you probably should
use the heap. An exception might be when you need lots of objects or
have really large objects, these are usually placed on the heap.

Learn about the differences and how they are affected by scope and what
other obligations that comes with them and you'll have little problem
deciding which to use.