dar-libdar_api — discussion area for developpers that want to use the libdar API

[Dar-libdar_api] Re: Re context variable in callbacks

[Denis C. <dar...@fr...>]

Johnathan Burchill wrote:
> Hi Denis,

Hello Johnathan,

> 
> Unfortunately, I only just read your reply to my post! I never got the 
> reply from sourceforge, even though I was confirmed as a member of the 
> dar_api mailing list...I only got a message that my post was waiting to be 
> reviewed by the moderator. Too bad, as I would have liked to have 
> discussed this further with you before you went ahead with coding.

strange, there is still one of your email address in the list... Well 
the coding done is a lot code cleaning to have a thread safe library. 
Few conceptions changes were necessary to reach this aim like the 
"user_interaction" class but I don't think you've missed the most 
interesting part ;)

> 
>   > Apparently it is standard coding practice for API callback functions to
>   > accept a "context value", which is a void *, that allows one to use a
>   > class member function as a callback without resorting to a global 
>   > pointer
>   > variable.
>  
> 
>>Well, to my point of view, after having read the tutorial you give
>>reference bellow, there is no standard coding practice that speaks about
>>a "context value" for callback. The "context value" is used as a trick
>>to make a callback function pointing to non-static member functions of a
>>C++ class. The trick implies a static method or normal function to 
>>explicitely pass the "this" pointer (pointer to the current object which 
>>is a hidden argument in C++) as explicit argument.
> 
>  
> I based that statement on something a professional programmer told me --- I 
> can only take him at his word. In fact I was not able to find anything in 
> any reference books on C++ programming that explains context variables for 
> callback functions. The tutorial is the closest thing I could come up 
> with.

Whatever standard programming it is or not, It makes a lot of sens. So 
as I said I will go this way.

> 
> 
>>Now my question, is do we need libdar calling a non-static member of a
>>given object (as callback) ?
> 
> 
> As I understand static member functions, you are not allowed to change 
> their member variables. So in order to return a boolean from the callback, 
> we need non-static member functions whose variables can be altered. Right?

you are right about static member functions, they are not part of any 
object but global to a class, so they cannot access to the data of a 
particular object (non static data member).

>[...]
> 
>  >kdar, and libdar does not know anything about this class. This would not
>  >be very useful to libdar point of view.
>  
> I don't understand. Libdar does not understand anything about the regular 
> callback function either, which is the point of having the callback 
> function.

I think I make a mistake and wanted to say "dar and libdar" do not (have 
to) know kdar own data structure.

> 
>   >
>   > As I understand dar, it uses a regular function as the callback. 
> 
>>Could you
> 
>   > add perhaps a new set of callback setting functions to the libdar API 
>  >that
>   > accept a void * context value to be passed. It would be easy to keep
>   > backwards compatibility with earlier libdar versions by redefining the
>   > standard callback setting functions to call the new ones with NULL 
>  >for the
>   > void *.
>  
>  >Yes, this is still possible.
>  
> 
>>I think the need behind is the thread safe libdar library. If the
>>library is thread safe, there must not be a function in the API that
>>receive the address of a callback function without any context.
> 
>  
> 
>>Let"s take an example:
> 
>  
> 
>>actually (version 2.1.2 is the last release) libdar API proposes the
>>following function:
> 
>  
> 
>>       set_warning_callback(&my_warning_callback);
> 
>  
>  >to reach thread safe level, set_warning_callback must have a contextual 
>  >argument, to have a thread discriminant, the callback function stays the 
>  >same. In my idea actually, a possible solution is a new class that will 
>  >gather all static variables that currently make the libdar thread 
>  >unsafe. I have not yet a name for that class, so let"s call it "junk" 
>  >for now. We would then have set_warning_callback a method of the "junk" 
>  >class, and probably any other functions of the current API (op_create, 
> 
>>etc.)
> 
>  
>  >Before anything else, each thread should create its own "junk" object 
>  >forcing the calling application to give a thread specific callback 
>  >function in the "junk" constructor.
>  
>  >OK now, I see, if you have several threads, you could give several 
>  >callback functions (one per thread), but that could lead to some 
>  >ineficiency, you could rather give the same callback function to all 
>  >thread and have an additional argument in the callback prototype that 
>  >tell this common callback function which thread it is called from, and 
>  >which action to do (which object to call, etc...). A void pointer should 
>  >be effectively interesting as it could carry the address to a function 
>  >or the address to an object which method to call.
> 
>  >we would have someting like this:
>  
> I'm lost on all of this. I don't know anything yet about making libraries 
> thread-safe. Is the issue that two instances of a libdar operation,
> say isolation and diffing, might try to call the same callback function at 
> the same time?

