Assigning values to a struct
Cliff
I'm in the process of porting some code from a 3rd party and have hit
a problem with the following:
typedef struct {
unsigned char Red;
unsigned char Green;
unsigned char Blue;
}TBoxColour;
//---------------------------------------------------------------------------
void DoSomething(void)
{
TBoxColour Col;
Col = (TBoxColour){10, 20, 30};
}
My compiler (CodeGear C++ Builder) complains with the error:
Improper use of typedef 'TBoxColour'
It seems a perfectly logical was of assigning values to the struct
members, but is it legal, or was the original programmer just
exploiting some quirk in a specific compiler (don't know which)?
Thanks
Alf P. Steinbach
> Hi,
>
> I'm in the process of porting some code from a 3rd party and have hit
> a problem with the following:
>
> typedef struct {
> unsigned char Red;
> unsigned char Green;
> unsigned char Blue;
> }TBoxColour;
That's an ungood way to define a struct in C++. Use instead
struct BoxColor
{
// ...
};
> //---------------------------------------------------------------------------
> void DoSomething(void)
> {
> TBoxColour Col;
>
> Col = (TBoxColour){10, 20, 30};
> }
>
> My compiler (CodeGear C++ Builder) complains with the error:
>
> Improper use of typedef 'TBoxColour'
>
> It seems a perfectly logical was of assigning values to the struct
> members, but is it legal,
Not in standard C++.
> or was the original programmer just
> exploiting some quirk in a specific compiler (don't know which)?
Yes.
Try
BoxColor const color = { 10, 20, 30 };
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Alf P. Steinbach
> * Cliff:
>> Hi,
>>
>> I'm in the process of porting some code from a 3rd party and have hit
>> a problem with the following:
>>
>> typedef struct {
>> unsigned char Red;
>> unsigned char Green;
>> unsigned char Blue;
>> }TBoxColour;
>
> That's an ungood way to define a struct in C++. Use instead
>
> struct BoxColor
> {
> // ...
> };
Hm, thinking about it, I was just mindlessly reflecting the Common
Wisdom. Which is wrong. If you want to clearly indicate that the
struct should be POD (no constructors etc.), then the typedef is one way
-- it does not guarantee POD'ness, but makes it impossible to define
constructor and destructor, and without those non-POD'ness doesn't
usually make much sense, hence, typedef in a way implies POD'ness.
Cheers, & again, hth.,
Cliff
> Try
>
> BoxColor const color = { 10, 20, 30 };
>
> Cheers, & hth.,
>
> - Alf
>
Hi Alf,
Sorry, I should have said, a single instance of this TBoxColour gets
assigned new values in 100's of locations throughout the code.
I suppose the only way is:
Col.Red = 10;
Col.Green = 20;
Col.Blue = 30;
The original method looks more elegant, This is just ugly, but more
importantly it's not easy for me to change the code with a simple
search and replace.
Victor Bazarov
You can define a function (a pseudo-constructor):
BoxColor createBoxColor(int a, int b, int c) {
BoxColor bc = { a, b, c };
return bc;
}
and then use it anywhere you need to assign:
Col = createBoxColor(10, 20, 30);
(I understand that I barge in without reading the rest of the thread,
sorry for that; if what I wrote is bogus, forgive me and ignore it)
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
BobR
Cliff <user...@btconnect.com> wrote in message...
> On Aug 29, 12:59 am, "Alf P. Steinbach" <al...@start.no> wrote:
> > Try
> > BoxColor const color = { 10, 20, 30 };
>
> Hi Alf,
>
> Sorry, I should have said, a single instance of this TBoxColour gets
> assigned new values in 100's of locations throughout the code.
> I suppose the only way is:
>
> Col.Red = 10;
> Col.Green = 20;
> Col.Blue = 30;
>
> The original method looks more elegant, This is just ugly, but more
> importantly it's not easy for me to change the code with a simple
> search and replace.
>
Well, since you won't say, maybe this will drag it out of you:
struct BoxColor{
unsigned char Red;
unsigned char Green;
unsigned char Blue;
BoxColor() : Red(0),Green(0),Blue(0){}
BoxColor( unsigned char R, unsigned char G,
unsigned char B ) : Red(R), Green(G), Blue(B){}
void Color( unsigned char R, unsigned char G,
unsigned char B ){
Red = R; Green = G; Blue = B;
return;
}
};
// if you cannot change this struct, see BoxColor2
typedef struct{
unsigned char Red;
unsigned char Green;
unsigned char Blue;
}TBoxColour;
struct BoxColor2 : TBoxColour{
BoxColor2(){ Red = 0; Green = 0; Blue = 0; }
BoxColor2( unsigned char R, unsigned char G,
unsigned char B ){
Red = R;
Green = G;
Blue = B;
}
};
int main(){
BoxColor bc1( 10, 20, 30 );
cout<<"bc1 Red="<<int(bc1.Red)<<" Green="
<<int(bc1.Green)<<" Blue="<<int(bc1.Blue)<<std::endl;
BoxColor bc2;
cout<<"bc2 Red="<<int(bc2.Red)<<" Green="
<<int(bc2.Green)<<" Blue="<<int(bc2.Blue)<<std::endl;
bc2.Color( 40, 50, 60 );
cout<<"bc2 Red="<<int(bc2.Red)<<" Green="
<<int(bc2.Green)<<" Blue="<<int(bc2.Blue)<<std::endl;
BoxColor2 BC2( 10, 20, 30 );
TBoxColour TBC;
TBC = BC2;
cout<<"TBC Red="<<int(TBC.Red)<<" Green="
<<int(TBC.Green)<<" Blue="<<int(TBC.Blue)<<std::endl;
TBC = BoxColor2( 30, 40, 50 );
cout<<"TBC Red="<<int(TBC.Red)<<" Green="
<<int(TBC.Green)<<" Blue="<<int(TBC.Blue)<<std::endl;
// ------------------------------------
return 0;
} // main()
That, or use Victor's example.
--
Bob R
POVrookie
Cliff
> Well, since you won't say, maybe this will drag it out of you:
Sorry, I'm not intentionally withholding anything, what else would you
like to know?
I'll summarise what I am trying to do:
I have some c++ code that I am porting to a different compiler.
The original programmer has used a non standard way of assigning
values to members of several types of struct.
For example:
Col = (TBoxColour){10, 20, 30};
My compiler doesn't want to know this, so I have to alter every
occurrence (many 100's) to a legal alternative. So I'm looking for a
solution that most closely resembles this format so that I can
automatically make the changes with a search and replace. This will
significantly reduce the probability of my making a typo, giving
problems later.
I am free to change the stuct declarations, or even change them to
classes.
Both yours and Victors solutions look viable and I thank you for
taking the time to help me out.
Cliff
BobR
> > Well, since you won't say, maybe this will drag it out of you:
>
> Sorry, I'm not intentionally withholding anything, what else would you
> like to know?
> I am free to change the stuct declarations, or even change them to
> classes.
That's what I was after. I think adding constructor(s) and maybe a member
function (called 'method' by some) to the modified struct will set you on
the right path.
I didn't show it, but, you can get away with one constructor if you give it
default values:
// class BoxColor{ public: // same functionality as next line.
struct BoxColor{
unsigned char Red;
unsigned char Green;
unsigned char Blue;
// BoxColor() : Red(0),Green(0),Blue(0){}
BoxColor( unsigned char R = 0, unsigned char G = 0,
unsigned char B = 0 ) : Red(R), Green(G), Blue(B){} // Ctor
void Color( unsigned char R, unsigned char G,
unsigned char B ){
Red = R; Green = G; Blue = B;
return;
} // Color(uchar,uchar,uchar)
}; // struct BoxColor
Now the compiler will take that constructor as a default (one without
parameters), and you can use it with parameters too.
BoxColor ColorArray[200]; // all set to 0,0,0
std::vector<BoxColor> vColors( 200, BoxColor( 1, 2, 3 ) );
// all set to 1,2,3
// cout<<int(vColors.at(199).Green); // output (last element): 2
vColors.at(3).Color( 25, 77, 42 );
// cout<<int(vColors.at(3).Green); // output (forth element): 77
BoxColor Col; // or: BoxColor Col( 20, 40, 255 );
Col.Color( 25, 77, 42 );
// ....
Col.Color( 2, 99, 0 );
// ....
>
> Both yours and Victors solutions look viable and I thank you for
> taking the time to help me out.
> Cliff
Glad to help. Let us know which solution you go with, and if you need
further assistance.
--
Bob R
POVrookie
Jorgen Grahn
> Col = (TBoxColour){10, 20, 30};
>
> My compiler doesn't want to know this, so I have to alter every
> occurrence (many 100's) to a legal alternative. So I'm looking for a
> solution that most closely resembles this format so that I can
> automatically make the changes with a search and replace. This will
> significantly reduce the probability of my making a typo, giving
> problems later.
In that situation I'd go for a class, with an interface which is as
restricted as possible. No default constructor, const members,
"explicit", things like that -- if possible.
I wouldn't worry too much about typos; they are likely to be caught by
the compiler.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
dilip
myself Dilip
Replace following code with your code to get correct output.
typedef struct
{
unsigned char Red;
unsigned char Green;
unsigned char Blue;
}TBoxColour;
void DoSomething(void)
{
struct typedef TBoxColour Col;
Col = (TBoxColour){10, 20, 30};
}
Thanks,
Dilip Kumar
http://www.intelcs.com/IT-Companies/
Cliff
Thanks for your idea, however what you have suggested does not
compile.
The error is "{ expected" pointing to the "typedef" in the DoSomething
function.
Cliff
BobR
But Cliff, (s)he said, "Replace following code with **your** code to get
correct output.".
In other words, do nothing!
> void DoSomething(void){ // it MUST be 'C' code, '(void)' !C++
> struct typedef TBoxColour Col;
> Col = (TBoxColour){10, 20, 30};
> }
'DoSomething()' (if it compiled) does NOTHING! <G>
Did you solve your original problem?
--
Bob R
POVrookie
Cliff
> Did you solve your original problem?
Well, I though I had. I decided to go with adding a simple method to
the struct. e.g.:
typedef struct {
unsigned char red;
unsigned char green;
unsigned char blue;
Set(unsigned char R, unsigned char G, unsigned char B){red=R,
green=G, blue=B;}
}TBoxColour;
After many hours I figured out how to do search and replace using
regular expressions,
and made the changes to all the files.
Then I discovered that there are a couple of .C files lurking in the
project that
pull in the header containing these structs.
So, of course the compiler starts throwing its toys out of the pram
when it sees
functions in a structure. Darn!
As Fagin once said "I think I better think it out again". :-(
Cliff
LR
Do those C files actually make use of the struct in question?
LR
Jim Langston
news:1188603918.3...@w3g2000hsg.googlegroups.com...
Can't you simply rename the .C files to .cpp?
BobR
If you really need to keep the 'typedef struct', you will need to use the
inheritance method I showed (in an earlier post) to give some attitude to
it.
You said you could change it, so use:
struct TBoxColour{
unsigned char red;
unsigned char green;
unsigned char blue;
void Set(unsigned char R, unsigned char G, unsigned char B){red=R,
green=G, blue=B;}
// the 'void' (or some type) is required. !!!
};
For your 'C' headers, you may need:
extern "C" {
#include "myCheader.h"
}
--
Bob R
POVrookie
Jorgen Grahn
...
> Then I discovered that there are a couple of .C files lurking in the
> project that
> pull in the header containing these structs.
Nitpick: you mean C files, as in "C source code". Some people use ".C"
(capital letter C) as the file extension for C++ source code, so I first
read that as "a couple of C++ files" and was thoroughly confused.
Cliff
wrote:
> Nitpick: you mean C files, as in "C source code". Some people use ".C"
> (capital letter C) as the file extension for C++ source code...
Oh, didn't know about the .c .C difference. I meant .c.
What's wrong with .cpp then?
Anyway, I've been dragged onto another job for a while so I'll have to
return to
my original problem later. Although it looks like the .c files don't
use any of
the struct's, so I can mask them in a #ifdef __cplusplus condition.
Cliff
Jorgen Grahn
> On Sep 3, 5:15 pm, Jorgen Grahn <grahn+n...@snipabacken.dyndns.org>
> wrote:
>
>> Nitpick: you mean C files, as in "C source code". Some people use ".C"
>> (capital letter C) as the file extension for C++ source code...
>
> Oh, didn't know about the .c .C difference. I meant .c.
>
> What's wrong with .cpp then?
Nothing. .cpp and .cc are more common than .C, which doesn't work well
on case-insensitive file systems, like MS-DOS and early Windows.
Victor Bazarov
> On Mon, 03 Sep 2007 13:35:53 -0700, Cliff <user...@btconnect.com>
> wrote:
>> On Sep 3, 5:15 pm, Jorgen Grahn <grahn+n...@snipabacken.dyndns.org>
>> wrote:
>>
>>> Nitpick: you mean C files, as in "C source code". Some people use
>>> ".C" (capital letter C) as the file extension for C++ source code...
>>
>> Oh, didn't know about the .c .C difference. I meant .c.
>>
>> What's wrong with .cpp then?
>
> Nothing. .cpp and .cc are more common than .C, which doesn't work well
> on case-insensitive file systems, like MS-DOS and early Windows.
<OT>
You seem to imply that "recent" Windows (as opposed to "early") are
somehow case-sensitive. That's incorrect. .C and .c are the same
on _all_ MS Windows file systems. They do keep the "correct" case
(the case with which the file was originally named) and can display
it if asked, but the case is not considered when finding/opening
a file by name.
</OT>
Alf P. Steinbach
> Jorgen Grahn wrote:
>> On Mon, 03 Sep 2007 13:35:53 -0700, Cliff <user...@btconnect.com>
>> wrote:
>>> On Sep 3, 5:15 pm, Jorgen Grahn <grahn+n...@snipabacken.dyndns.org>
>>> wrote:
>>>
>>>> Nitpick: you mean C files, as in "C source code". Some people use
>>>> ".C" (capital letter C) as the file extension for C++ source code...
>>> Oh, didn't know about the .c .C difference. I meant .c.
>>>
>>> What's wrong with .cpp then?
>> Nothing. .cpp and .cc are more common than .C, which doesn't work well
>> on case-insensitive file systems, like MS-DOS and early Windows.
>
> <OT>
> You seem to imply that "recent" Windows (as opposed to "early") are
> somehow case-sensitive. That's incorrect. .C and .c are the same
> on _all_ MS Windows file systems. They do keep the "correct" case
> (the case with which the file was originally named) and can display
> it if asked, but the case is not considered when finding/opening
> a file by name.
> </OT>
Uh, I hate to correct an off-topic correction, but the 32-bit Windows
file system, NTFS, has always supported case sensitive file names. It
also supports hard links, internal file streams, very long file names
(cirka 2^15 chars, which the standard Windows shell can't handle...),
and in Windows Vista the brilliant technicians at Microsoft even
introduced symbolic links like Unix has had since the 1970's![1]
Tools are a different matter.
Most Windows tools treat file names as not case sensitive, and as being
limited to a few hundre characters, because that's the usual Windows
/convention/ and the default behavior (sorry, I don't know what that
means exactly for characters with one-to-many upper/lower-case).
Cheers, & hth.,
- Alf
Follow-ups set to [comp.os.ms-windows.programmer.win32].
[1] I don't know exactly when Unix got symbolic links, but surely it
could not have been as late as the 1980's. Correct me if wrong.
Jerry Coffin
says...
[ ... ]
> You seem to imply that "recent" Windows (as opposed to "early") are
> somehow case-sensitive. That's incorrect. .C and .c are the same
> on _all_ MS Windows file systems. They do keep the "correct" case
> (the case with which the file was originally named) and can display
> it if asked, but the case is not considered when finding/opening
> a file by name.
This correctly describes the default behavior of Windows, but not all of
the behavior. In particular, the Windows CreateFile call supports a
FILE_FLAG_POSIX_SEMANTICS, which makes it treat the file name in a case
sensitive manner.
When opening a file with portable code, there's no way to affect that
flag, so you're entirely at the whim of the library implementation -- it
could be case sensitive or case insensitive. With proper documentation,
I'm pretty sure it could even do something silly like being case
sensitive during odd seconds and case insensitive during even seconds...
--
Later,
Jerry.
The universe is a figment of its own imagination.
Victor Bazarov
Well, you're probably right (I've never used that flag with CreateFile)
but the essence is that using Standard C++ means of opening a file,
there is no way to distinguish between .c and .C file extension on MS
Windows, which is what most likely happens with a C++ compiler or its
preprocessor.
Jerry Coffin
says...
[ ... ]
> Well, you're probably right (I've never used that flag with CreateFile)
> but the essence is that using Standard C++ means of opening a file,
> there is no way to distinguish between .c and .C file extension on MS
> Windows, which is what most likely happens with a C++ compiler or its
> preprocessor.
The point is that it can if it wants to. Most compilers for Windows
observe the local custom (so to speak) and ignore case -- but the system
allows them to be case sensitive if they choose to do so.