Unresolved linker errors in PluginProcessor that don't occur in test class

No one confuses namespaces and functions. It’s not even possible. I go for easy and simple to remember.

As far as test is concerned, that’s a temp class just to check if the same thing works in a different class than JUCE’s Processor class, which it does; the temporary class gets deleted when this bug is solved.

ExampleApp is an example app; it’s there as an example and is not a part of the technical system – a common practice when writing frameworks.

None2 sounds beautiful to me. That’s a name, and I’ve seen everything from things like bshu8 to CommonDrawTool. A name is a bit creative, I think. :face_with_monocle:

Well, I get the feeling you ask for help but do not want to receive any, because it is already completely perfect. Sorry man.

1 Like

You were asking about coding style. This is about linker errors stemming from missing functions occurring after the library was built for the app, then on include and usage, the functions are missing from the library.

Sure,

If need obfuscation for my projects, I will contact you :slight_smile:

Well ok. I’m certain you’re seeing something different. There’s no way that makes any sense.

Peter and Daniel are top notch fellows. They are using their free time to think about, and comment on, your issue. They are trying to help you, listen to them, don’t argue with them :slight_smile: You will become a better engineer :nerd_face:

1 Like

You speak good words. It is always good to 1) listen, 2) think independently, and then 3) find a type of conclusion or probabilistic conclusion.

It’s wonderful to have people on here wanting to support, even if it’s for a subjective stipulation! Life is meant to be wonderful, cpr, :laughing:

1 Like

I got it to build. :laughing:

My use of the superclass’s constructor apparently was causing the issue. Will have to look more into why.

Nonetheless, here’s what I did.

In ExampleApp.h, I changed:

	ExampleApp() : None2App() {};

to

	using None2App::None2App;

	ExampleApp() {};

Now I’m wondering what will I do if I add parameters to the superclass’s constructor! Ha, well, I may be looking into that another time. :partying_face:

You are truly trying to lift C++ to another level :crazy_face:

Of course when no parameters are required in a parent constructor there is no need to call it yourself, it will get called automatically. With parameters you have to specify how the call is done.

I will not look into the differences in your example until you move the stuff out of header files :wink:

I also like the

using None2App::None2App;

:+1:

1 Like

False alert! It turns out, I had commented out the instance of ExampleApp in JUCE’s PluginProcessor, so it was building. It still has the same errors though. False excitement, although kind of nice to think it changed.

Yeah, for some reason without calling the base class constructor, I was getting an error, so that’s why I have it there.

I did move the definitions out of ExampleApp.h, where they were, since that’s really oriented towards scripting style, although per daniel’s suggestion, I did, although I still have the errors.

I definitely do notice it is having problems with exactly the virtual functions from the Base class NoneApp, and not only the overrides in the derived class. For a reason or another, once it builds the library, the implementations cannot be found (when it links it to the VST or Standalone). I tried looking in the library, but I can’t find a good way to read it.

Please read this:

You can declare that a base class’s constructors shall be inherited, e.g., using B::B

From: Can the keyword "using" in C++ be used with something except of "namespace"? - Stack Overflow

Is that your intention? I find it a very confusing use of “using” - try to get rid of it

Yes, it’s very interesting. It can be used on type-aliases, too, although typedef works for that. C++ keywords: using - cppreference.com

Perhaps the unusual constructor method is unnecessary. Not sure if I should consider it messy. It is neat to know using isn’t just for namespaces.

Ah, so you were not aware of what the line was actually doing?

Please try to write code as if you are writing it for a colleague that you only speak to once in a while. Make it understable and be careful with uncommon stuff that you may like but someone else may find confusing or weird. I was not aware of this - and thought it was a shortcut for using a namespace (it is not)

I am certainly not a C++ expert, I think I am using a good subset that I feel very comfortable with, but don’t ask me about the more specialized aspects.

It was just running the default constructor of the base class. It’s another method I found aside from the initialization list (delegated constructor) method.

The initialization list is very, very basic, common and recommendable. This is a more exotic thing, I would really not use it. And: it is not “running” the constructor. It is how the following code should work…

1 Like

Ok, this time I think I finally found the answer.

I was going with Visual Studio’s automated suggestion to define functions as inline, when moving definitions to source files (I figured the functions were short enough, so why not?). I think, because JUCE relies on building the SharedCode into a library, then linking it into the final application, the functions it was looking for did not exist, since the inline keyword treats functions as copy+paste code; so I think, when looking the functions up in the library files, they could not be found.

Removing the inline keyword solved the compiler/linker issues.

The reason the code worked with the test class is because the test class is in the SharedCode directory, so it is not affected by JUCE’s linking scheme.