Well, the work about thread-safe libdar is the following: Several API 
functions on variable not passed as argument (the callback functions for 
example), and some value passed in argument were stored as class static 
data (like compression algorithm used, and several other things). So 
theses variables are shared by all the running threads, causing a 
problem if you want modify theses variables.

Now, all parameters needed for API functions are passed as argument and 
stay on the stack (they are passed as argument and temporary variables 
stay "local" to functions). One exception concerns the special 
allocation scheme, which must stay global (the ::new and ::delete 
operator cannot be else), this scheme needs global variable and any 
change to theses variable is now in a critical section thanks to a mutex 
(Posix threading). This allow several threads to run without the risk of 
having one destructing the variable set by another one.

But as I said, theses changes are mainly internal to the libdar library.

> 
> 
>>class junk
> 
>  >{
>  >public:
>   >   set_warning_callback(void (*callback)(const std::string &x,
>    >                                        void *context) )
>     >     { warning_callback = callback; };
>      >set_warning_callback_context_to_give(void *context)
>      >    { context_to_give = context; };
>  >
>   >   op_create(....);
>    >  op_create_noexcept(...);
>     > [...]
>  
> 
>>private:
> 
>  >    void *context_to_give;
>   >   void (*warning_callback)(const std::string &x, void *context);
>  >};
>  
>  >and inside a give thread :
>  
>   >    ...
>    >   junk toto;
>     >  toto.set_warning_callback(&mycallback);
>     >  toto.set_warning_context_to_give(this);
>     >  toto.op_create_noexcept(...);
>      > ...
>  
>  >with the global callback function:
>  
>   >    void mycallback(const std::string &x, void *context)
>    >   {
>     >       context->some_method(x);
>      >     // well, this is much simplified.
>       >}
>  
>  
> 
>>Does this makes sens to you ?
> 
>  
> Not yet. I have to put some serious thought into all of this. Feels a lot 
> like you're reinventing the wheel. Unfortunately I'm not much help, and 
> neither do the texts that I've looked at. Do you know any good books on 
> C++ library programming that you could point me to?


first you can forget the junk class, it was not necessary to introduce 
it in the API. Second I suggest having a look at user_interaction.hpp 
and lidar.hpp as well as the raw notes in doc/DOC_API3 (taken from CVS) 
to have a idea of the changes brought to the API.

I don't think I am reiventing the wheel (at least now) :-). I had some 
good books about C++ programming and C library at the time I was student 
  in computer science,... but today I build dar based on my souvenirs 
;-) and my programming experience. I don't pretend doing totally 
academic things.

> 
>   >
>   > There is a good tutorial at
>   > http://www.function-pointer.org/callback.html
>   > #3:  How to Implement Callbacks in C and C++
>   >
>   > In the examples given, I currently use method B, but it would be 
>  >better to
>   > use method A to avoid using the global variable.
>  
>  >I agree, I dislike global variables.
> 
> Glad to see that libdar is on track to be thread-safe.

it should be thread-safe now.

> I updated the cvs, but the docs need some work, so I'll put off the API3 

sure they need ! In fact, API3 is for me today a reminder of changes 
done, as there will be probably some others before 2.2.0. I also plan to
have all documentation in HTML, which is portable format, and allow 
better readability than pure text. :-)

> upgrade to KDar until later.

I will contact you through this mailing-list when the API will be frozen 
for release 2.2.0 (at that time new features will be for following 
release). Tjis will take place a few weeks before pre-release time, so 
we can integrate you needs in the API if necessary.

> 
> Best regards,
> JB
>  

Kind Regards,
Denis.

[Dar-libdar_api] Re: API / thread safe libdar

[Denis C. <dar...@fr...>]

