«

On Oct 18, 10:04*am, Werner <wer...@gmail.com> wrote:
> On Oct 17, 9:20*pm, someone <newsbo...@gmail.com> wrote:
>
> [snip]
>
> > Maybe it's a simple question for you... When I wrote the first post, I
> > confused myself a bit. I still think this is not very C++'ish, but
> > it's the best I can do now, but I would like to learn from someone
> > here if you have better suggestions
>
> > Thanks for any comments, if you like... If not, then this is the way
> > it's gonna be - it works
>
> Adding to what Victor said, I've looked at the interface, and I think
> this is a better example of what you should do. I've replaced the
> library classes with my own placeholders. Note that no private
> data exists. This compiles and runs fine courtesy of ideone.

Thanks a lot for doing that! Fantastic work - I must say that I had to
add "include<stdlib.h>" for it to compile, but it looks really good
and definately, there's something I can learn from...

I tried to modify your code and use it on my own - however I get a
"segmentation fault" - not sure why... I'll have to look into it and
prepare/post a better reply tomorrow... It's really a great help, that
you made this. Thanks - I'll be back, after I've slept (am too tired
now)...

On Oct 19, 1:35*am, someone <newsbo...@gmail.com> wrote:

> Thanks a lot for doing that! Fantastic work - I must say that I had to
> add "include<stdlib.h>" for it to compile, but it looks really good
> and definately, there's something I can learn from...

Rather use <cstdlib>. It caters for c++ better (as opposed to c).
Yes, the compiler I used did not require additional includes
for NULL. I cut and paste the definition from the graph
API without looking.

> I tried to modify your code and use it on my own - however I get a
> "segmentation fault" - not sure why...

The code I gave you runs as is. You can view the output
of this:

http://ideone.com/JIlfF

I've modified mysample_impl to access the reader as proof of
concept. This would mean you have some problem in your code.

In:

gr.Window( argc, argv, mysample, "My Window", &myBinReader );

I would make sure that myBinReader starts out simply. You can
even make it an integer or a vector of ints to test the
concept. Remember to replace the placeholders with the
actual graph API...

Regards,

Werner

On Mon, 2011-10-17, Victor Bazarov wrote:
....
> Most callbacks provide an alternative way of passing an argument - like
> this 'void*' here.

And those that /don't/ are broken by design. I see them far too often.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Oct 19, 4:08*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Mon, 2011-10-17, Victor Bazarov wrote:
>
> ...
>
> > Most callbacks provide an alternative way of passing an argument - like
> > this 'void*' here.
>
> And those that /don't/ are broken by design. I see them far too often.

I think we all more or less agree now...

When you see these broken designs (where it's not possible to pass
additional user-defined arguments), then you'll have to go for a
solution with global variables, right? I mean, something similar to
what I came up with after about 3 posts?

There is no alternative to using global vars in that case, at least
not AFAIK - is this right or not?

On Oct 19, 1:06*pm, Werner <wer...@gmail.com> wrote:
> On Oct 19, 1:35*am, someone <newsbo...@gmail.com> wrote:
>
> > Thanks a lot for doing that! Fantastic work - I must say that I had to
> > add "include<stdlib.h>" for it to compile, but it looks really good
> > and definately, there's something I can learn from...
>
> Rather use <cstdlib>. It caters for c++ better (as opposed to c).
> Yes, the compiler I used did not require additional includes
> for NULL. I cut and paste the definition from the graph
> API without looking.

Ok. It's really great. I appreciate it a lot - extremely helpful for
me...

> > I tried to modify your code and use it on my own - however I get a
> > "segmentation fault" - not sure why...
>
> The code I gave you runs as is. You can view the output
> of this:
>
> http://ideone.com/JIlfF
>
> I've modified mysample_impl to access the reader as proof of
> concept. This would mean you have some problem in your code.

Yep - it's a really great example which I can learn (and have learned)
a lot from.

> In:
>
> gr.Window( argc, argv, mysample, "My Window", &myBinReader );
>
> I would make sure that myBinReader starts out simply. You can

Ok, my data passing / argument passing code works now... I just have
another problem, which I think I can solve myself... The plot looks
wrong... I think that the x-axis is wrong even though the text for the
xlabel looks right. I'm actually a bit disappointed about this mathgl-
library... But that is perhaps not something to discuss here...

> even make it an integer or a vector of ints to test the
> concept. Remember to replace the placeholders with the
> actual graph API...

