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

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

Visual C++ 2019 is having a hissy fit over these two lines of code

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

Contents

  Visual C++ 2019 is having a hissy fit over these two lines of code Lynn McGuire <lynnmcguire5@gmail.com> - 2023-07-19 21:46 -0500
    Re: Visual C++ 2019 is having a hissy fit over these two lines of code Lynn McGuire <lynnmcguire5@gmail.com> - 2023-07-19 21:48 -0500
      Re: Visual C++ 2019 is having a hissy fit over these two lines of code Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-07-19 21:46 -0700
        Re: Visual C++ 2019 is having a hissy fit over these two lines of code Lynn McGuire <lynnmcguire5@gmail.com> - 2023-07-20 00:31 -0500
          Re: Visual C++ 2019 is having a hissy fit over these two lines of code Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-19 22:51 -0700
          Re: Visual C++ 2019 is having a hissy fit over these two lines of code Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-20 16:11 +0200
            Re: Visual C++ 2019 is having a hissy fit over these two lines of code "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-20 12:57 -0700
              Re: Visual C++ 2019 is having a hissy fit over these two lines of code Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-21 04:51 +0200
                Re: Visual C++ 2019 is having a hissy fit over these two lines of code "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-21 12:59 -0700
      Re: Visual C++ 2019 is having a hissy fit over these two lines of code "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-07-20 09:04 +0200
        Re: Visual C++ 2019 is having a hissy fit over these two lines of code Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-07-20 23:20 -0400
      Re: Visual C++ 2019 is having a hissy fit over these two lines of code Paavo Helde <eesnimi@osa.pri.ee> - 2023-07-20 11:22 +0300
        Re: Visual C++ 2019 is having a hissy fit over these two lines of code Lynn McGuire <lynnmcguire5@gmail.com> - 2023-07-20 14:05 -0500
          Re: Visual C++ 2019 is having a hissy fit over these two lines of code Paavo Helde <eesnimi@osa.pri.ee> - 2023-07-20 23:32 +0300
      Re: Visual C++ 2019 is having a hissy fit over these two lines of code Ralf Fassel <ralfixx@gmx.de> - 2023-07-20 15:19 +0200
    Re: Visual C++ 2019 is having a hissy fit over these two lines of code Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-20 01:53 -0700
      Re: Visual C++ 2019 is having a hissy fit over these two lines of code Lynn McGuire <lynnmcguire5@gmail.com> - 2023-07-20 14:19 -0500
        Re: Visual C++ 2019 is having a hissy fit over these two lines of code Paavo Helde <eesnimi@osa.pri.ee> - 2023-07-20 23:27 +0300

#91152 — Visual C++ 2019 is having a hissy fit over these two lines of code

And Visual C++ 2019 is having a hissy fit over these two lines of code:

static const size_t size_t_max = std::numeric_limits<size_t>::max();
static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();

That code worked just fine in Visual C++ 2015.  What am I screwing up here ?

Thanks,
Lynn

[toc] | [next] | [standalone]

#91153

On 7/19/2023 9:46 PM, Lynn McGuire wrote:
> And Visual C++ 2019 is having a hissy fit over these two lines of code:
> 
> static const size_t size_t_max = std::numeric_limits<size_t>::max();
> static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();
> 
> That code worked just fine in Visual C++ 2015.  What am I screwing up 
> here ?
> 
> Thanks,
> Lynn

You know, I should give the error code:

Severity	Code	Description	Project	File	Line	Suppression State
Error	C2440	'initializing': cannot convert from 'unsigned int (__cdecl 
*)(void) noexcept' to 'fem::size_t'	dii_c_library 
C:\dii\inc\fem\size_t.hpp	12	

And here is the file:

#ifndef FEM_SIZE_T_HPP
#define FEM_SIZE_T_HPP

#include <limits>
#include <cstddef>

namespace fem {

   typedef std::size_t size_t;
   typedef std::ptrdiff_t ssize_t;

   static const size_t size_t_max = std::numeric_limits<size_t>::max();
   static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();

   template <typename T>
   struct array_of_2
   {
     T elems[2];

     array_of_2() {}

     array_of_2(T const& i, T const& j) { elems[0] = i; elems[1] = j; }
   };