Christian Neumann wrote:
> On Wed, 16 Jun 2004 21:50:31 +0200
> Denis Corbin <dar...@fr...> wrote:
> 
> 
>>I could keep the use of the op_create and other API functions as
>>normal function (not class members). They received several new
>>arguments, among which, the most important is the "dialog" class (as
>>first argument). This object contains all the callback functions, as
>>defined by the libdar user. Given this object libdar is able to use
>>the appropriate callback function.
> 
> It would be nice to have the possibility to derive from this Dialog
> class, so that one could overwrite the Dialog's write() members.
> Example: (I don't know yet how you implemented it..)

First I made a mistake the real name of the class is "user_interaction" 
not "dialog"... (this was the name at specification time but as it 
replaces the whole use_interaction module, I have kept the name of the 
module).

> 
> class Dialog { // @ libdar
> private:
> void set_warning_callback(...);
> protected:
> virtual void write_warning(...);
> }

This is an interesting idea ! In the user_interaction class, the 
constructor receives two arguments (the two callback functions), and 
provides to libdar rawly two methods : pause() and warning(). So it is 
absolutely possible to have an inherited class from user_interaction 
that do not rely at all on callback function. The constructor can pass 
fake callback functions to user_interaction, and the pause() and 
warning() be overwritten. I will just add the "virtual" keyword in the 
declaration of the concerned methods.

> 
> The dialog's implementation of write_warning should call the callback
> function defined by set_write_callback(...) or sth else. So the user
> could create a Dialog, set the callback functions, and pass the Dialog
> to op_create etc.

absolutely.

> 
> But he should also be able to do something like this:
> 
> class LogWindow : public Dialog { // @ backup gui
> private:
> void add_line_to_log(...);
> void write_warning(...) { add_line_to_log(...) };
> }
> 
> The overwritten write_warning(...) would write the warning directly to
> the LogWindow, without calling any callback function. I think that
> this would result in cleaner code (but as said, one could have both
> possibilities).

100% agreed  :-)

> 
> 
> 
>>The native language support is also a feature for next major release 
>>(version 2.2.0) ;-)
> 
> That's good :) If you need a german translator, tell me ;)

sure ! I note your proposal ! ;-)

> 
> Regards,
> Christian
> 

Cheers,
Denis.

Re: [Dar-libdar_api] Re: API / thread safe libdar

[Christian N. <chr...@al...>]

On Wed, 16 Jun 2004 21:50:31 +0200
Denis Corbin <dar...@fr...> wrote:

> I could keep the use of the op_create and other API functions as
> normal function (not class members). They received several new
> arguments, among which, the most important is the "dialog" class (as
> first argument). This object contains all the callback functions, as
> defined by the libdar user. Given this object libdar is able to use
> the appropriate callback function.
It would be nice to have the possibility to derive from this Dialog
class, so that one could overwrite the Dialog's write() members.
Example: (I don't know yet how you implemented it..)

class Dialog { // @ libdar
private:
void set_warning_callback(...);
protected:
virtual void write_warning(...);
}

The dialog's implementation of write_warning should call the callback
function defined by set_write_callback(...) or sth else. So the user
could create a Dialog, set the callback functions, and pass the Dialog
to op_create etc.

But he should also be able to do something like this:

class LogWindow : public Dialog { // @ backup gui
private:
void add_line_to_log(...);
void write_warning(...) { add_line_to_log(...) };
}

The overwritten write_warning(...) would write the warning directly to
the LogWindow, without calling any callback function. I think that
this would result in cleaner code (but as said, one could have both
possibilities).


> The native language support is also a feature for next major release 
> (version 2.2.0) ;-)
That's good :) If you need a german translator, tell me ;)

Regards,
Christian

[Dar-libdar_api] Re context variable in callbacks

[Johnathan B. <jk...@us...>]

Hi Denis,

Unfortunately, I only just read your reply to my post! I never got the=20
reply from sourceforge, even though I was confirmed as a member of the=20
dar_api mailing list...I only got a message that my post was waiting to be=
=20
reviewed by the moderator. Too bad, as I would have liked to have=20
discussed this further with you before you went ahead with coding.

  > Apparently it is standard coding practice for API callback functions to
  > accept a "context value", which is a void *, that allows one to use a
  > class member function as a callback without resorting to a global=20
  > pointer
  > variable.
=20
> Well, to my point of view, after having read the tutorial you give
> reference bellow, there is no standard coding practice that speaks about
> a "context value" for callback. The "context value" is used as a trick
> to make a callback function pointing to non-static member functions of a
> C++ class. The trick implies a static method or normal function to=20
> explicitely pass the "this" pointer (pointer to the current object which=
=20
> is a hidden argument in C++) as explicit argument.
=20
I based that statement on something a professional programmer told me --- I=
=20
can only take him at his word. In fact I was not able to find anything in=20
any reference books on C++ programming that explains context variables for=
=20
callback functions. The tutorial is the closest thing I could come up=20
with.

