Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #118653 > unrolled thread

Ain't that beautiful ?

Started byBonita Montero <Bonita.Montero@gmail.com>
First post2024-04-04 20:11 +0200
Last post2024-04-07 18:25 +0300
Articles 20 on this page of 90 — 10 participants

Back to article view | Back to comp.lang.c++

Contents

  Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-04 20:11 +0200
    Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-04 21:55 +0300
      Re: Ain't that beautiful ? Sam <sam@email-scan.com> - 2024-04-04 20:00 -0400
        Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-05 00:21 +0000
          Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-05 17:44 +0300
            Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 17:27 +0200
              Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-05 18:37 +0300
                Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 18:04 +0200
                  Re: Ain't that beautiful ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-06 15:55 -0700
                    Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 08:28 +0200
                      Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-07 15:51 +0000
                        Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:35 +0200
                          Re: Ain't that beautiful ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-07 12:21 -0700
      Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 05:05 +0200
        Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-05 17:52 +0300
          Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 17:26 +0200
            Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-05 20:00 +0000
              Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 22:29 +0200
                Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-05 21:29 +0000
                  Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-06 09:06 +0200
                  Re: Ain't that beautiful ? Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-06 17:29 +0300
                    Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-06 14:56 +0000
                      Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-06 18:34 +0200
                        Re: Ain't that beautiful ? wij <wyniijj5@gmail.com> - 2024-04-07 03:00 +0800
                          Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 08:28 +0200
                            Re: Ain't that beautiful ? wij <wyniijj5@gmail.com> - 2024-04-08 07:47 +0800
                      Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 15:25 +0300
                    Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 16:00 +0300
                      Re: Ain't that beautiful ? David Brown <david.brown@hesbynett.no> - 2024-04-07 16:06 +0200
                        Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 18:37 +0300
                          Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-07 15:58 +0000
                          Re: Ain't that beautiful ? David Brown <david.brown@hesbynett.no> - 2024-04-07 18:00 +0200
                          Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:38 +0200
                        std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-07 18:38 +0300
                          Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-07 18:06 +0200
                            Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-07 19:35 +0300
                              Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-08 11:29 +0200
                                Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 13:34 +0300
                                  Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-08 19:18 +0800
                                    Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 16:32 +0300
                                      Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-09 08:40 +0800
                                        Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 12:48 +0300
                                          Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-09 13:16 +0200
                                  Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-08 15:30 +0200
                                  Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-08 17:19 +0000
                                    Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 00:47 +0300
                                      Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-08 23:00 +0000
                                        Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 02:20 +0300
                                          Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-09 15:22 +0000
                                      Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 09:11 +0200
                                        Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 13:12 +0300
                                          Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 15:01 +0200
                                Re: std::map advocacy Richard Damon <richard@damon-family.org> - 2024-04-08 07:10 -0400
                                  Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-08 15:45 +0200
                                    Re: std::map advocacy James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-04-08 19:42 -0400
                                      Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 09:45 +0200
                                        Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 13:27 +0300
                                          Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 15:13 +0200
                                            Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 18:12 +0300
                                              Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 18:22 +0200
                                              Re: std::map advocacy James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-04-10 02:24 -0400
                                                Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 00:07 +0300
                                                  Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 16:18 +0300
                                                    Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 16:39 +0300
                                                      Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-11 16:21 +0200
                                                    Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-11 15:31 +0200
                                                  Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-11 22:40 +0800
                                                    Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-11 16:55 +0200
                                                  Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 16:13 +0300
                                                    Re: std::map advocacy Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-11 18:18 +0300
                                                  Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-11 09:57 +0200
                                                    Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-11 13:47 +0200
                                                      Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-11 14:04 +0200
                                                    Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-11 19:25 +0800
                          Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-07 16:09 +0000
                            Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-07 19:48 +0300
                              Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:45 +0200
                            Re: std::map advocacy Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-08 16:37 +0300
                          Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:44 +0200
                            Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 11:15 +0300
                              Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-08 14:09 +0200
                                Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 16:26 +0300
                                  Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-08 16:54 +0200
                                    Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 20:52 +0300
                                      Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 00:17 +0300
                                      Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-09 07:34 +0200
                      Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 16:39 +0200
                        Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 18:41 +0300
                          Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:36 +0200
                      Re: Ain't that beautiful ? Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-07 18:25 +0300

Page 1 of 5  [1] 2 3 4 5  Next page →

#118653 — Ain't that beautiful ?

FromBonita Montero <Bonita.Montero@gmail.com>
Date2024-04-04 20:11 +0200
SubjectAin't that beautiful ?
Message-ID<uumqfq$q6p0$1@raubtier-asyl.eternal-september.org>
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;
}

[toc] | [next] | [standalone]

#118654

FromMichael S <already5chosen@yahoo.com>
Date2024-04-04 21:55 +0300
Message-ID<20240404215534.0000623d@yahoo.com>
In reply to#118653
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. 
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!

[toc] | [prev] | [next] | [standalone]

#118655

FromSam <sam@email-scan.com>
Date2024-04-04 20:00 -0400
Message-ID<cone.1712275227.292802.483430.1004@monster.email-scan.com>
In reply to#118654
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.

[toc] | [prev] | [next] | [standalone]

#118656

Fromscott@slp53.sl.home (Scott Lurndal)
Date2024-04-05 00:21 +0000
Message-ID<CuHPN.189578$taff.30721@fx41.iad>
In reply to#118655
Sam <sam@email-scan.com> writes:
>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.
>

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;
}