   typedef array_of_2<size_t> size_t_2;
   typedef array_of_2<ssize_t> ssize_t_2;

} // namespace fem

#endif // GUARD

Thanks,
Lynn

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

#91154

On 07/19/23 7:48 PM, Lynn McGuire wrote:
> You know, I should give the error code:

Compiles perfectly fine in my VS2019.

The first thought was that it was just another example of the well-known 
conflict with Windows' own min/max macros. But regardless of `NOMINMAX` 
state, this code compiled without any issues for me.

-- 
Best regards,
Andrey

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

#91155

On 7/19/2023 11:46 PM, Andrey Tarasevich wrote:
> On 07/19/23 7:48 PM, Lynn McGuire wrote:
>> You know, I should give the error code:
> 
> Compiles perfectly fine in my VS2019.
> 
> The first thought was that it was just another example of the well-known 
> conflict with Windows' own min/max macros. But regardless of `NOMINMAX` 
> state, this code compiled without any issues for me.

Thanks !

I can fix the problem by replacing the 
std::numeric_limits<size_t>::max(); with UINT_MAX.  But, that is a cheat.

Thanks,
Lynn

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

#91156

Lynn McGuire <lynnmcguire5@gmail.com> writes:
> On 7/19/2023 11:46 PM, Andrey Tarasevich wrote:
>> On 07/19/23 7:48 PM, Lynn McGuire wrote:
>>> You know, I should give the error code:
>> Compiles perfectly fine in my VS2019.
>> The first thought was that it was just another example of the
>> well-known conflict with Windows' own min/max macros. But regardless
>> of `NOMINMAX` state, this code compiled without any issues for me.
>
> Thanks !
>
> I can fix the problem by replacing the
> std::numeric_limits<size_t>::max(); with UINT_MAX.  But, that is a
> cheat.

Surely you mean SIZE_MAX, defined in <cstdint>.  (It's common for int to
be 32 bits and size_t 64 bits.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#91162

Am 20.07.2023 um 07:31 schrieb Lynn McGuire:
> On 7/19/2023 11:46 PM, Andrey Tarasevich wrote:
>> On 07/19/23 7:48 PM, Lynn McGuire wrote:
>>> You know, I should give the error code:
>>
>> Compiles perfectly fine in my VS2019.
>>
>> The first thought was that it was just another example of the 
>> well-known conflict with Windows' own min/max macros. But regardless 
>> of `NOMINMAX` state, this code compiled without any issues for me.
> 
> Thanks !
> 
> I can fix the problem by replacing the 
> std::numeric_limits<size_t>::max(); with UINT_MAX.  But, that is a cheat.

For me is #define-ing NOMIMMAX before including <Windows.h>
the smarter solution.

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

#91168

On 7/20/2023 7:11 AM, Bonita Montero wrote:
> Am 20.07.2023 um 07:31 schrieb Lynn McGuire:
>> On 7/19/2023 11:46 PM, Andrey Tarasevich wrote:
>>> On 07/19/23 7:48 PM, Lynn McGuire wrote:
>>>> You know, I should give the error code:
>>>
>>> Compiles perfectly fine in my VS2019.
>>>
>>> The first thought was that it was just another example of the 
>>> well-known conflict with Windows' own min/max macros. But regardless 
>>> of `NOMINMAX` state, this code compiled without any issues for me.
>>
>> Thanks !
>>
>> I can fix the problem by replacing the 
>> std::numeric_limits<size_t>::max(); with UINT_MAX.  But, that is a cheat.
> 
> For me is #define-ing NOMIMMAX before including <Windows.h>
> the smarter solution.
> 
> 

Don't forget  WIN32_LEAN_AND_MEAN ... :^)

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

#91174

Am 20.07.2023 um 21:57 schrieb Chris M. Thomasson:
> On 7/20/2023 7:11 AM, Bonita Montero wrote:
>> Am 20.07.2023 um 07:31 schrieb Lynn McGuire:
>>> On 7/19/2023 11:46 PM, Andrey Tarasevich wrote:
>>>> On 07/19/23 7:48 PM, Lynn McGuire wrote:
>>>>> You know, I should give the error code:
>>>>
>>>> Compiles perfectly fine in my VS2019.
>>>>
>>>> The first thought was that it was just another example of the 
>>>> well-known conflict with Windows' own min/max macros. But regardless 
>>>> of `NOMINMAX` state, this code compiled without any issues for me.
>>>
>>> Thanks !
>>>
>>> I can fix the problem by replacing the 
>>> std::numeric_limits<size_t>::max(); with UINT_MAX.  But, that is a 
>>> cheat.
>>
>> For me is #define-ing NOMIMMAX before including <Windows.h>
>> the smarter solution.
>>
>>
> 
> Don't forget  WIN32_LEAN_AND_MEAN ... :^)

That's 100ms difference when compiling for me (7950X).

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

#91178

On 7/20/2023 7:51 PM, Bonita Montero wrote:
> Am 20.07.2023 um 21:57 schrieb Chris M. Thomasson:
>> On 7/20/2023 7:11 AM, Bonita Montero wrote:
>>> Am 20.07.2023 um 07:31 schrieb Lynn McGuire:
>>>> On 7/19/2023 11:46 PM, Andrey Tarasevich wrote:
>>>>> On 07/19/23 7:48 PM, Lynn McGuire wrote:
>>>>>> You know, I should give the error code:
>>>>>
>>>>> Compiles perfectly fine in my VS2019.
>>>>>
>>>>> The first thought was that it was just another example of the 
>>>>> well-known conflict with Windows' own min/max macros. But 
>>>>> regardless of `NOMINMAX` state, this code compiled without any 
>>>>> issues for me.
>>>>
>>>> Thanks !
>>>>
>>>> I can fix the problem by replacing the 
>>>> std::numeric_limits<size_t>::max(); with UINT_MAX.  But, that is a 
>>>> cheat.
>>>
>>> For me is #define-ing NOMIMMAX before including <Windows.h>
>>> the smarter solution.
>>>
>>>
>>
>> Don't forget  WIN32_LEAN_AND_MEAN ... :^)
> 
> That's 100ms difference when compiling for me (7950X).
> 

:^) Still, its something that was ingrained in my brain from long ago.

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

