29 Jul
2006
29 Jul
'06
9:31 a.m.
Hi all,
Thanks to suggestions from people here I now have a relatively
complete C++ wrapper for libsndfile:
http://www.mega-nerd.com/tmp/sndfile.hh
There is also a pre-release of libsndfile which includes a
test for this wrapper:
http://www.mega-nerd.com/tmp/libsndfile-1.0.17pre7.tar.gz
C++ users, please comment.
Cheers,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Even among Europe's Muslim minorities, roughly one-in-seven in France,
Spain, and Great Britain feel that suicide bombings against civilian targets
can at least sometimes be justified to defend Islam against its enemies."
-- http://pewglobal.org/reports/display.php?ReportID=253
29 Jul
29 Jul
9:53 a.m.
On Sat, 2006-07-29 at 21:31 +1000, Erik de Castro Lopo wrote:
Hi all,
Thanks to suggestions from people here I now have a relatively
complete C++ wrapper for libsndfile:
http://www.mega-nerd.com/tmp/sndfile.hh
There is also a pre-release of libsndfile which includes a
test for this wrapper:
http://www.mega-nerd.com/tmp/libsndfile-1.0.17pre7.tar.gz
C++ users, please comment.
The 4 different overloaded versions of the read, readf, write, and
writef functions will cause ambiguities that will force you to cast them
to their respective types in order to use pointers to them, for example
in functors (e.g. a sigc++ slot), like this:
mem_fun(sndobj, (sf_count_t (Sndfile::*)(float*,
sf_count_t))&Sndfile::read);
If they were specialisations of the same template functions instead,
with the sample type as template parameter, you'd only have to write
this:
mem_fun(sndobj, &Sndfile::read<float>);
which is a lot nicer and easier to read.
--
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
11:14 a.m.
Lars Luthman wrote:
The 4 different overloaded versions of the read,
readf, write, and
writef functions will cause ambiguities that will force you to cast them
to their respective types in order to use pointers to them, for example
in functors (e.g. a sigc++ slot), like this:
mem_fun(sndobj, (sf_count_t (Sndfile::*)(float*,
sf_count_t))&Sndfile::read);
If they were specialisations of the same template functions instead,
with the sample type as template parameter, you'd only have to write
this:
mem_fun(sndobj, &Sndfile::read<float>);
which is a lot nicer and easier to read.
Interesting use case.
I'm not even close to being an expert in C++ templates, but
I suppose that read function would then be defined as something
like:
template <T> sf_count_t read (T *ptr, sf_count_t items) ;
SO how do I ensure that <T> only gets specialised as short,
int, float and double?
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
The difference between genius and stupidity is that
genius has its limits.
11:29 a.m.
On Sat, 2006-07-29 at 23:14 +1000, Erik de Castro Lopo wrote:
Lars Luthman wrote:
class Sndfile {
...
template <typename T> sf_count_t read (T *ptr, sf_count_t items);
...
};
template <> sf_count_t Sndfile::read<short>(short* ptr, sf_count_t
items) { ... }
template <> sf_count_t Sndfile::read<int>(int* ptr, sf_count_t items)
{ ... }
template <> sf_count_t Sndfile::read<float>(float* ptr, sf_count_t
items) { ... }
template <> sf_count_t Sndfile::read<double>(double* ptr, sf_count_t
items) { ... }
...and nothing more. If you don't have a generic implementation anyone
who tries to instantiate the template with an unsupported type will get
a compilation error.
I don't think there is a way to actually prevent someone else from
writing a generic implementation or a different specialisation in their
own source, but if they try that they should _really_ know what they are
doing.
--
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
The 4 different overloaded versions of the read,
readf, write, and
writef functions will cause ambiguities that will force you to cast them
to their respective types in order to use pointers to them, for example
in functors (e.g. a sigc++ slot), like this:
mem_fun(sndobj, (sf_count_t (Sndfile::*)(float*,
sf_count_t))&Sndfile::read);
If they were specialisations of the same template functions instead,
with the sample type as template parameter, you'd only have to write
this:
mem_fun(sndobj, &Sndfile::read<float>);
which is a lot nicer and easier to read.
Interesting use case.
I'm not even close to being an expert in C++ templates, but
I suppose that read function would then be defined as something
like:
template <T> sf_count_t read (T *ptr, sf_count_t items) ;
SO how do I ensure that <T> only gets specialised as short,
int, float and double? 
30 Jul
30 Jul
5:46 p.m.
On Jul 29, 2006, at 9:29 AM, Lars Luthman wrote:
I don't think there is a way to actually prevent
someone else from
writing a generic implementation or a different specialisation in
their
own source, but if they try that they should _really_ know what
they are
doing.
I've heard that a mechanism for disallowing certain types in
templates will be in the next version of C++.
Taybin
29 Jul
29 Jul
10:04 p.m.
Erik de Castro Lopo wrote:
Hi all,
Thanks to suggestions from people here I now have a relatively
complete C++ wrapper for libsndfile:
http://www.mega-nerd.com/tmp/sndfile.hh
I've updated this with the following:
- Templatize the read/write/readf/writef methods.
- Stop (potentially) leaking SNDFILE* pointers in the open*()
methods.
- Change the SF_INFO pointer to const in:
Sndfile (const char *path, int mode, const SF_INFO *sfinfo_in) ;
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Software is largely a service industry operating under the persistent
but unfounded delusion that it is a manufacturing industry."
-- Eric S. Raymond
30 Jul
30 Jul
1:43 a.m.
Erik de Castro Lopo wrote:
Erik de Castro Lopo wrote:
> Hi all,
>
> Thanks to suggestions from people here I now have a relatively
> complete C++ wrapper for libsndfile:
>
> http://www.mega-nerd.com/tmp/sndfile.hh
An another update incorporating a number of suggestions from Daniel
Schmitt.
- The SF_INFO struct is now private.
- Add frames, channels, format and samplerate getters.
- Sndfile constructor and open method now require a mode
(SFM_READ, SFM_RDWR or SFM_WRITE) and optional format/
channels/samplerate.
The latest is at the same URL as the above.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"No Silicon Heaven? Preposterous! Where would
all the calculators go?" -- Kryten, Red Dwarf
6474
days inactive
6475
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
Erik de Castro Lopo -
Lars Luthman -
Taybin Rutkin