Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / General Programming / Another template question for the C++ masters! Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Randall Foster

March 16, 2005, 03:23 AM

What is the correct way to get this to compile?
I get a bunch of errors while compiling a class C.

Thanks!

  1.  
  2.  
  3. template <class T> class A
  4. {
  5.         public:
  6.  
  7.                 T                               m_A;
  8.                 u32                             m_Crap;
  9.                 u32                             m_Stuff;
  10. };
  11.  
  12. template <class T> class B
  13. {
  14.         public:
  15.  
  16.                 T                               m_B;
  17.                 u32                             m_MoreCrap;
  18.                 u32                             m_MoreStuff;
  19.                 u32                             m_Things;
  20. };
  21.  
  22. template <class T> class C
  23. {
  24.         private:
  25.                
  26.                 A<B<T>> m_C; // <<<<<<<<<<<<<<<< BIG PROBLEMS!
  27. }
  28.  
  29.  

 
Gerald Knizia (cgk)

March 16, 2005, 03:28 AM

Instead of "A" write "A" (insert a space between the two closing parenthesis). The way it stands now, the >> would be interpreted as operator. C++ :).

 
Andrew Newton

March 16, 2005, 03:29 AM

You need to insert a space between the two >> like this:

A m_C

Otherwise the compiler interprets the '>>' as the right shift operator.

 
Andrew Newton

March 16, 2005, 03:30 AM

Damn, just beaten to it!

 
Randall Foster

March 16, 2005, 03:38 AM

Wow thanks guys...
That never occured to me. You'd think the compiler would check for this.

Problem solved,
Thanks to all who posted!

 
Victor Widell

March 16, 2005, 05:25 AM

Yes, the template < and > really should have higher priority than the >> operator. I can't see any advantage with the way it works now.

 
Rui Martins

March 16, 2005, 06:24 AM

Yes, the template < and > really should have higher priority than the >> operator. I can't see any advantage with the way it works now.


Actually it's not a question of priority but instead reserved symbols.

The unfortunate coincidence is that due to how template use the symbol "", allows one to nest them, and hence possible to incorrectly express a different symbol ">>"

This is a similar problem to the one that prevents you to use a spaces between the name of a Macro and it's first parenthesis.

This works:
  1. #define swap(x, y) { int tmp = x; x = y; y = tmp }


But this doesn't
  1. #define swap (x, y) { int tmp = x; x = y; y = tmp }


The problem is that the compiler can't determine if it should be a macro, because to "him" it looks as a regular constant define.

Same problem as above, it's a parser problem, created by poorelly chosen symbols or language structure.

For example, this can never happen with the "&" and "&&" or "|" and "||", since if you nest them, you will never get to the other symbol.

 
Chris

March 16, 2005, 06:39 AM

It cannot detect that >> actually means > >, because the C standard says that during lexical analysis, the tokenizer has to emit the longest possible token it can create.

When it reads the first >, it detects that by consuming the next > it can create a token of length 2. There is no possibility to introduce priorities here, because lexical analysis is (mostly) context free, and has no chance to recognize whether it's currently within a template or not.

 
Bramz

March 16, 2005, 08:41 AM

AFAIK this will be fixed in the new standard to allow the >>.

 
Victor Widell

March 16, 2005, 08:16 PM

Oh, I see. I had forgot about the lexer/parser distinction.

 
This thread contains 10 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.