C++ Gem
-
I cam across this C++ gem today in some code that a co-worker wrote. In his defense, the bulk of his programming experience is in OS/390 Assembler.
char *ShowDrive( TAPEDRIVE *DRV, char *out ) {
int status; char \*msg; status = 0x2D2D; if ( DRV->stat & POWERON ) status = 0x4E4F; if ( DRV->stat & MOUNTED ) status = 0x544D; if ( DRV->stat & STARTED ) status = 0x5453; if ( DRV->stat & INTREQD ) status = 0x5249;sprintf_s( out, 80,"%2d %4.4s %4.4s %2.2s %6.6s %8.8s %8.8s\n ",
DRV->slot, DRV->host, DRV->name, &status, DRV->vols, DRV->msg1, DRV->msg2 );msg = out + strlen( out );sprintf_s( msg, 80," Block=%d\n", DRV->blockID );
return out + strlen( out ); }Where do I begin? I especially like the int status variable that he uses in the sprintf_s with a format specifier of "%2.2s". It took me a while to realize that since he used "&status" as the argument, he was forcing sprintf_s to use it as a char pointer, and that the value of the int was two ASCII characters (reversed, because of Little Endianness). I also like the return of the char pointer that points to the middle of the constructed string. (In his code the return value was ignored.) I'm not wild about the way it plays willy-nilly with the char pointers, etc. Too much horrible crap to even go into it all. My head hurts. :doh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
I cam across this C++ gem today in some code that a co-worker wrote. In his defense, the bulk of his programming experience is in OS/390 Assembler.
char *ShowDrive( TAPEDRIVE *DRV, char *out ) {
int status; char \*msg; status = 0x2D2D; if ( DRV->stat & POWERON ) status = 0x4E4F; if ( DRV->stat & MOUNTED ) status = 0x544D; if ( DRV->stat & STARTED ) status = 0x5453; if ( DRV->stat & INTREQD ) status = 0x5249;sprintf_s( out, 80,"%2d %4.4s %4.4s %2.2s %6.6s %8.8s %8.8s\n ",
DRV->slot, DRV->host, DRV->name, &status, DRV->vols, DRV->msg1, DRV->msg2 );msg = out + strlen( out );sprintf_s( msg, 80," Block=%d\n", DRV->blockID );
return out + strlen( out ); }Where do I begin? I especially like the int status variable that he uses in the sprintf_s with a format specifier of "%2.2s". It took me a while to realize that since he used "&status" as the argument, he was forcing sprintf_s to use it as a char pointer, and that the value of the int was two ASCII characters (reversed, because of Little Endianness). I also like the return of the char pointer that points to the middle of the constructed string. (In his code the return value was ignored.) I'm not wild about the way it plays willy-nilly with the char pointers, etc. Too much horrible crap to even go into it all. My head hurts. :doh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Tom Delany wrote:
I also like the return of the char pointer that points to the middle of the constructed string.
Tom Delany wrote:
return out + strlen( out );
I'd have thought that would return a pointer to the character after the constructed string. Could be excusable if he's intending to add further text to the buffer , although judging by your comments that isn't the case.
-
Tom Delany wrote:
I also like the return of the char pointer that points to the middle of the constructed string.
Tom Delany wrote:
return out + strlen( out );
I'd have thought that would return a pointer to the character after the constructed string. Could be excusable if he's intending to add further text to the buffer , although judging by your comments that isn't the case.
Yeah, isn't that the technique Joel recommends? To avoid the Shlemiel the painter's algorithm[^] problem.
-
I cam across this C++ gem today in some code that a co-worker wrote. In his defense, the bulk of his programming experience is in OS/390 Assembler.
char *ShowDrive( TAPEDRIVE *DRV, char *out ) {
int status; char \*msg; status = 0x2D2D; if ( DRV->stat & POWERON ) status = 0x4E4F; if ( DRV->stat & MOUNTED ) status = 0x544D; if ( DRV->stat & STARTED ) status = 0x5453; if ( DRV->stat & INTREQD ) status = 0x5249;sprintf_s( out, 80,"%2d %4.4s %4.4s %2.2s %6.6s %8.8s %8.8s\n ",
DRV->slot, DRV->host, DRV->name, &status, DRV->vols, DRV->msg1, DRV->msg2 );msg = out + strlen( out );sprintf_s( msg, 80," Block=%d\n", DRV->blockID );
return out + strlen( out ); }Where do I begin? I especially like the int status variable that he uses in the sprintf_s with a format specifier of "%2.2s". It took me a while to realize that since he used "&status" as the argument, he was forcing sprintf_s to use it as a char pointer, and that the value of the int was two ASCII characters (reversed, because of Little Endianness). I also like the return of the char pointer that points to the middle of the constructed string. (In his code the return value was ignored.) I'm not wild about the way it plays willy-nilly with the char pointers, etc. Too much horrible crap to even go into it all. My head hurts. :doh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Looks like a C gem to me.
-
I cam across this C++ gem today in some code that a co-worker wrote. In his defense, the bulk of his programming experience is in OS/390 Assembler.
char *ShowDrive( TAPEDRIVE *DRV, char *out ) {
int status; char \*msg; status = 0x2D2D; if ( DRV->stat & POWERON ) status = 0x4E4F; if ( DRV->stat & MOUNTED ) status = 0x544D; if ( DRV->stat & STARTED ) status = 0x5453; if ( DRV->stat & INTREQD ) status = 0x5249;sprintf_s( out, 80,"%2d %4.4s %4.4s %2.2s %6.6s %8.8s %8.8s\n ",
DRV->slot, DRV->host, DRV->name, &status, DRV->vols, DRV->msg1, DRV->msg2 );msg = out + strlen( out );sprintf_s( msg, 80," Block=%d\n", DRV->blockID );
return out + strlen( out ); }Where do I begin? I especially like the int status variable that he uses in the sprintf_s with a format specifier of "%2.2s". It took me a while to realize that since he used "&status" as the argument, he was forcing sprintf_s to use it as a char pointer, and that the value of the int was two ASCII characters (reversed, because of Little Endianness). I also like the return of the char pointer that points to the middle of the constructed string. (In his code the return value was ignored.) I'm not wild about the way it plays willy-nilly with the char pointers, etc. Too much horrible crap to even go into it all. My head hurts. :doh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Yeah, isn't that the technique Joel recommends? To avoid the Shlemiel the painter's algorithm[^] problem.
PIEBALDconsult wrote:
To avoid the Shlemiel the painter's algorithm[^] problem.
As noted, it is often useful to have functions that append to strings return either a count of the number of bytes written or a pointer to the end of the new data. While C-style string handling is often dangerous because of a general lack of bounds checking, suitable coding techniques can at least make it efficient. BTW, the painter's problem could be adjusted to give whatever performance dropoff is desired between day #2 and day #3 by specifying that the paint dries out with time. When the painter makes shorter trips, he can use up all the paint on his brush before it dries out. After a certain point, however, drying will become a factor. Depending upon whether the paint is useful until it dries out and then becomes useless, or whether painting becomes slower as the paint gets drier, different performance characteristics may be achieved.
-
Looks like a C gem to me.
Yeah. He gave the file a .CPP extension, but there was nothing really C++ about it. X|
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
Tom Delany wrote:
I also like the return of the char pointer that points to the middle of the constructed string.
Tom Delany wrote:
return out + strlen( out );
I'd have thought that would return a pointer to the character after the constructed string. Could be excusable if he's intending to add further text to the buffer , although judging by your comments that isn't the case.
Rob Grainger wrote:
I'd have thought that would return a pointer to the character after the constructed string.
You're right. My head was hurting so much from the rest that I misread it. :doh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
Rob Grainger wrote:
I'd have thought that would return a pointer to the character after the constructed string.
You're right. My head was hurting so much from the rest that I misread it. :doh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
Quite understandable - I think returning the pointer to the next character is the only redeeming factor I could spot ;)
-
Yeah. He gave the file a .CPP extension, but there was nothing really C++ about it. X|
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
Tom Delany wrote:
He gave the file a .CPP extension, but there was nothing really C++ about it.
That actually makes sense sometimes. If he really knows C, but wants to make use of a C++ stricter type system and catches more errors at compile time, that is a way to go.
-
PIEBALDconsult wrote:
To avoid the Shlemiel the painter's algorithm[^] problem.
As noted, it is often useful to have functions that append to strings return either a count of the number of bytes written or a pointer to the end of the new data. While C-style string handling is often dangerous because of a general lack of bounds checking, suitable coding techniques can at least make it efficient. BTW, the painter's problem could be adjusted to give whatever performance dropoff is desired between day #2 and day #3 by specifying that the paint dries out with time. When the painter makes shorter trips, he can use up all the paint on his brush before it dries out. After a certain point, however, drying will become a factor. Depending upon whether the paint is useful until it dries out and then becomes useless, or whether painting becomes slower as the paint gets drier, different performance characteristics may be achieved.
supercat9 wrote:
the painter's problem could be adjusted to give whatever performance dropoff is desired between day #2 and day #3 by specifying that the paint dries out with time. When the painter makes shorter trips, he can use up all the paint on his brush before it dries out. After a certain point, however, drying will become a factor. Depending upon whether the paint is useful until it dries out and then becomes useless, or whether painting becomes slower as the paint gets drier, different performance characteristics may be achieved.
I imagine an optimalization task based on that in an exam of computers' architecture (+ a bunch of extra triple integrals to do).
Greetings - Gajatko Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
-
I cam across this C++ gem today in some code that a co-worker wrote. In his defense, the bulk of his programming experience is in OS/390 Assembler.
char *ShowDrive( TAPEDRIVE *DRV, char *out ) {
int status; char \*msg; status = 0x2D2D; if ( DRV->stat & POWERON ) status = 0x4E4F; if ( DRV->stat & MOUNTED ) status = 0x544D; if ( DRV->stat & STARTED ) status = 0x5453; if ( DRV->stat & INTREQD ) status = 0x5249;sprintf_s( out, 80,"%2d %4.4s %4.4s %2.2s %6.6s %8.8s %8.8s\n ",
DRV->slot, DRV->host, DRV->name, &status, DRV->vols, DRV->msg1, DRV->msg2 );msg = out + strlen( out );sprintf_s( msg, 80," Block=%d\n", DRV->blockID );
return out + strlen( out ); }Where do I begin? I especially like the int status variable that he uses in the sprintf_s with a format specifier of "%2.2s". It took me a while to realize that since he used "&status" as the argument, he was forcing sprintf_s to use it as a char pointer, and that the value of the int was two ASCII characters (reversed, because of Little Endianness). I also like the return of the char pointer that points to the middle of the constructed string. (In his code the return value was ignored.) I'm not wild about the way it plays willy-nilly with the char pointers, etc. Too much horrible crap to even go into it all. My head hurts. :doh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
The code works, so this is not a coding horror? I don't see any problem here. Maybe it's just your head. You should get a new one and then look at the code again.
Tom Delany wrote:
he was forcing sprintf_s
This does not mean that he was "forcing" anything.