Can i create a constructor in a data structure?

[fuiwong]

Can i create a constructor in a data structure? does the following
codes right?

sample code
#include <iostream.h>
struct USERID{
char UserName[4];
char Password[7];
char LoginName[21];
char LoginPassword[11];

USERID( ){
UserName[0]= '\0';
Password[0]= '\0';
LoginName[0]= '\0';
LoginPassword[0]= '\0';}};

 

[Ian Collins]

Can i create a constructor in a data structure? does the following
codes right?

sample code
#include <iostream.h>
struct USERID{
char UserName[4];
char Password[7];
char LoginName[21];
char LoginPassword[11];

USERID( ){
UserName[0]= '\0';
Password[0]= '\0';
LoginName[0]= '\0';
LoginPassword[0]= '\0';}};

It's legal, but why not use std::string and avoid the messy initialisations?

 

[Stuart Redmann]

Can i create a constructor in a data structure? does the following
codes right?

sample code
#include <iostream.h>
struct USERID{
char UserName[4];
char Password[7];
char LoginName[21];
char LoginPassword[11];

USERID( ){
UserName[0]= '\0';
Password[0]= '\0';
LoginName[0]= '\0';
LoginPassword[0]= '\0';}};

Of course this is right. Keep in mind that under C++ a struct is
basically treated as a class except that you cannot use the access
modifiers like 'public:', 'protected:', or 'private:', because all
members of the struct are public. You may add other methods, even
virtual ones.

Regards,
Stuart

 

[Alf P. Steinbach]

* (e-mail address removed):

Can i create a constructor in a data structure? does the following
codes right?

sample code
#include <iostream.h>
struct USERID{
char UserName[4];
char Password[7];
char LoginName[21];
char LoginPassword[11];

USERID( ){
UserName[0]= '\0';
Password[0]= '\0';
LoginName[0]= '\0';
LoginPassword[0]= '\0';}};

Others have commented on your constructor: it's OK.

However, your code will not compile with some newer compilers unless you
change

#include <iostream.h>

to

#include <iostream>

or define an <iostream.h> header yourself -- it's not standard.

Second, it's generally a Good Idea(TM) to reserve all uppercase for macros.

Third, but this has already been remarked on, you'll save a lot of work
and anguish by using std::string instead of raw character arrays.

 

[Kai-Uwe Bux]

Can i create a constructor in a data structure? does the following
codes right?

sample code
#include <iostream.h>
struct USERID{
char UserName[4];
char Password[7];
char LoginName[21];
char LoginPassword[11];

USERID( ){
UserName[0]= '\0';
Password[0]= '\0';
LoginName[0]= '\0';
LoginPassword[0]= '\0';}};

Of course this is right. Keep in mind that under C++ a struct is
basically treated as a class except that you cannot use the access
modifiers like 'public:', 'protected:', or 'private:', because all
members of the struct are public.

This is incorrect. All access specifiers are at your disposal. What differs
is the default: in struct, members are public by default.

You may add other methods, even virtual ones.

That is correct.


Best

Kai-Uwe Bux

 

[Michiel.Salters]

Can i create a constructor in a data structure? does the following
codes right?

sample code
#include <iostream.h>
struct USERID{
char UserName[4];
char Password[7];
char LoginName[21];
char LoginPassword[11];

USERID( ){
UserName[0]= '\0';
Password[0]= '\0';
LoginName[0]= '\0';
LoginPassword[0]= '\0';}};

It's legal, but why not use std::string and avoid the messy initialisations?

Because that would make it no longer a POD? Of course, in that case you
want to derive from struct USERID and put the ctor in the derived
class.
You don't have to change the original struct for that, which is another
advantage. (Of course, for new software this is irrelevant)

HTH,
Michiel Salters

 

[Jerry Coffin]

[ ... ]
[ ... ]

[ ... ]

Because that would make it no longer a POD?

"A POD-struct is an aggregate class..." (9/4), and "An aggregate is
an array or class with no user-defined constructors..." (8.5.1). As
it stands right now, it's not a POD (though from your comments below,
perhaps you already knew that...)

Of course, in that case you
want to derive from struct USERID and put the ctor in the derived
class.

That would be better avoided, IMO. One of the strengths of C++ is the
ability to ensure against creating uninitialized objects, but this
removes any such assurance. At least in my mind, the first question
would be whether there's really any reason for this to be a POD to
start with. If there is, the second question would be how much work
it'll take to fix that.

 

[Geo]

Second, it's generally a Good Idea(TM) to reserve all uppercase for macros.

