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 contain several routines which must share one interface to Pd, and C++ will be most convenient for it. I've used C and C++ for Pd classes before, and both seem to work properly and efficient. But I lack experience to know on beforehand if there is some disadvantage of using C++ for a reusable dsp library. This will be my first. Quite some dsp libs are written in C, even today. Is there good reason to refrain from C++'s conveniences for writing classes, and use C instead?
Katja
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.
Is there good reason to refrain from C++'s conveniences for writing classes, and use C instead?
The big problem I'm aware of, is that GEM binaries for Windows ship as MSVC binaries instead of GCC4 binaries, and that prevents any GCC4 binaries from interacting with its C++ functions.
ABI compatibility is still an issue with C++. GCC has had at least three different ABI versions, but they haven't changed it in years. I'm not counting the libstdc++ version conflicts in shared libraries that contain a static libstdc++, which causes a crash at startup (maybe you can avoid it by disabling try/catch, but at this point, I'm using that feature).
If I could figure out how to call MSVC C++ functions from GCC4 modules, I'd probably find out that using throw/catch will crash or do something weird that doesn't work. Both ABI standards are variants of the same CDECL ABI (that is, non-PASCAL), but they differ in how they encode class names, arg types, namespaces, within symbols... and how try/catch works.
But when going through Pd's API, everything talking to Pd will be able to talk to anything else talking to Pd. It's just an issue when you have to avoid Pd in order to get access to external-specific data types such as GEM's pixes, PDP's packets and GF's grids, and this usually involves calling functions. In the case of PDP, it's all fine because it's all in C, but both GEM and GF are written in C++ and have a C++ API.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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 is designed with user-extensible classes, choosing C++ places severe constraints upon core development -- no new virtual methods or member variables in non-leaf classes, etc:
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
The comment thread here may be germane (it describes some of the reasons we avoided C++ for Apache Lucy):
https://issues.apache.org/jira/browse/LUCY-5
Marvin Humphrey
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 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.
So, the comfort of C++ programming and the time saved during development may be outweighed by troubles in deployment? I have to think twice... My lib should easily build and run wherever Pd runs.
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.
Fortunately I've time to reflect a bit more on the options, this lib need not be written today or tomorrow. Thanks again for all the advice.
Katja
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 even though I'd like Pd to be written in C++, I'm conscious of its limitations about dynamic OOP. For example, you can't define methods at runtime, find methods by string, etc., which is bad for making a language like Pd.
So, the comfort of C++ programming and the time saved during development may be outweighed by troubles in deployment? I have to think twice... My lib should easily build and run wherever Pd runs.
I'm not saying that, but it is annoying.
It's also possible to use a lot of C++ features while still using plain CDECL interfaces for external linkage (extern "C"). Plain Pd externals are even simpler : they only need to export one function to the linkers, and they do the rest of the linking by calling class_addmethod and such.
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.
OOP has been done many times in C. There are many examples of it, most notably Xt (the common portion between Athena, XView/OpenLook, Motif/CDE, the old widget toolkits) ; but even more notably, Glib/Gtk/GNOME.
It's good to read a book like that if you wanted to rewrite Pd in C++ (I don't know that book, I mean only this topic). This is because even if you use C++, you'll probably have to cook your own OOP features at one point or another. Even though C++ includes tonnes of features and very intricate details, it still leaves a lot of interesting topics untouched. C++ is really meant for compile-only use, and anything that looks like an interpreted language (such as Pd) is unimplemented.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
(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 coincidentally a rewrite of pd-core in C++), and Faust are the first three that come to mind. For graphics, there is both openFrameworks and Cinder, which each use very different features of the language.
In the end, I think you should use the language with the features you wish to use. While you could build an OO language on top of C, it is essentially a procedural language, so why bother when that is what C++ is for?
- rich
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 because of Java and C++, but there other paradigms working very well. C has been working for decades; why would you want to use it in a way it has not been conceived for?
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 seeing the core principles of it. OOP is not necessarily a paradigm either : its core concepts can be ported from «paradigm» to «paradigm» to create more new «paradigms». It has already gone well beyond imperative languages. 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.
C has been working for decades; why would you want to use it in a way it has not been conceived for?
Every programming language worth being calling that way is conceived to be used in ways it has not be conceived for.
There's also a big difference between what something is made for, and what it's good for.
Note that C is extremely often used for constructing interpreters for languages that are especially good at things that C isn't good at.
The activity of programming doesn't fit in narrow boxes of Paradigms and of Intended Purposes.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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 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. Every languages builds to ASM (or is interpreted by some interpreter built to ASM) and therefore use a storage modified over the course of the time in a specific order. What matters is how you organise your code, how you think your program. In the end, it will actually be the same - both C and C++ build to ASM. However, C++ forces you to think of objects while C doesn't: that's another way of thinking and therefore another paradigm.
Every programming language worth being calling that way is conceived to be used in ways it has not be conceived for.
Well, you can write purely functionnal programs in C, but good luck with that. You can, but I don't think this is what you want to do.
Note that C is extremely often used for constructing interpreters for
languages that >>are especially good at things that C isn't good at.
But you construct an interpreter for a new language instead of using C the way you would use this new language. That's how I have always seen languages: they try to help you to write programs like you think them. Every language brings you new ways of thinking programs. It seems also illogical to me to try thinking in a way which is not the one your tool does.
Again, I am probably wrong - I just would like to understand why.
Thanks!
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 category of languages that includes almost all languages in common use. That category includes executables, ASM, C, C++, Perl/Python/Ruby/Lua, Tcl, shell scripts, Java/C#, and even PureData.
Turing Machines are also in Imperative languages, but nearly all other Imperative languages are based on the idea of Von Neumann machine instead (in which the tape memory is replaced by the concept of RAM). This idea is refined differently by each language to structure the manner in which RAM is used and thought of. Almost no languages are based directly on the idea of Turing Machine.
Turing Equivalence doesn't mean every programming language is a Turing Machine, it means that every sufficiently complete programming language is able to express the same computations as every other sufficiently complete programming language. It doesn't say how fast it can possibly run, nor how short the programme is, nor how hard it was to write it. Turing-completeness is really just concerned with whether it's possible to compute a given thing at all with a given language.
What matters is how you organise your code, how you think your program. In the end, it will actually be the same - both C and C++ build to ASM. However, C++ forces you to think of objects while C doesn't: that's another way of thinking and therefore another paradigm.
C++ does not actually force you to do anything with objects. It's designed for seamless transition from C (unlike Java, for example, which does enforce objects). Therefore you can compile C programmes almost as-is, with occasional search-and-replace for minor details.
C++ introductory books might teach you to do everything with objects and with <fstream> and teachers might forbid you from using printf() so that you use <fstream>, but that's all ideology. The compiler has little opinion about the shape of your programmes apart from whether it compiles and detecting some gotchas that are actual bugs. For mistakes that aren't clearly mistakes, the compiler will just let you learn.
That's how I have always seen languages: they try to help you to write programs like you think them. Every language brings you new ways of thinking programs. It seems also illogical to me to try thinking in a way which is not the one your tool does.
The language is quite bad at preventing you from thinking in different ways, and sometimes it's quite bad at preventing you from writing in different ways. Structuring programmes in an OOP way is sometimes simply the best way of writing a C programme using C techniques. There is no hard barrier between the two, hardly a paradigm shift at all. C++ was created as a preprocessor for writing code that would have otherwise been OOP in C already, for use by people who expanded on the concept of Structured Programming in the same manner that people nowadays expand on the concept of OOP.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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 thing at the same speed, with not so sweet-looking code. This doesn't cover all the C/C++ differences, but in the end, everything can be solved in C one way or another. I'll put up with the annoyance of writing C, to increase the chances of unproblematic compilation and linking.
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. I've once written an optimized FFT lib (in C). It took me a month if I remember well, and that was not because of all the code typing.
Katja
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. I've once written an optimized FFT lib (in C). It took me a month if I remember well, and that was not because of all the code typing.
+1
For me, learning the subject and making good design desisions, then learning languages are the biggest overheads, measured in years or decades. Then debugging, correcting mistakes, optimising, packaging... these are things that take days or weeks. Once an idea is set in motion, actual coding seems to happen in sprints of a few dozen hours, and is largely independent of the language.
Shortcuts made because a language is compact and elegant only pay off where you write millions of lines of code. Some might properly aruge that you make fewer mistakes with an elegant language, but there is much more to elegance than compactness. In fact elegance, in the eye of the beholder, is quite subjective. C++ is a beautifully rich language that is very concept heavy, a far more mature tool than I need to do most DSP tasks.
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. I've once written an optimized FFT lib (in C). It took me a month if I remember well, and that was not because of all the code typing.
I wish I could code an external like he's coding: http://vimeo.com/36579366
Le 2012-02-25 à 12:32:00, patrick a écrit :
I wish I could code an external like he's coding: http://vimeo.com/36579366
you're not mentioning which part of this extremely long video you are referring to, and this player does not allow skip-ahead, which means I can't fast-forward faster than the download speed of the whole thing. This is why I won't try to figure out what you mean.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On 2/25/12 11:43 AM, Mathieu Bouchard wrote:
Le 2012-02-25 à 12:32:00, patrick a écrit :
I wish I could code an external like he's coding: http://vimeo.com/36579366
you're not mentioning which part of this extremely long video you are referring to, and this player does not allow skip-ahead, which means I can't fast-forward faster than the download speed of the whole thing. This is why I won't try to figure out what you mean.
It's well worth watching, all the way through. It was a "eureka" moment for me -- I now see the potential of "live-coding."
Phil
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2012-02-25 à 13:14:00, Phil Stone a écrit :
It's well worth watching, all the way through. It was a "eureka" moment for me -- I now see the potential of "live-coding."
Ah ok, you mean that you didn't see the potential of live-coding by using PureData ?
But PureData isn't just about the potential of live-coding. It's also about doing it. Possibly even every time you use it.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On 2/25/12 1:20 PM, Mathieu Bouchard wrote:
Le 2012-02-25 à 13:14:00, Phil Stone a écrit :
It's well worth watching, all the way through. It was a "eureka" moment for me -- I now see the potential of "live-coding."
Ah ok, you mean that you didn't see the potential of live-coding by using PureData ?
But PureData isn't just about the potential of live-coding. It's also about doing it. Possibly even every time you use it.
IMO, Pd *approaches* this potential of live-coding, but isn't there yet. The edit/play dichotomy, and the probability of audio dropouts resulting from trying to use both modes simultaneously is a big obstacle to smooth live-coding.
I use Pd because it is the best compromise that I have found toward achieving this idea-implementation feedback loop for audio/music design. I still maintain a divide between my design phase and my performance phase, though; I'd love to see that divide fade away.
I also like programming in "word" languages, and a Supercollider-type language with this the one in this video's level of instantaneous, round-trip synchronization between code and product would be pretty great.
Phil
Le 2012-02-25 à 14:29:00, Phil Stone a écrit :
IMO, Pd *approaches* this potential of live-coding, but isn't there yet. The edit/play dichotomy,
The Edit/Play modes are there just to allow more different mouse commands. It's not really a feature of the engine, it's just for switching between two sets of mouse behaviours in the GUI, because there are not enough buttons.
I also like programming in "word" languages,
For what I presume you call a non-word language, Pd has quite a large vocabulary of words in it.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On 2/26/12 10:29 AM, Mathieu Bouchard wrote:
Le 2012-02-25 à 14:29:00, Phil Stone a écrit :
IMO, Pd *approaches* this potential of live-coding, but isn't there yet. The edit/play dichotomy,
The Edit/Play modes are there just to allow more different mouse commands. It's not really a feature of the engine, it's just for switching between two sets of mouse behaviours in the GUI, because there are not enough buttons.
That's a good point, but the other problem I mentioned -- audio dropouts during editing, especially if the dsp graph needs recompiling -- is still a deal breaker for live *performance* coding (unless one embraces the glitches). Now, if by 'live', one just means highly interactive, I'll grant Pd that. That's more what I'm concerned with anyway -- a rapid connection between idea and execution, not necessarily doing programming in front of an audience.
I also like programming in "word" languages,
For what I presume you call a non-word language, Pd has quite a large vocabulary of words in it.
I'm pretty sure you, and most readers of this list, understand the distinction I am making between graphics-dominated and text-dominated programming environments. Perhaps the scare quotes should be a tip that I'm not speaking in exactitudes at that moment. :-)
Don't think that your points about the liveness of Pd are lost on me, though. I've been thinking about it a great deal since watching that video yesterday, and realized the very interactiveness the guy in the video was bragging about is something we take for granted. Number boxes change values instantly! Wow!
I was excited, however, by the capability of changing underlying code by manipulating the product. Pd even nudges into that territory with its bastard son dynamic patching, but it's not particularly intuitive.
Phil
Le 2012-02-26 à 10:53:00, Phil Stone a écrit :
On 2/26/12 10:29 AM, Mathieu Bouchard wrote:
Le 2012-02-25 à 14:29:00, Phil Stone a écrit :
I also like programming in "word" languages,
For what I presume you call a non-word language, Pd has quite a large vocabulary of words in it.
I'm pretty sure you, and most readers of this list, understand the distinction I am making between graphics-dominated and text-dominated programming environments. Perhaps the scare quotes should be a tip that I'm not speaking in exactitudes at that moment. :-)
I know, but I still think that it was worth mentioning, just like I'd doubt that Pd is that much graphics-dominated... I know the distinction you're trying to make, and the graphics part of Pd is what we notice the most, but there's an awful (or awesome) lot of text in there. It's nice like that, though. I wouldn't trade a language to get a bucketful of icons. More often than not, one word is worth a thousand pictures.
We won't be able to find what % of importance the graphics have in Pd in comparison to plain-text languages, but this time, I just want to point out that graphics in Pd look like they're dominating only because we're used to have text take nearly all the room.
I don't necessarily have good replacement adjectives to provide you with.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Phil Stone pkstone@ucdavis.edu To: Mathieu Bouchard matju@artengine.ca Cc: pd-list@iem.at Sent: Sunday, February 26, 2012 1:53 PM Subject: Re: [PD] OT - C++ for reusable dsp lib - or better use C?
On 2/26/12 10:29 AM, Mathieu Bouchard wrote:
Le 2012-02-25 à 14:29:00, Phil Stone a écrit :
IMO, Pd *approaches* this potential of live-coding, but isn't there
yet. The edit/play dichotomy,
The Edit/Play modes are there just to allow more different mouse commands.
It's not really a feature of the engine, it's just for switching between two sets of mouse behaviours in the GUI, because there are not enough buttons.
That's a good point, but the other problem I mentioned -- audio dropouts during editing, especially if the dsp graph needs recompiling
When does the recompiling actually happen? In pd-extended 0.43 If I start editing a patch with a subpatch that's already full of 700 or so [osc~] objects that are outputting to a bus, I can continue patching in the main canvas (with the subpatch unvis'd) and creating signal objects there, connect those signal objects to the [dac~] and ramp up and get no dropouts at all. I also don't get dropouts if I remove a signal object that was instantiated before all the signal objects in subpatch were instantiated, and rapidly redo/undo.
Is Pd recompiling the graph every time I create a new tilde object?
-Jonathan
On Feb 25, 2012, at 4:14 PM, Phil Stone wrote:
On 2/25/12 11:43 AM, Mathieu Bouchard wrote:
Le 2012-02-25 à 12:32:00, patrick a écrit :
I wish I could code an external like he's coding: http://vimeo.com/36579366
you're not mentioning which part of this extremely long video you are referring to, and this player does not allow skip-ahead, which means I can't fast-forward faster than the download speed of the whole thing. This is why I won't try to figure out what you mean.
It's well worth watching, all the way through. It was a "eureka" moment for me -- I now see the potential of "live-coding."
I agree that instant feedback is very important, that's a big reason why I use Pd. I wonder if he's ever used Pd. Pd has been providing a lot of that experience for almost 2 decades now. The one thing in it that Pd does not provide is the ability to click on the generated image in order to see which code is generating that part of the image. That would be a nice feature to have. But I can't see how you would generalize beyond drawing pictures. Drawing with code is basically the easiest realm to solve that particular problem, IMHO. How would you click on the sound to see the code that is generating it? How would you click on a mail program, a network service, file encryption?
The live table of variables is pretty typical for lots of debuggers like Java in Eclipse. That would be nice to have as an extended Magic Glass version: basically, tag cords and they would be listed in separate table view as you tag them. I think the tags could be little random colored shapes to mark the code and its place in the table.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
On 2/25/12 2:49 PM, Hans-Christoph Steiner wrote:
On Feb 25, 2012, at 4:14 PM, Phil Stone wrote:
On 2/25/12 11:43 AM, Mathieu Bouchard wrote:
Le 2012-02-25 à 12:32:00, patrick a écrit :
I wish I could code an external like he's coding: http://vimeo.com/36579366
you're not mentioning which part of this extremely long video you are referring to, and this player does not allow skip-ahead, which means I can't fast-forward faster than the download speed of the whole thing. This is why I won't try to figure out what you mean.
It's well worth watching, all the way through. It was a "eureka" moment for me -- I now see the potential of "live-coding."
I agree that instant feedback is very important, that's a big reason why I use Pd. I wonder if he's ever used Pd. Pd has been providing a lot of that experience for almost 2 decades now. The one thing in it that Pd does not provide is the ability to click on the generated image in order to see which code is generating that part of the image. That would be a nice feature to have. But I can't see how you would generalize beyond drawing pictures. Drawing with code is basically the easiest realm to solve that particular problem, IMHO. How would you click on the sound to see the code that is generating it? How would you click on a mail program, a network service, file encryption?
Visual representations of audio/music parameters are quite common (spectral plots, traditional and non-traditional notation, spatial controls, etc.). Having a two-way connection between graphical representations of audio/music and the underlying code would be quite useful and conducive to empirical experimentation.
Phil
On Feb 25, 2012, at 6:05 PM, Phil Stone wrote:
On 2/25/12 2:49 PM, Hans-Christoph Steiner wrote:
On Feb 25, 2012, at 4:14 PM, Phil Stone wrote:
On 2/25/12 11:43 AM, Mathieu Bouchard wrote:
Le 2012-02-25 à 12:32:00, patrick a écrit :
I wish I could code an external like he's coding: http://vimeo.com/36579366
you're not mentioning which part of this extremely long video you are referring to, and this player does not allow skip-ahead, which means I can't fast-forward faster than the download speed of the whole thing. This is why I won't try to figure out what you mean.
It's well worth watching, all the way through. It was a "eureka" moment for me -- I now see the potential of "live-coding."
I agree that instant feedback is very important, that's a big reason why I use Pd. I wonder if he's ever used Pd. Pd has been providing a lot of that experience for almost 2 decades now. The one thing in it that Pd does not provide is the ability to click on the generated image in order to see which code is generating that part of the image. That would be a nice feature to have. But I can't see how you would generalize beyond drawing pictures. Drawing with code is basically the easiest realm to solve that particular problem, IMHO. How would you click on the sound to see the code that is generating it? How would you click on a mail program, a network service, file encryption?
Visual representations of audio/music parameters are quite common (spectral plots, traditional and non-traditional notation, spatial controls, etc.). Having a two-way connection between graphical representations of audio/music and the underlying code would be quite useful and conducive to empirical experimentation.
Yeah, i agree, I guess I'm responding to the speaker's tone. Something about him rubs me the wrong way, it seems like he claims to invent all this stuff, then talks about Engelbart, Kay, Tesler as if they were people who invented all this stuff in isolation when in reality they all were working in large, collaborative labs.
He also seems to imply that the techniques he demos are easily applicable to everything. That's unfortunately not really true.
I like the idea that software work should be guided by principles, that is what guides a lot of the contributions to Pd development, I think. And he does a good job of explaining why rapid feedback loops are important.
.hc
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." --Bjarne Stroustrup (creator of C++)
Le 2012-02-25 à 17:49:00, Hans-Christoph Steiner a écrit :
I agree that instant feedback is very important, that's a big reason why I use Pd. I wonder if he's ever used Pd. Pd has been providing a lot of that experience for almost 2 decades now. The one thing in it that Pd does not provide is the ability to click on the generated image in order to see which code is generating that part of the image. That would be a nice feature to have. But I can't see how you would generalize beyond drawing pictures.
It can't even generalise to all images. There's an OpenGL feature whether if you get a mouse position, you can tell the OpenGL engine to find any geos that contain that (x,y) location while drawing the next frame. I forgot what the name is and I never used it.
But this can't possibly tell you anything about the construction of Gem pixes or GridFlow grids, in which solutions range from complicated to impossible, especially because a lot of objects modify all pixels in the image at once, but also because even for more localised edits of images, the objects currently don't track that info and it would take lots of work to make them do so... or create an image diff tool that would be very slow.
Most ~-objects also operate on the whole signal.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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, but in the end, everything can be solved in C one way or another.
It's not a strict matter of beauty of code. The reason why programmers talk so much about the beauty (or cleanliness) of the code, is because of the practical qualities. But the appreciation of beauty or cleanliness is something that evolves with time... depending on one's experience of what matters and what doesn't.
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. I've once written an optimized FFT lib (in C). It took me a month if I remember well, and that was not because of all the code typing.
If you have to write twice more characters to do the same thing in C as in C++, then you will have to read twice more characters when you want to review the code, debug the code, or just re-understand the code later. If you optimise your code or reorganise your code, then you will need to read twice more AND rewrite twice more. But that's not that much compared to the effect of having to think about cluttered sentences of code.
That's just an example. Some C is the same length as the C++ equivalent. Some other C is 3, 4 or 5 times longer than the C++ equivalent, sometimes worse.
As a conclusion, a famous quote :
« There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. »
— Antony HOARE (alias Mr. QuickSort)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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:
https://live.gnome.org/Vala
It's an OOP language ( looks like C#) that compiles down to OOP C. That way, it is ABI compliant with all other C libs. You can also create a C lib yourself from it.
It was written with GNOME's GObject in mind, so anything you write in Vala would depend on libglib and libgobject....which may or may not be what you want. However, if you are creating a DSP library, the larger set of utility features that libglib has to offer might come in handy.
best
-august.
On Wed, Feb 22, 2012 at 1:59 PM, august august@alien.mur.at wrote:
Hi Katja,
You might want to have a look at a language called Vala:
Thanks for the link, August. Do you happen to use Vala yourself? I'll definitely take a deeper look into it.
Katja
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 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. You can read about it here:
http://underweb.info/
Vala allows me to experiment much much faster than C or even C++. It has a lot of great features like anonymous and asynchronous functions. It also gives me use of all the fantastic free software libs written for GNOME, but are too hairy to use in C directly. Benchmarks even show that with -O3 optimization at the gcc compile stage, programs in Vala are faster than C++ in most areas.
Supposedly, there is even a way to compile it so that GLib and Gobject are not dependencies, but I haven't looked into that.
-august.
On Wed, Feb 22, 2012 at 7:21 PM, august august@alien.mur.at 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. You can read about it here:
An impressive project, August. Keeping the web open for all to actively use it, that is an important issue indeed.
About Vala, it isn't so platform independent, that's a pity. The docs are decent, there's frequent releases, these are good signs.
Katja
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 mostly compiled this way from 1979 until approx 1987, long before I ever heard of it, and before nearly anyone had heard of it.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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 until approx 1987, long before I ever heard of it, and before nearly anyone had heard of it.
That's too bad because it's a great feature to have.
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 something like that with PD's object system?
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 something like that with PD's object system?
You can already inspect several aspects of Pd objects and classes, at runtime, without having to read any XML at all. However, this info is not especially complete : in particular, classes don't contain lists of methods for non-first inlets, and there is no class-table, only a constructor-table, so you need an object to be instantiated before you can access a class. Also, method signatures are often limited to A_GIMME for lack of ability to say it differently.
That's except for pd classes that go through GridFlow's C++ interface. In that case, there's a central class-table, from which you can find all method-names for all inlets. Method signatures (argument types) are not available but this feature could be added to the system without modifying any class. Each class also has a list of attributes, which gives you at least type info for *some* of the methods.
There are some other exceptions like that as well, having to do with various bridges between one language and Pd.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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, but if it's a substantial amount of code, i would go for C++ with a C interface. gr~~~
Am 22.02.2012 um 02:12 schrieb katja:
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 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.
So, the comfort of C++ programming and the time saved during development may be outweighed by troubles in deployment? I have to think twice... My lib should easily build and run wherever Pd runs.
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.
Fortunately I've time to reflect a bit more on the options, this lib need not be written today or tomorrow. Thanks again for all the advice.
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Thomas Grill http://grrrr.org +43 699 19715543
On Wed, Feb 29, 2012 at 9:17 PM, Thomas Grill gr@grrrr.org 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 library is just a wrapper it might not be worth to live in both worlds, but if it's a substantial amount of code, i would go for C++ with a C interface. gr~~~
Thanks for your recommendation, Thomas. Mathieu and IOhannes did similar suggestions.
Can anyone point me to an example of a C++ lib with C API, in the field of dsp? Not sure if I can think of the best way how to do it.
As I see it now, a C++ class could be instantiated and accessed from C like so:
- define an extern "C" wrapper which calls a class constructor and
returns the pointer to the instantiated object.
- define extern "C" accessor wrappers which take the object pointer as
their first argument, like how you would access data in C structs.
- via the object pointer, the extern "C" accessor wrappers can call
class member functions to access the class private data in C++ style.
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.
Katja
On Mar 2, 2012, at 4:32 AM, katja wrote:
On Wed, Feb 29, 2012 at 9:17 PM, Thomas Grill gr@grrrr.org 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 library is just a wrapper it might not be worth to live in both worlds, but if it's a substantial amount of code, i would go for C++ with a C interface. gr~~~
Thanks for your recommendation, Thomas. Mathieu and IOhannes did similar suggestions.
Can anyone point me to an example of a C++ lib with C API, in the field of dsp? Not sure if I can think of the best way how to do it.
As I see it now, a C++ class could be instantiated and accessed from C like so:
- define an extern "C" wrapper which calls a class constructor and
returns the pointer to the instantiated object.
- define extern "C" accessor wrappers which take the object pointer as
their first argument, like how you would access data in C structs.
- via the object pointer, the extern "C" accessor wrappers can call
class member functions to access the class private data in C++ style.
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.
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 portable C++, if you track all of these various issues across the platforms you want to support.
.hc
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
On Sat, Mar 3, 2012 at 3:47 AM, Hans-Christoph Steiner hans@at.or.atwrote:
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 portable C++, if you track all of these various issues across the platforms you want to support.
Not true, the Android NDK added support for exceptions in R5, I think that was about a year ago. Here's a port of Cinder that works on android, which uses just about every nifty feature available in C++ / stl / boost:
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 your routines will most probably outweigh that small member calling overhead. If your methods are real lightweight (and they are defined in an included - not a linked - file) you can still rely on a decent compiler to inline them, bashing overhead to zero.
gr~~~
On Sat, Mar 3, 2012 at 12:57 AM, Thomas Grill gr@grrrr.org 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 that too much. The potential number-crunching happening in your routines will most probably outweigh that small member calling overhead. If your methods are real lightweight (and they are defined in an included - not a linked - file) you can still rely on a decent compiler to inline them, bashing overhead to zero.
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 per sample.
So it could be done like this: write a lib in C++ with C++ API, and additionally provide C wrappers for the API functions. Then it's up to the application programmer to use the C wrappers or call C++ functions directly. That seems convenient, apart from other issues as mentioned by Hans and Mathieu.
Katja
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 per sample.
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. I don't see GEM hiding its classes in such a manner. What might happen instead, is that a lot of code gets duplicated into the wrapper. This makes the executable bigger, but you still get the extra speed from inlining that way (for small functions).
The « omit frame pointer » optimisation may cut a lot of the overhead while reducing code size, for function calls that are not inlined.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Sat, Mar 3, 2012 at 6:40 PM, Mathieu Bouchard matju@artengine.ca 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. The original accessor functions (class members) should be defined inline so they get inlined in their C wrapper. Those class members must be defined in the header then, in the class body, as the wrappers may be in another file.
What might happen instead, is that a lot of code gets duplicated into the wrapper. This makes the executable bigger, but you still get the extra speed from inlining that way (for small functions).
I was thinking about simple getters and setters for single values and for passing array pointers. Code duplication wouldn't be a problem in that case.
Thanks.
Katja
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 pointers to objects that deletes itself before it deletes itself in a polymorphic virtual destructor. ;) C++ is great but it is much easier to keep up with pointers in c. c is just like c++ without the confusion you can work yourself into a pointer to a function is a pointer to a function and if yo look at the assembly language there aint nothing wrong with using struct instead of class. it's all code an data when its running. the differences in the output are going to be more than likely caused by leaky capacitors and noisy fans or 2 coils of wire too close together.
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 itself in a polymorphic virtual destructor. ;)
Any language with sufficient power will have to allow the user to screw up. C gives you the power to decide of your own allocation duration (after malloc, how long before you free). But C also gives you the power to write your own automatic-free, or use someone else's. C++ makes it easier in some ways (ref-counting can become almost completely implicit).
C++ is great but it is much easier to keep up with pointers in c.
Please don't make it look like you didn't try C++ ;) In C++ you have a larger number of constructs you can use ; in C you have to reuse the same constructs in more different ways before you can get to the same solution. Any C++ programme could have been written using C by the means of more funny tricks and longer, more redundant code. The length and redundancy is sometimes all it takes to make bugs harder to find.
c is just like c++ without the confusion you can work yourself into a pointer to a function is a pointer to a function
I can't parse your sentence... sorry
and if yo look at the assembly language there aint nothing wrong with using struct instead of class.
In C++, struct and class are near-synonymous. All the OOP features are available with the struct keyword. In fact, you never need the class keyword, if you don't want it to appear in your source code.
it's all code an data when its running.
Even when not running, if you ask me...
the differences in the output are going to be more than likely caused by leaky capacitors and noisy fans or 2 coils of wire too close together.
The differences in the output between asm, C and C++ is more likely going to be about which categories of bugs, in which amounts, will be found between the chair and the keyboard.
And I'm not talking about Cimex Lectularius.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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 is handled by scope.
Here's a recent talk from Bjarne Stroustrup who says something to these affects: http://video.ch9.ms/ch9/252f/ed5c3dc3-3335-493b-9e2c-9fd00012252f/GoingNativ...
I think he gets into unique_ptr about 2/3rds in.
On Sun, Mar 4, 2012 at 7:10 PM, Billy Stiltner billy.stiltner@gmail.comwrote:
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 pointers to objects that deletes itself before it deletes itself in a polymorphic virtual destructor. ;) C++ is great but it is much easier to keep up with pointers in c. c is just like c++ without the confusion you can work yourself into a pointer to a function is a pointer to a function and if yo look at the assembly language there aint nothing wrong with using struct instead of class. it's all code an data when its running. the differences in the output are going to be more than likely caused by leaky capacitors and noisy fans or 2 coils of wire too close together.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 variable calls. Pd does call by function pointer, which needs to be figured out before the CPU pipeline can start reading and parsing the machine-code for it. When it's just a function-pointer in a known variable, it's not very slow, and might be very fast (?), but it takes a lot more time if there are conditional statements necessary to figure out which function-pointer should be used. This should tell you a lot about Pd's message-passing if you read that part of Pd.
A wrapper that is specific to each method is very fast, because the pointer is already known.
GridFlow uses two levels of wrappers, one of which is supposed to be slow according to what I say above (because the outer wrapper does its own message dispatch) ; but keeping things in perspective, it's still faster than anything else in Pd, when it comes to doing things that no other Pd class provides.
GEM's wrappers have virtually no runtime overhead, except that wrapper has to be written. GridFlow's method-wrappers are auto-generated, so that you don't have to write them. Those are two big examples of wrapping a C++ library in C so that it can be used in Pd.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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 katjavetter@gmail.com wrote:
Can anyone point me to an example of a C++ lib with C API, in the field of dsp? Not sure if I can think of the best way how to do it.
On Mon, Mar 5, 2012 at 2:15 AM, Rich E reakinator@gmail.com 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:
Thanks for pointing to this library, Rich. This is very informative.
Katja
http://en.wikipedia.org/wiki/Global_Descriptor_Table
I see all this 32 bit code needs to be ported to 64 bit.
-----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 first place, but meant to be portable to other real time dsp frameworks. This project will contain several routines which must share one interface to Pd, and C++ will be most convenient for it. I've used C and C++ for Pd classes before, and both seem to work properly and efficient. But I lack experience to know on beforehand if there is some disadvantage of using C++ for a reusable dsp library. This will be my first. Quite some dsp libs are written in C, even today. Is there good reason to refrain from C++'s conveniences for writing classes, and use C instead?
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 that you can avoid this, if you provide a public "C" API, and use C++ only as an implementation detail (e.g. and pass classes around as anonymous structs)
fgmasdr IOhannes
-----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++ 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 contain several routines which must share one interface to Pd, and C++ will be most convenient for it. I've used C and C++ for Pd classes before, and both seem to work properly and efficient. But I lack experience to know on beforehand if there is some disadvantage of using C++ for a reusable dsp library. This will be my first. Quite some dsp libs are written in C, even today. Is there good reason to refrain from C++'s conveniences for writing classes, and use C instead?
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 that you can avoid this, if you provide a public "C" API, and use C++ only as an implementation detail (e.g. and pass classes around as anonymous structs)
Hey Katja,
To throw in my related experience mirroring what Matju and IOhannes are saying, if you also care about making it easy to deploy, and you plan on doing the work to make it easy to deploy, you probably are going to spend less time if you do it in C. 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 :-)
.hc
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
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 in more different programmes than freetype, ffmpeg, libquicktime and gmerlin together, and it's all written in hardcore C++.
And how many apps use Qt ? That's all C++ as well.
Boost is a library... no... it's a large collection of C++ libraries... how many programmers use it ? There are 3000 people on the mailing-list, and then, there are other people.
What does « fundamental » mean ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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, libquicktime, gmerlin, etc. And of course... Pd :-)
STL is used in more different programmes than freetype, ffmpeg, libquicktime and gmerlin together, and it's all written in hardcore C++.
And how many apps use Qt ? That's all C++ as well.
Boost is a library... no... it's a large collection of C++ libraries... how many programmers use it ? There are 3000 people on the mailing-list, and then, there are other people.
What does « fundamental » mean ?
Meaning used widely and in many different programming languages. STL, Qt, and Boost are all only used in C++. freetype, ffmpeg, iconv, libjpeg, libpng, zlib, bzip2, sqlite, etc. have been used in many many different languages.
.hc
http://at.or.at/hans/
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%29#Bindings
now for the others...
STL and Boost are different. While Qt's interface (API) consists of features that are in many languages (or have very close equivalents), STL uses several features that are quite C++-specific and at odds with how other programming languages work. Other languages have already their own library covering the same ground as the STL, though usually in a quite different way and usually not that efficiently. Boost goes further in the direction of using all the C++ features that exist and it's at least as impossible to port.
This shows a rift between libraries with least-common-denominator interfaces that are somewhet easy to port to many languages (incl Qt), and libraries that are deeply entrenched in a language to get the best of it. The latter is more common in C++, because least-common-denominator tend to be a same small set of data types (int,float,string,array), basic OOP features, and that's all, while C++ has long expanded beyond « C with Classes » to include templates and stuff.
Templates can't be easily wrapped because their point is to generate code on-the-fly as the programmer is programming. Wrapping that kind of library means reducing the flexibility and/or efficiency, by precompiling some use-cases of templates, and forbidding the rest. Otherwise, you'd need something that can recompile C++ templates on-the-fly in another language, and I haven't seen that yet.
Actually, one can do similar tricks in plain C with macros, but those same caveats appear as with templates.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at 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, 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.
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.
See http://en.wikipedia.org/wiki/Qt_%28framework%29#Bindings
now for the others...
STL and Boost are different. While Qt's interface (API) consists of features that are in many languages (or have very close equivalents), STL uses several features that are quite C++-specific and at odds with how other programming languages work. Other languages have already their own library covering the same ground as the STL, though usually in a quite different way and usually not that efficiently. Boost goes further in the direction of using all the C++ features that exist and it's at least as impossible to port.
This shows a rift between libraries with least-common-denominator interfaces that are somewhet easy to port to many languages (incl Qt), and libraries that are deeply entrenched in a language to get the best of it. The latter is more common in C++, because least-common-denominator tend to be a same small set of data types (int,float,string,array), basic OOP features, and that's all, while C++ has long expanded beyond « C with Classes » to include templates and stuff.
Templates can't be easily wrapped because their point is to generate code on-the-fly as the programmer is programming. Wrapping that kind of library means reducing the flexibility and/or efficiency, by precompiling some use-cases of templates, and forbidding the rest. Otherwise, you'd need something that can recompile C++ templates on-the-fly in another language, and I haven't seen that yet.
Actually, one can do similar tricks in plain C with macros, but those same caveats appear as with templates.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 mention, so I can't guarantee you that any of those wrappers are well-made or worth using.
Tcl may be one of the lesser languages for Qt. The intersection of Tcl and Qt users is somewhat small, but even so, there are multiple projects about the same thing.
First look at http://wiki.tcl.tk/2181
Skip over TclQt, it's a windows binary thing that doesn't come with source (even though it's on SF.net) and it's very old. There's another one named Tq that is supposedly better but it's commercial and probably abandoned.
Look at Qtcl. The source is at http://sourceforge.net/projects/qtcl/ and I could get it to compile after I installed qmake and libqt4-dev. I didn't try it.
If Qtcl works well, it could be a possible path for speeding up the GUI, by replacing Tk entirely, but keeping Tcl (which is easier than changing everything at once). But there are other paths (the ones I suggested recently).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; "pd-list@iem.at" pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Wednesday, February 22, 2012 2:03 PM Subject: Re: [PD] C++ for reusable dsp lib - or better use C?
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 mention, so I can't guarantee you that any of those wrappers are well-made or worth using.
Tcl may be one of the lesser languages for Qt. The intersection of Tcl and Qt users is somewhat small, but even so, there are multiple projects about the same thing.
First look at http://wiki.tcl.tk/2181
Skip over TclQt, it's a windows binary thing that doesn't come with source (even though it's on SF.net) and it's very old. There's another one named Tq that is supposedly better but it's commercial and probably abandoned.
Look at Qtcl. The source is at http://sourceforge.net/projects/qtcl/ and I could get it to compile after I installed qmake and libqt4-dev. I didn't try it.
It looks old and unmaintained, and I doubt it supports the newest version of Qt which has introduced the graphics view stuff plus probably a lot of other changes. But I will give it a shot.
If Qtcl works well, it could be a possible path for speeding up the GUI, by replacing Tk entirely, but keeping Tcl (which is easier than changing everything at once). But there are other paths (the ones I suggested recently).
The only other path I remember is patching Tk to make it more efficient, but you still wouldn't get zooming with that.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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 replacing Tk entirely, but keeping Tcl (which is easier than changing everything at once). But there are other paths (the ones I suggested recently).
The only other path I remember is patching Tk to make it more efficient, but you still wouldn't get zooming with that.
I also mentioned the use of binary protocols, but it depends how much the binary protocol removes the Tcl dependency. A light use of binary elements means efficiently cutting the stream into Tcl commands to be run, and also ability to transmit raw data (array coords, images) at higher speed. But if that path is followed further, then... well, there are dozens of possible ways of making things more modular and it's not necessary to enumerate every possible way of doing so.
Tk zooming can be achieved using a TkCanvas wrapper that filters all coordinates. I'd use poe.tcl and follow a structure similar to Chun's TkZinc wrapper experiment and «def Canvas item» at once.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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 that you can avoid this, if you provide a public "C" API, and use C++ only as an implementation detail (e.g. and pass classes around as anonymous structs)
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 ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----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 like to
fgmsdrt IOhannes
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 other contexts. But an independent reusable library will need equivalents for constructor / destructor, access methods, private procedures and private data. When writing C, one has to invent an approach for that, or copy an existing style. It's in any case more tedious than using C++.
For a reusable audio analysis lib I would straightforwardly use C++, where it not for the considerations mentioned by Mathieu, Hans and Marvin. The intricate runtime support required for C++ leads to specific incompatibilities which don't exist for C.
The audio analysis lib I'm planning to do will be intended for static linking. 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. None of it's API symbols need be exported globally. The problem is sort of transferred to the application programmer. Pd's API m_pd.h is well prepared for compilation with g++. You only need not forget to export the setup symbol as "EXTERN C".
I use to link GNU C++ standard libs statically, just in case my class is used with a Pd which doesn't have them. This adds more than 100 KB to the executable size, not so nice detail. Then I'm not even talking about version incompatibilities, of which I was unaware till Mathieu mentioned it.
A C lib would not impose all these concerns on an application programmer. I'm inclined to look at C once more. (flip-flop-flip-flop...)
Katja
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 which does a job similar to what SWIG does.
For a reusable audio analysis lib I would straightforwardly use C++, where it not for the considerations mentioned by Mathieu, Hans and Marvin. The intricate runtime support required for C++ leads to specific incompatibilities which don't exist for C.
IMHO, fighting those incompatibilities is worth it ; also, some of them don't exist anymore (in recent years), and some others have a workaround whenever you provide a C interface to a C++ library, and some others don't exist if you turn off try/catch/throw support.
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 ?
I use to link GNU C++ standard libs statically, just in case my class is used with a Pd which doesn't have them. This adds more than 100 KB to the executable size, not so nice detail.
Isn't this mostly when you use STL ? The use of STL is optional. For example, I almost never use #include <fstream> in C++, I still prefer <stdio.h>.
A C lib would not impose all these concerns on an application programmer. I'm inclined to look at C once more.
Instead, a C lib will impose other concerns that C++ won't. What will those be ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Sat, Feb 25, 2012 at 8:59 PM, Mathieu Bouchard matju@artengine.ca 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 about the extraction of time domain features from an audio signal, mainly period length and note detection. Procedures to find these parameters will have best results if they can connect to each other at some points, and that is the reason to make an integrated lib. For efficiency, a multirate approach with polyphase FIR filtering will be applied. I've posted an outline to Pd forum (post #1 and #13):
http://puredata.hurleur.com/sujet-6814-rap-realtime-analysis-project
And the period detector code is now in a Pd class [helmholtz~]:
http://www.katjaas.nl/helmholtz/helmholtz.html
I use to link GNU C++ standard libs statically, just in case my class is used with a Pd which doesn't have them. This adds more than 100 KB to the executable size, not so nice detail.
Isn't this mostly when you use STL ? The use of STL is optional. For example, I almost never use #include <fstream> in C++, I still prefer <stdio.h>.
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.
A C lib would not impose all these concerns on an application programmer. I'm inclined to look at C once more.
Instead, a C lib will impose other concerns that C++ won't. What will those be ?
Actually, I can't think of any at the moment. That's partly by lack of experience. I'm planning to provide an unambiguous interface with 'new', 'free' and access methods. But most of it must still be designed.
Katja
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 <malloc.h> static inline void *operator new (unsigned int n) {return malloc(n);} static inline void operator delete (void *p) {return free(p);}
and add -fno-rtti to the flags (to disable the typeinfo feature). If you encounter anything else, just ask me and I'll try to find it.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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; i'd like to
Well, let's say that this interface is only for supporting pixes in other frameworks without having to go through [pix_data] and [pix_set]. What would you put in it ?
Some kind of permanent interface for getting/setting xsize, ysize, csize, upsidedown, type and format ; something to see whether there's a pix at all, something for creating one, and some explanation of how newimage/newfilm is supposed to work...
And a try/catch in every wrapper to protect against exception problems between MSVC and GCC.
Or else just discontinuing the MSVC edition... which thing do you mean when you say that you would « like to » ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----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 actually collaborate with other Pd-based frameworks that want to read its data on Windows ?
well, yes; i'd like to
Well, let's say that this interface is only for supporting pixes in other frameworks without having to go through [pix_data] and [pix_set]. What would you put in it ?
Some kind of permanent interface for getting/setting xsize, ysize, csize, upsidedown, type and format ; something to see whether there's a pix at all, something for creating one, and some explanation of how newimage/newfilm is supposed to work...
yes....basically a C-wrapper to access imageStruct members and methods via an opaque (imageStruct*) pointer. and a wrapper to extract that from an opaque GemState* pointer.
And a try/catch in every wrapper to protect against exception problems between MSVC and GCC.
Or else just discontinuing the MSVC edition...
no.
which thing do you mean when you say that you would « like to » ?
i'd like to have both MinGW and MSVC
fgm,asdr IOhannes
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 with GEM that require MSVC and can't work with MinGW ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----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 edition, again ? You probably told me already, but I don't remember.
i think there are two things:
- writing code that compiles on _both_ MSVC and gcc gives me a better
feeling of "standard conformity". people using only gcc tend to use gcc-specific extensions (which is ok if you only ever intend your program to be compiled with gcc; similarily, it is ok to make heavy use of msvc-specifics if you don't care about gcc; i prefer code that makes few assumptions about the used compiler)
Are there libraries that people use with GEM that require MSVC and can't work with MinGW ?
unfortunately yes. some of the proprietary video backends (NaturalPoint,...) only come with c++-libraries compiled with msvc. it doesn't help to say "then don't support them", if your employer bought already bought their system.
also the current implementation of the DirectShow backend is tied to MSVC.
again, a solution would be to use a C-wrapper for anything that involves crossing dll-boundaries (all video acquisition in Gem is nowadays done in separate dlls)...
fgmasdr5 IOhannes
-
Andy Farnell -
august -
Billy Stiltner -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
katja -
Krnk Ktz -
Marvin Humphrey -
Mathieu Bouchard -
patrick -
Phil Stone -
Rich E -
Thomas Grill