Prev: Programatically rearranging icons
Next: utime() and GMT
From: Ulrich Eckhardt on 28 Oct 2009 03:49
Jeff Chang wrote:
> Thanks for your help. I will try the non-DotNet group. I also found out
> putting the "typename" up front fix the error message. By the way is this
> ANSI standard or just VS-2008?

It's part of the ISO standard.

> My textbook (year 2004) sample didn't have the "typename" in front.

Many compilers at that time still let it slip. However, there are also many
bad textbooks out there.

Uli


--
C++ FAQ: http://parashift.com/c++-faq-lite

Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
From: Giovanni Dicanio on 8 Nov 2009 13:56
"Jeff Chang" <cpmame(a)hotmail.com> ha scritto nel messaggio
news:065D01A9-0582-4345-BEFA-CA9027885534(a)microsoft.com...

> Besides hope you could give me some advice. Is there any benefit switching
> to .Net C++? I am interested in audio-visual programming in the long run.
> Should I even consider C# or Java for the sack of productivity?

With '.Net C++' you mean C++/CLI, don't you?
I think that C++/CLI is good as a bridging layer between native code and
managed code.
e.g. if you have some native C++ library and you want to use that from .NET
languages like C#, you could develop a thin C++/CLI layer to connect the
native C++ platform with the .NET managed platform.
But my impression is that C++/CLI is not a first class .NET language; for
example: if you want to build GUIs with WPF, you can use C# or VB.NET, but
not C++/CLI (at least, this is my understanding).
And I think that ASP.NET does not support C++/CLI (only C# or VB.NET).
So, if you want to build something in .NET, I would suggest to consider C#
or VB.NET (if you come from C++, you would prefer C#, because its syntax
looks more natural than VB.NET for someone with a C++/Java background).

About productivity, yes C# offers high productivity to the programmer.
But if you want something that is small and fast, C++ is the way to go.

Giovanni



From: Scot Brennecke on 9 Nov 2009 00:56
Giovanni Dicanio wrote:
> "Jeff Chang" <cpmame(a)hotmail.com> ha scritto nel messaggio
> news:065D01A9-0582-4345-BEFA-CA9027885534(a)microsoft.com...
>
>> Besides hope you could give me some advice. Is there any benefit
>> switching to .Net C++? I am interested in audio-visual programming in
>> the long run. Should I even consider C# or Java for the sack of
>> productivity?
>
> With '.Net C++' you mean C++/CLI, don't you?
> I think that C++/CLI is good as a bridging layer between native code and
> managed code.
> e.g. if you have some native C++ library and you want to use that from
> .NET languages like C#, you could develop a thin C++/CLI layer to
> connect the native C++ platform with the .NET managed platform.
> But my impression is that C++/CLI is not a first class .NET language;
> for example: if you want to build GUIs with WPF, you can use C# or
> VB.NET, but not C++/CLI (at least, this is my understanding).
> And I think that ASP.NET does not support C++/CLI (only C# or VB.NET).
> So, if you want to build something in .NET, I would suggest to consider
> C# or VB.NET (if you come from C++, you would prefer C#, because its
> syntax looks more natural than VB.NET for someone with a C++/Java
> background).
>
> About productivity, yes C# offers high productivity to the programmer.
> But if you want something that is small and fast, C++ is the way to go.
>
> Giovanni

Well, C++/CLI will compile to MSIL just as any other .NET language, so
once it's compiled, it is supported anywhere any .NET assembly might be.
However, I agree that C# would almost always be the better choice for
developing a WinForms or WPF application. You CAN do it with C++/CLI,
but the syntax and IDE just aren't as friendly.
From: Triple-DES on 10 Nov 2009 03:43
On 26 Okt, 18:34, David Wilkinson <no-re...(a)effisols.com> wrote:
>
> You think online Comeau is wrong to accept OP's original code? That would be bad
> news, because Comeau is my operational definition of whether a piece of code is
> correct or not :-).

In some instances, Comeau (online) is more lenient with typename than
the Standard. Example:

template <typename T>
struct A
{
struct B { };
B b1_; // ok
A::B b2_; // ill-formed, 'typename' required

};

Comeau online compiles this without a diagnostic.
From: Igor Tandetnik on 10 Nov 2009 07:51
Triple-DES wrote:
> In some instances, Comeau (online) is more lenient with typename than
> the Standard. Example:
>
> template <typename T>
> struct A
> {
> struct B { };
> B b1_; // ok
> A::B b2_; // ill-formed, 'typename' required
>
> };
>
> Comeau online compiles this without a diagnostic.

typename keyword is not required here. There's an example in 14.6 that shows this exact situation, and no typename keyword:

14.6p2 A name used in a template declaration or definition and that is dependent on a template-parameter is assumed not to name a type *unless the applicable name lookup finds a type name* [emphasis mine] or the name is qualified by the keyword typename. [Example:
// no B declared here
class X;
template<class T> class Y {
class Z; // forward declaration of member class
void f() {
X* a1; // declare pointer to X
T* a2; // declare pointer to T
Y* a3; // declare pointer to Y<T>

// ****** This is the part similar to your example.
Z* a4; // declare pointer to Z

typedef typename T::A TA;
TA* a5; // declare pointer to T's A
typename T::A* a6; // declare pointer to T's A
T::A* a7; // T::A is not a type name:
// multiply T::A by a7; ill-formed,
// no visible declaration of a7
B* a8; // B is not a type name:
// multiply B by a8; ill-formed,
// no visible declarations of B and a8
}
};
-end example]

--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Programatically rearranging icons
Next: utime() and GMT