#91157

On 2023-07-20 4:48 AM, Lynn McGuire wrote:
> On 7/19/2023 9:46 PM, Lynn McGuire wrote:
>> And Visual C++ 2019 is having a hissy fit over these two lines of code:
>>
>> static const size_t size_t_max = std::numeric_limits<size_t>::max();
>> static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();
>>
>> That code worked just fine in Visual C++ 2015.  What am I screwing up 
>> here ?
>>
>> Thanks,
>> Lynn
> 
> You know, I should give the error code:
> 
> Severity    Code    Description    Project    File    Line    
> Suppression State
> Error    C2440    'initializing': cannot convert from 'unsigned int 
> (__cdecl *)(void) noexcept' to 'fem::size_t'    dii_c_library 
> C:\dii\inc\fem\size_t.hpp    12
> 
> And here is the file:
> 
> #ifndef FEM_SIZE_T_HPP
> #define FEM_SIZE_T_HPP
> 
> #include <limits>
> #include <cstddef>
> 
> namespace fem {
> 
>    typedef std::size_t size_t;
>    typedef std::ptrdiff_t ssize_t;
> 
>    static const size_t size_t_max = std::numeric_limits<size_t>::max();
>    static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();
> 
>    template <typename T>
>    struct array_of_2
>    {
>      T elems[2];
> 
>      array_of_2() {}
> 
>      array_of_2(T const& i, T const& j) { elems[0] = i; elems[1] = j; }
>    };
> 
>    typedef array_of_2<size_t> size_t_2;
>    typedef array_of_2<ssize_t> ssize_t_2;
> 
> } // namespace fem
> 
> #endif // GUARD

I can't see anything technically wrong and it compiles fine with current 
Visual C++ and g++.

Not what you're asking but note that

* `typedef` is old C syntax, modern `using` can be more clear.
* `const` at namespace scope implies `static`, i.e. no need to repeat.
* `array_of_2` won't work for T that's not default constructible.

