http://en.wikipedia.org/wiki/Global_Descriptor_Table
I see all this 32 bit code needs to be ported to 64 bit.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
On Mon, Mar 5, 2012 at 2:15 AM, Rich E wrote:
> It's a bit dated now, but loris is a good example; a sophisticated sound
> modeling library. Written in C++ with a procedural interface in C and a
> scripting interface in python:
>
> http://www.hakenaudio.com/Loris/#doc
Thanks for pointing to this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-03-03 18:12, Mathieu Bouchard wrote:
> Le 2012-02-27 à 10:34:00, IOhannes m zmoelnig a écrit :
>> On 2012-02-26 19:50, Mathieu Bouchard wrote:
>>> Or else just discontinuing the MSVC edition...
>>
>> no.
>
> Why do you need to keep a MSVC edit
It's a bit dated now, but loris is a good example; a sophisticated sound
modeling library. Written in C++ with a procedural interface in C and a
scripting interface in python:
http://www.hakenaudio.com/Loris/#doc
cheers,
Rich
On Fri, Mar 2, 2012 at 11:32 PM, katja wrote:
>
> Can anyone point m
For the last 10 years or so, it's been considered bad practice to use naked
pointers in C++. This is because of shared_ptr and friends, along with
stl. It's great; for example, I have a moderately sized C++ project I'm
working on at the moment that has absolutely no explicit delete's -
everything
On Sat, Mar 3, 2012 at 3:47 AM, Hans-Christoph Steiner wrote:
>
> The C++ ABI compatibility problems are not the only thing that make C++
> hard to deploy. On limited platforms like Android, they include limited
> C++ support, like no exceptions and other stuff. Its still possible to
> write por
Le 2012-03-04 à 03:10:00, Billy Stiltner a écrit :
What we need is flat address space without the overhead of GDS segment
sorcery.
What's GDS ? Is that a Windows-only thing ?
It's pretty bad to be able to delete a list of a list of pointers to
objects that deletes itself before it deletes i
You guys made me remember why I don't like compiler options. Thanks! haha.
asm to me is like programming in c++. but inline assembly in either c or
c++ is not. What we need is flat address space without the overhead of GDS
segment sorcery. It's pretty bad to be able to delete a list of a list of
p
On Sat, Mar 3, 2012 at 6:40 PM, Mathieu Bouchard wrote:
> Le 2012-03-03 à 10:32:00, katja a écrit :
> If a function is only called from a single location and the function is
> hidden, then the original function may disappear and become embedded into
> the wrapper.
Now I'm getting the picture. T
Le 2012-03-03 à 10:32:00, katja a écrit :
I fail to see how those C wrappers could be inlined. Wouldn't that undo
their raison d'être (replacing a C++ call with a C call)? But indeed
function call overhead is small when compared to number-crunching, if
these calls are done per block and not pe
Le 2012-03-02 à 13:32:00, katja a écrit :
How about function call overhead? For constructor and destructor no
problem of course, but accessor wrappers will be called often, in fact
it doubles the number of function calls for external access.
Constant calls are possibly a lot quicker than vari
Le 2012-02-27 à 10:34:00, IOhannes m zmoelnig a écrit :
On 2012-02-26 19:50, Mathieu Bouchard wrote:
Or else just discontinuing the MSVC edition...
no.
Why do you need to keep a MSVC edition, again ? You probably told me
already, but I don't remember.
Are there libraries that people use w
On Sat, Mar 3, 2012 at 12:57 AM, Thomas Grill wrote:
>>
>>
>> How about function call overhead? For constructor and destructor no
>> problem of course, but accessor wrappers will be called often, in fact
>> it doubles the number of function calls for external access.
>>
>
> I would not worry about
I think we should rewrite it i Assembly Language
OOP makes much sense in Assembly.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>
>
> How about function call overhead? For constructor and destructor no
> problem of course, but accessor wrappers will be called often, in fact
> it doubles the number of function calls for external access.
>
I would not worry about that too much. The potential number-crunching happening
in
On Mar 2, 2012, at 4:32 AM, katja wrote:
> On Wed, Feb 29, 2012 at 9:17 PM, Thomas Grill wrote:
>>
>> Hi Katja,
>> maybe i'm chiming in too late, but i would definitely use C++ programming for
>> whatever i do in the C-world.
>> It's no problem to make the public API (exported functions) C-styl
On Wed, Feb 29, 2012 at 9:17 PM, Thomas Grill wrote:
>
> Hi Katja,
> maybe i'm chiming in too late, but i would definitely use C++ programming for
> whatever i do in the C-world.
> It's no problem to make the public API (exported functions) C-style then to
> avoid
> various hassles.
> If your lib
Hi Katja,
maybe i'm chiming in too late, but i would definitely use C++ programming for
whatever i do in the C-world.
It's no problem to make the public API (exported functions) C-style then to
avoid various hassles.
If your library is just a wrapper it might not be worth to live in both worlds,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-02-26 19:50, Mathieu Bouchard wrote:
> Le 2012-02-22 à 08:42:00, IOhannes m zmoelnig a écrit :
>> On 2012-02-22 06:46, Mathieu Bouchard wrote:
>>> So, are you switching GEM away from MSVC, or are you going to make a C
>>> API so that GEM can ac
On Sun, Feb 26, 2012 at 01:15:33PM -0500, Mathieu Bouchard wrote:
> You don't need to spit out that kind of gratuitous nonsense.
Thanks. You take it from here, I'll put me feet up.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
Le 2012-02-22 à 08:42:00, IOhannes m zmoelnig a écrit :
On 2012-02-22 06:46, Mathieu Bouchard wrote:
So, are you switching GEM away from MSVC, or are you going to make a C
API so that GEM can actually collaborate with other Pd-based frameworks
that want to read its data on Windows ?
well, yes;
Le 2012-02-25 à 23:44:00, katja a écrit :
I do not use STL functionality, libstdc++ seems to be required for other
functions as well, and vanilla Pd can't load a C++ object without it.
If you really want to avoid libstdc++, I think that you can do something
like :
#include
static inline voi
Le 2012-02-25 à 09:55:00, Andy Farnell a écrit :
Shortcuts made because a language is compact and elegant only pay off
where you write millions of lines of code.
Who knows, maybe they don't pay off ever. :-P
You don't need to spit out that kind of gratuitous nonsense.
__
Le 2012-02-22 à 13:51:00, Jonathan Wilkes a écrit :
It looks old and unmaintained, and I doubt it supports the newest
version of Qt which has introduced the graphics view stuff
What's the graphics view stuff ?
If Qtcl works well, it could be a possible path for speeding up the GUI, by
replac
On Sun, Feb 26, 2012 at 11:49 AM, Jamie Bullock
wrote:
> I follow your work with interest, and this sounds like a promising new
> development. I think writing generic routines, e.g. in the form of a shared
> library that can then support bindings for various contexts is a good one
> since it e
On Sat, Feb 25, 2012 at 8:59 PM, Mathieu Bouchard wrote:
>> A collection of useful routines which may be used individually, or
>> combined as integrated analysis-engine, in the context of a framework like
>> Pd, MaxMsp, SuperCollider.
>
>
> Can you be more specific about what this will be ?
It's
Le 2012-02-25 à 01:58:00, katja a écrit :
I'll do it the hard way, plain C. I've rewritten one of my own C++
library classes into C by way of exercise and comparison. It does
exactly the same thing at the same speed, with not so sweet-looking
code. This doesn't cover all the C/C++ differences,
Le 2012-02-22 à 15:30:00, katja a écrit :
Pd classes can be done in C very well, if procedures are not too
complicated and not meant to be used in other contexts.
In my practice, C is not high-level enough. So, for coding my own C++
externals, I use C++ together with a custom preprocessor whi
On Sat, Feb 25, 2012 at 01:58:14AM +0100, katja wrote:
> In my (not so huge) coding experience, I've always noticed that code
> typing is the least time consuming aspect of a dsp project. To figure
> out a good concept takes longer. Testing and bug fixing takes longer.
> Optimization takes longer.
Hi all,
Thanks for this very informative discussion. As I had the initial
question 'C++ or C', I wanted to let you know that I've made up my
mind: I'll do it the hard way, plain C. I've rewritten one of my own
C++ library classes into C by way of exercise and comparison. It does
exactly the same t
Le 2012-02-22 à 20:47:00, Krnk Ktz a écrit :
Sorry, I'm no professional programmer (I don't think i'm even good at
it!) but it seems like you are describing a Turing Machine, which
includes every programming language.
Well... no. I'm talking about Imperative languages, which is a very broad
On Wed, Feb 22, 2012 at 7:21 PM, august wrote:
> Yes, I even wrote an interface file for libpd so you can use libpd to load and
> control pd patches from within vala.
>
> It is part of a larger experimental project I've been working on and have
> meant
> to post here. It's called the Underweb.
- Original Message -
> From: Mathieu Bouchard
> To: Jonathan Wilkes
> Cc: Hans-Christoph Steiner ; "pd-list@iem.at"
> ; IOhannes m zmoelnig
> Sent: Wednesday, February 22, 2012 2:03 PM
> Subject: Re: [PD] C++ for reusable dsp lib - or better use C?
&
>> I
>> don't consider C++/Java to be in a different paradigm than C, because
they all use
>> the concept of storage that gets read and written along a timeline of
programme
>> steps that have to be run one after the other in the order specified by
the
>> programmer.
Sorry, I'm no professional pro
Le 2012-02-22 à 09:05:00, Jonathan Wilkes a écrit :
That's great news.
Would you mind giving me the link to the stable, actively maintained
library that makes Qt available for Tcl? I look forward to testing it
out.
I'm not responsible for every project or category of projects that I
menti
Le 2012-02-22 à 07:58:00, Krnk Ktz a écrit :
You could also consider not to use OOP. It has become very fashionable
because of Java and C++, but there other paradigms working very well.
OOP is not a matter of fashion. There's a fashion aspect about it, but
that shouldn't prevent you from seei
Le 2012-02-22 à 19:25:00, august a écrit :
The GObject method is pretty clever. It allows you to abstract objects
in an XML format. Then, based on those abstractions, you can introspect
them for their behaviour and link them into almost any language.
I wonder how difficult it would be to do
>
> >It's an OOP language ( looks like C#) that compiles down to OOP C.
>
> BTW, early C++ compilers also used to compile to C, but that feature
> was «removed» long ago. Nearly none of the well-known compilers have
> ever implemented it. I think that C++ was mostly compiled this way
> from 1979
> > Hi Katja,
> >
> > You might want to have a look at a language called Vala:
> >
> > https://live.gnome.org/Vala
>
>
> Thanks for the link, August. Do you happen to use Vala yourself? I'll
> definitely take a deeper look into it.
Yes, I even wrote an interface file for libpd so you can
- Original Message -
> From: Mathieu Bouchard
> To: Hans-Christoph Steiner
> Cc: pd-list@iem.at; IOhannes m zmoelnig
> Sent: Wednesday, February 22, 2012 11:44 AM
> Subject: Re: [PD] C++ for reusable dsp lib - or better use C?
>
> Le 2012-02-22 à 09:37:00, Han
Le 2012-02-22 à 13:59:00, august a écrit :
It's an OOP language ( looks like C#) that compiles down to OOP C.
BTW, early C++ compilers also used to compile to C, but that feature was
«removed» long ago. Nearly none of the well-known compilers have ever
implemented it. I think that C++ was m
Le 2012-02-22 à 09:37:00, Hans-Christoph Steiner a écrit :
STL, Qt, and Boost are all only used in C++.
Qt is also available for Ada, C#, D, Haskell, Harbour, Java, Lisp, Lua,
Pascal, Perl, PHP, Python, QML, R, Ruby, Scheme, ... and even Tcl.
See http://en.wikipedia.org/wiki/Qt_%28framework
On Wed, Feb 22, 2012 at 1:59 PM, august wrote:
> Hi Katja,
>
> You might want to have a look at a language called Vala:
>
> https://live.gnome.org/Vala
Thanks for the link, August. Do you happen to use Vala yourself? I'll
definitely take a deeper look into it.
Katja
___
On Feb 22, 2012, at 12:42 AM, Mathieu Bouchard wrote:
> Le 2012-02-21 à 11:12:00, Hans-Christoph Steiner a écrit :
>
>> If you look at all the fundamental libraries that are ported and used
>> everywhere, they are written in C. freetype, ffmpeg, iconv, libjpeg,
>> libpng, zlib, bzip2, sqlite,
These questions, distilled from the discussion, reflect my dilemma:
'Why use C for object oriented programming if you have C++?'
'Why use object oriented programming at all, if you have C?'
Pd classes can be done in C very well, if procedures are not too
complicated and not meant to be used in
> But indeed, C++ ABI complexities make it harder to get a C++ lib
> working always and everywhere. I've come across the MSVC/GNU
> incompatibility, but didn't know about the GNU version conflicts
> mentioned by Mathieu.
Hi Katja,
You might want to have a look at a language called Vala:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-02-22 06:46, Mathieu Bouchard wrote:
>
> So, are you switching GEM away from MSVC, or are you going to make a C
> API so that GEM can actually collaborate with other Pd-based frameworks
> that want to read its data on Windows ?
well, yes; i'd
(To throw in a different take). I definitely like C++ more for ease of
interface. Templated math functions and overloaded operators are just too
nice, the code looks so much better (at a user level).
There are also plenty of audio languages written in C++ - SuperCollider,
ZenGarden (which is coin
I started reading Axel-Tobias Schreiner's 'Object-Oriented Programming
> with ANSI-C', found via Marvin's link. The title made me enthusiastic
> for a moment. I like C. But for OOP? It's a lot of dull
> administration.
>
>
You could also consider not to use OOP. It has become very fashionable
beca
Le 2012-02-21 à 17:00:00, IOhannes m zmoelnig a écrit :
one problem with C++ is that name-mangling is different depending on
which compiler/linker you are using. this basically means, that you
cannot use your C++-library binary made with g++ in an application/...
build with e.g. M$VC. note tha
Le 2012-02-21 à 11:12:00, Hans-Christoph Steiner a écrit :
If you look at all the fundamental libraries that are ported and used
everywhere, they are written in C. freetype, ffmpeg, iconv, libjpeg,
libpng, zlib, bzip2, sqlite, libquicktime, gmerlin, etc. And of
course... Pd :-)
STL is used
Le 2012-02-22 à 02:12:00, katja a écrit :
I was considering C++ just for programming comfort. I know that
everything can be done in C but it is so clumsy for making class-like
things. If Pd would be conceived today, would it be written in C?
I can't imagine Miller writing it in C++...
But ev
Hello Mathieu, IOhannes, Hans, Marvin,
Thanks for all your informed answers.
I was considering C++ just for programming comfort. I know that
everything can be done in C but it is so clumsy for making class-like
things. If Pd would be conceived today, would it be written in C?
But indeed, C++ ABI
On Tue, Feb 21, 2012 at 10:59:59AM -0500, Mathieu Bouchard wrote:
> ABI compatibility is still an issue with C++.
In addition to name mangling, calling convention and other issues accross
compilers, C++ presents problems with ABI incompatibility even when using the
same compiler. If your library
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Feb 21, 2012, at 11:00 AM, IOhannes m zmoelnig wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2012-02-21 16:36, katja wrote:
>> Hello,
>>
>> I'd like to know opinions from experienced developers about the use of
>> C versus C+
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-02-21 16:36, katja wrote:
> Hello,
>
> I'd like to know opinions from experienced developers about the use of
> C versus C++ for dsp libs.
>
> I'm planning to write a compact library with audio analysis functions,
> to be used with Pd in the
Le 2012-02-21 à 16:36:00, katja a écrit :
Quite some dsp libs are written in C, even today.
It's inertia. It's a bit like how FORTRAN and COBOL and BASIC are still
used today, except that C has had such a tremendous influence, that most
of its potential replacements also look a lot like C.
Hello,
I'd like to know opinions from experienced developers about the use of
C versus C++ for dsp libs.
I'm planning to write a compact library with audio analysis functions,
to be used with Pd in the first place, but meant to be portable to
other real time dsp frameworks. This project will cont
58 matches
Mail list logo
