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

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

A way around _HAS_ITERATOR_DEBUGGING

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

Contents

  A way around _HAS_ITERATOR_DEBUGGING Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-02 14:49 +0200
    Re: A way around _HAS_ITERATOR_DEBUGGING "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-06-02 15:07 +0200
      Re: A way around _HAS_ITERATOR_DEBUGGING Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-02 15:12 +0200
        Re: A way around _HAS_ITERATOR_DEBUGGING "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-06-02 20:27 +0200
          Re: A way around _HAS_ITERATOR_DEBUGGING red floyd <myob@its.invalid> - 2021-06-02 14:24 -0700
          Re: A way around _HAS_ITERATOR_DEBUGGING Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-03 00:54 +0200
          Re: A way around _HAS_ITERATOR_DEBUGGING Öö Tiib <ootiib@hot.ee> - 2021-06-02 17:30 -0700
    Re: A way around _HAS_ITERATOR_DEBUGGING Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-02 16:46 +0300
      Re: A way around _HAS_ITERATOR_DEBUGGING Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-02 16:23 +0200
        Re: A way around _HAS_ITERATOR_DEBUGGING Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-02 19:43 +0300
          Re: A way around _HAS_ITERATOR_DEBUGGING Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-02 18:57 +0200
            Re: A way around _HAS_ITERATOR_DEBUGGING Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-02 21:13 +0300
              Re: A way around _HAS_ITERATOR_DEBUGGING James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-02 17:23 -0400
                Re: A way around _HAS_ITERATOR_DEBUGGING Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-03 00:53 +0200
              Re: A way around _HAS_ITERATOR_DEBUGGING Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-03 00:52 +0200
          Re: A way around _HAS_ITERATOR_DEBUGGING Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-02 18:59 +0200
        Re: A way around _HAS_ITERATOR_DEBUGGING Juha Nieminen <nospam@thanks.invalid> - 2021-06-03 09:21 +0000
          Re: A way around _HAS_ITERATOR_DEBUGGING Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-03 11:33 +0200
            Re: A way around _HAS_ITERATOR_DEBUGGING Bo Persson <bo@bo-persson.se> - 2021-06-03 12:17 +0200
              Re: A way around _HAS_ITERATOR_DEBUGGING Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-03 12:25 +0200
            Re: A way around _HAS_ITERATOR_DEBUGGING Juha Nieminen <nospam@thanks.invalid> - 2021-06-03 17:49 +0000
              Re: A way around _HAS_ITERATOR_DEBUGGING MrSpook_ujp@3p26kggzpvpn2h.gov.uk - 2021-06-04 07:43 +0000
          Re: A way around _HAS_ITERATOR_DEBUGGING James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-03 11:06 -0400
            Re: A way around _HAS_ITERATOR_DEBUGGING David Brown <david.brown@hesbynett.no> - 2021-06-03 19:07 +0200
            Re: A way around _HAS_ITERATOR_DEBUGGING Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-03 20:18 +0300
              Re: A way around _HAS_ITERATOR_DEBUGGING Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-04 10:22 +0100
                Re: A way around _HAS_ITERATOR_DEBUGGING Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-04 14:19 +0300
                  Re: A way around _HAS_ITERATOR_DEBUGGING Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-04 13:07 +0100
              Re: A way around _HAS_ITERATOR_DEBUGGING James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-04 10:40 -0400
                Re: A way around _HAS_ITERATOR_DEBUGGING Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-04 19:28 +0300
                  Re: A way around _HAS_ITERATOR_DEBUGGING James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-04 13:04 -0400
                    Re: A way around _HAS_ITERATOR_DEBUGGING "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-06-04 13:30 -0700
                      Re: A way around _HAS_ITERATOR_DEBUGGING MrSpook_6qpp@dggw8.org - 2021-06-05 09:28 +0000
                    Re: A way around _HAS_ITERATOR_DEBUGGING Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-04 23:45 +0300
            Re: A way around _HAS_ITERATOR_DEBUGGING Juha Nieminen <nospam@thanks.invalid> - 2021-06-03 17:52 +0000

Page 1 of 2  [1] 2  Next page →

#80079 — A way around _HAS_ITERATOR_DEBUGGING

Because i needed something like ptr = &*vec.end() and MSVC has iterator
-debugging by default I had a little header which I included before all
other headers.

