in my humble opinion both the printf family and c++ standard streams have
undefined behaviour in these cases (NULL dereferencing).
In the case of the streams, it possible to check the "good" or the "badbit", as
in "if( std::cin )", but I never do that for output streams. The thing is that
if the badbit is on, there is no guarranty that the rest of the program hasn't
been affected.
Of all the possible "undefined" outcomes, I personally prefer the prolematic
one, because it hints me at a problem, as it was in this case.
Thnak you very much for your valuable help!
p.
> MacArthur, Ian (SELEX GALILEO, UK) wrote:
> >
> >> for( int t = 0; t < _menuBar->size(); ++t )
> >> { Fl_Menu_Item *m = (Fl_Menu_Item*)&(_menuBar->menu()[t]);
> >> std::cout << m->label() << std::endl;
> >> }
> >
> > I think your for loop is wrong - you are dereferencing NULL values.
>
> Good point. When I tested the partial code parts, I did not only
> replace variable names, but I also replaced std::cout with
> printf(), and that's why it worked for me.
>
> Interesting observation(s) on Windows/Cygwin:
>
> The first std::cout with a Null pointer seem to "close" the output
> channel. No more output reaches the console terminal window.
> However, printf() still works. printf() with %s and a Null pointer
> writes "(null)" to stdout, and I saw similar output on Linux.
>
> When I added a printf() to the callback(s), the printf() worked,
> although the cout didn't. That explained why the callbacks seemed
> "not to work" for the OP.
>
> Does anybody know if this is defined behavior of std::cout ? Or
> is it a bug? Maybe Windows only?
>
> Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
