Re: Extended API: Constructors and alloca()

[Takashi Iwai <tiwai@suse.de>]

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