problem when moving from 32 to 64 platform

[lastchance]

I'm not sure that I entirely agree with it, but I was amused by
https://www.learncpp.com/cpp-tutorial/unsigned-integers-and-why-to-avoid-them/

I particularly liked the example (from that link)

#include <iostream>

int main()
{
    signed int s { -1 };
    unsigned int u { 1 };

    if (s < u)
        std::cout << "-1 is less than 1\n";
    else
        std::cout << "1 is less than -1\n";
}

At least my compiler is kind enough to give a warning, but the usual expectation is that you would convert to the more general type before doing an operation.

The other cogent point made in the article is that you shouldn't subtract unsigned ints (well, not 50% of the time, anyway).


Languages like Fortran and Python don't have unsigned integers. The latter aren't as "safe" as you think.


So, to stick with the thread, I suggest that you use int and MPI_INT throughout. If your number of nodes exceeds what can safely be stored in an int then your computer setup probably isn't going to be solving that CFD problem anyway.

[seeplus]

I've certainly seen this 'brilliant' piece of code:

#include <iostream>

int main() {
	constexpr size_t NoElem {10};

	const int arr[NoElem] {1,2,3,4,5,6,7,8,9,10};

	for (size_t i = NoElem - 1; i >= 0; --i)
		std::cout << arr[i] << ' ';

	std::cout << '\n';
}

which gives a good impression of an infinite loop... as i will always be >= 0 as it is unsigned!

Instead of:

#include <iostream>

int main() {
	constexpr size_t NoElem {10};

	const int arr[NoElem] {1,2,3,4,5,6,7,8,9,10};

	for (size_t i = NoElem; i > 0; --i)
		std::cout << arr[i - 1] << ' ';

	std::cout << '\n';
}

The first example works, of course, if i is of type int instead of an unsigned type...

The .size() member functions (and std::size() ) return a type of size_t (unsigned). Which is why since C++20 we have std::ssize() which returns a signed type - std::ptrdiff_t

[deleted account xyzzy]

A while back I saw this version of a reverse for loop and thought it was devilishly clever:

#include <iostream>

int main()
{
   constexpr size_t numElems { 10 };

   const int arr[numElems]   { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

   for (size_t i { numElems }; i-- > 0;)
   {
      std::cout << arr[i] << ' ';
   }

   std::cout << '\n';
}

[seeplus]

Yep - for unsigned the test has to be > and not >=.

[TheIdeasMan]

Ah, the accidental operator:

GeorgeP wrote:

for (size_t i { numElems }; i --> 0;)

With c++20 ranges, from cppreference, 3 different ways:
https://en.cppreference.com/w/cpp/ranges/reverse_view

#include <ranges>
#include <iostream>
 
int main()
{
    static constexpr auto il = {3, 1, 4, 1, 5, 9};
 
    std::ranges::reverse_view rv {il};
    for (int i : rv)
        std::cout << i << ' ';
    std::cout << '\n';
 
    for (int i : il | std::views::reverse)
        std::cout << i << ' ';
    std::cout << '\n';
 
    // operator[] is inherited from `view_interface`
    for (auto i{0U}; i != rv.size(); ++i)
        std::cout << rv[i] << ' ';
    std::cout << '\n';
}

[deleted account xyzzy]

@TheIdeasMan,

I was wondering if it was possible to do the reverse range-based for loop, other reverse for loops with numbers and iterators I knew about long ago.

And then about a year ago I ran across the reverse range-based for loop here:
https://www.fluentcpp.com/2020/02/11/reverse-for-loops-in-cpp/

I was in coding hog heaven! :)

[seeplus]

#include <iostream>
#include <iterator>

template<typename InputIter>
class RangeF {
public:
	constexpr RangeF(const InputIter& b, const InputIter& e) : beg_(b), end_(e) {}

	constexpr auto begin() const noexcept { return beg_; }
	constexpr auto end() const noexcept { return end_; }

private:
	InputIter beg_ {};
	InputIter end_ {};
};