[toc] | [prev] | [next] | [standalone]

#118659

FromMichael S <already5chosen@yahoo.com>
Date2024-04-05 17:44 +0300
Message-ID<20240405174448.00001e50@yahoo.com>
In reply to#118656
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.

[toc] | [prev] | [next] | [standalone]

#118662

FromBonita Montero <Bonita.Montero@gmail.com>
Date2024-04-05 17:27 +0200
Message-ID<uup59h$1esu3$2@raubtier-asyl.eternal-september.org>
In reply to#118659
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.

[toc] | [prev] | [next] | [standalone]

#118663

FromMichael S <already5chosen@yahoo.com>
Date2024-04-05 18:37 +0300
Message-ID<20240405183723.0000585f@yahoo.com>
In reply to#118662
On Fri, 5 Apr 2024 17:27:49 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> 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.

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.

[toc] | [prev] | [next] | [standalone]

#118664

FromBonita Montero <Bonita.Montero@gmail.com>
Date2024-04-05 18:04 +0200
Message-ID<uup7dg$1febk$1@raubtier-asyl.eternal-september.org>
In reply to#118663
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.

[toc] | [prev] | [next] | [standalone]

#118673

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2024-04-06 15:55 -0700
Message-ID<uusjso$2bl1s$1@dont-email.me>
In reply to#118664
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?

[toc] | [prev] | [next] | [standalone]

#118675

FromBonita Montero <Bonita.Montero@gmail.com>
Date2024-04-07 08:28 +0200
Message-ID<uuteen$2kq8k$2@raubtier-asyl.eternal-september.org>
In reply to#118673
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://learn.microsoft.com/en-us/cpp/atl/reference/chandle-class?view=msvc-170
> 
> Right?
> 
>

[toc] | [prev] | [next] | [standalone]

#118684

Fromscott@slp53.sl.home (Scott Lurndal)
Date2024-04-07 15:51 +0000
Message-ID<hizQN.166156$46Te.75316@fx38.iad>
In reply to#118675
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

[toc] | [prev] | [next] | [standalone]

#118691

FromBonita Montero <Bonita.Montero@gmail.com>
Date2024-04-07 19:35 +0200
Message-ID<uuulgg$2tk05$1@raubtier-asyl.eternal-september.org>
In reply to#118684
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.

[toc] | [prev] | [next] | [standalone]

#118696

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2024-04-07 12:21 -0700
Message-ID<uuurom$2utdf$2@dont-email.me>
In reply to#118691
On 4/7/2024 10:35 AM, Bonita Montero wrote:
> 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.

I was just wondering if it was actually a CHandle, or what.

[toc] | [prev] | [next] | [standalone]

#118658

FromBonita Montero <Bonita.Montero@gmail.com>
Date2024-04-05 05:05 +0200
Message-ID<uunpq1$14t9p$1@raubtier-asyl.eternal-september.org>
In reply to#118654
Am 04.04.2024 um 20:55 schrieb Michael S:
> 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.

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.

[toc] | [prev] | [next] | [standalone]

#118660

FromMichael S <already5chosen@yahoo.com>
Date2024-04-05 17:52 +0300
Message-ID<20240405175257.000066a0@yahoo.com>
In reply to#118658
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.

> > 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.

[toc] | [prev] | [next] | [standalone]

#118661

FromBonita Montero <Bonita.Montero@gmail.com>
Date2024-04-05 17:26 +0200
Message-ID<uup56c$1esu3$1@raubtier-asyl.eternal-september.org>
In reply to#118660
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. The standard library
can thow bad_alloc(), system_error() from a lot of places and if
you use C++ you must handle these exceptions.

> Your template supposed to be provided as generic utility, right?

In some cases the immediate caller needs the error code and in other
cases you would pass the exceptions a few call levels higher; my code
can handle both.

[toc] | [prev] | [next] | [standalone]

#118665

Fromscott@slp53.sl.home (Scott Lurndal)
Date2024-04-05 20:00 +0000
Message-ID<GLYPN.6$zaCc.4@fx08.iad>
In reply to#118661
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.

[toc] | [prev] | [next] | [standalone]

#118666

FromBonita Montero <Bonita.Montero@gmail.com>
Date2024-04-05 22:29 +0200
Message-ID<uupmvv$1j8sq$1@raubtier-asyl.eternal-september.org>
In reply to#118665
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++.

[toc] | [prev] | [next] | [standalone]

#118667

Fromscott@slp53.sl.home (Scott Lurndal)
Date2024-04-05 21:29 +0000
Message-ID<03_PN.124502$U1cc.11575@fx04.iad>
In reply to#118666
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.

[toc] | [prev] | [next] | [standalone]

#118668

FromBonita Montero <Bonita.Montero@gmail.com>
Date2024-04-06 09:06 +0200
Message-ID<uuqsa9$1unv9$1@raubtier-asyl.eternal-september.org>
In reply to#118667
Am 05.04.2024 um 23:29 schrieb Scott Lurndal:
> 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.

That's not true. Nearly all C++ features don't have
an additional performance hit.

> Classes are genuinely useful, as are namespaces.

You're a simple mind.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web