That implies that it is a Good Idea(TM) to have macros in the first
place, why reserve an entire class of identifiers for something you
should never need ?

 

[Kai-Uwe Bux]

That implies that it is a Good Idea(TM) to have macros in the first
place, why reserve an entire class of identifiers for something you
should never need ?

Because you do need macros (whether you should or not).


Best

Kai-Uwe Bux

 

[Geo]

Because you do need macros (whether you should or not).


Best

Kai-Uwe Bux

Do I ?

The only explicit #defines I have in my code are include guards and I
don't consider them macros, what do I NEED macros for ?

 

[Kai-Uwe Bux]

Do I ?

Clearly. See your next statement:

The only explicit #defines I have in my code are include guards

There you are.

and I don't consider them macros,

Whether you consider them macros or not is utterly irrelevant. They *are*
macros.

what do I NEED macros for ?

Try to write a simple logging facility that only is active in debug mode and
registers file and line number with each log entry automatically, so that
you could do in your code

RLOG << some_data; // this is in the file CTime.cpp on line 242

and in the log-file, it would read, say:

[CTime.cpp: 242] 120978

In this case, I would be very surprised if you could do that without macros.


Best

Kai-Uwe Bux

 

[Old Wolf]

Try to write a simple logging facility that only is active in debug mode and
registers file and line number with each log entry automatically, so that
you could do in your code

RLOG << some_data; // this is in the file CTime.cpp on line 242

I do that in my code without using macros, except that it looks like:

log() << "some" << data;

 

[Kai-Uwe Bux]

I do that in my code without using macros, except that it looks like:

log() << "some" << data;

I take it that log() creates a temporary. Now, how do you get the file and
line number in there? If you do

class log {

std::string file;
std::string line;

public:

log ( void )
: file ( __FILE__ )
, line ( __LINE__ )
{}

// more

};

then you will end up doing the file and line number of the definition of the
log constructor instead of the file and line number of the logging line

log() << "some" << data; // this file and line number shall be recorded


I would love to see how your log class does that.


Best

Kai-Uwe Bux

 

[Victor Bazarov]

I take it that log() creates a temporary. Now, how do you get the
file and line number in there? If you do

class log {

std::string file;
std::string line;

public:

log ( void )
: file ( __FILE__ )
, line ( __LINE__ )
{}

// more

};

then you will end up doing the file and line number of the definition
of the log constructor instead of the file and line number of the
logging line

log() << "some" << data; // this file and line number shall be
recorded


I would love to see how your log class does that.

It probably doesn't. It doesn't have to. Not everything has to be
logged with __FILE__ or __LINE__ involved. And 'log()' could be a simple
function that returns a reference [to a static object inside it].

V

 

[Kai-Uwe Bux]

Note the following claim:

Old Wolf explicitly claims to do *that* (refering to the logging
requirements laid out in the paragraph before, which include recording of
file and line number information).

It probably doesn't.

Then, Old Wolfs claim that his class does *that* is false.

It doesn't have to. Not everything has to be logged with __FILE__ or
__LINE__ involved.

True, but irrelevant for the point under discussion (unless you want to
change the topic from "what can you do with macros that is hard or
impossible to do without" to "how should a logging facility be designed").

And 'log()' could be a simple function that returns a reference [to a
static object inside it].

True. And how would that allow for file and line logging without macros?


Best

Kai-Uwe Bux

 

[Old Wolf]

I take it that log() creates a temporary. Now, how do you get the file and
line number in there? If you do

I don't (file/line logging is yucky IMHO). Anyway, this can't be done
easily without using __FILE__ and __LINE__ , which are macros.
So it is a bit strange to distinguish between solutions that use
macros and solutions that don't.

 

[Kai-Uwe Bux]

I don't (file/line logging is yucky IMHO). Anyway, this can't be done
easily without using __FILE__ and __LINE__ , which are macros.

Actually, my point is a little less trivial. It is not just that you cannot
avoid __FILE__ and __LINE__, but that I do not see a way to avoid defining
your *own* macros to do this. E.g., something like

#define RLOG ( log() << __FILE__ << " [" << __LINE__ << "]: " )

would do it. If you see a way of doing away with the #define, I would be
surprised.

So it is a bit strange to distinguish between solutions that use
macros and solutions that don't.

The distinction is more about solutions where you use #define and solutions
where you don't. Please reread the discussion up-thread. The dispute
started from the claim "I only use #define for include guards" or some such
thing.


Best

Kai-Uwe Bux