Yep! It works (except that the graph looks wrong, but I think this is
a bug not related to the argument passing).

I spend approx. 5 hours figuring out what was wrong and why I got a
segmentation fault... Turned out that I had to replace this line:

gr.Window(argc,argv,mysample,"My window");

With this line:

gr.Window(argc,argv,mysample,"My window", &myBinReader);

Well... I learned my lesson now and next time, I'll not do so many
mistakes with passing arguments to callback-functions

Thanks a lot! The replies I got was a huge (invaluable) help to me and
I would never have sorted this out myself...

On 10/18/2011 10:17 AM, Werner wrote:
>> library classes with my own placeholders.
>> Note that no private
>
> "private" should be "global". Sorry!
>
> Code can be viewed here:
>
> http://ideone.com/mrePw

By the way: How come you code on that webpage? Or I assume you made the
program on your own pc and then copy/pasted it?

I'm not familiar with that webpage, but I tried to clone the code and
run it and modified it slightly... I prefer to code on my own pc, rather
than to use a webbased online webcoding solution (or whatever it's
called)...

?

Not that I mind other people using it... Just wondering...

On 10/19/2011 09:36 PM, Paavo Helde wrote:
> someone<> wrote in
> news:f158fe69-2f8a-4127-a512-:
>> When you see these broken designs (where it's not possible to pass
>> additional user-defined arguments), then you'll have to go for a
>> solution with global variables, right? I mean, something similar to
>> what I came up with after about 3 posts?
>>
>> There is no alternative to using global vars in that case, at least
>> not AFAIK - is this right or not?
>
> Global variables break down hard in case of multithreading. In this case
> one can use thread-specific storage, the boost::thread library provides
> some cross-platform support for it for example. This still has all other
> drawbacks of globals.

Ok, so boost:thread has some kind of data type that is only "global" to
a single thread, unlike global to all threads...

Ok, I'll remember that in case I'll ever need it, thanks...

On Wed, 2011-10-19, someone wrote:
> On Oct 19, 4:08*pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Mon, 2011-10-17, Victor Bazarov wrote:
>>
>> ...
>>
>> > Most callbacks provide an alternative way of passing an argument - like
>> > this 'void*' here.
>>
>> And those that /don't/ are broken by design. I see them far too often.
>
> I think we all more or less agree now...
>
> When you see these broken designs (where it's not possible to pass
> additional user-defined arguments), then you'll have to go for a
> solution with global variables, right?

Yes -- or rewrite the callback interface if you can.

> There is no alternative to using global vars in that case, at least
> not AFAIK - is this right or not?

Perhaps I used the word "global" a bit sloppily; it could e.g. be
something like:

int * get_the_data()
{
static int foo;
return &foo;
}

but that doesn't really help much.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On 10/19/2011 10:34 PM, Jorgen Grahn wrote:
> On Wed, 2011-10-19, someone wrote:
>> On Oct 19, 4:08 pm, Jorgen Grahn<grahn+n...@snipabacken.se> wrote:
>>> On Mon, 2011-10-17, Victor Bazarov wrote:
>> There is no alternative to using global vars in that case, at least
>> not AFAIK - is this right or not?
>
> Perhaps I used the word "global" a bit sloppily; it could e.g. be
> something like:
>
> int * get_the_data()
> {
> static int foo;
> return&foo;
> }
>
> but that doesn't really help much.

Because that is not thread-safe ? Not sure I understand why "global" was
used sloppily, neither not sure of the purpose of this get_the_data()
function. Isn't this get_the_data() function a global function, so
instead foo could just as well be a global variable - the result is the
same: Ugly?

Foo is static, so it exists until the program terminates... Static is
not thread-safe, right? I think I can see that this doesn't really help
much, I'm just only 95% sure of the explanation...

On Oct 19, 6:36*pm, someone <newsbo...@gmail.com> wrote:
>
> By the way: How come you code on that webpage? Or I assume you made the
> program on your own pc and then copy/pasted it?

perhaps OT... but

- I don't need to create a project everytime.
- I can use the latest compiler...
- It's a nice way of sharing ideas. It's certainly a
better way of looking at the code that using a
newsreader. [You] can compile and run it
immediately
- The only disadvantage I see is that I don't know
how persistent the code is (how long it will remain
there).

Of course when I do work I code on my PC/Notebook etc.

Glad to be of help.