Re: Extended API: Constructors and alloca()

Re: Extended API: Constructors and alloca()

[Takashi Iwai]

Hi Lars,

[i forwarded this to alsa-devel, since i'd like to keep the development
 as open as possible.]


BACKGROUND:

we're trying to define a C++ library set on the top of alsa-lib.
my idea is to provide this library separately from alsa-lib itself,
i.e. as a c++ wrapper library (just like the relationship between
libgtk++ and libgtk).


At Thu, 20 Mar 2003 19:52:54 +0100,
Lars Hamren wrote:
> 
> Hi,
> 
> we talked during the econference about documentation and about a new
> API. I have been looking a the API part since I came home.
> 
> Unfortunately, alloca() cannot be used in a constructor, since the
> memory will be deallocated when the constructor exits. Instead I think
> that a good solution is to embed the data structure from the
> standard library into into each class:
> 
> 	# include <stdio.h>
> 	# include <string.h>
> 
> 	# define ATTRIBUTE_UNUSED
> 
> 	namespace AlsaStandardLibrary {
> 	#    include "src/control/control_local.h"
> 	};	 
> 
> 	namespace Alsa {
> 	    class Control {
> 	      public:
> 		Control() { memset(&_data, 0, sizeof _data); }
> 	      private:
> 		AlsaStandardLibrary::snd_ctl_t _data;
> 	    };
> 	}
> 
> 	int main()
> 	{
> 	    Alsa::Control c;
> 	    printf("&c = %08lX\n", (long)&c);
> 	}
> 
> Using this implementation there is no extra memory allocation, and
> alloca() is no longer necessary.

however, by this implementation, the private headers are still
referred from the public headers.  IMO, this is the very weakpoint of
c++.  you cannot hide the private members at all...

i believe putting the private things to the public place is not
suitable from the viewpoint of the design of alsa-lib.


> By padding the class definition with a few extra longs, the size could
> stay fixed even if there are small changes to alsalib structure
> definitions.

it's pragmatic but still the problem remains how to manage the private
header files.


> One alternative is to use a pointer instead of embedde data, but that
> would require more use of malloc and free.

i think this is not so bad as imagined.
you can put a reference counter and a copy constructor to reuse the
allocated object.

in most cases, the instances are not always necessarily on stack.
in addition to the fact some instances are big, in c programs, we've
used alloca in many places just because it doesn't need the manual
free().  in c++, it's no longer problem.
also, the instances are often used for long term, so the total impact
wouldn't be too much.

the only flaw of this method is that it forces to allocate a temporary
data such as pcm_status in advance.  otherwise calling malloc at API
call will result in a sleep, which is critical for a realtime app.


> Another alternative is to embed a `char _data[BIG_ENOUGH];' but that
> would require a cast for every use of _data.

hmm...  i will not take this...


> A third alternative is to derive:
> 
> 	class Control : public AlsaStandardLibrary::snd_ctl_t {
> 	  public:
> 	    Control() { memset(this, 0, sizeof *this); }
> 	};
> 
> which is more or less equivalent to embedding in this case. I may
> settle for this.
> 
> It would be a good thing if the necesary structs (snd_ctl_t, et c.)
> were available in an unofficial include file in the library.

THIS is the very question.
so far, in the implementation of alsa-lib, we have been trying to hide
this.  the all strucs are suppose to be opaque (except for some
trivial cases).
putting the struct in public (even though it's unofficial) breaks this
policy.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: Extended API: Constructors and alloca()

[Paul Davis]

>> It would be a good thing if the necesary structs (snd_ctl_t, et c.)
>> were available in an unofficial include file in the library.
>
>THIS is the very question.
>so far, in the implementation of alsa-lib, we have been trying to hide
>this.  the all strucs are suppose to be opaque (except for some
>trivial cases).
>putting the struct in public (even though it's unofficial) breaks this
>policy.

i (and i hope many other ALSA users/developers) would scream very
loudly if we moved from this design/policy. it has been critical and
central to success in stabilizing the API from the perspective of
applications. it has worked for Xlib for a long time, it has worked
for us for a year or more, and we should not change this. making the
change proposed by lars would open us up to major binary compatibility
issues as alsa evolves.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: Extended API: Constructors and alloca()

[Takashi Iwai]

At Fri, 21 Mar 2003 07:51:41 -0500,
Paul Davis wrote:
> 
> >> It would be a good thing if the necesary structs (snd_ctl_t, et c.)
> >> were available in an unofficial include file in the library.
> >
> >THIS is the very question.
> >so far, in the implementation of alsa-lib, we have been trying to hide
> >this.  the all strucs are suppose to be opaque (except for some
> >trivial cases).
> >putting the struct in public (even though it's unofficial) breaks this
> >policy.
> 
> i (and i hope many other ALSA users/developers) would scream very
> loudly if we moved from this design/policy. it has been critical and
> central to success in stabilizing the API from the perspective of
> applications. it has worked for Xlib for a long time, it has worked
> for us for a year or more, and we should not change this. making the
> change proposed by lars would open us up to major binary compatibility
> issues as alsa evolves.

agreed, the compatibility must be kept.

as mentioned in the last mail, our initial plan is to make a c++
library which covers the existing alsa-lib, that is, alsa-lib++.

alsa-lib API (in C) won't be changed by this, i promise you.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf