#pragma warning(error: 4265) [SOLVED]

On 22/08/2015 at 12:42, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   16+ 
Platform:   Windows  ; Mac  ;  Mac OSX  ; 
Language(s) :     C++  ;

---------
Hi,

is there a reason why the C4D API is having #pragma warning(error: 4265) set?
This collides with libraries which (by design choice) have some abstract base class destructors marked as non-virtual.

Why couldn't it remain at warning level? Currently I am disabling it locally for the corresponding includes (which works) but I would be interested to know why the error handling in the API.

Thanks

On 24/08/2015 at 02:16, xxxxxxxx wrote:

Hello,

in the context of the Cinema 4D SDK it is likely that a non-virtual destructor would not clean up properly on destruction. The developers pointed me to this article explaining the issue: "When should your destructor be virtual?"

best wishes,
Sebastian

On 24/08/2015 at 03:09, xxxxxxxx wrote:

Hi,

thanks for the answer first of all.

I know why a virtual destructor is used in a (base) class, thanks, still the question remains, why is it made an error instead of keeping it a warning (actually compiler-wise this is even off by default)?
It would surely be enough for an implementer to be notified (via the appropriate warning) instead of throwing a compiler error globally which collides with other class concepts (for example when by design it shall not be destroyed by deleting a base class pointer).

On 24/08/2015 at 04:55, xxxxxxxx wrote:

What I am trying to say I guess is that the C4D SDK should not interfere with my class design concepts (or that of an external library) in a global manner.
I should not be forced to handle an error which is clearly not an error but depends on implementation detail. Maybe I should have posted this as an SDK feature request?

On 24/08/2015 at 04:56, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Hi,thanks for the answer first of all.I know why a virtual destructor is used in a (base) class, thanks, still the question remains, why is it made an error instead of keeping it a warning (actually compiler-wise this is even off by default)? It would surely be enough for an implementer to be notified (via the appropriate warning) instead of throwing a compiler error globally which collides with other class concepts (for example when by design it shall not be destroyed by deleting a base class pointer).

As explained, in the context of the SDK it's almost certain that you have a resource leak/bug if you don't have a virtual destructor - and we found plenty of plugins where exactly that happened (and programmers just ignored the warning).

It's possible to create classes (with virtual methods) where a virtual destructor ain't necessary, but you have been very cautious and as shown in the link Sebastian pointed too, even then you might run into problems you haven't thought of.

You can of course change this compiler message from an error to a warning, personally I'd chose a different class design though.

Best regards,

Wilfried

On 24/08/2015 at 05:09, xxxxxxxx wrote:

Thanks Wilfried. I understand it fits the implementation detail of the SDK but here I would probably repeat the last answer I posted. I am not a fan of having this errored globally and by default.

If you sweep the stl or boost you can find a tremendous amount of non-virtual destructor design concepts. I agree this may not be a class design for novice programmers to handle but if more advanced concepts are in need (or seem appropriate) I shouldn't get an error message for it imo.

Anyway, thanks both for the discussion (and my preliminary question if I can turn it off was answered by wilfried as well). Maybe this can be moved to SDK feature request forum instead?

It can be marked as solved as well. I got all the info I needed.

On 24/08/2015 at 06:13, xxxxxxxx wrote:

You can push disable the warning only for including Boost. See http://stackoverflow.com/questions/4193476/is-using-pragma-warning-push-pop-the-right-way-to-temporarily-alter-warning-lev

On 24/08/2015 at 06:18, xxxxxxxx wrote:

That's what I am doing already Niklas (see first posting) but thanks. Still it's ugly and must be done for any includes which is annoying. Hence this thread. : )

On 24/08/2015 at 10:03, xxxxxxxx wrote:

Ups, missed that part :-)