> Now my question, is do we need libdar calling a non-static member of a
> given object (as callback) ?

As I understand static member functions, you are not allowed to change=20
their member variables. So in order to return a boolean from the callback,=
=20
we need non-static member functions whose variables can be altered. Right?

 >First there is a risk, if this objects dies, we will have big problems
 >like memory violations. But OK, if you give a wrong argument as address=20
 >of the callback function we get to the same point.
=20
> Second, libdar would always call the method of the same object, and it
> would require first, a way for kdar (for example) to tell libdar which
> object address (the "this" argument) to give to the callback function in
> the "context value".

> Third, logically, it is a class defined in the user application like
 >kdar, and libdar does not know anything about this class. This would not
 >be very useful to libdar point of view.
=20
I don't understand. Libdar does not understand anything about the regular=20
callback function either, which is the point of having the callback=20
function.

  >
  > As I understand dar, it uses a regular function as the callback.=20
> Could you
  > add perhaps a new set of callback setting functions to the libdar API=20
 >that
  > accept a void * context value to be passed. It would be easy to keep
  > backwards compatibility with earlier libdar versions by redefining the
  > standard callback setting functions to call the new ones with NULL=20
 >for the
  > void *.
=20
 >Yes, this is still possible.
=20
> I think the need behind is the thread safe libdar library. If the
> library is thread safe, there must not be a function in the API that
> receive the address of a callback function without any context.
=20
> Let"s take an example:
=20
> actually (version 2.1.2 is the last release) libdar API proposes the
> following function:
=20
>        set_warning_callback(&my_warning_callback);
=20
 >to reach thread safe level, set_warning_callback must have a contextual=20
 >argument, to have a thread discriminant, the callback function stays the=
=20
 >same. In my idea actually, a possible solution is a new class that will=20
 >gather all static variables that currently make the libdar thread=20
 >unsafe. I have not yet a name for that class, so let"s call it "junk"=20
 >for now. We would then have set_warning_callback a method of the "junk"=20
 >class, and probably any other functions of the current API (op_create,=20
>etc.)
=20
 >Before anything else, each thread should create its own "junk" object=20
 >forcing the calling application to give a thread specific callback=20
 >function in the "junk" constructor.
=20
 >OK now, I see, if you have several threads, you could give several=20
 >callback functions (one per thread), but that could lead to some=20
 >ineficiency, you could rather give the same callback function to all=20
 >thread and have an additional argument in the callback prototype that=20
 >tell this common callback function which thread it is called from, and=20
 >which action to do (which object to call, etc...). A void pointer should=
=20
 >be effectively interesting as it could carry the address to a function=20
 >or the address to an object which method to call.
>=20
 >we would have someting like this:
=20
I'm lost on all of this. I don't know anything yet about making libraries=20
thread-safe. Is the issue that two instances of a libdar operation,
say isolation and diffing, might try to call the same callback function at=
=20
the same time?

> class junk
 >{
 >public:
  >   set_warning_callback(void (*callback)(const std::string &x,
   >                                        void *context) )
    >     { warning_callback =3D callback; };
     >set_warning_callback_context_to_give(void *context)
     >    { context_to_give =3D context; };
 >
  >   op_create(....);
   >  op_create_noexcept(...);
    > [...]
=20
> private:
 >    void *context_to_give;
  >   void (*warning_callback)(const std::string &x, void *context);
 >};
=20
 >and inside a give thread :
=20
  >    ...
   >   junk toto;
    >  toto.set_warning_callback(&mycallback);
    >  toto.set_warning_context_to_give(this);
    >  toto.op_create_noexcept(...);
     > ...
=20
 >with the global callback function:
=20
  >    void mycallback(const std::string &x, void *context)
   >   {
    >       context->some_method(x);
     >     // well, this is much simplified.
      >}
