Re: Error Compiling on macOS

Denis Corbin <[email protected]> Wed, 24 Apr 2024 20:52:40 +0200
Newsgroups	gmane.comp.sysutils.backup.dar.support
Message-ID	<[email protected]>
On 24/04/2024 17:50, Rolf Gebhardt wrote:
> Hi James, hi Denis,

Hi Rolf,

> 
> because I have some macs under my desk, i tried to reproduce the error. 
> (Usually I don't compile Dar on MacOS and use the homebrew version 
> instead.)
> 
> On my new mac mini (MacOS Sonoma) the error does not occur.
> 
> So I booted Mojave on my old Mac Pro (normally I run Ubuntu on it) and 
> got the error reported by you.
> 
> It seems to have to do with one member of cat_entree: 
> smart_pointer<pile_descriptor> pdesc;
> 
> The class template "smart_pointer" itself  has a non default move 
> assignment operator that is not declared "noexcept". If you edit 
> smart_pointer.hpp and add the "noexcept"-specification to it, dar 
> compiles fine on my machine.
> 
>      /// move assignment operator
>      smart_pointer & operator = (smart_pointer && ref) noexcept
>      {
> 
> Perhaps this helps.

definitively yes, it should help James now and will reduce my 
investigation time later, thanks for that!

> 
> Don't know, whether stating the error is a compiler bug or just a 
> behaviour allowed by the language specification. I am not very familiar 
> with exception specifications, neither with the old and deprecated 
> "throws", nor with the newer "noexcept".

Yes, at the beginning of this century, dar/libdar made use of 
throws(<list of exception>) declarations, it was painful because you 
could forget a type of exception thrown indirectly by some method of 
function called from another method calling another one and so on.

the noexcept is simpler and easier to maintain (you just put it when you 
have made the necessary for no exception to be thrown, this leads to 
some possible optimization in the standard library). But the point here 
is the specifications of the default move, copy constructor, move and 
copy assignment operators. If not specified with the "= default" at the 
end I guess the compiler will generate the expected thing without 
warning, but for some reason I wanted to systematically have them 
mentionned in all classes, either defined with specific implementation 
or deleted ( = delete;) or use the default implementation ( = default;).

However C++ is changing over time (and that's good sign of life for this 
wondeful, poweful, lovely language ;) ) and compilers do not implement 
at the same pace the updated expectations/specifications of the 
language. some like clang are stricter than others like cpp... even if 
the code complied with both at a time... this changes a few years 
later... for one or the other or both.

so in short, this is probably not a compiler error, dar/libdar code 
needs to be updated from time to time to compile with modern 
compilers... and it will be.

> 
> Regards,
> 
> Rolf
> 
> 
[...]

Regards,
Denis
OpenPGP_signature.asc (application/pgp-signature, 840 B)