Wusik 4000 Module SDK Docs Ready

[WilliamK]

Got it, thank you, maybe take a while for my poor brain to understand how I could update my code to take advantage of those, but I will try.

[cpr]

Regarding struct vs class: "In a class definition, the default access for members and base classes is private. In a struct definition, the default is public. That is the only difference between a class and a struct.." If there is something aciddose is trying to convey to himself thru his choosing between struct and class, I suspect naming convention could convey the same thing.

Since there is no technological reason to make the choice, the only time I use a struct is when an external API requires it.

[aciddose]

No the reason I suggested using struct is because it eliminates the need to manually specify public: for what is a simple block of data with a single accessor or constructor.

Using the terms to differentiate even further is what I do and naming convention doesn't come close.

Most code analysis tools do not differentiate based upon whether you used C or S in front of your type name. All tools do however differentiate between struct and class.

Sure if your code isn't complex enough to benefit from it, but any large project should benefit greatly from the ability to graph relationships in a hierarchical structure.

Naming conventions are old burnt-out C programming.

Actually the most significant difference is that if you inherit from a struct it also defaults to public visibility. That members are automatically public is simply the best known difference.

Of course you can go ahead and throw out entire portions of the language and claim others are "wasting their time" using them, but honestly where do you think you're coming from here commenting on a feature you claim yourself never to use?

You don't use it, therefore it must be useless?

[arakula]

http://en.wikipedia.org/wiki/Software_development_kit
http://en.wikipedia.org/wiki/Juce

In case that was meant as a response to my question, please note that I'm not exactly a beginner in this business

@Arakula Wusik 4000 is a new modular-synth project by Wusik. It allows open-source custom modules to be created and used with it, and it's totally cross-platform, that's why it uses JUCE for the whole thing.

Thank you, that's more like it. This information was missing IMO. Is Wusik 4000 itself open source as well?

[WilliamK]

No, Wusik 4000 itself is not open-source, just the module format is open-source, and all modules I have coded so far, plus, 3rd party modules also need to be open-source. The idea is to make things as public as possible. Of course, the core is still closed, but I may change that with time, but still charge licenses fees to use it.

[paulbreeze]

In case that was meant as a response to my question, please note that I'm not exactly a beginner in this business

Great ...

[sonigen]

Actually the most significant difference is that if you inherit from a struct it also defaults to public visibility.

The default visibility is purely down to whether you choose class or struct. What you inherit from is irrelevant in that respect.

[mystran]

From the compiler point of view "struct" and "class" are indeed interchangeable, except for forward declarations and default visibility.

From the cultural point of view, it's common to declare things "struct" when (and only when) they are a POD type without any fancy rules on how you need to manage it (ie you can memcpy them around and such, just like with C structs). Likewise with a "class" you wouldn't normally expect that, unless the documentation specifically states otherwise.

[aciddose]

It's a religious discussion that boils down to whether you want to use a feature of the language for a valid purpose or not.

If people want to ignore parts of the language they "don't like" such as structs and templates that is fine. It just doesn't leave any room for an assertion that others should also limit themselves in that way or that using such features is "unproductive".

I think making the distinction is very useful - it's a distinction!

Having code littered with redundant comments and bizarre naming conventions is something you were forced to do in c. The reason for these features in c++ is partially due to those limitations of c and in my opinion it doesn't make sense not to use them.

I think the wusik4k headers should benefit greatly by making this sort of distinction and while I'm open to hear arguments about why not, they should need to make a valid point other than "you don't really need to" or "you really should anyway" without any real basis.

When someone is writing an interface like this, in my opinion they should not slack on any of the features that can provide more rigid definition for that interface.

We don't want to see more VST SDKs, do we really?

[cpr]

to be clear, I only commented on my personal usage of structs, without any judgement of their value. as well, if a coding standard of my employer differs, that is how I code for them.

[aciddose]

I understood that of course.

You did however say that there is "no technological reason" to use structs which I would argue is untrue. As I explained, the compiler understands the distinction between a struct and class while it is unable to make a distinction between variations of a naming convention.

I personally don't like the "struct as a strict aggregate POD" limitation although I understand its purpose. Its purpose is that an aggregate can be aggregated - that is can be defined as part of an array and initialized directly:

Code: Select all

aggregate_type array[2] = 
{
 {member1, member2, member3},
 {member1, member2, member3},
};

It can also be allocated in an array without worrying about a constructor:

Code: Select all

aggregate_type *array = new aggregate_type[2];

This wouldn't work if the aggregate_type contained a constructor. Instead you would need to allocate an array of pointers to aggregate_type, then allocate each aggregate_type individually calling its constructor in the process.

There are workarounds of course but let's ignore these because they are terrible.

The heap allocation is the one rule that really matters to me although I find that the overhead of an array of pointers to type is not significant in the instances I need to use it.

There are obviously going to be cases where an aggregate is required to eliminate that overhead, but without running into one of those conditions I don't see much justification for the POD limitation for structs.

For example:

Code: Select all