=20
=20
> Does this makes sens to you ?
=20
Not yet. I have to put some serious thought into all of this. Feels a lot=20
like you're reinventing the wheel. Unfortunately I'm not much help, and=20
neither do the texts that I've looked at. Do you know any good books on=20
C++ library programming that you could point me to?

  >
  > There is a good tutorial at
  > http://www.function-pointer.org/callback.html
  > #3:  How to Implement Callbacks in C and C++
  >
  > In the examples given, I currently use method B, but it would be=20
 >better to
  > use method A to avoid using the global variable.
=20
 >I agree, I dislike global variables.

Glad to see that libdar is on track to be thread-safe.
I updated the cvs, but the docs need some work, so I'll put off the API3=20
upgrade to KDar until later.

Best regards,
JB
=20
=2D-=20
Johnathan K. Burchill, Ph.D.
jk...@us...

[Dar-libdar_api] Re: API / thread safe libdar

[Denis C. <dar...@fr...>]

Christian Neumann wrote:
> Hi.

Hello,

> I am currently developing a GUI backup program and I am planning to use
> libdar as the backend. But I have some problems with the current API.
> For example, it's hard to use a non-static class member function as an
> callback. The problem has been discussed some months ago in this list
> (thread "callback function context value"). I think that it would be
> _really_ nice to have some sort of thread safe Backup class as Denis
> Corbin proposed. Will this be implemented or are you, Denis Corbin,
> already working on such an API?

The current development version is now thread safe (I hope so ;-) ). 
This has been a lot of work and code rewriting. Next change is adding a 
(void*) pointer as argument to call back functions (as described in the 
"callback function context value").

In the current state, the API specifications are not yet stable, I mean 
there is still some features I want to add for release 2.2.0 (like 
encryption for example), that may impact the libdar API function 
definitions. But, what the target is the following:

I could keep the use of the op_create and other API functions as normal 
function (not class members). They received several new arguments, among 
which, the most important is the "dialog" class (as first argument). 
This object contains all the callback functions, as defined by the 
libdar user. Given this object libdar is able to use the appropriate 
callback function.

the void* argument in each callback function, will let you use 
non-static methods as callback function through the use of a wrapper 
function like this simplified example:

void my_callback_function(std::string & x, void *ptr)
{
      my_class *clptr = dynamic_cast<my_class *>(ptr);
      clptr->my_non_static_method(x);
}



> And another proposal: I would like to get an error/question id
> instead of a complete message. For example:
> 
> --snip--
> enum eMessageID {
> DISC_FULL, PERMISSION_DENIED [...] }

