2007-05-14 09:55:24 +00:00
|
|
|
/*
|
2017-05-03 19:59:31 +00:00
|
|
|
** Copyright (C) 2005-2017 Erik de Castro Lopo <erikd@mega-nerd.com>
|
2007-05-14 09:55:24 +00:00
|
|
|
**
|
2006-07-29 11:19:19 +00:00
|
|
|
** All rights reserved.
|
2007-05-14 09:55:24 +00:00
|
|
|
**
|
2006-07-29 11:19:19 +00:00
|
|
|
** Redistribution and use in source and binary forms, with or without
|
|
|
|
** modification, are permitted provided that the following conditions are
|
|
|
|
** met:
|
2007-05-14 09:55:24 +00:00
|
|
|
**
|
2006-07-29 11:19:19 +00:00
|
|
|
** * Redistributions of source code must retain the above copyright
|
|
|
|
** notice, this list of conditions and the following disclaimer.
|
|
|
|
** * Redistributions in binary form must reproduce the above copyright
|
|
|
|
** notice, this list of conditions and the following disclaimer in
|
|
|
|
** the documentation and/or other materials provided with the
|
|
|
|
** distribution.
|
|
|
|
** * Neither the author nor the names of any contributors may be used
|
|
|
|
** to endorse or promote products derived from this software without
|
|
|
|
** specific prior written permission.
|
|
|
|
**
|
|
|
|
** THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
** "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
|
|
|
|
** TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
** PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
|
|
|
|
** CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
|
|
|
** EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
|
|
|
|
** PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
|
|
|
|
** OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
|
|
|
|
** WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
|
|
|
|
** OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
|
|
|
|
** ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2006-07-30 00:15:10 +00:00
|
|
|
** The above modified BSD style license (GPL and LGPL compatible) applies to
|
|
|
|
** this file. It does not apply to libsndfile itself which is released under
|
|
|
|
** the GNU LGPL or the libsndfile test suite which is released under the GNU
|
|
|
|
** GPL.
|
|
|
|
** This means that this header file can be used under this modified BSD style
|
|
|
|
** license, but the LGPL still holds for the libsndfile library itself.
|
2007-05-14 09:55:24 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2006-07-30 00:15:10 +00:00
|
|
|
** sndfile.hh -- A lightweight C++ wrapper for the libsndfile API.
|
|
|
|
**
|
|
|
|
** All the methods are inlines and all functionality is contained in this
|
|
|
|
** file. There is no separate implementation file.
|
2007-05-14 09:55:24 +00:00
|
|
|
**
|
|
|
|
** API documentation is in the doc/ directory of the source code tarball
|
2020-10-05 07:11:47 +00:00
|
|
|
** and at http://libsndfile.github.io/libsndfile/api.html.
|
2007-05-14 09:55:24 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef SNDFILE_HH
|
|
|
|
#define SNDFILE_HH
|
|
|
|
|
|
|
|
#include <sndfile.h>
|
|
|
|
|
2006-10-04 22:51:31 +00:00
|
|
|
#include <string>
|
2006-08-01 05:20:19 +00:00
|
|
|
#include <new> // for std::nothrow
|
|
|
|
|
|
|
|
class SndfileHandle
|
2007-05-14 09:55:24 +00:00
|
|
|
{ private :
|
2006-08-01 05:20:19 +00:00
|
|
|
struct SNDFILE_ref
|
2006-08-08 08:13:40 +00:00
|
|
|
{ SNDFILE_ref (void) ;
|
2006-08-01 05:20:19 +00:00
|
|
|
~SNDFILE_ref (void) ;
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2006-08-01 05:20:19 +00:00
|
|
|
SNDFILE *sf ;
|
2006-08-08 08:13:40 +00:00
|
|
|
SF_INFO sfinfo ;
|
2006-08-01 05:20:19 +00:00
|
|
|
int ref ;
|
|
|
|
} ;
|
|
|
|
|
|
|
|
SNDFILE_ref *p ;
|
2006-07-27 10:38:35 +00:00
|
|
|
|
2007-05-14 09:55:24 +00:00
|
|
|
public :
|
2006-06-05 11:54:03 +00:00
|
|
|
/* Default constructor */
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
SndfileHandle (void) : p (NULL) {} ;
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle (const char *path, int mode = SFM_READ,
|
|
|
|
int format = 0, int channels = 0, int samplerate = 0) ;
|
2006-10-04 22:51:31 +00:00
|
|
|
SndfileHandle (std::string const & path, int mode = SFM_READ,
|
|
|
|
int format = 0, int channels = 0, int samplerate = 0) ;
|
2010-01-25 20:55:02 +00:00
|
|
|
SndfileHandle (int fd, bool close_desc, int mode = SFM_READ,
|
|
|
|
int format = 0, int channels = 0, int samplerate = 0) ;
|
2012-09-25 11:16:34 +00:00
|
|
|
SndfileHandle (SF_VIRTUAL_IO &sfvirtual, void *user_data, int mode = SFM_READ,
|
|
|
|
int format = 0, int channels = 0, int samplerate = 0) ;
|
2011-01-27 09:49:30 +00:00
|
|
|
|
2021-02-18 08:09:16 +00:00
|
|
|
#ifdef _WIN32
|
|
|
|
SndfileHandle (const wchar_t *wpath, int mode = SFM_READ,
|
2011-01-27 09:49:30 +00:00
|
|
|
int format = 0, int channels = 0, int samplerate = 0) ;
|
|
|
|
#endif
|
|
|
|
|
2006-08-01 05:20:19 +00:00
|
|
|
~SndfileHandle (void) ;
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle (const SndfileHandle &orig) ;
|
|
|
|
SndfileHandle & operator = (const SndfileHandle &rhs) ;
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2006-08-01 05:20:19 +00:00
|
|
|
/* Mainly for debugging/testing. */
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
int refCount (void) const { return (p == NULL) ? 0 : p->ref ; }
|
2006-08-01 05:20:19 +00:00
|
|
|
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
operator bool () const { return (p != NULL) ; }
|
2006-08-01 05:20:19 +00:00
|
|
|
|
|
|
|
bool operator == (const SndfileHandle &rhs) const { return (p == rhs.p) ; }
|
2006-07-30 08:24:34 +00:00
|
|
|
|
2006-08-08 08:13:40 +00:00
|
|
|
sf_count_t frames (void) const { return p ? p->sfinfo.frames : 0 ; }
|
|
|
|
int format (void) const { return p ? p->sfinfo.format : 0 ; }
|
|
|
|
int channels (void) const { return p ? p->sfinfo.channels : 0 ; }
|
|
|
|
int samplerate (void) const { return p ? p->sfinfo.samplerate : 0 ; }
|
2006-07-30 08:24:34 +00:00
|
|
|
|
|
|
|
int error (void) const ;
|
|
|
|
const char * strError (void) const ;
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2006-07-27 10:38:35 +00:00
|
|
|
int command (int cmd, void *data, int datasize) ;
|
|
|
|
|
|
|
|
sf_count_t seek (sf_count_t frames, int whence) ;
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2006-08-01 05:20:19 +00:00
|
|
|
void writeSync (void) ;
|
|
|
|
|
2006-07-27 10:38:35 +00:00
|
|
|
int setString (int str_type, const char* str) ;
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2006-07-30 08:24:34 +00:00
|
|
|
const char* getString (int str_type) const ;
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2007-04-10 23:50:50 +00:00
|
|
|
static int formatCheck (int format, int channels, int samplerate) ;
|
|
|
|
|
2006-08-01 05:20:19 +00:00
|
|
|
sf_count_t read (short *ptr, sf_count_t items) ;
|
|
|
|
sf_count_t read (int *ptr, sf_count_t items) ;
|
|
|
|
sf_count_t read (float *ptr, sf_count_t items) ;
|
|
|
|
sf_count_t read (double *ptr, sf_count_t items) ;
|
|
|
|
|
|
|
|
sf_count_t write (const short *ptr, sf_count_t items) ;
|
|
|
|
sf_count_t write (const int *ptr, sf_count_t items) ;
|
|
|
|
sf_count_t write (const float *ptr, sf_count_t items) ;
|
|
|
|
sf_count_t write (const double *ptr, sf_count_t items) ;
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2006-08-01 05:20:19 +00:00
|
|
|
sf_count_t readf (short *ptr, sf_count_t frames) ;
|
|
|
|
sf_count_t readf (int *ptr, sf_count_t frames) ;
|
|
|
|
sf_count_t readf (float *ptr, sf_count_t frames) ;
|
|
|
|
sf_count_t readf (double *ptr, sf_count_t frames) ;
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2006-08-01 05:20:19 +00:00
|
|
|
sf_count_t writef (const short *ptr, sf_count_t frames) ;
|
|
|
|
sf_count_t writef (const int *ptr, sf_count_t frames) ;
|
|
|
|
sf_count_t writef (const float *ptr, sf_count_t frames) ;
|
|
|
|
sf_count_t writef (const double *ptr, sf_count_t frames) ;
|
|
|
|
|
|
|
|
sf_count_t readRaw (void *ptr, sf_count_t bytes) ;
|
|
|
|
sf_count_t writeRaw (const void *ptr, sf_count_t bytes) ;
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2010-12-01 08:42:54 +00:00
|
|
|
/**< Raw access to the handle. SndfileHandle keeps ownership. */
|
|
|
|
SNDFILE * rawHandle (void) ;
|
|
|
|
|
2012-06-11 16:48:13 +00:00
|
|
|
/**< Take ownership of handle, if reference count is 1. */
|
2010-12-01 08:42:54 +00:00
|
|
|
SNDFILE * takeOwnership (void) ;
|
2007-05-14 09:55:24 +00:00
|
|
|
} ;
|
|
|
|
|
2006-07-27 10:38:35 +00:00
|
|
|
/*==============================================================================
|
|
|
|
** Nothing but implementation below.
|
|
|
|
*/
|
2006-06-05 11:54:03 +00:00
|
|
|
|
2006-07-27 10:38:35 +00:00
|
|
|
inline
|
2006-08-08 08:13:40 +00:00
|
|
|
SndfileHandle::SNDFILE_ref::SNDFILE_ref (void)
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
: sf (NULL), sfinfo (), ref (1)
|
2006-08-01 05:20:19 +00:00
|
|
|
{}
|
|
|
|
|
|
|
|
inline
|
|
|
|
SndfileHandle::SNDFILE_ref::~SNDFILE_ref (void)
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
{ if (sf != NULL) sf_close (sf) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::SndfileHandle (const char *path, int mode, int fmt, int chans, int srate)
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
: p (NULL)
|
2006-08-08 08:13:40 +00:00
|
|
|
{
|
|
|
|
p = new (std::nothrow) SNDFILE_ref () ;
|
|
|
|
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
if (p != NULL)
|
2006-08-08 08:13:40 +00:00
|
|
|
{ p->ref = 1 ;
|
|
|
|
|
|
|
|
p->sfinfo.frames = 0 ;
|
|
|
|
p->sfinfo.channels = chans ;
|
|
|
|
p->sfinfo.format = fmt ;
|
|
|
|
p->sfinfo.samplerate = srate ;
|
|
|
|
p->sfinfo.sections = 0 ;
|
|
|
|
p->sfinfo.seekable = 0 ;
|
|
|
|
|
2007-06-14 09:07:34 +00:00
|
|
|
p->sf = sf_open (path, mode, &p->sfinfo) ;
|
2006-08-08 08:13:40 +00:00
|
|
|
} ;
|
2007-06-14 09:07:34 +00:00
|
|
|
|
|
|
|
return ;
|
2006-10-04 22:51:31 +00:00
|
|
|
} /* SndfileHandle const char * constructor */
|
|
|
|
|
|
|
|
inline
|
|
|
|
SndfileHandle::SndfileHandle (std::string const & path, int mode, int fmt, int chans, int srate)
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
: p (NULL)
|
2006-10-04 22:51:31 +00:00
|
|
|
{
|
|
|
|
p = new (std::nothrow) SNDFILE_ref () ;
|
|
|
|
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
if (p != NULL)
|
2006-10-04 22:51:31 +00:00
|
|
|
{ p->ref = 1 ;
|
|
|
|
|
|
|
|
p->sfinfo.frames = 0 ;
|
|
|
|
p->sfinfo.channels = chans ;
|
|
|
|
p->sfinfo.format = fmt ;
|
|
|
|
p->sfinfo.samplerate = srate ;
|
|
|
|
p->sfinfo.sections = 0 ;
|
|
|
|
p->sfinfo.seekable = 0 ;
|
|
|
|
|
2007-06-14 09:07:34 +00:00
|
|
|
p->sf = sf_open (path.c_str (), mode, &p->sfinfo) ;
|
2006-10-04 22:51:31 +00:00
|
|
|
} ;
|
2007-06-14 09:07:34 +00:00
|
|
|
|
|
|
|
return ;
|
2006-10-04 22:51:31 +00:00
|
|
|
} /* SndfileHandle std::string constructor */
|
2006-08-01 05:20:19 +00:00
|
|
|
|
2010-10-08 07:43:25 +00:00
|
|
|
inline
|
2010-01-25 20:55:02 +00:00
|
|
|
SndfileHandle::SndfileHandle (int fd, bool close_desc, int mode, int fmt, int chans, int srate)
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
: p (NULL)
|
2010-01-25 20:55:02 +00:00
|
|
|
{
|
|
|
|
if (fd < 0)
|
|
|
|
return ;
|
|
|
|
|
|
|
|
p = new (std::nothrow) SNDFILE_ref () ;
|
|
|
|
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
if (p != NULL)
|
2010-01-25 20:55:02 +00:00
|
|
|
{ p->ref = 1 ;
|
|
|
|
|
|
|
|
p->sfinfo.frames = 0 ;
|
|
|
|
p->sfinfo.channels = chans ;
|
|
|
|
p->sfinfo.format = fmt ;
|
|
|
|
p->sfinfo.samplerate = srate ;
|
|
|
|
p->sfinfo.sections = 0 ;
|
|
|
|
p->sfinfo.seekable = 0 ;
|
|
|
|
|
|
|
|
p->sf = sf_open_fd (fd, mode, &p->sfinfo, close_desc) ;
|
|
|
|
} ;
|
|
|
|
|
|
|
|
return ;
|
|
|
|
} /* SndfileHandle fd constructor */
|
|
|
|
|
2012-09-25 11:16:34 +00:00
|
|
|
inline
|
|
|
|
SndfileHandle::SndfileHandle (SF_VIRTUAL_IO &sfvirtual, void *user_data, int mode, int fmt, int chans, int srate)
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
: p (NULL)
|
2012-09-25 11:16:34 +00:00
|
|
|
{
|
|
|
|
p = new (std::nothrow) SNDFILE_ref () ;
|
|
|
|
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
if (p != NULL)
|
2012-09-25 11:16:34 +00:00
|
|
|
{ p->ref = 1 ;
|
|
|
|
|
|
|
|
p->sfinfo.frames = 0 ;
|
|
|
|
p->sfinfo.channels = chans ;
|
|
|
|
p->sfinfo.format = fmt ;
|
|
|
|
p->sfinfo.samplerate = srate ;
|
|
|
|
p->sfinfo.sections = 0 ;
|
|
|
|
p->sfinfo.seekable = 0 ;
|
|
|
|
|
|
|
|
p->sf = sf_open_virtual (&sfvirtual, mode, &p->sfinfo, user_data) ;
|
|
|
|
} ;
|
|
|
|
|
|
|
|
return ;
|
|
|
|
} /* SndfileHandle std::string constructor */
|
|
|
|
|
2006-08-01 05:20:19 +00:00
|
|
|
inline
|
|
|
|
SndfileHandle::~SndfileHandle (void)
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
{ if (p != NULL && -- p->ref == 0)
|
2006-08-01 05:20:19 +00:00
|
|
|
delete p ;
|
|
|
|
} /* SndfileHandle destructor */
|
|
|
|
|
|
|
|
|
|
|
|
inline
|
|
|
|
SndfileHandle::SndfileHandle (const SndfileHandle &orig)
|
2006-08-08 08:13:40 +00:00
|
|
|
: p (orig.p)
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
{ if (p != NULL)
|
2020-08-21 06:13:16 +00:00
|
|
|
++ p->ref ;
|
2006-08-01 05:20:19 +00:00
|
|
|
} /* SndfileHandle copy constructor */
|
|
|
|
|
|
|
|
inline SndfileHandle &
|
|
|
|
SndfileHandle::operator = (const SndfileHandle &rhs)
|
|
|
|
{
|
|
|
|
if (&rhs == this)
|
|
|
|
return *this ;
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
if (p != NULL && -- p->ref == 0)
|
2006-08-01 05:20:19 +00:00
|
|
|
delete p ;
|
|
|
|
|
|
|
|
p = rhs.p ;
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
if (p != NULL)
|
2020-08-21 06:13:16 +00:00
|
|
|
++ p->ref ;
|
2006-08-01 05:20:19 +00:00
|
|
|
|
|
|
|
return *this ;
|
|
|
|
} /* SndfileHandle assignment operator */
|
2006-07-27 10:38:35 +00:00
|
|
|
|
2006-07-28 09:28:09 +00:00
|
|
|
inline int
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::error (void) const
|
|
|
|
{ return sf_error (p->sf) ; }
|
2006-07-28 09:28:09 +00:00
|
|
|
|
|
|
|
inline const char *
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::strError (void) const
|
|
|
|
{ return sf_strerror (p->sf) ; }
|
2006-07-28 09:28:09 +00:00
|
|
|
|
|
|
|
inline int
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::command (int cmd, void *data, int datasize)
|
|
|
|
{ return sf_command (p->sf, cmd, data, datasize) ; }
|
2006-07-28 09:28:09 +00:00
|
|
|
|
2006-07-27 10:38:35 +00:00
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::seek (sf_count_t frame_count, int whence)
|
|
|
|
{ return sf_seek (p->sf, frame_count, whence) ; }
|
|
|
|
|
|
|
|
inline void
|
|
|
|
SndfileHandle::writeSync (void)
|
|
|
|
{ sf_write_sync (p->sf) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
2006-07-28 09:28:09 +00:00
|
|
|
inline int
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::setString (int str_type, const char* str)
|
|
|
|
{ return sf_set_string (p->sf, str_type, str) ; }
|
2006-07-28 09:28:09 +00:00
|
|
|
|
|
|
|
inline const char*
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::getString (int str_type) const
|
|
|
|
{ return sf_get_string (p->sf, str_type) ; }
|
2006-07-28 09:28:09 +00:00
|
|
|
|
2007-04-10 23:50:50 +00:00
|
|
|
inline int
|
2010-01-25 20:55:02 +00:00
|
|
|
SndfileHandle::formatCheck (int fmt, int chans, int srate)
|
2007-04-10 23:50:50 +00:00
|
|
|
{
|
|
|
|
SF_INFO sfinfo ;
|
|
|
|
|
|
|
|
sfinfo.frames = 0 ;
|
|
|
|
sfinfo.channels = chans ;
|
|
|
|
sfinfo.format = fmt ;
|
|
|
|
sfinfo.samplerate = srate ;
|
|
|
|
sfinfo.sections = 0 ;
|
|
|
|
sfinfo.seekable = 0 ;
|
|
|
|
|
|
|
|
return sf_format_check (&sfinfo) ;
|
|
|
|
}
|
2006-07-28 09:28:09 +00:00
|
|
|
|
2006-07-27 10:38:35 +00:00
|
|
|
/*---------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::read (short *ptr, sf_count_t items)
|
|
|
|
{ return sf_read_short (p->sf, ptr, items) ; }
|
|
|
|
|
|
|
|
inline sf_count_t
|
|
|
|
SndfileHandle::read (int *ptr, sf_count_t items)
|
|
|
|
{ return sf_read_int (p->sf, ptr, items) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::read (float *ptr, sf_count_t items)
|
|
|
|
{ return sf_read_float (p->sf, ptr, items) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::read (double *ptr, sf_count_t items)
|
|
|
|
{ return sf_read_double (p->sf, ptr, items) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::write (const short *ptr, sf_count_t items)
|
|
|
|
{ return sf_write_short (p->sf, ptr, items) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::write (const int *ptr, sf_count_t items)
|
|
|
|
{ return sf_write_int (p->sf, ptr, items) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::write (const float *ptr, sf_count_t items)
|
|
|
|
{ return sf_write_float (p->sf, ptr, items) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::write (const double *ptr, sf_count_t items)
|
|
|
|
{ return sf_write_double (p->sf, ptr, items) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::readf (short *ptr, sf_count_t frame_count)
|
|
|
|
{ return sf_readf_short (p->sf, ptr, frame_count) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::readf (int *ptr, sf_count_t frame_count)
|
|
|
|
{ return sf_readf_int (p->sf, ptr, frame_count) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::readf (float *ptr, sf_count_t frame_count)
|
|
|
|
{ return sf_readf_float (p->sf, ptr, frame_count) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::readf (double *ptr, sf_count_t frame_count)
|
|
|
|
{ return sf_readf_double (p->sf, ptr, frame_count) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::writef (const short *ptr, sf_count_t frame_count)
|
|
|
|
{ return sf_writef_short (p->sf, ptr, frame_count) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::writef (const int *ptr, sf_count_t frame_count)
|
|
|
|
{ return sf_writef_int (p->sf, ptr, frame_count) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::writef (const float *ptr, sf_count_t frame_count)
|
|
|
|
{ return sf_writef_float (p->sf, ptr, frame_count) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::writef (const double *ptr, sf_count_t frame_count)
|
|
|
|
{ return sf_writef_double (p->sf, ptr, frame_count) ; }
|
2006-07-27 10:38:35 +00:00
|
|
|
|
|
|
|
inline sf_count_t
|
2006-08-01 05:20:19 +00:00
|
|
|
SndfileHandle::readRaw (void *ptr, sf_count_t bytes)
|
|
|
|
{ return sf_read_raw (p->sf, ptr, bytes) ; }
|
|
|
|
|
|
|
|
inline sf_count_t
|
|
|
|
SndfileHandle::writeRaw (const void *ptr, sf_count_t bytes)
|
|
|
|
{ return sf_write_raw (p->sf, ptr, bytes) ; }
|
|
|
|
|
2010-12-01 08:42:54 +00:00
|
|
|
inline SNDFILE *
|
|
|
|
SndfileHandle::rawHandle (void)
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
{ return (p ? p->sf : NULL) ; }
|
2010-12-01 08:42:54 +00:00
|
|
|
|
|
|
|
inline SNDFILE *
|
|
|
|
SndfileHandle::takeOwnership (void)
|
|
|
|
{
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
if (p == NULL || (p->ref != 1))
|
|
|
|
return NULL ;
|
2010-12-01 08:42:54 +00:00
|
|
|
|
|
|
|
SNDFILE * sf = p->sf ;
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
p->sf = NULL ;
|
2010-12-01 08:42:54 +00:00
|
|
|
delete p ;
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
p = NULL ;
|
2010-12-01 08:42:54 +00:00
|
|
|
return sf ;
|
|
|
|
}
|
2007-05-14 09:55:24 +00:00
|
|
|
|
2021-02-18 08:09:16 +00:00
|
|
|
#ifdef _WIN32
|
2009-09-28 08:48:46 +00:00
|
|
|
|
|
|
|
inline
|
2021-02-18 08:09:16 +00:00
|
|
|
SndfileHandle::SndfileHandle (const wchar_t *wpath, int mode, int fmt, int chans, int srate)
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
: p (NULL)
|
2009-09-28 08:48:46 +00:00
|
|
|
{
|
|
|
|
p = new (std::nothrow) SNDFILE_ref () ;
|
|
|
|
|
Revert "Fix zero-as-null-pointer-constant-warning"
This reverts commit 2269af84173c1f70b6d700fa167e1e8ea01d7247.
The code which defined nullptr mysteriously broke the Windows build for
SuperCollider. After some investigation I discovered this commit to be the
cause, as MSVC by default does not set __cplusplus to anything greater
than 199711L unless explicitly asked to.
In general, #defining a keyword like nullptr in a library header is not
courteous, as it can affect compilation of later code and cause
significant confusion. This was exactly the situation I encountered, and
it took several days to track down the source.
The stated reason for the commit reverted by this was to prevent a
specific warning from appearing during compilation. However, there are
a few less intrusive ways of accomplishing this. For example, by using
`#pragma`s offered by all major compilers which temporarily disable
warnings, or by including headers with `-isystem` or any similar
mechanism which disables warnings from "system" headers. For code which
is intended to support C++98 and newer standards, preventing all
compilers from emitting any warnings is a losing battle. It is easier
in my view for consuming code to handle this as it needs to.
There are several options here for resolving this. I could just fix my
project, but that would not prevent others from encountering the same
issue. I could try for a clever-er version of this using a macro not
named nullptr and an additional check for MSVC, but this seems to offer
diminishing returns considering how easily any warnings about NULL can
be silenced, and carries the risk of introducing new and unforeseen
problems. So, I have here simply reverted the commit so the code uses
NULL once again.
2021-02-28 11:27:08 +00:00
|
|
|
if (p != NULL)
|
2009-09-28 08:48:46 +00:00
|
|
|
{ p->ref = 1 ;
|
|
|
|
|
|
|
|
p->sfinfo.frames = 0 ;
|
|
|
|
p->sfinfo.channels = chans ;
|
|
|
|
p->sfinfo.format = fmt ;
|
|
|
|
p->sfinfo.samplerate = srate ;
|
|
|
|
p->sfinfo.sections = 0 ;
|
|
|
|
p->sfinfo.seekable = 0 ;
|
|
|
|
|
|
|
|
p->sf = sf_wchar_open (wpath, mode, &p->sfinfo) ;
|
|
|
|
} ;
|
|
|
|
|
|
|
|
return ;
|
|
|
|
} /* SndfileHandle const wchar_t * constructor */
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2007-05-14 09:55:24 +00:00
|
|
|
#endif /* SNDFILE_HH */
|
|
|
|
|