Here's re-styling of the code with the above 3 points addressed:

     #pragma once
     #include <limits>       // std::numeric_limits
     #include <utility>      // std::move
     #include <cstddef>      // std::(size_t, ptrdiff_t)

     namespace fem {
         using   std::numeric_limits,
                 std::move;

         using size_t    = std::size_t;
         using ssize_t   = std::ptrdiff_t;

         template< class Type >
         constexpr Type max_ = numeric_limits<Type>::max();

         constexpr size_t  size_t_max  = max_<size_t>;
         constexpr ssize_t ssize_t_max = max_<ssize_t>;

         template< class T >
         struct array_of_2_
         {
             T elems[2];

             array_of_2_() {}
             array_of_2_( T a, T b ): elems{ move( a ), move( b ) } {}
         };

         using size_t_2    = array_of_2_<size_t> ;
         using ssize_t_2   = array_of_2_<ssize_t> ;
     } // namespace fem

- Alf

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

#91175

Alf P. Steinbach wrote:
> On 2023-07-20 4:48 AM, Lynn McGuire wrote:
>> On 7/19/2023 9:46 PM, Lynn McGuire wrote:
>>> And Visual C++ 2019 is having a hissy fit over these two lines of code:
>>>
>>> static const size_t size_t_max = std::numeric_limits<size_t>::max();
>>> static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();
>>>
>>> That code worked just fine in Visual C++ 2015.  What am I screwing up 
>>> here ?
>>>
>>> Thanks,
>>> Lynn
>>
>> You know, I should give the error code:
>>
>> Severity    Code    Description    Project    File    Line Suppression 
>> State
>> Error    C2440    'initializing': cannot convert from 'unsigned int 
>> (__cdecl *)(void) noexcept' to 'fem::size_t'    dii_c_library 
>> C:\dii\inc\fem\size_t.hpp    12
>>
>> And here is the file:
>>
>> #ifndef FEM_SIZE_T_HPP
>> #define FEM_SIZE_T_HPP
>>
>> #include <limits>
>> #include <cstddef>
>>
>> namespace fem {
>>
>>    typedef std::size_t size_t;
>>    typedef std::ptrdiff_t ssize_t;
>>
>>    static const size_t size_t_max = std::numeric_limits<size_t>::max();
>>    static const ssize_t ssize_t_max = 
>> std::numeric_limits<ssize_t>::max();
>>
>>    template <typename T>
>>    struct array_of_2
>>    {
>>      T elems[2];
>>
>>      array_of_2() {}
>>
>>      array_of_2(T const& i, T const& j) { elems[0] = i; elems[1] = j; }
>>    };
>>
>>    typedef array_of_2<size_t> size_t_2;
>>    typedef array_of_2<ssize_t> ssize_t_2;
>>
>> } // namespace fem
>>
>> #endif // GUARD
> 
> I can't see anything technically wrong and it compiles fine with current 
> Visual C++ and g++.
> 
> Not what you're asking but note that
> 
> * `typedef` is old C syntax, modern `using` can be more clear.
Any code is written to be read by humans. Uniform hurts the readability, 
specific improves it. Plus, using declaration make the reader read more 
tokens. Upshot: use typedef where you can and using where you can't.

> * `const` at namespace scope implies `static`, i.e. no need to repeat.
Another change from more to less readable code. In order to know a 
declaration is in a namespace, one has to either keep this in mind or 
look up. The former is inefficient in space, the latter -- in time. 
Upshot: feel free to be helpful and use static.

Morale: a new shiny multitool is not a universally good replacement for 
the old good pliers.

> * `array_of_2` won't work for T that's not default constructible.
> 
> Here's re-styling of the code with the above 3 points addressed:
> 
>      #pragma once
>      #include <limits>       // std::numeric_limits
>      #include <utility>      // std::move
>      #include <cstddef>      // std::(size_t, ptrdiff_t)
> 
>      namespace fem {
>          using   std::numeric_limits,
>                  std::move;
> 
>          using size_t    = std::size_t;
>          using ssize_t   = std::ptrdiff_t;
> 
>          template< class Type >
>          constexpr Type max_ = numeric_limits<Type>::max();
> 
>          constexpr size_t  size_t_max  = max_<size_t>;
>          constexpr ssize_t ssize_t_max = max_<ssize_t>;
> 
>          template< class T >
>          struct array_of_2_
>          {
>              T elems[2];
> 
>              array_of_2_() {}
>              array_of_2_( T a, T b ): elems{ move( a ), move( b ) } {}
>          };
> 
>          using size_t_2    = array_of_2_<size_t> ;
>          using ssize_t_2   = array_of_2_<ssize_t> ;
>      } // namespace fem
> 
> - Alf
> 
> 