int main() {
	const int arr[] {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

	for (const auto a : RangeF(std::rbegin(arr), std::rend(arr)))
		std::cout << a << ' ';

	std::cout << '\n';
}

See cplusplus.com/forum/lounge/279954/#msg1210389

RangeF enables an iterator range to be specified for the range-for - which can a reverse iterator.

[deleted account xyzzy]

For me if'n I was to go with iterators for a reverse loop on a regular array I'd do this:

#include <iostream>
#include <iterator>

int main()
{
   constexpr size_t numElems { 10 };

   const int arr[numElems]   { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

   for (auto itr { std::rbegin(arr) }; itr != std::rend(arr); ++itr)
   {
      std::cout << *itr << ' ';
   }

   std::cout << '\n';
}

Ranges adds a bit too much complexity for my tastes for such a simple task. Given a real-world app dealing with gobs and gobs of data might make using ranges worthwhile.

[TheIdeasMan]

GeorgeP wrote:

Ranges adds a bit too much complexity for my tastes for such a simple task. Given a real-world app dealing with gobs and gobs of data might make using ranges worthwhile.

I don't see the following as being complex, mainly because there are no iterators or de-referencing at all. This code is taken from my previous post, as it is the simplest IMO of the 3 methods shown there.

#include <ranges>
#include <iostream>
 
int main()
{
    static constexpr auto il = {3, 1, 4, 1, 5, 9};
 
    for (int i : il | std::views::reverse)
        std::cout << i << ' ';
    std::cout << '\n';
}

The other really handy thing is the variety of range adapters, such as filters and various ways of obtaining range views.

https://en.cppreference.com/w/cpp/ranges

[seeplus]

But why so wordy? Why introduce yet another namespace? It just makes you want to use using namespace... Why not just:

for (auto i : std::reverse(il))

and don't say that there is already a std::reverse. Yes - but this has a different function signature.

[TheIdeasMan]

I just copy'n'paste from cppreference.

[JLBorges]

> But why so wordy? Why introduce yet another namespace? ... Why not just: ...

The alternatives, and the rationale for a separate namespace (extract from the proposal DD4128):

3.3.6 Algorithm Return Types are Changed to Accommodate Sentinels
... most algorithm get new return types when they are generalized to support sentinels. This is a source-breaking change in many cases. ... Merely accepting the breakage is clearly not acceptable. We can imagine three ways to mitigate the problem:

1. Only change the return type when the types of the iterator and the sentinel differ. This leads to a slightly more complicated interface that may confuse users. It also greatly complicates generic code, which would need metaprogramming logic just to use the result of calling some algorithms. For this reason, this possibility is not explored here.

2. Make the new return type of the algorithms implicitly convertible to the old return type. Consider copy, which currently returns the ending position of the output iterator. When changed to accommodate sentinels, the return type would be changed to something like pair<I, O>; that is, a pair of the input and output iterators. Instead of returning a pair, we could return a kind of pair that is implicitly convertible to its second argument. This avoids breakage in some, but not all, scenarios. This subterfuge is unlikely to go completely unnoticed.

3. Deliver the new standard library in a separate namespace that users must opt into. In that case, no code is broken until the user explicitly ports their code. The user would have to accommodate the changed return types then. An automated upgrade tool similar to clang modernize can greatly help here.

We, the authors, prefer (3). Our expectation is that the addition of concepts will occasion a rewrite of the STL to properly concept-ify it. The experience with C++0x Concepts taught us that baking concepts into the STL in a purely backward-compatible way is hard and leads to an unsatisfactory design with a proliferation of meaningless, purely syntactic concepts. ...

From: https://ericniebler.github.io/std/wg21/D4128.html

[seeplus]

OK - In other words a camel... I'm not liking ranges - probably because I have trouble getting the **** things to compile properly and do what I expect. Does anyone know a link to a good 'idiots guide to ranges' site - or preferably a book that covers the topic in detail as a beginner (not Josuttis or Grimm)?

[deleted account xyzzy]

I do understand about "backwards compatibility," I keep running into that issue with WinAPI code.

It's a "damned if you do, damned if you don't" situation. As annoying as the excess of verbosity can be it could be worse with terser constructs.

One really annoying aspect of ranges for me is VS requires the language standard to be set for c++latest instead of c++20.

Why? Because <ranges> uses aspects of <concepts> to work. HUH?!?

M'ok, I don't understand the WHY, I just have to DO or get code that will DIE in whimpering agony with errors.

[seeplus]

There' also several DR (Defect Report) changes to ranges in C++23 which you get with VS2022 set to latest.

[deleted account xyzzy]

Did not know that, seeplus, thanks for the update.

I wish the std::format compile-time defect report was done. :| *crosses fingers and toes*

As of this time VS is fully C++20 compliant, all the other compiler vendors for once are lagging behind.

A change from the bad ol' days when MSVC was the one even years later out-of-date.

M'ok, so I have to use language standard c++latest instead of c++20. MEH! :)

[helios]

It'd be nice if they backported compiler updates to previous IDE versions. I'd like to be able to use newer features, but I also have other stuff that I need my IDE to interface with that doesn't work (yet) with 2022.

[seeplus]

For a list of the changes in each if the C++ versions and compiler support see:
https://en.cppreference.com/w/cpp/compiler_support

For a list of VS C++ compliance see:
https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=msvc-170

Format changes are coming in VS2022 17.2 (currently in preview).

For info about std::format in VS, see:
https://devblogs.microsoft.com/cppblog/format-in-visual-studio-2019-version-16-10/

[deleted account xyzzy]

I haven't found anything C++20 specific that won't work in VS2019 that works in VS2022.

Getting modules to work in VS2019 required a while back enabling C++ standard experimental libraries setting, not required with VS2022. Maybe that has changed, I haven't tried it recently.

M'ok, just tested VS2019 with some modules, .cpp & .cppm files. As with VS2022 any module code .cpp file needs to be set as a module internal partition, .cppm files set to interface.

No need to muck around with the experimental C++ standard libraries. Huzzah! :D

VS2019's Intellisense is a bit more "twitchy" when it comes to modules compared to VS2022. 2019 shows more "errors" than 2022, yet both compile the code.

[deleted account xyzzy]

seeplus wrote:

Does anyone know a link to a good 'idiots guide to ranges' site

Maybe this might be helpful?
https://hannes.hauswedell.net/post/2019/11/30/range_intro/

Here's the meta-search I used, there might be other coding gold to mine:
https://duckduckgo.com/?q=c%2B%2B20+ranges+tutorial&t=ffsb&ia=web