Using declaration inside first template parameter as default value for second template parameter.

Using declaration inside first template parameter as default value for second template parameter.

Post by Stuart Red » Fri, 14 Dec 2007 23:55:59


Hello newsgroup,

please don't flame me: I use the very old and very non-conformant MS VC6.0
compiler. Though I'd like to upgrade to a better compiler, I'm afraid that some
of my code will break. One of the "features" of MS VC6.0 is the following:

template<class A, class B = A::Type>
class C
{
};

class D
{
public:
typedef D Type;
};

int main ()
{
D d;
}

This compiles fine under VC, and does what I expect it to do (in my real
application, not this down-cut sample). I tried to compile it with Comeau
online, and surprise, surprise, it gives an error:

"ComeauTest.c", line 1: error: nontype "A::Type" is not a type name
template<class A, class B = A::Type>
^

What do I have to do to make the code work under Comeau?

Thanks,
Stuart
 
 
 

Using declaration inside first template parameter as default value for second template parameter.

Post by Victor Baz » Sat, 15 Dec 2007 00:33:05


Wow... What do you say to that, eh?

Do you leave your house at all or are you afraid you will be hit with
a bus? How do you code at all? You must be afraid that whatever you
write has a bug or two in it... Or does the code you write work the
first time and always?


Change this to

template<class A, class B = typename A::Type>

But I am not sure your outdated and non-standard VC++ is going to
accept that (and I don't have any way to check).


Write standard C++.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

 
 
 

Using declaration inside first template parameter as default value for second template parameter.

Post by Stuart Red » Sat, 15 Dec 2007 01:15:36


Don't blame me, the decision to use MS VC6.0 was not made by me but my employer.
Have you tried at some time to ask your boss permission for some hundred
man-hours working on your software without A) adding some features or B) fixing
any bugs? Maybe I expressed it badly: I'm afraid that I'll have to spend too
much time to make my otherwise working code more standard-conformant.


Surprisingly, it does.

[snip]

That's hardly a guarantee that the code will actually work. AFAIK, there is no
compiler that is 100 percent standard-conformant.

Many thanks,
Stuart
 
 
 

Using declaration inside first template parameter as default value for second template parameter.

Post by anon » Sat, 15 Dec 2007 02:15:21


But, isn't your code already broken if you are using "very old and very
non-conformant" compiler? By updating the compiler, you will:
A) add features easier
B) fix existing bugs in your code
Therefore, the time you invest will pay off (not only for you, but also
for people working on the project)
 
 
 

Using declaration inside first template parameter as default value for second template parameter.

Post by Salt_Pete » Sat, 15 Dec 2007 09:46:18


The above doesn't make sense. You are suggesting that anyone whom
decides to do business with you must code out_of_standard. Thats a
train wreck waiting to happen. What then constitutes undefined
behaviour? How does one justify some code's result if it doesn't
adhere to a standard?
Not adhering to a standard essentially strips you all of an expected
result and throws any justification out the door.
Would it not cost a considearable, additional amount of time since you
can't reuse what is now (and later) available?


Probably not 100%, but its more like 99% which is consideably more
than VC6.0's conformance.
The point being that it should be resonably expected that code does
what it does regardless of the compiler employed.
You can't guarentee that if you code is out_of_standard.

The issue is not the compiler.
 
 
 

Using declaration inside first template parameter as default value for second template parameter.

Post by Stuart Red » Sat, 15 Dec 2007 17:42:28

gt;>>Stuart Redmann wrote:

Salt_Peter wrote:

I suggest that anyone who decides to make business with me may use non-standard
code, as long as the results produced by his code are fulfilling my
specifications. Note that I am talking about industrial produced software. I
have never seen a line of code of the software components I use, so I don't care
about whether those pieces of software were written with standard-conformant
compilers or not, I even don't care which programming language was used. And
surely clients that use my software components don't care about my non-standard
conformant code. Using non-standard conformant code makes you more dependent on
the tools you can use, it doesn't necessarily mean that the code you have
written is non working or that production costs are higher.

I'd be very curious how many software developer that code in C++ are actually
producing standard-conformant code (let's make a survey, shall we?)

Salt_Peter wrote:

I'd agree if at some point some feature gets added to the C++ language which is
not already supported by the compiler I'm currently using. Unless there is a
considerable gain from changing compilers, I'd rather stick to the one I'm
currently using.

Stuart Redmann wrote:
Victor Bazarov wrote:
Stuart Redmann wrote:

Salt_Peter wrote:

I already tried to upgrade to MS VC7.0, because I wanted to be able to take
addresses of member templates (which is impossible under VC6.0). Compiling the
code under VC7.0 succeeded, but the addresses I got were complete garbage (I
don't know whether this works under later releases, but since I found an even
more elegant alternative to this feature, I stopped worrying). Could this be
counted as counterexample that writing standard-conformant code produces
well-defined results?

I understand that the C++ standard is a good thing (it should have been
constituted much earlier). Unfortunately, the compilers available are somewhat
imperfect. As we cannot wait the ultimate and truly conformant compiler to
appear, we'll have to stick to what exists (this makes life quite hard for the
Boost people, whose code must be littered with #ifdef __XYZ_C_, I guess).

Regards,
Stuart