Several aspects have to be seen for that:
- first thing it may make the libdar code less readable. The short name 
of a macro (#define) is not as explicit as the message itself.
- second thing it make thing more complex. As last ressort, you want to 
display the error message to the user.
- third point, the error string is build all along the exception path. 
For example, while you do a backup, while considering a given file, when 
dar opens the file, a system error occurs, thus an exception is created 
with just the sytstem errno string message. The exception is caught at 
the file backup level and the exception is completed with "error while 
saving file xxx :"+[original error message]", and it is thrown again. 
Then at the overall backup level the exception is caught the message is 
transmitted to the user throught a callback function, and the next file 
is processed.
- there is a lot of possible messages (due to the system itself), due to 
the fact that error message are built the way described above.


> 
> class Warning {
>   public: 
>     eMessageID mID;
>     std::slist<std::string> mArgs;
> }
> 
> --
> libdar:
> 
> Warning w;
> w.mID = PERMISSION_DENIED;
> w.mArgs.push_back("/file/that/dar/couldnt/access");
> w.mArgs.push_back("/another/file/that/dar/couldnt/access");
> call_warning_callback(w);
> --
> frontend:
> 
> void warning_callback(Warning& w)
> {
>   switch(w.mID) {
>     case(PERMISSION_DENIED) :
>       [report to user in his own language, tell him what he can do...]
> [...]
> --snip--

The native language support is also a feature for next major release 
(version 2.2.0) ;-)

> 
> That would be very convenient!

yes, I understand.

> 
> Regards,
> Christian
> 

Regards,
Denis.

[Dar-libdar_api] API / thread safe libdar

[Christian N. <chr...@al...>]

Hi.
I am currently developing a GUI backup program and I am planning to use
libdar as the backend. But I have some problems with the current API.
For example, it's hard to use a non-static class member function as an
callback. The problem has been discussed some months ago in this list
(thread "callback function context value"). I think that it would be
_really_ nice to have some sort of thread safe Backup class as Denis
Corbin proposed. Will this be implemented or are you, Denis Corbin,
already working on such an API?
And another proposal: I would like to get an error/question id
instead of a complete message. For example:

--snip--
enum eMessageID {
DISC_FULL, PERMISSION_DENIED [...] }

class Warning {
  public: 
    eMessageID mID;
    std::slist<std::string> mArgs;
}

--
libdar:

Warning w;
w.mID = PERMISSION_DENIED;
w.mArgs.push_back("/file/that/dar/couldnt/access");
w.mArgs.push_back("/another/file/that/dar/couldnt/access");
call_warning_callback(w);
--
frontend:

void warning_callback(Warning& w)
{
  switch(w.mID) {
    case(PERMISSION_DENIED) :
      [report to user in his own language, tell him what he can do...]
[...]
--snip--

That would be very convenient!

Regards,
Christian

[Dar-libdar_api] Re: callback function context value

[Denis C. <den...@fr...>]

Johnathan Burchill wrote:
 > Hi Denis,

Hello Johnathan,

 >
 > Apparently it is standard coding practice for API callback functions to
 > accept a "context value", which is a void *, that allows one to use a
 > class member function as a callback without resorting to a global 
pointer
 > variable.

Well, to my point of view, after having read the tutorial you give
reference bellow, there is no standard coding practice that speaks about
a "context value" for callback. The "context value" is used as a trick
to make a callback function pointing to non-static member functions of a
C++ class. The trick implies a static method or normal function to 
explicitely pass the "this" pointer (pointer to the current object which 
is a hidden argument in C++) as explicit argument.

Now my question, is do we need libdar calling a non-static member of a
given object (as callback) ?

First there is a risk, if this objects dies, we will have big problems
like memory violations. But OK, if you give a wrong argument as address 
of the callback function we get to the same point.

Second, libdar would always call the method of the same object, and it
would require first, a way for kdar (for example) to tell libdar which
object address (the "this" argument) to give to the callback function in
the "context value".

Third, logically, it is a class defined in the user application like
kdar, and libdar does not know anything about this class. This would not
be very useful to libdar point of view.

 >
 > As I understand dar, it uses a regular function as the callback. 
Could you
 > add perhaps a new set of callback setting functions to the libdar API 
that
 > accept a void * context value to be passed. It would be easy to keep
 > backwards compatibility with earlier libdar versions by redefining the
 > standard callback setting functions to call the new ones with NULL 
for the
 > void *.

Yes, this is still possible.

I think the need behind is the thread safe libdar library. If the
library is thread safe, there must not be a function in the API that
receive the address of a callback function without any context.

Let's take an example:

actually (version 2.1.2 is the last release) libdar API proposes the
following function:

	set_warning_callback(&my_warning_callback);

to reach thread safe level, set_warning_callback must have a contextual 
argument, to have a thread discriminant, the callback function stays the 
same. In my idea actually, a possible solution is a new class that will 
gather all static variables that currently make the libdar thread 
unsafe. I have not yet a name for that class, so let's call it 'junk' 
for now. We would then have set_warning_callback a method of the 'junk' 
class, and probably any other functions of the current API (op_create, etc.)

Before anything else, each thread should create its own 'junk' object 
forcing the calling application to give a thread specific callback 
function in the 'junk' constructor.

OK now, I see, if you have several threads, you could give several 
callback functions (one per thread), but that could lead to some 
ineficiency, you could rather give the same callback function to all 
thread and have an additional argument in the callback prototype that 
tell this common callback function which thread it is called from, and 
which action to do (which object to call, etc...). A void pointer should 
be effectively interesting as it could carry the address to a function 
or the address to an object which method to call.

we would have someting like this:

class junk
{
public:
    set_warning_callback(void (*callback)(const std::string &x,
                                          void *context) )
        { warning_callback = callback; };
    set_warning_callback_context_to_give(void *context)
        { context_to_give = context; };

    op_create(....);
    op_create_noexcept(...);
    [...]

private:
    void *context_to_give;
    void (*warning_callback)(const std::string &x, void *context);
};

and inside a give thread :

     ...
     junk toto;
     toto.set_warning_callback(&mycallback);
     toto.set_warning_context_to_give(this);
     toto.op_create_noexcept(...);
     ...

with the global callback function:

     void mycallback(const std::string &x, void *context)
     {
          context->some_method(x);
    	  // well, this is much simplified.
     }


Does this makes sens to you ?

 >
 > There is a good tutorial at
 > http://www.function-pointer.org/callback.html
 > #3:  How to Implement Callbacks in C and C++
 >
 > In the examples given, I currently use method B, but it would be 
better to
 > use method A to avoid using the global variable.

I agree, I dislike global variables.

 >
 > Cheers,
 > JB
 >

Cheers,
Denis.

P.S.: the sample code are not expected to compile, there are here for 
further reference if necessary.

[Dar-libdar_api] callback function context value

[Johnathan B. <jk...@us...>]

Hi Denis,

Apparently it is standard coding practice for API callback functions to=20
accept a "context value", which is a void *, that allows one to use a=20
class member function as a callback without resorting to a global pointer=20
variable.

As I understand dar, it uses a regular function as the callback. Could you=
=20
add perhaps a new set of callback setting functions to the libdar API that=
=20
accept a void * context value to be passed. It would be easy to keep=20
backwards compatibility with earlier libdar versions by redefining the=20
standard callback setting functions to call the new ones with NULL for the=
=20
void *.

There is a good tutorial at
http://www.function-pointer.org/callback.html
#3:  How to Implement Callbacks in C and C++

In the examples given, I currently use method B, but it would be better to=
=20
use method A to avoid using the global variable.

Cheers,
JB

=2D-=20
Johnathan K. Burchill, Ph.D.
jk...@us...

[Dar-libdar_api] Re: [Dar-discussions] mail to news gateway

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

As no opposition have been expressed, each mailing-list will have a
corresponding newsgroups under the gmane.comp.sysutils.backup.dar tree.

theses newsgroups are accessible in NNTP from news.gmane.org or through
the web interface http://gmane.org/webnews.php

Cheers,
Denis.


Denis Corbin wrote:
| Hello,
|
| A gateway between theses mailing lists and a gmane group will be
| installed soon. For more information, you can check the
| http://gmane.org/ web site to see how your email will be protected
| against spam if you post in the mailing-list.
|
| If you have any objections, let us know your arguments before the 1st of
| September, as I will not install the gateway before that date. Thus, you
| are welcome to use the dar-discussion mailing list for that.
|
| Regards,
|
| Denis.







-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/VPgqpC5CI8gYGlIRApNLAJ9G1jTymfv6OB0vgsx6S+X2z1jQjgCeIBFM
I90A2h3HjhsJe9S0HcEgI2M=
=yX9S
-----END PGP SIGNATURE-----

[Dar-libdar_api] mail to news gateway

[Denis C. <dar...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

A gateway between theses mailing lists and a gmane group will be
installed soon. For more information, you can check the
http://gmane.org/ web site to see how your email will be protected
against spam if you post in the mailing-list.

If you have any objections, let us know your arguments before the 1st of
September, as I will not install the gateway before that date. Thus, you
are welcome to use the dar-discussion mailing list for that.

Regards,

Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/RmElpC5CI8gYGlIRAkUQAKCUHU+UtNhrR3DccpW/q8LZ5VWlbACfTUZs
BxbnwB68yxVwFxa1RcCxRto=
=sjTe
-----END PGP SIGNATURE-----

[Dar-libdar_api] welcome

[Denis C. <dar...@fr...>]

Hello,

the next major version to come is version 2.0.0 (available through CVS).

Amoung other new features, dar suite programs implementation has been 
re-designed to have a common set of sources that form a library called 
libdar, and a specific set of sources to each dar suite program. The 
specific part is strongly linked to the command-line environment, 
leaving all the general algorithms and data structures in the libdar 
library.

The access to the libdar library is planned to be a documented API (work 
still under process), and open to anyone who whish to use theses 
algorithms. The main target to the API/library is to pass the relay to 
people that want to make a GUI front-end for dar, and, as already 
suggested to me, to directly integrate dar in already existing tools.

libdar usage has nevertheless an important restriction concerning the 
license:
unlike some other libraries, libdar will *not* be provided under the 
Lesser GPL, be will be instead released as part of dar, and thus, under 
the (Full) GNU General Public License. The consequence is that any 
software that has to use libdar *must* be itself a GPL software. This 
closes the door to *any* commercial utilization of this library.

I will not admit that somebody/company makes money with a software I 
provide freely for all, just hidding my work under a commercial GUI.


Denis Corbin.