having fun with kvr developers

DSP, Plug-in and Host development discussion.
mystran
KVRAF
6922 posts since 12 Feb, 2006 from Helsinki, Finland

Post Wed Dec 22, 2021 7:36 am

I tend to follow slightly different conventions depending on the type of code I'm writing.

Essentially, for "public API" type of stuff (whether it's truly a public API, or just a sufficiently self-contained module), I tend to split the interface (header) almost completely from the implementation (source files) whenever possible (except for some one-liner accessors and similar) and trying to also keep the header as readable as possible, so that it can be used as a reference documentation directly.

On the other hand, for "business logic" type of high-level code (and also any internal helper classes for specific single-file module implementation), I just tend to put it directly into source file (or sometimes header files included from the main source file, if the main source file grows too large). This tends to be code that is messy no matter what, so spreading it around in too many files just makes everything even more confusing.

For stuff that's somewhere in the middle between the two, I tend to write headers initially, then as the stuff matures I tend to move larger functions (or methods) into their own source file mostly for the purpose of keeping the header more manageable and for taking advantage of separate compilation (which is useful for speeding up incremental builds, but obviously only when the stuff is mature enough that you're not tweaking it completely).

Anyway, I feel like trying to keep things modular, trying to split stuff into reusable components, is generally more useful than stressing about a particular scheme for organizing files... except as far as it's easier to reuse something if it's in it's own source file, obviously. :)
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

kirsty roland
KVRist
406 posts since 21 Nov, 2012 from Sitting in front of my PC

Post Wed Dec 22, 2021 8:55 am

mystran wrote: Wed Dec 22, 2021 7:36 am ...On the other hand, for "business logic"...
"business logic" reminds me of this little gem.

When I was working for <name withheld> writing Rt image processing software for their ultrasound scanners, my IT project leader/supervisor was a complete dick head. To get back at him I would obfuscate a lot of code. I remember one day he was asked by the managing director to explain some of my work. I was watching from across the office, crouched down in my partitioned booth. He was like, "OK sir this part does this and then I got her to write this really efficient routine to draw the sound waves on the monitor".
It was very hard not to burst out laughing :lol: :lol: :lol:

So...
If you are programming for yourself. Write nice clean easy to read manageable code.
If you are doing work for some company and getting paid peanuts. Write code that works but is sloppy, unreadable and very hard for others to maintain. That way you can stretch the contract out for months.

mystran
KVRAF
6922 posts since 12 Feb, 2006 from Helsinki, Finland

Post Wed Dec 22, 2021 9:10 am

kirsty roland wrote: Wed Dec 22, 2021 8:55 am If you are doing work for some company and getting paid peanuts. Write code that works but is sloppy, unreadable and very hard for others to maintain. That way you can stretch the contract out for months.
Is the goal to keep getting paid peanuts in the future too?
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

User avatar
AnX
Banned
10824 posts since 17 Nov, 2015

Post Wed Dec 22, 2021 9:19 am

:lol:

User avatar
syntonica
KVRian
1374 posts since 25 Sep, 2014 from Specific Northwest

Post Wed Dec 22, 2021 11:08 am

quikquak wrote: Wed Dec 22, 2021 4:24 am Totally agree. Separate header files seemed insane as soon as I started playing with C#. What a shit concept. In C++ I only use both cpp and h files when I know there’s going to be a dependancy loop in the future. Usually just an h file will do.
I think you could get around this by putting all your code into header files. Then, have one .cpp file that just includes them for compilation. You'd very quickly discover if you had any circular references. :lol:

I just hate repeating myself or wasting time on inane busy work garbage to keep the compiler from whining. For example, I made my two main plugin classes (plugin and editor) friend each other on Facebook as I got tired of moving crap around between public and private.

I suppose quite a bit of what I complain about has to do with preventing disasters when working in large teams, but I'd rather read a quick doc that says this method does this, allocate this memory on the heap and has these other side effects or is thread safe than look at black box classes and guess what the author's up to.

Jeff McClintock
KVRist
354 posts since 30 Jan, 2005 from New Zealand

Post Thu Dec 23, 2021 1:17 pm

quikquak wrote: Wed Dec 22, 2021 4:24 am In C++ I only use both cpp and h files when I know there’s going to be a dependancy loop
yep, makes perfect sense.

at least 'modules' are coming to C++ soon. These allow you to 'import' a class without including it's header. Which should be a big help.

User avatar
syntonica
KVRian
1374 posts since 25 Sep, 2014 from Specific Northwest

Post Sat Dec 25, 2021 12:43 pm

