Structured binding as initialisation

[2kaud]

In this example code

string newfile()
{
	const string filstem = "test"s;
	const size_t fnumstart = 0U;

	string filnam;
	size_t fnum = fnumstart;

	for (ifstream ifs; ifs.open(filnam = filstem + (fnum ? to_string(fnum) : "")), ifs.is_open(); ifs.close(), ++fnum);

	return filnam;
}

The variable fnum is only used within the for loop - and hence ideally it's scope should be thus limited. However the init-statement element of a for (and with c++17 if and switch) statement only allows one type to be specified.

c++17 introduced structured bindings, primarily for use with function return values. However, this concept can also be used to initialise multiple variables of different types. Consider

string newfile()
{
	const string filstem = "test"s;
	const size_t fnumstart = 0U;

	string filnam;

	for (auto[fnum, ifs] = make_tuple(fnumstart, ifstream()); ifs.open(filnam = filstem + (fnum ? to_string(fnum) : "")), ifs.is_open(); ifs.close(), ++fnum);

	return filnam;
}

Now the variables fnum and ifs are limited in scope as required.

My question is this. Is there a 'better' way of accomplishing this?

[wolle]

My question is this. Is there a 'better' way of accomplishing this?

I wouldn't say it's better but as an alternative you could introduce an outer scope to the for-loop, like

string newfile()
{
	const string filstem = "test"s;
	const size_t fnumstart = 0U;

	string filnam;

        { // for-loop outer scope
		size_t fnum = fnumstart;

		for (ifstream ifs; ifs.open(filnam = filstem + (fnum ? to_string(fnum) : "")), ifs.is_open(); ifs.close(), ++fnum);
	}

	return filnam;
}

Actually in the C++ standard a for-loop is defined to be equivalent to a while-loop with an outer scope like above, so it's an established usage. I use it quite often especially in association with scoped locks but also to split up Direct3D functions (that tend to be long and tedious).

Your for-loop looks a little too crammed for my taste. I would probably try an algorithm and a lambda expression.

When using a for loop I think it should be kept very simple. I probably would loop over fnum and do something very traditional like this.

string newfile2()
{
	const string filstem = "test";
	const size_t fnumstart = 0U;
	const size_t MAX_FNUM = 1000; // max number of files

	ifstream ifs;
	string filnam = filstem;
	for (size_t fnum=fnumstart; fnum<MAX_FNUM; ++fnum) {
		ifs.open(filnam);
		if (ifs.is_open()) {
			ifs.close();
			return filnam; // a file was found - return
		}
		filnam = filstem + to_string(fnum);
	}
	return ""; // error
}

[AvDav]

I used to meet such a question on interviews, my point was "as soon as the variable doesn't redefine another variable the traditional way of doing this is the way to go.". The issue needs to be investigated with the inclination of performance, which could be easily checked out with help of profiler.

[2kaud]

What is probably really wanted is the ability to have a definition statement like

char a, int b = 0, c = 0, string d, ifstream e;

[AvDav]

As far as I'm concerned, modern C++ doesn't allow to define multiple types in a for loop, so your solution with the tuple would flawlessly work out in this case. Probably, this issue would be eliminated in the upcoming editions of C++ standard.

[wolle]

Well, for readability reasons I don't think for-loops should be too crammed. And as we all know, syntax cramming (aka one-liners) don't make code more efficient.

But okay, you could collect the multiple variable types in a struct. The struct could then be used as the loop variable in a for-loop.

[2kaud]

string newfile2()
{
	const string filstem = "test";
	const size_t fnumstart = 0U;
	const size_t MAX_FNUM = 1000; // max number of files

	ifstream ifs;
	string filnam = filstem;
	for (size_t fnum=fnumstart; fnum<MAX_FNUM; ++fnum) {
		ifs.open(filnam);
		if (ifs.is_open()) {
			ifs.close();
			return filnam; // a file was found - return
		}
		filnam = filstem + to_string(fnum);
	}
	return ""; // error
}