struct non_pod_aggregate_type {
 // default lazy do-nothing constructor required to make this class an aggregate
 non_pod_aggregate_type() {
 }
 non_pod_aggregate_type(int init) {
  member = init;
 }
 int member;
}

non_pod_aggregate_type array[2] =
{
 non_pod_aggregate_type(0),
 non_pod_aggregate_type(1),
 }

Here we can use the default copy-constructor to achieve the same results (should be, with optimization) and the only downside if you'd consider it so is that we need to use constructor-syntax to initialize members.

I don't consider that a downside because I find it actually improves readability, although opinions will differ I'm sure.

So yes, don't worry I understand that we all have our reasons

[mtytel]

For style and best practice I usually follow: http://google-styleguide.googlecode.com ... pguide.xml

Some of the things are a little strict for some people (e.g. 80 character line limits) but it covers most of the things mentioned in this thread.

[aciddose]

I've solved a lot of the problems their rules are based upon by using some of the methods I've described so far in this thread.

For example by using c++11's enum class or the workaround of wrapping an enum in a struct with operator enumtype you eliminate the need to use the ugly k prefix. kinst kthat ka kgood kthing kor kwhat? ki kbought ksome kwurst kat kmart.

It also solves the use of generic names, which the k-prefix DOESN'T solve.

They don't provide a justification for their trailing underscore rule, although I suspect they hated having to add get_ prefixes to accessors. This is just lame in my opinion. Which is better, get_ham() or ham(). What on earth does ham() do? It creates ham? Roasts it? What?

They are ignorant of the issues of c-style /* */ comments and their inability to be overlapped. For commenting sections use the preprocessor #if 0 ... #endif, which don't suffer from this problem. Always use c++ comments. // because it's far more uniform and doesn't have any cons associated with it

Lots of other silly issues like their fear of operator overloading... Yes, it can be abused and it is very hard to write a rule explaining how it may be used without abusing it. Throwing out one of the very best features of the c++ language doesn't make sense, though.

Likewise with their fear of using namespace, for the same reasons. Try to limit using namespace to source files defining a specific object within a specific namespace. Hierarchical namespaces can become very difficult to use without using namespace and google's method of namespace google_projectname_dir_file is ridiculous and ugly. google { projectname { dir { file { ... }; }; }; };
Etc...

Code: Select all

myclass.h
namespace author/project/whatever
{
  namespace context (for example, dsp, math, networking, ...)
  {
    class myclass // note can be named something sweet and short, not ProjectNetworkingWayTooLong
    { 
    somefunction();
    ...
    };
  };
};

// bracket-hell only applies to headers and it is most definitely worth it

myclass.cpp
#include "myclass.h"

using namespace project::context;

myclass::somefunction()
{
 ...
}

By using "using namespace" you can avoid horrendous amounts of redundant crap in this case.

Otherwise you'd need:

Code: Select all

#include "myclass.h"

project::context::myclass::somefunction()
{
 ...
}

Have fun trying to figure out which class you're defining when it has a generic name and you're five namespace levels deep without "using namespace". With "using namespace" it's a single glance at the top of the source!

The one rule I would go by is never, ever use "using namespace" when you're accessing some component of a namespace on a one-off. Only use it while you're defining members of a namespace.

If you are using many instances of a member of a namespace try to limit use of "using namespace" to the smallest context possible.

Don't do:

Code: Select all

using namespace cause_problems_for_everyone_because_of_namespace_collisions_yay;

function()
{
 test(); 
 test1(); 
 test2();
 generic_name();
 generic_type purpose;
 purpose.member = generic_name_used_in_c_stdlib_worst_of_all_possible_cases();
 purpose.member2 = rand(); // did we mean stdlib rand() or some other?
}

Do:

Code: Select all

sub_function()
{
 using namespace dont_cause_problems_for_anyone;
 test(); 
 test1(); 
 test2();
 generic_name();
}

function()
{
 sub_function();
 dont_cause_problems_for_anyone::generic_type purpose;
 purpose.member = dont_cause_problems_for_anyone::generic_name_no_problem();
 purpose.member2 = dont_cause_problems_for_anyone::rand();
}

I'd advise against following google rules strictly

[mtytel]

I offered the google style guide as a comprehensive list of dos and don'ts rather than the splattering recommendations on a forum.

Yes it is a bit strict and makes arbitrary assertions, but I wouldn't be so quick to bash the style guide of a company who has successful multimillion line open source projects.

[aciddose]

I'm not too quick to bash it, they're using some features and not others for reasons that only apply to large scale projects with numerous contributors.

That is the justification for "throw out this set of c++ features entirely". The justification is simply "people are stupid, don't trust them to follow the rules, in fact don't bother writing any rules at all other than never to use feature x."

That is intelligent at that scale under those conditions but in all others it is completely stupid.

My point stands - strictly following a standard designed and used by a huge corporation with thousands of contributors working on massive billion-dollar-plus-plus-plus projects maybe doesn't make sense for all projects not under those same conditions.

The things that make the most sense are all part of things I've already suggested