#pragma once
#if defined(_MSC_VER)
	#if defined(_HAS_ITERATOR_DEBUGGING) && _HAS_ITERATOR_DEBUGGING != 0
		#error _HAS_ITERATOR_DEBUGGING must be set to 0
	#elif !defined(_HAS_ITERATOR_DEBUGGING)
		#define _HAS_ITERATOR_DEBUGGING 0
	#endif
#endif

But now I found that to_address( it ) of C++ 20 translates to
it.operator ->(), so I don't use the above header any more but
just it.operator ->() to stick with C++17 - although the latest
MSVC++-upddate is C++20 feature-complete and I could use to_address().

[toc] | [next] | [standalone]

#80080

On 2 Jun 2021 14:49, Bonita Montero wrote:
> Because i needed something like ptr = &*vec.end() and MSVC has iterator
> -debugging by default I had a little header which I included before all
> other headers.
> 
> #pragma once
> #if defined(_MSC_VER)
>      #if defined(_HAS_ITERATOR_DEBUGGING) && _HAS_ITERATOR_DEBUGGING != 0
>          #error _HAS_ITERATOR_DEBUGGING must be set to 0
>      #elif !defined(_HAS_ITERATOR_DEBUGGING)
>          #define _HAS_ITERATOR_DEBUGGING 0
>      #endif
> #endif

Hm. If you've defined the macro as anything but 0, then this code errs 
out. Otherwise it defines the macro as 0. So what does it tell you other 
than that it's Visual C++, which `_MSC_VER` already tells you?


> But now I found that to_address( it ) of C++ 20 translates to
> it.operator ->(), so I don't use the above header any more but
> just it.operator ->() to stick with C++17 - although the latest
> MSVC++-upddate is C++20 feature-complete and I could use to_address().

This seems unrelated to above, perhaps you inadvertently failed to 
include some more code?

Anyway, it's practically safe to take the address of `*s.end()` for a 
`std::string`, because since C++11 the buffer has a guaranteed 
null-terminator, and (at least as I see it) only a perverse 
implementation would not let `*s.end()` be that final null item.

But in general, e.g. for a `std::vector`, there is no guaranteed item 
beyond the last one "in" the collection, so that the `collection.end()` 
iterator can even be a nullvalue itself. To get a pointer beyond the 
collection use `collection.data() + collection.size()`.

However, that's pretty annoying for a `std::string_view` or (disclaimer: 
haven't used it) `std::span`.

So, good idea to define it yourself, agreed, but not by dereferencing 
the end iterator.


- Alf

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

#80081

>> Because i needed something like ptr = &*vec.end() and MSVC has iterator
>> -debugging by default I had a little header which I included before all
>> other headers.
>>
>> #pragma once
>> #if defined(_MSC_VER)
>>      #if defined(_HAS_ITERATOR_DEBUGGING) && _HAS_ITERATOR_DEBUGGING != 0
>>          #error _HAS_ITERATOR_DEBUGGING must be set to 0
>>      #elif !defined(_HAS_ITERATOR_DEBUGGING)
>>          #define _HAS_ITERATOR_DEBUGGING 0
>>      #endif
>> #endif

> Hm. If you've defined the macro as anything but 0, then this code errs 
> out. Otherwise it defines the macro as 0. So what does it tell you other 
> than that it's Visual C++, which `_MSC_VER` already tells you?

I want to set _HAS_ITERATOR_DEBUGGING to 0 and if it is already set the
compilation should stop.

>> But now I found that to_address( it ) of C++ 20 translates to
>> it.operator ->(), so I don't use the above header any more but
>> just it.operator ->() to stick with C++17 - although the latest
>> MSVC++-upddate is C++20 feature-complete and I could use to_address().

> This seems unrelated to above, perhaps you inadvertently failed to 
> include some more code?

No, if I do ptr = &*vec.end(), depending on _HAS_ITERATOR_DEBUGGING,
the dereferencing of end is runtime-checked and an assertion fails.

> Anyway, it's practically safe to take the address of `*s.end()` for
> a  `std::string`, because since C++11 the buffer has a guaranteed 
> null-terminator, and (at least as I see it) only a perverse 
> implementation would not let `*s.end()` be that final null item.

