Thread: Though implementation problem

Originally Posted by (::)

since you seem to be already having problems with gcc tell me do you also have this problem now or before

why gcc would expect unqualified-id and what is that id

Maybe if you posted the code that relates to that error message we could figure out what the problem is.

--
Mats

Code:

return this->OperatorMinusMinusPost< /*CIteratorTmpl*/Iterators::CIterator<VecT, Proxy, Base> >();

Gives me the errors:

Code:

error: expected primary-expression before '>' token
error: expected primary-expression before ')' token

...with GCC, but compiles in Visual Studio.
Why? I don't understand how GCC works or what it expects.

OperatorMinusMinusPost is a member function inherited from the template base class. But it is also a template member function:

Code:

template<typename T> T OperatorMinusMinusPost();

Anyone knows what the "correct" syntax is?

What are Iterators, CIterator, and the three arguments?

You might have to write

return this->template OperatorM...

They are:

Code:

namespace Iterators
{
	// ...
	template<typename VecT,
	template<typename ProxyBase, typename Iterator, typename Type> class Proxy,
	typename Base> CIteratorTemplate class CIterator:
		public CIteratorBase<VecT, Proxy, Base>,
		// ...

And base:

Code:

namespace Iterators
{
	// ...
	template<typename VecT,
	template<typename ProxyBase, typename Iterator, typename Type> class Proxy,
	typename Base> class CIteratorBase:
		public std::iterator<std::random_access_iterator_tag, VecT>
	{
		// ...
	protected:
		// ...
		template<typename T> T OperatorMinusMinusPost();

I don't understand what syntax GCC is expecting.

Well, as I said, try

Code:

return this->template OperatorMinusMinusPost< /*CIteratorTmpl*/Iterators::CIterator<VecT, Proxy, Base> >();

OperatorMinusMinusPost is a dependent name and it refers to a template, so you need the template keyword.

Seems to work. Again, it seems VS's compiler is too advanced and too good for its own good, seeing as it can compile without those words.

Originally Posted by Elysia

Seems to work. Again, it seems VS's compiler is too advanced and too good, seeing as it can compile without those words.

"Too advanced and too good"?

Well, perhaps. But I truly wish there was a way to switch it off and make it compile only strictly compliant code, so that such surprises wouldn't happen. In fact, since the compiler is able to compile the code without the help, it should be exceptionally good at pointing out where the typename and template keywords are missing.

But to the best of my knowledge, there's no such option.

Originally Posted by CornedBee

"Too advanced and too good"?

Originally Posted by phantomotap

Troll.

Yes, as in VS's compiler is advanced enough to be able to compile code without those keywords.
The standard requires them only to help with compiler implementation if I'm not mistaken.

But, this is not a good thing, since it doesn't enforce nor warn about it.

Well, perhaps. But I truly wish there was a way to switch it off and make it compile only strictly compliant code, so that such surprises wouldn't happen. In fact, since the compiler is able to compile the code without the help, it should be exceptionally good at pointing out where the typename and template keywords are missing.

But to the best of my knowledge, there's no such option.

There is a way, but unfortunately, Microsoft headers are full of extensions, so it won't compile without microsoft extensions. It's really a shame.

Which is just stupid. GCC has

Code:

#pragma GCC system_header

which enables all extensions for the file even if they're disabled on the command line. Which makes sense, because it's completely absurd that the windows.h header doesn't compile if I set VC++ to strict compliance mode.

So very true and I wish it were so, but I have absolutely NO way of progammatically enabling and disabling extensions.

Originally Posted by phantomotap

No. It isn't. It may appear that way, but in reality it is an artifact of a broken compiler. This artifact wasn't accomplished with intent; it wasn't done to make users lives easier.

So you say. I don't agree.

The standard requires them because the C++ language has several ambiguous uses leading to confusion or wrong results. Without the 'template' keyword the statement is wrong because the statement can be interpreted as a much more complex statement that is missing an element.

But all code compiles fine in VS. Apparently, it compiles the correct code.

This is a nonsensical reason. They use 'pragma' everywhere to turn off and on other warnings and errors. They didn't do it because supporting broken code is not something they want to do.

It's not nonsense. Compile the headers without extensions and you'll get loads of compile errors.

So you say. I don't agree.

Which is irrelevant; the accounts are in the history.

But all code compiles fine in VS. Apparently, it compiles the correct code.

It only compiles as you apparently want it to be compiled. A conforming compiler will interpret that statement as missing a key element because the standard says it is missing an element.

It's not nonsense. Compile the headers without extensions and you'll get loads of compile errors.

It is nonsense.

1): Nothing is stopping them from supporting C and C++ correctly.

2): As I've said, they use 'pragma' everywhere to turn off and on other warnings and errors.

Edit: "They didn't do it because supporting broken code is not something they want to do." Just to clear that up: they want to support the existing code base, but not new broken code.

Soma