13 Jul
2006
13 Jul
'06
3:57 p.m.
I mean some minimal C++ class set like: WavFile, WavHeader, WavFrame with
few apparent methods (open/close, read/write frame(s)).
Suggestions?
13 Jul
13 Jul
4:07 p.m.
On Thu, Jul 13, 2006 at 09:56:58PM +0400, Andrew Gaydenko wrote:
I mean some minimal C++ class set like: WavFile,
WavHeader, WavFrame with
few apparent methods (open/close, read/write frame(s)).
Libsndsfile is plain C, but will do what you want without any fuss.
You could write a WAV specific C++ wrapper on top of this in a few minutes.
--
FA
Follie! Follie! Delirio vano e' questo!
5:11 p.m.
Libsndsfile is plain C, but will do what you want
without any fuss.
You could write a WAV specific C++ wrapper on top of this in a few minutes.
libsndfile is superb, but sometimes you don't want to link against
external libraries in your code. I have some structs/classes which I use
if in-memory-handling of wav files is sufficient. You can have a look at
them at:
http://cubic.org/~doj/ebay/wav.tar.gz
If you have to handle large files you should go the libsndfile way.
--
---> Dirk Jagdmann ^ doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org
5:22 p.m.
On Thu, 2006-07-13 at 21:11 +0200, Dirk Jagdmann wrote:
please don't make this mistake.
after 5 years of doing its own audio file handling, ardour finally
switched to using libsndfile for everything.
you may think you know your applications limitations and don't need
libsndfile, but i claim that you're wrong. sooner or later, you will be
asked for, or will realize the need for, a change that will be much
easier if you just accept that the full range of functionality offered
by libsndfile is the place to start.
--p
Libsndsfile is
plain C, but will do what you want without any fuss.
You could write a WAV specific C++ wrapper on top of this in a few minutes.
libsndfile is superb, but sometimes you don't want to link against
external libraries in your code. I have some structs/classes which I use
if in-memory-handling of wav files is sufficient. You can have a look at
them at:
http://cubic.org/~doj/ebay/wav.tar.gz
If you have to handle large files you should go the libsndfile way.
5:23 p.m.
Dirk,
I'm afraid I have an appetite to work with long files also.
======= On Thursday 13 July 2006 23:11, Dirk Jagdmann wrote: =======
Libsndsfile is plain C, but will do what you want
without any fuss.
You could write a WAV specific C++ wrapper on top of this in a few minutes.
libsndfile is superb, but sometimes you don't want to link against
external libraries in your code. I have some structs/classes which I use
if in-memory-handling of wav files is sufficient. You can have a look at
them at:
http://cubic.org/~doj/ebay/wav.tar.gz
If you have to handle large files you should go the libsndfile way.
5:20 p.m.
Fons,
"in a few minutes" is true for *you* rather for me :-)
======= On Thursday 13 July 2006 22:07, Fons Adriaensen wrote: =======
On Thu, Jul 13, 2006 at 09:56:58PM +0400, Andrew Gaydenko wrote:
I mean some minimal C++ class set like: WavFile,
WavHeader, WavFrame with
few apparent methods (open/close, read/write frame(s)).
Libsndsfile is plain C, but will do what you want without any fuss.
You could write a WAV specific C++ wrapper on top of this in a few minutes.
6:48 p.m.
Fons Adriaensen wrote:
On Thu, Jul 13, 2006 at 09:56:58PM +0400, Andrew
Gaydenko wrote:
I have for some time been looking for someone to write a
lightweight C++ wrapper for libsndfile that I can distribute
with libsndfile.
My own rather feeble first attempt is here:
http://www.mega-nerd.com/tmp/sndfile.hh
but I am not a fan nor a great user of C++. The wrapper should
really be written by someone with a love for the language.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"An older MS internal whitepaper from August 2000 on switching
Hotmail, which MS acquired in 1997, from front-end servers
running FreeBSD and back-end database servers running Solaris
to a whole farm running Win2K, reads like a veritable sales
brochure for UNIX"
-- http://www.theregister.co.uk/content/4/28226.html
I mean some minimal C++ class set like: WavFile,
WavHeader, WavFrame with
few apparent methods (open/close, read/write frame(s)).
Libsndsfile is plain C, but will do what you want without any fuss.
You could write a WAV specific C++ wrapper on top of this in a few minutes.
7:17 p.m.
On Fri, 2006-07-14 at 06:48 +1000, Erik de Castro Lopo wrote:
but I am not a fan nor a great user of C++. The
wrapper should
really be written by someone with a love for the language.
LOL! that's pretty great. "not a fan" translates in real world terms
into "one of LAD's most persistent critics of almost every aspect of C+
+" :)) rock on erik, we love you anyway!
8:25 p.m.
Paul Davis wrote:
LOL! that's pretty great. "not a fan"
translates in real world terms
into "one of LAD's most persistent critics of almost every aspect of C+
+" :)) rock on erik, we love you anyway!
Aww shucks Paul. I'm blushing :-).
Maybe I should start pimping Ocaml here except that I would
be the first to agre that Ocaml is really not suited to
audio work :-(.
Anyway, for Ocaml pimping people can read my blog:
http://www.mega-nerd.com/erikd/Blog/CodeHacking/Ocaml/index.html
Cheers,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Oh my god! They killed init! You bastards!
14 Jul
14 Jul
5:31 a.m.
On Thu, Jul 13, 2006 at 05:16:01 -0400, Paul Davis wrote:
On Fri, 2006-07-14 at 06:48 +1000, Erik de Castro Lopo
wrote:
Dammit, I feel insulted ;)
Though, having just part-written a huge database engine in C I am feeling
warm thoughts about ObjectiveC, which maybe makes me a traitor to the
cause.
Go Ocaml though.
- Steve
but I am not a fan nor a great user of C++. The
wrapper should
really be written by someone with a love for the language.
LOL! that's pretty great. "not a fan" translates in real world terms
into "one of LAD's most persistent critics of almost every aspect of C+
+" :)) rock on erik, we love you anyway! 
20 Jul
20 Jul
1:16 a.m.
New subject: [linux-audio-dev] Re: light C++ set for WAV
On 7/14/06, Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
On Thu, Jul 13, 2006 at 05:16:01 -0400, Paul Davis
wrote:
There are quite a few c++ 'not fans' on LAD. C and python all the way ;)
Loki
On Fri, 2006-07-14 at 06:48 +1000, Erik de Castro
Lopo wrote:
Dammit, I feel insulted ;)
Though, having just part-written a huge database engine in C I am feeling
warm thoughts about ObjectiveC, which maybe makes me a traitor to the
cause.
Go Ocaml though.
- Steve
but I am not a fan nor a great user of C++. The
wrapper should
really be written by someone with a love for the language.
LOL! that's pretty great. "not a fan" translates in real world terms
into "one of LAD's most persistent critics of almost every aspect of C+
+" :)) rock on erik, we love you anyway!
2 a.m.
New subject: [linux-audio-dev] Re: light C++ set for WAV
Loki Davison wrote:
There are quite a few c++ 'not fans' on LAD. C
and python all the way ;)
I used to be a Python fan but for anything larger than a couple
of hundred lines I now prefer Ocaml.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Data is not information, Information is not knowledge, Knowledge is
not understanding, Understanding is not wisdom."
-- Clifford Stoll
4:57 a.m.
New subject: [linux-audio-dev] Re: light C++ set for WAV
On 7/20/06, Erik de Castro Lopo <mle+la(a)mega-nerd.com> wrote:
Loki Davison wrote:
I haven't tried ocaml. I should put it on the todo list. ;) I'm a bit
of a lisper and i find it easier to find places that let me program in
python than lisp/scheme, so it's a good back up plan. Jobs for both
are pretty damn hard to find though. :)
Loki
There are quite a few c++ 'not fans' on
LAD. C and python all the way ;)
I used to be a Python fan but for anything larger than a couple
of hundred lines I now prefer Ocaml.
Erik 
26 Jul
26 Jul
2:45 a.m.
On Jul 13, 2006, at 4:48 PM, Erik de Castro Lopo wrote:
I have for some time been looking for someone to write a
lightweight C++ wrapper for libsndfile that I can distribute
with libsndfile.
My own rather feeble first attempt is here:
http://www.mega-nerd.com/tmp/sndfile.hh
but I am not a fan nor a great user of C++. The wrapper should
really be written by someone with a love for the language.
I use C++ a lot, and I gotta say, this wrapper isn't bad at all. I
prefer lower case method names, but that's about it.
Taybin
3:07 a.m.
Taybin Rutkin wrote:
On Jul 13, 2006, at 4:48 PM, Erik de Castro Lopo
wrote:
Oh, cool, a response at last :-).
Well first off, it isn't quite complete and it hasn't been
properly tested either.
Secondly, with regard to the method names, which do you prefer:
- OpenRead
- openRead
- open_read
- something else
Since you're the only person who actually responded to the real
meat of my email, I have to assume that you are the only person
on this list with a love for C++ and hence the only one who
should have any real input on this issue ;-).
And what you and I come up with the Windiots will have to live
with :-).
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"The object-oriented model makes it easy to build up programs by
accretion. What this often means, in practice, is that it provides
a structured way to write spaghetti code." -- Paul Graham
I have for some time been looking for someone to write a
lightweight C++ wrapper for libsndfile that I can distribute
with libsndfile.
My own rather feeble first attempt is here:
http://www.mega-nerd.com/tmp/sndfile.hh
but I am not a fan nor a great user of C++. The wrapper should
really be written by someone with a love for the language.
I use C++ a lot, and I gotta say, this wrapper isn't bad at all. I
prefer lower case method names, but that's about it. 
8:12 a.m.
On Wed, 26 Jul 2006 15:07:13 +1000
Erik de Castro Lopo <mle+la(a)mega-nerd.com> wrote:
> > My own rather feeble first attempt is here:
> >
> > http://www.mega-nerd.com/tmp/sndfile.hh
> >
> > but I am not a fan nor a great user of C++. The wrapper should
> > really be written by someone with a love for the language.
>
> I use C++ a lot, and I gotta say, this wrapper isn't bad at all. I
Well, it is very thin though. Which is not a bad thing at all. One could
make ue of an arbitrary amount of more advanced C++ features if desired
though (i.e. templates parametrized with the type you want to read for
example, or operator<< and operator>> for reading and writing, etc.)
prefer lower
case method names, but that's about it.
Oh, cool, a response at last :-).
Well first off, it isn't quite complete and it hasn't been
properly tested either.
Secondly, with regard to the method names, which do you prefer: - OpenRead
- openRead
- open_read
vote++, i never cared for the
more java style methodName convention.
- something else
Since you're the only person who actually responded to the real
meat of my email, I have to assume that you are the only person
on this list with a love for C++ and hence the only one who
should have any real input on this issue ;-).
Nicely worded :)
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
8:25 a.m.
On Wednesday 26 Jul 2006 11:12, Florian Paul Schmidt wrote:
I think if your class is named LikeThis, then your method should be named
likeThat (Java-style). If your method is named like_this, then your class
should be named like_that (STL-style). Either is fine, but don't mix your
dialects.
Mmm. For what it's worth, I write mostly C++ but have no problem with using
the libsndfile C API. I don't really mind whether it has a C++ API as well
or not. So yes, you probably should ignore me.
Chris
Well, it is very thin though. Which is not a bad thing
at all. One could
make ue of an arbitrary amount of more advanced C++ features if desired
though (i.e. templates parametrized with the type you want to read for
example, or operator<< and operator>> for reading and writing, etc.)
operator<< and >>... ugh.
Secondly, with
regard to the method names, which do you prefer:
- OpenRead
- openRead
- open_read
vote++, i never cared for the more java style methodName convention. Since
you're the only person who actually responded to the real
meat of my email, I have to assume that you are the only person
on this list with a love for C++ and hence the only one who
should have any real input on this issue ;-).
Nicely worded :)
8:47 a.m.
On Wed, 26 Jul 2006 11:26:00 +0100
Chris Cannam <cannam(a)all-day-breakfast.com> wrote:
Oh well, this is precisely what i do. For classes i use FooBar. For
Objects i use foo_bar. and for methods, it's foo_bar, too.
class FooBar {
bool _yesno;
public:
FooBar (bool yesno) :
_yesno (yesno)
{
// ...
}
void foo_my_bar (bool yesno)
{
_yesno = yesno;
}
};
int main () {
FooBar foo_bar (false);
foo_bar.foo_my_bar (true);
}
It just strikes some aesthetic nerve in me. And this is something you
just cannot argue about. So to each his own i say :) And no, usually i
seperate header and implementation, too ;)
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
vote++, i
never cared for the more java style methodName convention.
I think if your class is named LikeThis, then your method should be
named likeThat (Java-style). If your method is named like_this, then
your class should be named like_that (STL-style). Either is fine,
but don't mix your dialects.
9:02 a.m.
Chris Cannam wrote:
On Wednesday 26 Jul 2006 11:12, Florian Paul Schmidt
wrote:
Yeah I really gotta agree here. Overloading the left and right
shift operators has got to the thing I find most distasteful
about C++.
Well, it is very thin though. Which is not a bad
thing at all. One could
make ue of an arbitrary amount of more advanced C++ features if desired
though (i.e. templates parametrized with the type you want to read for
example, or operator<< and operator>> for reading and writing, etc.)
operator<< and >>... ugh. I think if your class is named LikeThis, then your
method should be named
likeThat (Java-style). If your method is named like_this, then your class
should be named like_that (STL-style). Either is fine, but don't mix your
dialects.
Ok, "don't mix dialects" is a good tip. Most of the proposed methods
for the Sndfile class have single word names so Java style might be
the best option.
Mmm. For what it's worth, I write mostly C++ but
have no problem
with using the libsndfile C API.
Most people who really know C++ know enough to be comfortable
with pure C. I'm pretty sure you fall into this category.
However, I do get emails from some of the more clueless Windiots
complaining that libsndfile is written in old-fashioned C instead
of nice shiny modern C++. IMNSHO these people should not be allowed
anywhere near a language as complex, subtle, and unforgiving as
C++ (or for that matter as unforgiving as C).
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"I consider C++ the most significant technical hazard to the survival
of your project and do so without apologies." -- Alistair Cockburn
9:10 a.m.
On Wed, Jul 26, 2006 at 09:02:31 +1000, Erik de Castro Lopo wrote:
Heh, I get that from UNIX people too though, I always assumed they were
trying to wind me up...
- Steve
Mmm. For what
it's worth, I write mostly C++ but have no problem
with using the libsndfile C API.
Most people who really know C++ know enough to be comfortable
with pure C. I'm pretty sure you fall into this category.
However, I do get emails from some of the more clueless Windiots
complaining that libsndfile is written in old-fashioned C instead
of nice shiny modern C++. IMNSHO these people should not be allowed
anywhere near a language as complex, subtle, and unforgiving as
C++ (or for that matter as unforgiving as C). 
9:24 a.m.
On Wed, 2006-07-26 at 12:08 +0100, Steve Harris wrote:
On Wed, Jul 26, 2006 at 09:02:31 +1000, Erik de Castro
Lopo wrote:
Heh, I get that from UNIX people too though, I always assumed they were
trying to wind me up...
But it _would_ be nice to have template functors as callbacks in liblo,
so you wouldn't have to write static wrappers all the time. =)
--
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
Mmm. For
what it's worth, I write mostly C++ but have no problem
with using the libsndfile C API.
Most people who really know C++ know enough to be comfortable
with pure C. I'm pretty sure you fall into this category.
However, I do get emails from some of the more clueless Windiots
complaining that libsndfile is written in old-fashioned C instead
of nice shiny modern C++. IMNSHO these people should not be allowed
anywhere near a language as complex, subtle, and unforgiving as
C++ (or for that matter as unforgiving as C).
9:06 p.m.
New subject: [linux-audio-dev] Re: light C++ set for WAV
On 7/26/06, Erik de Castro Lopo <mle+la(a)mega-nerd.com> wrote:
Chris Cannam wrote:
Are you sure these people should be let near a computer, less alone a
complex, subtle and unforgiving language? ;) I still love your sig
messages.... ;)
Loki
--
"If once a man indulges himself in murder, very soon he comes to think
little of robbing; and from robbing he next comes to drinking and
Sabbath-breaking, and from that to incivility and procrastination."
-- Thomas De Quincey (1785 - 1859)
On Wednesday 26 Jul 2006 11:12, Florian Paul
Schmidt wrote:
Yeah I really gotta agree here. Overloading the left and right
shift operators has got to the thing I find most distasteful
about C++.
Well, it is very thin though. Which is not a bad
thing at all. One could
make ue of an arbitrary amount of more advanced C++ features if desired
though (i.e. templates parametrized with the type you want to read for
example, or operator<< and operator>> for reading and writing, etc.)
operator<< and >>... ugh. I think if your class is named LikeThis, then
your method should be named
likeThat (Java-style). If your method is named like_this, then your class
should be named like_that (STL-style). Either is fine, but don't mix your
dialects.
Ok, "don't mix dialects" is a good tip. Most of the proposed methods
for the Sndfile class have single word names so Java style might be
the best option.
Mmm. For what it's worth, I write mostly C++
but have no problem
with using the libsndfile C API.
Most people who really know C++ know enough to be comfortable
with pure C. I'm pretty sure you fall into this category.
However, I do get emails from some of the more clueless Windiots
complaining that libsndfile is written in old-fashioned C instead
of nice shiny modern C++. IMNSHO these people should not be allowed
anywhere near a language as complex, subtle, and unforgiving as
C++ (or for that matter as unforgiving as C).
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"I consider C++ the most significant technical hazard to the survival
of your project and do so without apologies." -- Alistair Cockburn
9:21 a.m.
On Wed, 2006-07-26 at 11:26 +0100, Chris Cannam wrote:
I think if your class is named LikeThis, then your method should be named
likeThat (Java-style). If your method is named like_this, then your class
should be named like_that (STL-style). Either is fine, but don't mix your
dialects.
I use ClassNames and function_names all the time. I think it makes it
easier to distinguish between them.
Mmm. For what it's worth, I write mostly C++ but have no problem with using
the libsndfile C API. I don't really mind whether it has a C++ API as well
or not. So yes, you probably should ignore me.
I agree - the libsndfile API is simple enough to fit into C++ code quite
nicely.
--
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
On Wednesday 26 Jul 2006 11:12, Florian Paul Schmidt
wrote:
Operator overloading is lovely. When reading fixed size audio chunks a
function call syntax makes more sense though (how else would you specify
the chunk size? sndfile>>setw(1024)>>my_buffer is a bit too weird).
Well, it is very thin though. Which is not a bad
thing at all. One could
make ue of an arbitrary amount of more advanced C++ features if desired
though (i.e. templates parametrized with the type you want to read for
example, or operator<< and operator>> for reading and writing, etc.)
operator<< and >>... ugh. Secondly, with regard to the method names, which do
you prefer:
- OpenRead
- openRead
- open_read
vote++, i never cared for the more java style methodName convention. Since you're the only person who actually
responded to the real
meat of my email, I have to assume that you are the only person
on this list with a love for C++ and hence the only one who
should have any real input on this issue ;-).
Nicely worded :)
9:22 a.m.
On Jul 26, 2006, at 1:07 AM, Erik de Castro Lopo wrote:
Taybin Rutkin wrote:
I prefer the unix-y open_read(). I don't think method names should
ever start with a capital, unless it's the ctor or dtor.
On Jul 13, 2006, at 4:48 PM, Erik de Castro Lopo
wrote:
Oh, cool, a response at last :-).
Well first off, it isn't quite complete and it hasn't been
properly tested either.
Secondly, with regard to the method names, which do you prefer:
- OpenRead
- openRead
- open_read
I have for some time been looking for someone to write a
lightweight C++ wrapper for libsndfile that I can distribute
with libsndfile.
My own rather feeble first attempt is here:
http://www.mega-nerd.com/tmp/sndfile.hh
but I am not a fan nor a great user of C++. The wrapper should
really be written by someone with a love for the language.
I use C++ a lot, and I gotta say, this wrapper isn't bad at all. I
prefer lower case method names, but that's about it. - something else
Since you're the only person who actually responded to the real
meat of my email, I have to assume that you are the only person
on this list with a love for C++ and hence the only one who
should have any real input on this issue ;-).
I noticed that the constructor SndFile::SndFile (const char *path,
int mode, SF_INFO *sfinfo)
isn't declared in the class. Also, since this constructor can fail
if sf_open() fails up, it should throw an exception. Maybe
containing the results of sf_strerror().
Something like
SndFile::SndFile (const char *path, int mode, SF_INFO *sfinfo)
{
psf = sf_open (path, mode, sfinfo) ;
if (!psf) {
throw sf_error(psf);
}
}
Taybin
9:52 a.m.
Taybin Rutkin wrote:
I prefer the unix-y open_read(). I don't think
method names should
ever start with a capital, unless it's the ctor or dtor.
I'm actually tending towards openRead().
I noticed that the constructor SndFile::SndFile (const
char *path,
int mode, SF_INFO *sfinfo)
isn't declared in the class. Also, since this constructor can fail
if sf_open() fails up, it should throw an exception. Maybe
containing the results of sf_strerror().
Something like
SndFile::SndFile (const char *path, int mode, SF_INFO *sfinfo)
{
psf = sf_open (path, mode, sfinfo) ;
if (!psf) {
throw sf_error(psf);
}
}
Good tip, thanks.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"If you think C++ is not overly complicated, just what is a
protected abstract virtual base pure virtual private destructor
and when was the last time you needed one?" -- Tom Cargill
3:32 p.m.
Hi, Erik!
I'd suggest making all wrapper functions inline,
as they are one-liners by definition and
anyway wrapper includes libsndfile headers.
So there's nothing to hide here.
Regards,
Dmitry
6:58 p.m.
Dmitry Baikov wrote:
Hi, Erik!
I'd suggest making all wrapper functions inline,
as they are one-liners by definition and
anyway wrapper includes libsndfile headers.
So there's nothing to hide here.
Yes, that was my idea. So if the sndfile.hh has:
class Sndile
{
int method (/* params */) ;
}
int method (/* params */)
{
/* whatever */
}
do I need to add an inline keyword anywhere and if so where?
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"It has been discovered that C++ provides a remarkable facility
for concealing the trival details of a program -- such as where
its bugs are." -- David Keppel
7:25 p.m.
On Thu, Jul 27, 2006 at 06:58:32AM +1000, Erik de Castro Lopo wrote:
Yes, that was my idea. So if the sndfile.hh has:
class Sndile
{
int method (/* params */) ;
}
int method (/* params */)
{
/* whatever */
}
do I need to add an inline keyword anywhere and if so where?
You need either
class Sndfile
{
int method (/* params */) ;
}; // note the ;
inline int Sndfile::method (/* params */)
{
/* whatever */
}
or
class Sndfile
{
int method (/* params */) { /* whatever */ }
};
I use the second form often if the function body is trivial
e.g. just one statement, as for a getter / setter.
--
FA
Lascia la spina, cogli la rosa.
4:04 p.m.
On 7/26/06, Erik de Castro Lopo <mle+la(a)mega-nerd.com> wrote:
I wouldn't bother with openRead/Write; just pass the mode in to open
like in the ctor.
I also second keeping the implementation entirely in the header (if it
really is a light wrapper) and put "inline" in front of each method
definition.
SndFile::strerror() should maybe take an int arg (the value returned
by SndFile::error()) and be declared as a static method?
Taybin Rutkin wrote:
I vote for Java (SmallTalk?) style too.
I prefer the unix-y open_read(). I don't
think method names should
ever start with a capital, unless it's the ctor or dtor.
I'm actually tending towards openRead().
I noticed that
the constructor SndFile::SndFile (const char *path,
int mode, SF_INFO *sfinfo)
isn't declared in the class. Also, since this constructor can fail
if sf_open() fails up, it should throw an exception. Maybe
containing the results of sf_strerror().
Something like
SndFile::SndFile (const char *path, int mode, SF_INFO *sfinfo)
{
psf = sf_open (path, mode, sfinfo) ;
if (!psf) {
throw sf_error(psf);
}
}
Good tip, thanks.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"If you think C++ is not overly complicated, just what is a
protected abstract virtual base pure virtual private destructor
and when was the last time you needed one?" -- Tom Cargill
6:45 p.m.
Paul Coccoli wrote:
I wouldn't bother with openRead/Write; just pass
the mode in to open
like in the ctor.
The open/close methods are provided so a single Sndfile object
can be opened and closed multiple times. I was also going to
make the copy constructor and asignment operator private so
they can't be misused.
I also second keeping the implementation entirely in
the header (if it
really is a light wrapper) and put "inline" in front of each method
definition.
Thats was the idea from the start. I light-weight wrapper.
SndFile::strerror() should maybe take an int arg (the
value returned
by SndFile::error()) and be declared as a static method?
Good catch. Thanks.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"To me C++ seems to be a language that has sacrificed orthogonality
and elegance for random expediency." -- Meilir Page-Jones
7041
days inactive
7054
days old
linux-audio-dev@lists.linuxaudio.org
29 comments
13 participants
participants (13)
-
Andrew Gaydenko -
Chris Cannam -
Dirk Jagdmann -
Dmitry Baikov -
Erik de Castro Lopo -
Florian Paul Schmidt -
Fons Adriaensen -
Lars Luthman -
Loki Davison -
Paul Coccoli -
Paul Davis -
Steve Harris -
Taybin Rutkin