Interesting, but I'm concerned about vecors in this case.

> But in general, e.g. for a `std::vector`, there is no guaranteed item 
> beyond the last one "in" the collection, so that the `collection.end()` 
> iterator can even be a nullvalue itself. To get a pointer beyond the 
> collection use `collection.data() + collection.size()`.

"ptr = vec.end().operator ->()" works perfectly - and even around
_HAS_ITERATOR_DEBUGGING.

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

#80110

On 2 Jun 2021 15:12, Bonita Montero wrote:
> [snip]
> "ptr = vec.end().operator ->()" works perfectly - and even around
> _HAS_ITERATOR_DEBUGGING.

But why use an expression with formally Undefined Behavior when there is 
a perfectly well-defined way to do it?

- Alf

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

#80115

On 6/2/2021 11:27 AM, Alf P. Steinbach wrote:
> On 2 Jun 2021 15:12, Bonita Montero wrote:
>> [snip]
>> "ptr = vec.end().operator ->()" works perfectly - and even around
>> _HAS_ITERATOR_DEBUGGING.
> 
> But why use an expression with formally Undefined Behavior when there is 
> a perfectly well-defined way to do it?
> 
> - Alf

Because it works on her system and therefore by definition it's all good.

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

#80120

>> [snip]
>> "ptr = vec.end().operator ->()" works perfectly - and even around
>> _HAS_ITERATOR_DEBUGGING.

> But why use an expression with formally Undefined Behavior when there is 
> a perfectly well-defined way to do it?

It actually works on all machines.

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

#80121

On Wednesday, 2 June 2021 at 21:28:00 UTC+3, Alf P. Steinbach wrote:
> On 2 Jun 2021 15:12, Bonita Montero wrote: 
> > [snip]
> > "ptr = vec.end().operator ->()" works perfectly - and even around 
> > _HAS_ITERATOR_DEBUGGING.
> But why use an expression with formally Undefined Behavior when there is 
> a perfectly well-defined way to do it? 

Bonita's actual name is Chuck Norris. He tested it on all machines and
with all compilers and also did count to infinity twice. So it is perfectly
valid to do it.

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

#80083

02.06.2021 15:49 Bonita Montero kirjutas:
> Because i needed something like ptr = &*vec.end() and MSVC has iterator
> -debugging by default

Dereferencing vec.end() is UB, so you should not do this even if it 
appears to work in some situation.

What's wrong with vec.data()+vec.size() ?

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

#80087

>> Because i needed something like ptr = &*vec.end() and MSVC has iterator
>> -debugging by default

> Dereferencing vec.end() is UB, ...

In theory, but there's for sure no actual vector-implementation
where this doesn't work as long as you don't read from or write
to the reference.
The theory bases on architectures which might check the pointers
inside the references when they're loaded to a register. F.e.
CPUs with segment-registers might load the segment and the seg-
ment might get checked; but such architectures aren't of any
importance today.

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

#80099

02.06.2021 17:23 Bonita Montero kirjutas:
>>> Because i needed something like ptr = &*vec.end() and MSVC has iterator
>>> -debugging by default
> 
>> Dereferencing vec.end() is UB, ...
> 
> In theory,

Says the person who complains that her code does not work in practice 
with a widespread implementation, unless specifically silenced with a 
_HAS_ITERATOR_DEBUGGING macro (note: using this macro is deprecated by MS).

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

#80101

> Says the person who complains that her code does not work in practice 
> with a widespread implementation, unless specifically silenced with a 
> _HAS_ITERATOR_DEBUGGING macro (note: using this macro is deprecated by MS).

That has nothing to do with pseudo-UB.

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

#80109

02.06.2021 19:57 Bonita Montero kirjutas:
>> Says the person who complains that her code does not work in practice 
>> with a widespread implementation, unless specifically silenced with a 
>> _HAS_ITERATOR_DEBUGGING macro (note: using this macro is deprecated by 
>> MS).
> 
> That has nothing to do with pseudo-UB.

There is no such thing as pseudo-UB. If your code contains UB, it might 
work, it might not work, it might appear to work without really working, 
and even if it worked it might cease to work in the next day, next 
compiler, or the next compiler version. There are no guarantees.

