On Thu, 4 Apr 2024 20:11:10 +0200
Bonita Montero <[email protected]> wrote:

template<bool Throw = false>
std::conditional_t<Throw, void, DWORD> getFileTime( wchar_t const
*file, FILETIME &ftCreationTime, FILETIME &ftLastAccessTime, FILETIME &ftLastWriteTime )
{
XHANDLE xhFile( CreateFileW( file, FILE_READ_ATTRIBUTES, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL ) );
if( xhFile == INVALID_HANDLE_VALUE )
if constexpr( Throw )
throwSysErr( "can't open file to get file
time" ); else
return GetLastError();
if( !GetFileTime( xhFile, &ftCreationTime, &ftLastAccessTime, &ftLastWriteTime ) )
if constexpr( Throw )
throwSysErr( "can't get file time" );
else
return GetLastError();
return NO_ERROR;
}

template<bool Throw = false>
std::conditional_t<Throw, void, DWORD> setFileTime( wchar_t const
*file, FILETIME const &ftCreationTime, FILETIME const
&ftLastAccessTime, FILETIME const &ftLastWriteTime )
{
XHANDLE xhFile( CreateFileW( file, FILE_WRITE_ATTRIBUTES, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL ) );
if( xhFile == INVALID_HANDLE_VALUE )
if constexpr( Throw )
throwSysErr( "can't open file to set file
time" ); else
return GetLastError();
if( !SetFileTime( xhFile, &ftCreationTime, &ftLastAccessTime, &ftLastWriteTime ) )
if constexpr( Throw )
throwSysErr( "can't set file time" );
else
return GetLastError();
return NO_ERROR;
}

No, it is not beautiful. It is not even half-decent.
Personally, I find all exceptions ugly, but that can be considered
my personal idiosyncrasy, even if it is shared by significant percentage
of C++ programmers.
However, reporting non-exceptional situation with exceptions is non-controversially bad design.
Is is listed high on "Don't do it" list in one of the books in Scott
Meyers's "Effective C++" series.
If you wonder why, it's not related to performance.

And not being able to open file is most certainly *not* an exceptional situation!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S writes:

On Thu, 4 Apr 2024 20:11:10 +0200
Bonita Montero <[email protected]> wrote:

template<bool Throw = false>
std::conditional_t<Throw, void, DWORD> getFileTime( wchar_t const
*file, FILETIME &ftCreationTime, FILETIME &ftLastAccessTime, FILETIME &ftLastWriteTime )
{
XHANDLE xhFile( CreateFileW( file, FILE_READ_ATTRIBUTES, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL ) );
if( xhFile == INVALID_HANDLE_VALUE )
if constexpr( Throw )
throwSysErr( "can't open file to get file
time" ); else
return GetLastError();
if( !GetFileTime( xhFile, &ftCreationTime, &ftLastAccessTime, &ftLastWriteTime ) )
if constexpr( Throw )
throwSysErr( "can't get file time" );
else
return GetLastError();
return NO_ERROR;
}

template<bool Throw = false>
std::conditional_t<Throw, void, DWORD> setFileTime( wchar_t const
*file, FILETIME const &ftCreationTime, FILETIME const
&ftLastAccessTime, FILETIME const &ftLastWriteTime )
{
XHANDLE xhFile( CreateFileW( file, FILE_WRITE_ATTRIBUTES, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL ) );
if( xhFile == INVALID_HANDLE_VALUE )
if constexpr( Throw )
throwSysErr( "can't open file to set file
time" ); else
return GetLastError();
if( !SetFileTime( xhFile, &ftCreationTime, &ftLastAccessTime, &ftLastWriteTime ) )
if constexpr( Throw )
throwSysErr( "can't set file time" );
else
return GetLastError();
return NO_ERROR;
}

No, it is not beautiful. It is not even half-decent.

Agreed. This looks like something I scraped off the bottom of my shoe, yesterday.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sam <[email protected]> writes:

Michael S writes:

On Thu, 4 Apr 2024 20:11:10 +0200
Bonita Montero <[email protected]> wrote:

template<bool Throw = false>
std::conditional_t<Throw, void, DWORD> getFileTime( wchar_t const
*file, FILETIME &ftCreationTime, FILETIME &ftLastAccessTime, FILETIME
&ftLastWriteTime )
{
XHANDLE xhFile( CreateFileW( file, FILE_READ_ATTRIBUTES,
FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS, NULL ) );
if( xhFile == INVALID_HANDLE_VALUE )
if constexpr( Throw )
throwSysErr( "can't open file to get file
time" ); else
return GetLastError();
if( !GetFileTime( xhFile, &ftCreationTime, &ftLastAccessTime,
&ftLastWriteTime ) )
if constexpr( Throw )
throwSysErr( "can't get file time" );
else
return GetLastError();
return NO_ERROR;
}

template<bool Throw = false>
std::conditional_t<Throw, void, DWORD> setFileTime( wchar_t const
*file, FILETIME const &ftCreationTime, FILETIME const
&ftLastAccessTime, FILETIME const &ftLastWriteTime )
{
XHANDLE xhFile( CreateFileW( file, FILE_WRITE_ATTRIBUTES,
FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS, NULL ) );
if( xhFile == INVALID_HANDLE_VALUE )
if constexpr( Throw )
throwSysErr( "can't open file to set file
time" ); else
return GetLastError();
if( !SetFileTime( xhFile, &ftCreationTime, &ftLastAccessTime,
&ftLastWriteTime ) )
if constexpr( Throw )
throwSysErr( "can't set file time" );
else
return GetLastError();
return NO_ERROR;
}

No, it is not beautiful. It is not even half-decent.

Agreed. This looks like something I scraped off the bottom of my shoe, >yesterday.

Concur. It appears to leak file handles as well.

int
set_filetime(const char *path, struct timespec access_time, struct timespec modify_time, int&
fd)
{
fd = open(path, O_RDWR|O_CREAT|O_EXCL, 0066);
if (fd != -1) {
struct timespec times[2] = { access_time, modify_time };
if (futimens(fd, times) == 0) {
(void) close(fd);
fd = -1;
}
return fd;
}
return errno;
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 5 Apr 2024 05:05:40 +0200
Bonita Montero <[email protected]> wrote:

Am 04.04.2024 um 20:55 schrieb Michael S:

On Thu, 4 Apr 2024 20:11:10 +0200

I just thought that sometimes I want the error code for the direct
caller and sometimes I want an exception that applies to the caller
a few levels higher, and so I can have both.
I don't find exceptions ugly at all, but rather very elegant.
For me, exceptions are the most convenient way of handling errors.

You're not alone. Nor am I.

However, reporting non-exceptional situation with exceptions is non-controversially bad design.

You can't say that, or in the given case it may be that the error has
to be acted upon by your immediate caller or just a few levels higher
in the call graph; In the latter case, exceptions make sense.

You're still not alone, unfortunately.
The computing world would be better place if your kind knew better.

And not being able to open file is most certainly *not* an
exceptional situation!

You can't say that across the board.

Your template supposed to be provided as generic utility, right?
So in order to be correct I don't have to be correct accros the board.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 05 Apr 2024 00:21:54 GMT
[email protected] (Scott Lurndal) wrote:

Concur. It appears to leak file handles as well.

Actually, we don't know, because Bonita did not show us a definition of XHANDLE. It could be an object that prevent handle leaks by means of
RAII.
I'd give her (or him) the benefit of doubt.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 5 Apr 2024 17:27:49 +0200
Bonita Montero <[email protected]> wrote:

Am 05.04.2024 um 16:44 schrieb Michael S:

On Fri, 05 Apr 2024 00:21:54 GMT
[email protected] (Scott Lurndal) wrote:

Concur. It appears to leak file handles as well.

Actually, we don't know, because Bonita did not show us a
definition of XHANDLE. It could be an object that prevent handle
leaks by means of RAII.
I'd give her (or him) the benefit of doubt.

If you knew Win32 you would know that XHANDLE is a RAII wrapper
for HANDLE.

I would think that nowadays even Dave Cutler does not know all Win32.
However I know enough to know that Win32 is defined in terms of C.
So I don't quite understand how XHANDLE can be part of it.
Anyway, it seems I guessed the meaning correctly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonita Montero <[email protected]> writes:

Am 05.04.2024 um 16:52 schrieb Michael S:

On Fri, 5 Apr 2024 05:05:40 +0200
Bonita Montero <[email protected]> wrote:

Am 04.04.2024 um 20:55 schrieb Michael S:

On Thu, 4 Apr 2024 20:11:10 +0200

I just thought that sometimes I want the error code for the direct
caller and sometimes I want an exception that applies to the caller
a few levels higher, and so I can have both.
I don't find exceptions ugly at all, but rather very elegant.
For me, exceptions are the most convenient way of handling errors.

You're not alone. Nor am I.

It's impossible to use C++ without exception.

It is quite possible. Don't use the standard library.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonita Montero <[email protected]> writes:

Am 05.04.2024 um 22:00 schrieb Scott Lurndal:

Bonita Montero <[email protected]> writes:

Am 05.04.2024 um 16:52 schrieb Michael S:

On Fri, 5 Apr 2024 05:05:40 +0200
Bonita Montero <[email protected]> wrote:

Am 04.04.2024 um 20:55 schrieb Michael S:

On Thu, 4 Apr 2024 20:11:10 +0200

I just thought that sometimes I want the error code for the direct
caller and sometimes I want an exception that applies to the caller
a few levels higher, and so I can have both.
I don't find exceptions ugly at all, but rather very elegant.
For me, exceptions are the most convenient way of handling errors.

You're not alone. Nor am I.

It's impossible to use C++ without exception.

It is quite possible. Don't use the standard library.

Then you're missing most of C++.

Most of C++ is useless cruft with a significant run-time
performance hit.

Classes are genuinely useful, as are namespaces.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

06.04.2024 00:29 Scott Lurndal kirjutas:

Most of C++ is useless cruft with a significant run-time
performance hit.

Classes are genuinely useful, as are namespaces.

So are standard containers, like std::vector and std::map. No run-time performance hits compared to equivalent solutions in C.

So are templates. No run-time performance hits. Template syntax, while horrible, is still more readable/maintainable than equivalent C macros.

For me, also exceptions are genuinely useful. In C code with adequate
error checking, half of the code deals with the error paths, and useful
error messages are often still lacking. YMMV.

I agree that iostreams are pretty useless and have significant run-time performance hits. But iostreams do not make up most of C++.

Still, the best feature of C++ is RAII (zero run-time performance hit).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paavo Helde <[email protected]> writes:

06.04.2024 00:29 Scott Lurndal kirjutas:

Most of C++ is useless cruft with a significant run-time
performance hit.

Classes are genuinely useful, as are namespaces.

So are standard containers, like std::vector and std::map. No run-time >performance hits compared to equivalent solutions in C.

For the most part true of std::vector. Not necessarily for
std::map.

So are templates. No run-time performance hits. Template syntax, while >horrible, is still more readable/maintainable than equivalent C macros.

Poorly used, templates increase the code footprint, sometimes
considerably - often just to avoid a couple of conditionals
in the code.

For me, also exceptions are genuinely useful. In C code with adequate
error checking, half of the code deals with the error paths, and useful
error messages are often still lacking. YMMV.

There is a definite run-time cost to using exceptions. And some
C++ code (operating systems, hypervisors) don't have the
run-time infrastructure to support exception handling and stack
unwinding.

I agree that iostreams are pretty useless and have significant run-time >performance hits. But iostreams do not make up most of C++.

Still, the best feature of C++ is RAII (zero run-time performance hit).

Useful, but can easily be abused (e.g. for locking).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <[email protected]> wrote:

run-time performance hits. But iostreams do not make up most of C++.

Still, the best feature of C++ is RAII (zero run-time performance
hit).

RAII has low run-time cost, although I doubt that it's really zero.
RAII has non-trivial code size cost, esp. when used a lot. See below.
But my main objection with RAII is that I feel like loosing track.

Simple test:
------ foo.cpp
void* allocate_bar(int x);
void free_bar(void* bar);
int foo_bar(void* bar);

int foo(int x)
{
void* bar = allocate_bar(x);
if (bar) {
int ret = foo_bar(bar);
free_bar(bar);
return ret;
}
return -1;
}
------ end of foo.cpp

------ raii-foo.cpp
void* allocate_bar(int x);
void free_bar(void* bar);
int foo_bar(void* bar);


class raii_bar {
public:
void* p;
raii_bar(int x) {
p = allocate_bar(x);
}
~raii_bar() {
if (p)
free_bar(p);
}
};

int foo(int x)
{
raii_bar bar(x);
if (bar.p)
return foo_bar(bar.p);
return -1;
}
------ end of raii-foo.cpp

$ gcc -c -Wall -O2 foo.cpp raii-foo.cpp
$ size *.o
text data bss dec hex filename
136 0 0 136 88 foo.o
172 0 0 172 ac raii-foo.o

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 06 Apr 2024 14:56:09 GMT
[email protected] (Scott Lurndal) wrote:

Paavo Helde <[email protected]> writes:

06.04.2024 00:29 Scott Lurndal kirjutas:

Most of C++ is useless cruft with a significant run-time
performance hit.

Classes are genuinely useful, as are namespaces.

So are standard containers, like std::vector and std::map. No
run-time performance hits compared to equivalent solutions in C.

For the most part true of std::vector. Not necessarily for
std::map.

IMHO, std::map is a very good default choice when you start coding and
don't know yet if key-value store is going to be big or small,
predominantly read or with significant updating, performance critical
or not and in need of ordering or there would never be such need.
Of course, normally you figure the part about the need of ordering quite quickly, but sweeping std::map with std:unordered_map is not hard.

The nice thing about std::map is that it's pretty much always within
factor of 10 from the absolutely best custom data structure, both in
memory consumption and in speed, so the choice std::map cam be wrong,
but unlikely to be critically wrong.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07/04/2024 15:00, Michael S wrote:

On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <[email protected]> wrote:

run-time performance hits. But iostreams do not make up most of C++.

Still, the best feature of C++ is RAII (zero run-time performance
hit).

RAII has low run-time cost, although I doubt that it's really zero.
RAII has non-trivial code size cost, esp. when used a lot. See below.
But my main objection with RAII is that I feel like loosing track.

$ gcc -c -Wall -O2 foo.cpp raii-foo.cpp
$ size *.o
text data bss dec hex filename
136 0 0 136 88 foo.o
172 0 0 172 ac raii-foo.o

You will almost certainly find that the overhead here is due to
exception handling and/or RTTI. Add the flag "-fno-execptions
-fno-rtti", and you'll see the same code generated using
<https://godbolt.org>.

For some kinds of code (such as the stuff Scott does, and the stuff I
do), exceptions are an unacceptable overhead, cost and complication in a language. Many other features of C++ - including RAII, templates,
classes, namespaces, strong enums, overloading, concepts, constexpr,
inline variables, smart pointers, and countless other bits and pieces
can be used to get better source code (clearer, simpler, more flexible,
safer, etc.) without inefficiency overheads compared to similar
solutions in C.

Different people have different needs from C++, and use different
features. If I were programming on a PC, I'd happily use std::map<> and
the like. But I don't program on PC's, and I don't use std::map<>. If
I needed something like that, I'd make my own class that fitted my
requirements tightly - a factor of 10 inefficiency is often fine on big systems, but not on the devices I work with.

But that's all fine - use whatever you find useful from the language.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 7 Apr 2024 16:06:02 +0200
David Brown <[email protected]> wrote:

On 07/04/2024 15:00, Michael S wrote:

On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <[email protected]> wrote:

run-time performance hits. But iostreams do not make up most of
C++.

Still, the best feature of C++ is RAII (zero run-time performance
hit).

RAII has low run-time cost, although I doubt that it's really zero.
RAII has non-trivial code size cost, esp. when used a lot. See
below. But my main objection with RAII is that I feel like loosing
track.

$ gcc -c -Wall -O2 foo.cpp raii-foo.cpp
$ size *.o
text data bss dec hex filename
136 0 0 136 88 foo.o
172 0 0 172 ac raii-foo.o

You will almost certainly find that the overhead here is due to
exception handling and/or RTTI. Add the flag "-fno-execptions
-fno-rtti", and you'll see the same code generated using <https://godbolt.org>.

Of course, it is due to exception!
But isn't exception safety the main point behind RAII?

RTTI plays no role here.
Is not RTTI supported only for classes with virtual functions?

For some kinds of code (such as the stuff Scott does, and the stuff I
do), exceptions are an unacceptable overhead, cost and complication
in a language. Many other features of C++ - including RAII,
templates, classes, namespaces, strong enums, overloading, concepts, constexpr, inline variables, smart pointers, and countless other bits
and pieces can be used to get better source code (clearer, simpler,
more flexible, safer, etc.) without inefficiency overheads compared
to similar solutions in C.

I am not a fan of smart pointers.
The other thing you mentioned can help sometimes, but also can make
a mess of your codebase. And I had seen the later more often than the
former.
In particular, classes with big number of members are used by lazy
programmers to have what is in effect global variables without feeling
guilty.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonita Montero <[email protected]> writes:

Am 07.04.2024 um 00:55 schrieb Chris M. Thomasson:

On 4/5/2024 9:04 AM, Bonita Montero wrote:

Am 05.04.2024 um 17:37 schrieb Michael S:

However I know enough to know that Win32 is defined in terms of C.
So I don't quite understand how XHANDLE can be part of it.

It's obvious.

Where is XHANDLE defined wrt any Microsoft documentation? Its not:

It's obvious that XHANDE is some kind of RAII-wrapper.

https://www.logicallyfallacious.com/logicalfallacies/Appeal-to-Self-evident-Truth

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

07.04.2024 16:00 Michael S kirjutas:

On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <[email protected]> wrote:

run-time performance hits. But iostreams do not make up most of C++.

Still, the best feature of C++ is RAII (zero run-time performance
hit).

RAII has low run-time cost, although I doubt that it's really zero.
RAII has non-trivial code size cost, esp. when used a lot. See below.

The last time when I had to worry about code size was in year 1992, with
an Intel 80186 processor. But I understand it might be a concern in some applications.

But my main objection with RAII is that I feel like loosing track.

It's the opposite for me. I feel myself at ease and having control only
after I put a resource release properly under RAII.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 7 Apr 2024 16:39:02 +0200
Bonita Montero <[email protected]> wrote:

Am 07.04.2024 um 15:00 schrieb Michael S:

$ gcc -c -Wall -O2 foo.cpp raii-foo.cpp
$ size *.o
text data bss dec hex filename
136 0 0 136 88 foo.o
172 0 0 172 ac raii-foo.o

That's because of the unrolling code for exceptions. But this
unrolling code is separate and usually not executed. The code
path for the non-exceptional case should have the same perfor-
mance.

Didn't I say it myself about low runtime cost?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07/04/2024 17:37, Michael S wrote:

On Sun, 7 Apr 2024 16:06:02 +0200
David Brown <[email protected]> wrote:

On 07/04/2024 15:00, Michael S wrote:

On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <[email protected]> wrote:

run-time performance hits. But iostreams do not make up most of
C++.

Still, the best feature of C++ is RAII (zero run-time performance
hit).

RAII has low run-time cost, although I doubt that it's really zero.
RAII has non-trivial code size cost, esp. when used a lot. See
below. But my main objection with RAII is that I feel like loosing
track.

$ gcc -c -Wall -O2 foo.cpp raii-foo.cpp
$ size *.o
text data bss dec hex filename
136 0 0 136 88 foo.o
172 0 0 172 ac raii-foo.o

You will almost certainly find that the overhead here is due to
exception handling and/or RTTI. Add the flag "-fno-execptions
-fno-rtti", and you'll see the same code generated using
<https://godbolt.org>.

Of course, it is due to exception!
But isn't exception safety the main point behind RAII?

Not at all!

RAII is about encapsulating an acquire-release pair in a manner that
makes it easy to get right, and hard to get wrong, while minimising the boiler-plate code needed at the time of use. It's convenience for use
with exceptions is almost completely incidental - as demonstrated by its usefulness when exceptions are not used (many C++ users don't use
exceptions, and for a lot of use-cases, particularly embedded uses or
safety or reliability critical code, exceptions are totally banned), and
also by languages that have exceptions but not RAII.

RAII is neither sufficient nor necessary for exception safety, but it
certainly makes exception safety easier.

RTTI plays no role here.

True - but RTTI goes along with exceptions as being a part of C++ that
adds overhead. If you don't use the information, it is generally just
wasted code space, rather than run time inefficiency, but for resource
limited systems, that's a relevant issue.

Is not RTTI supported only for classes with virtual functions?

No, it gets used for dynamic casts, and for identifying the class of a
thrown exception. (At least, I think that's true - wait for others to
either correct me or confirm this before believing it!)

For some kinds of code (such as the stuff Scott does, and the stuff I
do), exceptions are an unacceptable overhead, cost and complication
in a language. Many other features of C++ - including RAII,
templates, classes, namespaces, strong enums, overloading, concepts,
constexpr, inline variables, smart pointers, and countless other bits
and pieces can be used to get better source code (clearer, simpler,
more flexible, safer, etc.) without inefficiency overheads compared
to similar solutions in C.

I am not a fan of smart pointers.

Nobody likes /everything/ in C++ !

The other thing you mentioned can help sometimes, but also can make
a mess of your codebase. And I had seen the later more often than the
former.

With great power, comes great responsibility - that's why we fear it :-)

Useful tools for writing better code can also be used to mess things up
in new and imaginative ways.

In particular, classes with big number of members are used by lazy programmers to have what is in effect global variables without feeling guilty.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <[email protected]> writes:

On Sun, 7 Apr 2024 16:06:02 +0200
David Brown <[email protected]> wrote:

On 07/04/2024 15:00, Michael S wrote:

On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <[email protected]> wrote:

RAII has low run-time cost, although I doubt that it's really zero.
RAII has non-trivial code size cost, esp. when used a lot. See
below. But my main objection with RAII is that I feel like loosing
track.

$ gcc -c -Wall -O2 foo.cpp raii-foo.cpp
$ size *.o
text data bss dec hex filename
136 0 0 136 88 foo.o
172 0 0 172 ac raii-foo.o

You will almost certainly find that the overhead here is due to
exception handling and/or RTTI. Add the flag "-fno-execptions
-fno-rtti", and you'll see the same code generated using
<https://godbolt.org>.

Of course, it is due to exception!
But isn't exception safety the main point behind RAII?

Not necessarily. We used RAII (perhaps before it was called
such) in 1989, in cfront 2.1 (exceptions didn't appear until 3.0)
as a way to bail (return) from a long function (a kernel implementation
of fork) and automatically deallocate various system resources
(assigned credentials, memory map/pt, new process attributes,
process-id, session/process group associations, etc) that
had been allocated before the fork failure was detected.

RTTI plays no role here.
Is not RTTI supported only for classes with virtual functions?

dynamic_cast requires RTTI.

For some kinds of code (such as the stuff Scott does, and the stuff I
do), exceptions are an unacceptable overhead, cost and complication
in a language. Many other features of C++ - including RAII,
templates, classes, namespaces, strong enums, overloading, concepts,
constexpr, inline variables, smart pointers, and countless other bits
and pieces can be used to get better source code (clearer, simpler,
more flexible, safer, etc.) without inefficiency overheads compared
to similar solutions in C.

I am not a fan of smart pointers.

Concur.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)