You know you're in for a bad day of programming when....

Simon F

Tea maker
Moderator
Veteran
Supporter
You know you're in for a bad day of programming when....
Code:
 assert(isspace('\n'));
...fails.

It got worse when I changed it to assert(isspace(' ')) and it also died. Sigh.
 
i dont know c but that code seems to be saying
is the space character the newline character(aka the enter key, aka #13) ?
 
assert(isspace(' '))

I had something like that last week

X = 512;
cout << (( X >= 512 ) ? "yes" : "no" ) << endl;

output = 'no'

error was in a library corruption mem
 
I used to know I was in for a bad day of programming, well, every single day I had to do any!

I am a truly shite coder. :smile:
 
going into a ball + crying aint gonna solve the issue
oddly enuf I enojy when the comp asserts something that is obviously false

usually u can solve it within an hour, now the tricky things are when
A/ 'the code mohphs when u debug'
B/ 'its hard to replicate'
now those are day+ issues (what ivelearnt ehn is, if u dont solve it within 30mins then walk away + try tommorow)
 
Try assert(true). If that still fails, I suggest curling up into a ball and sobbing. :smile:
:) No, that was OK.

Turned out that a library I was using/including with an "include path" contained a .h file with the same name as one included by the standard "ctypes.h" and redefined some macros. That was fun to track down. :???:

If you're using Perl, use double quotes i.e. "\n".
Perl!? Get thee away from me Satan. ;)
 
:) No, that was OK.

Turned out that a library I was using/including with an "include path" contained a .h file with the same name as one included by the standard "ctypes.h" and redefined some macros. That was fun to track down. :???:

Which library dares to override standard macros? :devilish:
 
Which library dares to override standard macros? :devilish:
I don't think they were "standard" macros but internal ones that (a) happened to have the same name and (b) resided in a file with the same name (i.e. endian.h).

Frankly, I don't think this sort of thing should ever happen. E.g why aren't standard include files using explicit paths to their own included source files?
 
Frankly, I don't think this sort of thing should ever happen. E.g why aren't standard include files using explicit paths to their own included source files?

Well, there are reasons for both
#include <file>
and
#include "file"
to exist.

Could proper use of those be the cleanest solution for these issues?
 
Try assert(true). If that still fails, I suggest curling up into a ball and sobbing. :smile:

For extra fun, enter these lines into a central .h file in the project:

#define ture false
#define flase true

That should teach all crappy spellers. :p
 
Well, there are reasons for both
#include <file>
and
#include "file"
to exist.

Could proper use of those be the cleanest solution for these issues?
I have no control over what is inside the 'standard' <ctypes.h>. It clearly wanted access to an endian.h and because the include path on the command line had a directory with a file of that name, it picked up the wrong one :(

For extra fun, enter these lines into a central .h file in the project:

#define ture false
#define flase true

That should teach all crappy spellers. :p
You are an evil man.
 
I used to know I was in for a bad day of programming, well, every single day I had to do any!

I am a truly shite coder. :smile:

:LOL:

I liked programming for fun while in Junior High, after that I realized that there was no way in hell I would want to do if for a living. I really enjoy mechanical engineering though.:D
 
I had to debug code which contained this :

a = a++;

did different things in different platforms!
On the wall by my desk hangs the "+1 Mallet of Enlightenment." You are more than welcome to borrow it to provide percussive insight to the author of that line of code.
 
Back
Top