[gmpi] Re: low level API
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 4 Feb 2005 10:17:09 -0800
On Fri, Feb 04, 2005 at 01:10:33PM -0500, Ron Kuper wrote:
> Macros often make debugging very difficult. A one-liner to simplify
> some gnarly bit of bit-shifting is acceptable in my book, but
> multi-liners or macros that translate into elaborate declarations are
> bad news.
I agree. If a macro is performing multiple steps, or needs local
variables, or returns a value, there is often some other problem.
> Inlines are cool. The main interface is still C compatible, and I
> assume whatever we implement in the guts will be C++.
?
How dic C++ get in there? I was askign about inlines as an alternative
to macros. That is:
#define SOME_MACRO(x) do {
foo(x);
bar(x*1234);
} while (0)
can become
static inline void some_macro(int x)
{
foo(x);
bar(x*1234);
}
And gain us type safety. IFF all compilers can support that.
> -----Original Message-----
> From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On
> Behalf Of Tim Hockin
> Sent: Friday, February 04, 2005 1:01 PM
> To: gmpi@xxxxxxxxxxxxx
> Subject: [gmpi] Re: low level API
>
> On Fri, Feb 04, 2005 at 11:41:15AM -0500, gogins@xxxxxxxxxxxx wrote:
> > Of course that would work too.
> >
> > As for macros, they should be avoided. Period! As long as we're
> expressing
> > our personal preferences....
> >
> > No macros, no invisible namespace collisions, no undebuggable code, no
> > invisible side effects, no mysteries. Worst thing about C and C++,
> macros.
>
> oh man, I totoally DISagree. Macros, when used right, save so much
> headache. The key is WHEN USED RIGHT.
>
> That said, can we count on support for inline functions? Probably not.
> Inlines are better than macros in almost every case, except this case,
> which is a literal text insertion.
>
> > Original Message:
> > -----------------
> > From: Tim Hockin thockin@xxxxxxxxxx
> > Date: Fri, 4 Feb 2005 08:15:19 -0800
> > To: gmpi@xxxxxxxxxxxxx
> > Subject: [gmpi] Re: low level API
> >
> >
> > On Fri, Feb 04, 2005 at 10:11:18AM -0500, gogins@xxxxxxxxxxxx wrote:
> > > To declare a new interface deriving from IUnknown in C, copy the
> > > IUnknownVirtualFunctionTable declaration, rename it, and add new
> > > function
> >
> > Why copy it? Why not just put a struct IUnknown at the head of the
> > "subclass". You can then cast to IUnknown safely. Or why not make an
> > INHERIT_IUNKNOWN macro that pastes that signature in, thus avoiding
> > copy-paste errors?
> >
> > This is where C falls down. If we could peek inside a member struct,
> > life
> > would be better. E.g.:
> >
> > struct parentclass {
> > a
> > b
> > }
> > struct subclass {
> > struct parentclass; /* anonymous */
> > foo
> > bar
> > }
> >
> > in this case, subclass->a should work. But C is dumb.
> >
> >
> > ----------------------------------------------------------------------
> > Generalized Music Plugin Interface (GMPI) public discussion list
> > Participation in this list is contingent upon your abiding by the
> > following rules: Please stay on topic. You are responsible for your
> own
> > words. Please respect your fellow subscribers. Please do not
> > redistribute anyone else's words without their permission.
> >
> > Archive: //www.freelists.org/archives/gmpi
> > Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to
> unsubscribe
> >
> >
> > --------------------------------------------------------------------
> > mail2web - Check your email from the web at
> > http://mail2web.com/ .
> >
> >
> >
> > ----------------------------------------------------------------------
> > Generalized Music Plugin Interface (GMPI) public discussion list
> > Participation in this list is contingent upon your abiding by the
> > following rules: Please stay on topic. You are responsible for your
> own
> > words. Please respect your fellow subscribers. Please do not
> > redistribute anyone else's words without their permission.
> >
> > Archive: //www.freelists.org/archives/gmpi
> > Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to
> unsubscribe
> >
>
> ----------------------------------------------------------------------
> Generalized Music Plugin Interface (GMPI) public discussion list
> Participation in this list is contingent upon your abiding by the
> following rules: Please stay on topic. You are responsible for your
> own
> words. Please respect your fellow subscribers. Please do not
> redistribute anyone else's words without their permission.
>
> Archive: //www.freelists.org/archives/gmpi
> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
>
>
> ----------------------------------------------------------------------
> Generalized Music Plugin Interface (GMPI) public discussion list
> Participation in this list is contingent upon your abiding by the
> following rules: Please stay on topic. You are responsible for your own
> words. Please respect your fellow subscribers. Please do not
> redistribute anyone else's words without their permission.
>
> Archive: //www.freelists.org/archives/gmpi
> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
>
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