Cheers,
-Pavel

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

#91158

20.07.2023 05:48 Lynn McGuire kirjutas:
> On 7/19/2023 9:46 PM, Lynn McGuire wrote:
>> And Visual C++ 2019 is having a hissy fit over these two lines of code:
>>
>> static const size_t size_t_max = std::numeric_limits<size_t>::max();
>> static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();
>>
>> That code worked just fine in Visual C++ 2015.  What am I screwing up 
>> here ?
>>
>> Thanks,
>> Lynn
> 
> You know, I should give the error code:
> 
> Severity    Code    Description    Project    File    Line    
> Suppression State
> Error    C2440    'initializing': cannot convert from 'unsigned int 
> (__cdecl *)(void) noexcept' to 'fem::size_t'    dii_c_library 
> C:\dii\inc\fem\size_t.hpp    12


This complains about converting a function to an integer. The following 
line would emit the same error:

static const size_t size_t_max = std::numeric_limits<size_t>::max;

Suspecting either you did not post the actual failing code, or there is 
some evil macro hackery going on. To figure that out, hover the mouse 
over 'max', or right-click on it and select 'go to definition'.

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

#91166

On 7/20/2023 3:22 AM, Paavo Helde wrote:
> 20.07.2023 05:48 Lynn McGuire kirjutas:
>> On 7/19/2023 9:46 PM, Lynn McGuire wrote:
>>> And Visual C++ 2019 is having a hissy fit over these two lines of code:
>>>
>>> static const size_t size_t_max = std::numeric_limits<size_t>::max();
>>> static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();
>>>
>>> That code worked just fine in Visual C++ 2015.  What am I screwing up 
>>> here ?
>>>
>>> Thanks,
>>> Lynn
>>
>> You know, I should give the error code:
>>
>> Severity    Code    Description    Project    File    Line Suppression 
>> State
>> Error    C2440    'initializing': cannot convert from 'unsigned int 
>> (__cdecl *)(void) noexcept' to 'fem::size_t'    dii_c_library 
>> C:\dii\inc\fem\size_t.hpp    12
> 
> 
> This complains about converting a function to an integer. The following 
> line would emit the same error:
> 
> static const size_t size_t_max = std::numeric_limits<size_t>::max;
> 
> Suspecting either you did not post the actual failing code, or there is 
> some evil macro hackery going on. To figure that out, hover the mouse 
> over 'max', or right-click on it and select 'go to definition'.

I get the following "limits" code for min and max.

template <>
class numeric_limits<unsigned int> : public _Num_int_base {
public:
     _NODISCARD static constexpr unsigned int(min)() noexcept {
         return 0;
     }