Another reason I dislike C++: sooo, my codebase has multiple places where I mix two waves, i.e interpolate between two values: s1 * (1 - k) + s2 * k, or s1 + (s2 - s1) * k. Since I was on code cleanup duty, making it pretty and more readable, I tidied them all up using an inline function: double interpolate(const s1, const s2, const k). After doing this, on the same code, my 8-instance test was 5% faster than before. WTF?!? Can't the compiler infer their const-ness by seeing that they do not change in the current scope? This deserves an angry table flip: (ノಠ益ಠ)ノ彡┻━┻

I'll reserve judgment on C++ modules until I see their implementation. I'm still angry over Java's useless lambdas...

mystran
KVRAF
6922 posts since 12 Feb, 2006 from Helsinki, Finland

Post Sat Dec 25, 2021 1:55 pm

syntonica wrote: Sat Dec 25, 2021 12:43 pmCan't the compiler infer their const-ness by seeing that they do not change in the current scope?
You are observing some other effect, because "const" is not something that any optimizer can actually use for anything (there are a couple of reasons, but the most obvious one is that C++ allows you to explicitly drop the "const" qualifier if you really want to). It's purely a type-checking thing that's there to assist the programmer.

Optimizer can (and do) prove that a certain variable is a constant, but whether it's marked as "const" or not doesn't matter one bit.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

User avatar
syntonica
KVRian
1374 posts since 25 Sep, 2014 from Specific Northwest

Post Sat Dec 25, 2021 2:39 pm

mystran wrote: Sat Dec 25, 2021 1:55 pm
syntonica wrote: Sat Dec 25, 2021 12:43 pmCan't the compiler infer their const-ness by seeing that they do not change in the current scope?
You are observing some other effect, because "const" is not something that any optimizer can actually use for anything (there are a couple of reasons, but the most obvious one is that C++ allows you to explicitly drop the "const" qualifier if you really want to). It's purely a type-checking thing that's there to assist the programmer.

Optimizer can (and do) prove that a certain variable is a constant, but whether it's marked as "const" or not doesn't matter one bit.
Weird. I've read--in several places--that using const where possible helps with compiler optimizations. Now I'll have to try removing the consts from my function to see if there's a difference.,, *sigh*

I'm unable to think of any other reason why I should see such was palpable improvement.

mystran
KVRAF
6922 posts since 12 Feb, 2006 from Helsinki, Finland

Post Sat Dec 25, 2021 2:44 pm

syntonica wrote: Sat Dec 25, 2021 2:39 pm Weird. I've read--in several places--that using const where possible helps with compiler optimizations. Now I'll have to try removing the consts from my function to see if there's a difference.,, *sigh*
Nah, that's an urban legend. I don't think it makes any difference either way in any modern compiler. Like I said, the optimizer can't really use it for anything, because it doesn't really guarantee anything.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

User avatar
syntonica
KVRian
1374 posts since 25 Sep, 2014 from Specific Northwest

Post Sat Dec 25, 2021 2:46 pm

Weird. You were right. Unless the very fact of factoring these computations out to a separate function, regardless of being marked with const. allows the compiler to better determine that the values do not mutate and to optimize away...

Still. Very annoying.

mystran
KVRAF
6922 posts since 12 Feb, 2006 from Helsinki, Finland

Post Sat Dec 25, 2021 2:57 pm

syntonica wrote: Sat Dec 25, 2021 2:46 pm Weird. You were right. Unless the very fact of factoring these computations out to a separate function, regardless of being marked with const. allows the compiler to better determine that the values do not mutate and to optimize away...
The thing is a modern optimizing compiler typically tries pretty hard not to care what sort of variables you declare in the first place, unless you explicitly do something (eg. pass the address to an unknown function) that forces them to actually keep a certain layout. From the optimizers point of view, it makes more sense to ignore the actual source level variables (where possible) and just reason about data flow directly. The days when production compilers translated code line-by-line are long gone [edit: except if you ask for an unoptimized debug build]. :)
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

rafa1981
KVRian
730 posts since 4 Jan, 2007

Post Sun Dec 26, 2021 12:48 pm

kirsty roland wrote: Wed Dec 22, 2021 8:55 amIf you are doing work for some company and getting paid peanuts. Write code that works but is sloppy, unreadable and very hard for others to maintain. That way you can stretch the contract out for months.
I was reminding this when reading your post, maybe something to consider :D

User avatar
syntonica
KVRian
1374 posts since 25 Sep, 2014 from Specific Northwest

Post Fri Jan 14, 2022 1:46 pm

Sometimes, it's faster to just Do the Thing than to figure out first if you need to Do the Thing.

Return to “DSP and Plug-in Development”