Still learning new stuff about C++
Pages: 12
@TheIdeasMan, happens to me all the time. One compiler happily consumes code and another gets nauseous and vomits all over the place. :)
"ssize_t is POSIX only" is one of they reasons why I use VS and a GCC/MinGW compiler to test code. To "catch" such little things.
I sure do wish the C++ ISO Committee would approve std::ssize_t for the standard. It shouldn't be that much work to add it to an implementation, and code that used std::size_t/std::ptrdiff_t should still work.
Just don't deprecate or remove std::ptrdiff_t!
"ssize_t is POSIX only" is one of they reasons why I use VS and a GCC/MinGW compiler to test code. To "catch" such little things.
I sure do wish the C++ ISO Committee would approve std::ssize_t for the standard. It shouldn't be that much work to add it to an implementation, and code that used std::size_t/std::ptrdiff_t should still work.
Just don't deprecate or remove std::ptrdiff_t!
Last edited on
| I sure do wish the C++ ISO Committee would approve std::ssize_t for the standard. |
What I find confusing is the z or Z integer literal suffix that comes with c++23 (I mentioned it earlier):
https://en.cppreference.com/w/cpp/language/integer_literal
It produces the "signed version of std::size_t" , but there is no mention of it in detail.
In:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0330r8.html#design-suffix
section 4.1
| 4.1. Using t for ptrdiff_t and zu for size_t? Previous invocations of this paper used only z and uz/zu, mostly because there was no named type that represented what a signed std::size_t or an unsigned std::ptrdiff_t was. This made it awkward to place into the C++ wording for the author writing this paper. However, Core Wording experts (thanks Hubert Tong and Jens Maurer!) have helped elucidate that while the type may not have a formal name or type alias in the language, it is perfectly valid to say "the unsigned/signed integer type corresponding to {X}". |
emphasis by me :+)
Btw the MS compiler does not seem to have support for the integer literal suffix yet. It's pretty early days for c++23.
The other thing that bugs me is that I thought the motivation for a signed size_t was to use it for things like ranges, but ssize() and similar don't seem to use it. They use std::ptrdiff_t ?
| TheIdeasMan wrote: |
|---|
| Btw the MS compiler does not seem to have support for the integer literal suffix yet. It's pretty early days for c++23. |
Since C++23 hasn't been officially adopted I am not surprised by this.
I am more than happy for a change MS/Visual Studio is actually fully compliant at this time with the current C++ standard, while GCC/MinGW/TDM are still lagging behind.
https://en.cppreference.com/w/cpp/compiler_support/20
With past C++ standards this situation has been reversed, and took considerable time to catch up.
| It's pretty early days for c++23. |
I don't remember the specifics....I do remember when VS was considered a joke for taking so long to even partially support C++11. The free Express versions were....a mess. Paying for a pro/enterprise edition was not a wise investment.
These days the committee and the implementers are pretty good at sticking to the 3 year cycle. Back in c++11, clang was winning; g++ was second; and MS a distance third. Since then g++ and MS have undergone considerable reorganisation.
Looking at the compiler support table, I was wondering what the current version of visual studio is? A search only gives 2022. Is it somewhere around 19.29?
Looking at the compiler support table, I was wondering what the current version of visual studio is? A search only gives 2022. Is it somewhere around 19.29?
Ok, to kind of answer my own question:
https://en.cppreference.com/w/c/types/ptrdiff_t
https://en.cppreference.com/w/c/types/ptrdiff_t
| For char arrays shorter than PTRDIFF_MAX, ptrdiff_t acts as the signed counterpart of size_t: it can store the size of the array of any type and is, on most platforms, synonymous with intptr_t). |
The issue with C++ back in the days of C++11 was the structure/design/code of the MS compiler. It was still based on the design used for floppy disks when you could compile without a hard-drive and just change the floppy disc when moving between the compiler stages... Sometime around 13/15 (?) the compiler was re-written, a lot of issues were resolved and it was made much easier to add new features.
The current version is 17.0.6 (VS2022). 17.1.0 is in preview.
| I was wondering what the current version of visual studio is? A search only gives 2022. Is it somewhere around 19.29 |
The current version is 17.0.6 (VS2022). 17.1.0 is in preview.
| The current version is 17.0.6 (VS2022). 17.1.0 is in preview. |
Maybe I asked the wrong question: looking at the compiler support for c++20, the values are around 19.29
Is there a different number system for the compiler itself?
> Is there a different number system for the compiler itself?
Yes; it is defined by the predefined macro _MSC_VER
For example:
Or from the shell: cl /? prints out the compiler version.
Yes; it is defined by the predefined macro _MSC_VER
For example:
std::cout << "_MSC_VER == " << _MSC_VER << '\n' ; // 1930 (19.30) Or from the shell: cl /? prints out the compiler version.
Different versioning setup for the compiler used vs. the IDE apparently.
VS 2015 is 19.0, VS 2017 is 19.1, VS 2019 is 19.2 and VS 2022 is 19.3.
If'n you hover your mouse pointer over the version a feature became available a pop-up tells what the IDE version is.
VS 2015 is 19.0, VS 2017 is 19.1, VS 2019 is 19.2 and VS 2022 is 19.3.
If'n you hover your mouse pointer over the version a feature became available a pop-up tells what the IDE version is.
@JLBorges
Ok thankyou.
I don't have VS, I was just interested in what support for various standards.
Cheers :+)
Ok thankyou.
I don't have VS, I was just interested in what support for various standards.
Cheers :+)
As usual, MS does things in a weird way, using the IDE over-all version incrementing into the minor versioning of the compiler.
Topic archived. No new replies allowed.
Pages: 12