     _NODISCARD static constexpr unsigned int(max)() noexcept {
         return UINT_MAX;
     }


Thanks,
Lynn

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

#91171

20.07.2023 22:05 Lynn McGuire kirjutas:
> On 7/20/2023 3:22 AM, Paavo Helde wrote:
>> 20.07.2023 05:48 Lynn McGuire kirjutas:
>>> On 7/19/2023 9:46 PM, Lynn McGuire wrote:
>>>> And Visual C++ 2019 is having a hissy fit over these two lines of code:
>>>>
>>>> static const size_t size_t_max = std::numeric_limits<size_t>::max();
>>>> static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();
>>>>
>>>> That code worked just fine in Visual C++ 2015.  What am I screwing 
>>>> up here ?
>>>>
>>>> Thanks,
>>>> Lynn
>>>
>>> You know, I should give the error code:
>>>
>>> Severity    Code    Description    Project    File    Line 
>>> Suppression State
>>> Error    C2440    'initializing': cannot convert from 'unsigned int 
>>> (__cdecl *)(void) noexcept' to 'fem::size_t'    dii_c_library 
>>> C:\dii\inc\fem\size_t.hpp    12
>>
>>
>> This complains about converting a function to an integer. The 
>> following line would emit the same error:
>>
>> static const size_t size_t_max = std::numeric_limits<size_t>::max;
>>
>> Suspecting either you did not post the actual failing code, or there 
>> is some evil macro hackery going on. To figure that out, hover the 
>> mouse over 'max', or right-click on it and select 'go to definition'.
> 
> I get the following "limits" code for min and max.
> 
> template <>
> class numeric_limits<unsigned int> : public _Num_int_base {
> public:
>      _NODISCARD static constexpr unsigned int(min)() noexcept {
>          return 0;
>      }
> 
>      _NODISCARD static constexpr unsigned int(max)() noexcept {
>          return UINT_MAX;
>      }

This is the correct definition which ought to be used. Incidentally, 
this shows MS is also protecting itself from evil macro hackery (mostly 
caused by MS itself), by placing min and max in parens.

In general, if Visual Studio is acting weird, sometimes it might be 
helpful to Rebuild All, and/or to even delete the .vs folder where it 
caches a lot of things.

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

#91161

* Lynn McGuire <lynnmcguire5@gmail.com>
| Severity	Code	Description	Project	File	Line	Suppression State
| Error C2440 'initializing': cannot convert from 'unsigned int (__cdecl
| *)(void) noexcept' to 'fem::size_t' dii_c_library
| C:\dii\inc\fem\size_t.hpp	12	
>
| And here is the file:
>
| #ifndef FEM_SIZE_T_HPP
| #define FEM_SIZE_T_HPP
>
| #include <limits>
| #include <cstddef>
>
| namespace fem {
>
|   typedef std::size_t size_t;
|   typedef std::ptrdiff_t ssize_t;
>
|   static const size_t size_t_max = std::numeric_limits<size_t>::max();
|   static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();

Check whether

  #undef max
  static const size_t size_t_max = std::numeric_limits<size_t>::max();

makes a difference at that position.  If so, it *is* the 'max' macro,
and it very much depends on other include files before the current one
whether this triggers or not.

HTH
R'

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

#91160

On Thursday, 20 July 2023 at 03:47:12 UTC+1, Lynn McGuire wrote:
> And Visual C++ 2019 is having a hissy fit over these two lines of code: 
> 
> static const size_t size_t_max = std::numeric_limits<size_t>::max(); 
> static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max(); 
> 
> That code worked just fine in Visual C++ 2015. What am I screwing up here ? 
> 
> Thanks, 
> Lynn
>
Try
static const size_t size_t_max = (std::numeric_limits<size_t>::max)();

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

#91167

On 7/20/2023 3:53 AM, Malcolm McLean wrote:
> On Thursday, 20 July 2023 at 03:47:12 UTC+1, Lynn McGuire wrote:
>> And Visual C++ 2019 is having a hissy fit over these two lines of code:
>>
>> static const size_t size_t_max = std::numeric_limits<size_t>::max();
>> static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();
>>
>> That code worked just fine in Visual C++ 2015. What am I screwing up here ?
>>
>> Thanks,
>> Lynn
>>
> Try
> static const size_t size_t_max = (std::numeric_limits<size_t>::max)();

Nope, that threw me into std::max hell.  Then I get an error on:

     size_t n = std::max(lhs_size, rhs_size);

Thanks,
Lynn

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

#91170

20.07.2023 22:19 Lynn McGuire kirjutas:
> On 7/20/2023 3:53 AM, Malcolm McLean wrote:
>> On Thursday, 20 July 2023 at 03:47:12 UTC+1, Lynn McGuire wrote:
>>> And Visual C++ 2019 is having a hissy fit over these two lines of code:
>>>
>>> static const size_t size_t_max = std::numeric_limits<size_t>::max();
>>> static const ssize_t ssize_t_max = std::numeric_limits<ssize_t>::max();
>>>
>>> That code worked just fine in Visual C++ 2015. What am I screwing up 
>>> here ?
>>>
>>> Thanks,
>>> Lynn
>>>
>> Try
>> static const size_t size_t_max = (std::numeric_limits<size_t>::max)();
> 
> Nope, that threw me into std::max hell.  Then I get an error on:
> 
>      size_t n = std::max(lhs_size, rhs_size);

This still feels strongly like evil macro abuse. Try

#undef max

before the error points.

[toc] | [prev] | [standalone]

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

csiph-web