Multiple variable definitions of different types in for loop initialization

[darlingm]

Simple Version

I'm wondering if it's possible to define two variables (of different types) in the initialization section within a for loop. By this, I mean something like:

for(int i = 0, string j("a") ; i < 5 ; ++i) {
   // do something
}

The above fails with an error "error: expected initializer before 'j'". Using a double instead of a string gives an error "error: unqualified-id before 'double'"

I know this is erroring because the comma operator isn't designed to deal with defining multiple types of variables in one statement.

Is there any way to accomplish this within the for loop syntax, without defining either variable outside or within the foor loop?

I don't want to use

string j("a");
for(int i = 0, i < 5 ; ++i) {
   // do something
}

And I don't want to use

for(int i = 0, i < 5 ; ++i) {
   string j("a");
   // do something
}

The "OK, what the heck are you trying to do?" version

OK, why don't I want to use either? Right now I'm using (simplified of course):

#include <iostream>
#include <vector>
using namespace std;

#define myfor(type, variableName, vectorName) for(vector<type>::iterator variableName = vectorName.begin() ; variableName != vectorName.end() ; ++variableName)

int main() {
   vector<int*> vecOfInts;
   vecOfInts.push_back(new int(1));
   vecOfInts.push_back(new int(2));
   myfor(int*, theIntPointerIterator, vecOfInts) {   // the define doesn't have the "{" character so can be used here for readability
      cout << **theIntPointerIterator << endl;
   }
}

I'd like to remove the extra dereferencing to handle the iterator and go with something like:

#include <iostream>
#include <vector>
using namespace std;

#define myfor(type, variableName, vectorName) for(vector<type>::iterator iter = vectorName.begin(), type variableName = *iter ; iter != vectorName.end() ; ++iter, variableName = *iter)

int main() {
   vector<int*> vecOfInts;
   vecOfInts.push_back(new int(1));
   vecOfInts.push_back(new int(2));
   myfor(int*, theIntPointer, vecOfInts) {   // the define doesn't have the "{" character so can be used here for readability
      cout << *theIntPointer << endl;
   }
}

But, the above isn't valid as I mentioned a ways above, so won't compile.

I don't want to define 'type variableName = *iter' before the for loop, becuase I don't want it accessable outside the for scope. Bad practice, and I'll be using multiple uses of the define macro, so unless I do something weird to work around it, I'd have multiple definitions of the same variable.

I don't want to define it inside the for loop, because then I have to include the "{" to enter scope within the define and my code becomes a less readable - and unusable by programming gui's:

#include <iostream>
#include <vector>
using namespace std;

#define myfor(type, variableName, vectorName) for(vector<type>::iterator iter = vectorName.begin() ; iter != vectorName.end() ; ++iter) { \
type variableName = *iter;

int main() {
   vector<int*> vecOfInts;
   vecOfInts.push_back(new int(1));
   vecOfInts.push_back(new int(2));
   myfor(int*, theIntPointer, vecOfInts)    // note can't use "{" here becuase it's in the define
      cout << *theIntPointer << endl;
   }
}

(Edited typo)

[nuzzle]

becuase I don't want it accessable outside the for scope.

Why not just introduce a scope like

// code
{
   string j("a");
   for(int i = 0, i < 5 ; ++i) {
      // do something
   }
}
// more code

[darlingm]

Because of how the define macros that I'm using. I want the define to be able to declare both variables, and if it scopes within the define, it screws up that consistency of scoping in the source code... Unless I created an end macro, which I'd prefer not to.

I wasn't sure there was a way to do what I was trying, but hoping I wasn't aware of it.

[laserlight]

Well, you could provide another version of the macro that specifically caters for the declaration of a second type of variable.

By the way, your idea sounds very similiar to Boost.Foreach, although Boost's macro is also similiarly limited (but it does not require the user to provide an iterator).

Personally, I will be happier when there is native support of lambda functions in the next version of C++.