but this has the same issue re variable scope for ifs. Also don't you mean

string newfile2()
{
	const string filstem = "test";
	const size_t fnumstart = 0U;
	const size_t MAX_FNUM = 1000U; // max number of files

	ifstream ifs;
	string filnam = filstem;
	for (size_t fnum = fnumstart; fnum < MAX_FNUM; ++fnum) {
		ifs.open(filnam);
		if (!ifs.is_open())
			return filnam;    // a file was not found - return

                ifs.close();
		filnam = filstem + to_string(fnum);
	}
	return ""; // error
}

so that the for loop continues while files are found?

[jlb1]

Have you considered using std::filesystem instead of the fstream?

[wolle]

but this has the same issue re variable scope for ifs.

I thought about including my suggestion of an outer scope but since it had no meaning I left it out. Anyway it's easy to put one in anywhere you want it and it would look like this,

string newfile2()
{
	const string filstem = "test";
	const size_t fnumstart = 0U;
	const size_t MAX_FNUM = 1000; // max number of files

	{ // for-loop scope
		ifstream ifs;
		string filnam = filstem;
		for (size_t fnum=fnumstart; fnum<MAX_FNUM; ++fnum) {
			ifs.open(filnam);
			if (ifs.is_open()) {
				ifs.close();
				return filnam; // a file was found - return
			}
			filnam = filstem + to_string(fnum);
		}
	}
	return ""; // error
}

Also don't you mean [... source code omited ...] so that the for loop continues while files are found?

No I interpreted your function to mean that when an existing test file was found its name should be returned, otherwise "" should be returned. That's why I introduced an upper limit to how many test files names should be looked for. Without it the loop may potentially never end.

Isn't that what you intended?

The actual workings of your function may not matter though since I assume it serves as a mere backdrop for your question.

[2kaud]

I assume it serves a mere backdrop for your question

Have you considered using std::filesystem instead of the fstream?

This thread is about multi-variable initialisation of different types within a loop. The code given in post #1 is just an example from post #9 of this thread http://forums.codeguru.com/showthrea...le-name-change which illustrates the issue.

Yes, in this example the c++ filesystem could be used. Consider

string newfile()
{
	const string filstem = "test"s;
	const size_t fnumstart = 0U;

	string filnam;

	for(size_t fnum = fnumstart; exists(filnam = filstem + (fnum ? to_string(fnum) : "")); ++fnum);

	return filnam;
}

which simplifies the code. However, in VS the namespace is std::experimental::filesystem - and I'm not sure about using 'experimental' code in production programs?

[wolle]

This thread is about multi-variable initialisation of different types within a loop.

From what I can see there are two options, either use a Tuple as you did in #1, or use a struct (or class) as I suggested in #6.

BUT if the sole purpose is to get variables inside the scope of a for-loop I would prefer to introduce an outer "two-braces" scope as I suggested in #2. This allows the for-loop to be kept simple and straight-forward.

[2kaud]

From the code in post #1

for (auto[fnum, ifs] = make_tuple(fnumstart, ifstream()); ifs.open(filnam = filstem + (fnum ? to_string(fnum) : "")), ifs.is_open(); ifs.close(), ++fnum);

with VS2017 15.7.0 this can be now slightly simplified to

for (auto[fnum, ifs] = tuple(fnumstart, ifstream()); ifs.open(filnam = filstem + (fnum ? to_string(fnum) : "")), ifs.is_open(); ifs.close(), ++fnum);

as VS2017 15.7.0 now supports c++17 Template argument deduction for class templates. So the templated class names can be used directly without having to use the 'make_...' versions or to supply template type parameters. Finally!

[2kaud]

However, in VS the namespace is std::experimental::filesystem - and I'm not sure about using 'experimental' code in production programs?

As of VS 2017 15.7.1, filesystem is now in std namespace. Note that this is a new implementation version of filesystem and may not be always compatible with the previous experimental::filesystem, although experimental::filesystem is still available if needed but shouldn't be used unless absolutely necessary.