A term like "pseudo-UB" implies that there is some magic guarantee that 
the UB code always works as intended. Alas, UB specifically means no 
guarantees, so there is no such thing. Even if you hack your UB code to 
(apparently) work with some specific C++ implementation, you have no 
guarantee that your code will work with any other C++ implementation, or 
with the next version of the same implementation.

The fact that your code does not work with a specific C++ implementation 
without hacking already shows that this is not a theoretical issue.

If the C++ committee comes around and says, yes, sorry, we make 
&*vec.end() defined behavior after all, then yes, you are welcome to 
write this code, now with defined behavior, and MS is obliged to fix 
their now non-conforming compiler. But until this has not happened, UB 
is UB.

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

#80114

On 6/2/21 2:13 PM, Paavo Helde wrote:
> 02.06.2021 19:57 Bonita Montero kirjutas:
...
>> That has nothing to do with pseudo-UB.
> 
> There is no such thing as pseudo-UB. If your code contains UB, it might 
> work, it might not work, it might appear to work without really working, 
> and even if it worked it might cease to work in the next day, next 
> compiler, or the next compiler version. There are no guarantees.
> 
> A term like "pseudo-UB" implies that there is some magic guarantee that 
> the UB code always works as intended. Alas, UB specifically means no 
> guarantees,


Not quite. It means "behavior for which this document imposes no
requirements" (3.30). That wording deliberately and explicitly allows
for the possibility that something other than "this document" might in
fact impose requirements on the behavior of the code. This is, in fact,
one of the most common reasons for writing UB code (and the only
legitimate reason for doing so): an implementation provides some
guarantees for the behavior that the standard itself does not. Such code
is only portable to implementations which provide that same guarantee,
but in many contexts that's not a serious problem.

However, if Bonita wants to rely upon that exception, she needs to
identify the document which provides the guarantees she's relying on - and

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

#80119

> However, if Bonita wants to rely upon that exception, she needs to
> identify the document which provides the guarantees she's relying
> on - and.

No, I don't.
I just know that there's no machine that works other than expected.

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

#80118

> There is no such thing as pseudo-UB.

It's pseudo-ub because there's actually no machine where the behaviour
is not up to what you need.

Rest of your nonsense unread ...

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

#80102

> ... (note: using this macro is deprecated by MS).

I want the code to work with older compilers.

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

#80126

Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Because i needed something like ptr = &*vec.end() and MSVC has iterator
>>> -debugging by default
> 
>> Dereferencing vec.end() is UB, ...
> 
> In theory, but there's for sure no actual vector-implementation
> where this doesn't work as long as you don't read from or write
> to the reference.

The problem with relying on undefined behavior is that you have no
guarantees about what the compiler will do to your code.

Most people think that "undefined behavior" only pertains to how
your code will behave when run on a computer. Maybe you'll get a
segmentation fault, maybe you'll be reading garbage, maybe you'll
be overwriting values in the stack somewhere making the program
bug out...

However, not many people are aware that official UB frees the
*compiler* to do whatever it wants with that kind of code. The
standard does not require that the compiler does what you expect
it to do. The compiler might see that the code has UB and optimize
it away, for example. This is not illegal from the standard's
point of view.

So the problem is that you can never be sure what the compiler
will do with your UB code. It might do something you don't expect.

(This was the reason for that one infamous bug in the Linux kernel,
which dereferenced the null pointer, and the compiler performed an
optimization on it that made it behave in an unexpected manner.)

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

#80129

> The problem with relying on undefined behavior is that you have no
> guarantees about what the compiler will do to your code.

In theory - but in this case actually practically not.

Rest of your nonsense unread.

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

#80130

On 2021-06-03 at 11:33, Bonita Montero wrote:
>> The problem with relying on undefined behavior is that you have no
>> guarantees about what the compiler will do to your code.
> 
> In theory - but in this case actually practically not.
> 

So enlighten us - what are the guarantees?

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

#80131

>> In theory - but in this case actually practically not.

> So enlighten us - what are the guarantees?

referencing vec.end() is actually UB because there might be machines
on which loading such a reference traps. But actually these systems
aren't relevant today.
And I'm not even referencing vec.end(), but just calling operator ->(),
that's what to_address also does in one variant ([*]).

[*] https://en.cppreference.com/w/cpp/memory/to_address

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web