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;
}
On Thu, 4 Apr 2024 20:11:10 +0200
Bonita Montero <Bonita.Montero@gmail.com> 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.
Michael S writes:
On Thu, 4 Apr 2024 20:11:10 +0200
Bonita Montero <Bonita.Montero@gmail.com> 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.
On Thu, 4 Apr 2024 20:11:10 +0200
Bonita Montero <Bonita.Montero@gmail.com> 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.
And not being able to open file is most certainly *not* an exceptional situation!
Concur. It appears to leak file handles as well.
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.
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.
And not being able to open file is most certainly *not* an
exceptional situation!
You can't say that across the board.
On Fri, 5 Apr 2024 05:05:40 +0200
Bonita Montero <Bonita.Montero@gmail.com> 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.
Your template supposed to be provided as generic utility, right?
On Fri, 05 Apr 2024 00:21:54 GMT
scott@slp53.sl.home (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.
Am 05.04.2024 um 16:44 schrieb Michael S:
On Fri, 05 Apr 2024 00:21:54 GMT
scott@slp53.sl.home (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.
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.
Am 05.04.2024 um 16:52 schrieb Michael S:
On Fri, 5 Apr 2024 05:05:40 +0200
Bonita Montero <Bonita.Montero@gmail.com> 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.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 05.04.2024 um 16:52 schrieb Michael S:
On Fri, 5 Apr 2024 05:05:40 +0200
Bonita Montero <Bonita.Montero@gmail.com> 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.
Am 05.04.2024 um 22:00 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 05.04.2024 um 16:52 schrieb Michael S:
On Fri, 5 Apr 2024 05:05:40 +0200
Bonita Montero <Bonita.Montero@gmail.com> 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++.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 05.04.2024 um 22:00 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 05.04.2024 um 16:52 schrieb Michael S:
On Fri, 5 Apr 2024 05:05:40 +0200
Bonita Montero <Bonita.Montero@gmail.com> 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.
Most of C++ is useless cruft with a significant run-time
performance hit.
Classes are genuinely useful, as are namespaces.
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).
For the most part true of std::vector. Not necessarily for
std::map.
Poorly used, templates increase the code footprint, ...
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.
Useful, but can easily be abused (e.g. for locking).
Am 06.04.2024 um 16:56 schrieb Scott Lurndal:
For the most part true of std::vector. Not necessarily for
std::map.
Show me a better key-value data structure when you
also need to iterate through the KVs in sorting order.
Poorly used, templates increase the code footprint, ...
They're fast and the code-foooprint may not be tolerable only on very
small systems.
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.
Then don't throw exceptions through that foreign code. I'm often using lambdas without captures as callbacks to C-interfaces with Win32. With
these callback's I can't use exceptions but that's not a problem.
Useful, but can easily be abused (e.g. for locking).
Ok, "can be abused", then drop it ! ;-)
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.
On Sat, 2024-04-06 at 18:34 +0200, Bonita Montero wrote:
Am 06.04.2024 um 16:56 schrieb Scott Lurndal:I estimate ::hsearch(...) is about 20 times faster than std::map, that says it all,
For the most part true of std::vector. Not necessarily for
std::map.
although the key is limited to c-string.
Show me a better key-value data structure when you
also need to iterate through the KVs in sorting order.
Poorly used, templates increase the code footprint, ...
They're fast and the code-foooprint may not be tolerable only on very
small systems.
One of the worst part of C++ is memory consumption, compared with C.
Let's say C program can solve problems of size X, C++ normally solves of size X/2.
This is equivalent to time performance in larger size.
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.
Then don't throw exceptions through that foreign code. I'm often using
lambdas without captures as callbacks to C-interfaces with Win32. With
these callback's I can't use exceptions but that's not a problem.
The problem of 'throw' is context-loss and time cost. For context-loss, you generally
won't be able to have library-level reusable codes. 'Throw' is normally one thousand
times slower than return, this part is, generally speaking, doomed.
The problem of std::exception family is simply unnecessarily complex.
Useful, but can easily be abused (e.g. for locking).
Ok, "can be abused", then drop it ! ;-)
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:
https://learn.microsoft.com/en-us/cpp/atl/reference/chandle-class?view=msvc-170
Right?
Paavo Helde <eesnimi@osa.pri.ee> 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.
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).
On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <eesnimi@osa.pri.ee> 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
$ 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
On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <eesnimi@osa.pri.ee> 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.
On 07/04/2024 15:00, Michael S wrote:
On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <eesnimi@osa.pri.ee> 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.
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.
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.
On Sun, 7 Apr 2024 16:06:02 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 07/04/2024 15:00, Michael S wrote:
On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <eesnimi@osa.pri.ee> 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?
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.
On Sun, 7 Apr 2024 16:06:02 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 07/04/2024 15:00, Michael S wrote:
On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <eesnimi@osa.pri.ee> 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.
Bonita Montero <Bonita.Montero@gmail.com> 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
On Sun, 7 Apr 2024 16:39:02 +0200
Bonita Montero <Bonita.Montero@gmail.com> 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?
RTTI plays no role here.
Is not RTTI supported only for classes with virtual functions?
In particular, classes with big number of members are used by lazy programmers to have what is in effect global variables without feeling guilty.
Am 07.04.2024 um 17:51 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> 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
My XHANDLE has nearly the same name like a HANDLE and takes a HANDLE
as its constructor parameter, so this is obvious.
Am 06.04.2024 um 21:00 schrieb wij:
On Sat, 2024-04-06 at 18:34 +0200, Bonita Montero wrote:
Am 06.04.2024 um 16:56 schrieb Scott Lurndal:
For the most part true of std::vector. Not necessarily for std::map.
I estimate ::hsearch(...) is about 20 times faster than std::map, that says it all,
although the key is limited to c-string.
A tree is slow, but if you need to iterate with key order there's
nothing faster. Hash-maps are O(1) are faster but you can't traverse
the KVs in key-order.
Show me a better key-value data structure when you
also need to iterate through the KVs in sorting order.
Poorly used, templates increase the code footprint, ...
They're fast and the code-foooprint may not be tolerable only on very small systems.
One of the worst part of C++ is memory consumption, compared with C.
C++ is not known for its bad memory consumption.
Let's say C program can solve problems of size X, C++ normally solves of size X/2.
This is equivalent to time performance in larger size.
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.
Then don't throw exceptions through that foreign code. I'm often using lambdas without captures as callbacks to C-interfaces with Win32. With these callback's I can't use exceptions but that's not a problem.
The problem of 'throw' is context-loss and time cost. For context-loss, you generally
won't be able to have library-level reusable codes. 'Throw' is normally one thousand
times slower than return, this part is, generally speaking, doomed.
Exceptions are only thrown in exceptional cases like I/O-errors or a
memory collapse. That happens very rarely and performance of thrown exceptions doens't count.
The problem of std::exception family is simply unnecessarily complex.
Useful, but can easily be abused (e.g. for locking).
Ok, "can be abused", then drop it ! ;-)
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 915 |
Nodes: | 10 (1 / 9) |
Uptime: | 22:05:29 |
Calls: | 12,168 |
Files: | 186,520 |
Messages: | 2,233,970 |