What are the most important parts of C++ for coding plug-ins?

[LIMITAPROACHINGINFINITY]

THank you very much for your reply! But does the two mentioned compilers gcc and vc++ express work with the steinberg SDK? And also, when i used to have VC++ I took a look at the GUI toolkit and i remebered being puzzled. Is there any tutorial/ threads on how to buil guis with the SDK? Also, im just curious, does anyone know how the gui toolkit works.. I mean, is it built directly on top of API? You said it was cross platform so that can't be.

Thank you all!

[Christian Schüler]

Just wanted to add that GCC is just fine for coding VST plugins. AriesVerb was done using GCC 3.3.1 (MinGW port http://www.mingw.org), a text editor (http://www.pfersdorff.de/) and Perforce JAM for project management (http://www.perforce.com/jam/jam.html). I admit this approach is certainly off the mainstream line, but it perfectly fits my style .

[thaddy]

Well,

C++ is just a tool, a way of expressing things.
As far as I know any serious audio programmer does his really critical stuff in assembler anyway, so there's really no difference between:

void dosomething(float *buffer)
{
asm{
..}
};

and
// delphi
procedure dosomething(Buffer: PSingle);
asm
...
end;

or Powerbasic, or real assembler, any language that compiles to true machinecode.

Point is none of the compilers are by itself better suited to audio programming.

It's a matter of taste, availability of resources and common sense (everybody else seems to use it) but it's not a matter of 'better suited' in terms of the language features. If you can't switch between languages you are not a programmer. (meaning design, algorithm and data structure are far more important than a language.

In my opinion Delphi (and freepascal) are more readable and the resources are catching up fast.
(Although I have to admit my real work is eventually written in C++ after the design stage which as someone stated very eloquently is far more time consuming than writing it down in a language, whatever one you choose)

[tlr]

Just curious, is there any downside to using the new safe StringCchCopy functions in the new Platform SDK? Seems like those cover the buffer overrun scenarios, but I haven't checked to see if they have a perf hit or other side effects.

It's not very portable! If you want to use your code on another platform than win32 you will have to change your code.
Why would anyone _not_ use stl btw? It's in the C++ standard since 1998, and VC++ supports it pretty well.
(sucks a bit in VC6.0, but std::string should work atleast.)

/Daniel

[fishbowl.tucson.az]

In its current form, strncpy() is one of the most dangerous functions in the C library simply because it lulls intermediate programmers into a false sense of security.

I really like the idiom that's standardized in Java, and I apply it to C and C++:

Strings, once created, are immutable. There is no changing characters or length once a string is created.
There are other classes for modifiable character data, like StringBuffer. That has memory-safe methods built in for appending, indexing, replacing, etc.

[phatdumi]

I see yu'all mentioning c and c++ what about c sharp is it any good at coding these little babies?(soz my sharp sign button has abandoned me) Ant books or forums out there that can help a newbie lay a good solid foundation regarding this subject?

[Grimes]

I do operating systems programming for a living, so I don't have a whole lot of stuff specific to writing VSTs. That said, here are some general pointers on programming:

* I find it easiest to learn a new task by trying, failing at it, understanding why I failed, and then doing it the correct way. Once I have that task down, I try to move on to another more challenging task.

* Unit tests! If you see boundary conditions in your code, try to write a test that will exercise your code so that you can make sure you have correctly handle the case. When you find a new bug, try to write a new test case that tickles the bug. If done well, you can build up a testsuite for your program that you can easily run (e.g. a script). This makes it easier to prevent regressions (i.e. reintroducing bugs you've already fixed) and find new bugs (as you already have some stress tests).

* Don't try to optimize while doing the initial pass through. People often spend a large amount of time making their code into gibberish because they think they are making it faster. It is better to do this once you have a working prototype. Then you run a profiler, find a critical region of the code, and optimize that. Don't optimize before!

* Similar to above, don't worry too much about inlining. A good compiler can do inlining for you. I've often seen people inline a function in a header file, thinking "hey, only a couple places ever call this". After awhile the function is used in more places and it actually causes performance degradation.

* Do high level analysis of the performance critical regions of the code. People often spend time optimizing a poor algorithm. Understanding some basics about algorithms (e.g. O(n) vs exponential) and about computer architecture (e.g. disk access speeds vs memory access, caching issues) may yield an algorithm that's far better than the optimized poor one.

* Have fun. People tend to learn when they're excited about what they're doing.

[Scr1pt3r]

* Don't try to optimize while doing the initial pass through. People often spend a large amount of time making their code into gibberish because they think they are making it faster. It is better to do this once you have a working prototype. Then you run a profiler, find a critical region of the code, and optimize that. Don't optimize before!

Great post Grimes!

Regarding a profiler, Can you give an example of such a tool ?

[SQ4]

Well,

C++ is just a tool, a way of expressing things.
As far as I know any serious audio programmer does his really critical stuff in assembler anyway, so there's really no difference between:

void dosomething(float *buffer)
{
asm{
..}
};

and
// delphi
procedure dosomething(Buffer: PSingle);
asm
...
end;

or Powerbasic, or real assembler, any language that compiles to true machinecode.

Point is none of the compilers are by itself better suited to audio programming.

It's a matter of taste, availability of resources and common sense (everybody else seems to use it) but it's not a matter of 'better suited' in terms of the language features. If you can't switch between languages you are not a programmer. (meaning design, algorithm and data structure are far more important than a language.

In my opinion Delphi (and freepascal) are more readable and the resources are catching up fast.
(Although I have to admit my real work is eventually written in C++ after the design stage which as someone stated very eloquently is far more time consuming than writing it down in a language, whatever one you choose)

Very true.
If you like OOP, go for C++ / Delphi.
If you're a dinosaur like me, still thinking the procedural way, go for something like PureBasic (incredibly fast) + inline assembler...
PureBasic has the best Windows-API implementation I ever saw.
It compiles very fast, creates very small executables which run at the speed of light.
And for time critical sections there's a rather good assembly implementation (Fasm).
Don't believe me : Try it!

[Grimes]

Regarding a profiler, Can you give an example of such a tool?

Well, I don't write any code for Windows, so I can't really recommend something there. For UNIX, though, gprof, oprofile (Linux-only), and valgrind are probably your best bet.

You can often learn a lot about how your program works by adding things like statistics (e.g. how often a certain function is executed, how often a certain case is handled, or how long some portion of code usually takes), or tracing code (i.e. adding the ability to trace the path of a given operation through a series of function calls). The goal is to find the portions of code that are taking up the most time - profilers can often do this automatically, but the same thing can be done by hand.

By the way, you want to be careful about printing stats too often, though, as attempting to print several hundred times a second can cause your program to really slow down and thus skew the results you're trying to get.

[Mr Smith]

good idea is to get a book about software development in general, i'm talking UML design, requirement specifications and so on. Will help you a lot.

[peanut]

edit (whoops)

[VitaminD]

"applying uml and patterns: an introduction to OOA/D and iterative development" by larman (whew thats a mouthful)? I'm in a software development class at the moment.. thats the book we're using..

actually.. just found it on amazon http://www.amazon.com/exec/obidos/ASIN/ ... 03-7910239



though I came here to ask.. is anyone developing VST plugins using C#?

[keyman_sam]

This may be a silly question, but here goes :

I know a little bit of java, and from the code i saw here, it looks like its the same as java, except a few changes.

Am i right? can i implement Java style code into C++? Is it all the same basic thing?

[VitaminD]

no they are different..

Java is very C++esque for a reason (wooing C++ devs) however, there are serious differences such as Java having a garbage collector and C++ having pointers..