|
I think that I have found the root of the problem...
The template class has an enum inside it:
template<typename _Ty> class TemplateClass<br />
{<br />
public:<br />
enum ConstantValue<br />
{<br />
constant_value = 17<br />
};<br />
};
The type definition works when the enum is taken out of the template class. So the following works:
enum ConstantValue { constant_Value = 17 };<br />
<br />
template<typename _Ty> class TemplateClass<br />
{<br />
public:<br />
...<br />
};<br />
<br />
...<br />
<br />
typedef Root::Nested::TemplateClass<int> NESTED_CLASS;
I still do not understand why this is, but at least I have a solution now. I found a BUG report on the Microsoft website which addresses this very issue with template functions, the remedee there is to typedef the enum...typedef'ing the enum within the template class didn't improve the situation for me though.
http://support.microsoft.com/kb/125495[^]">
I thought it was worth posting the solution in case somebody else has a similar issue. It would be interesting if someone was able to give a reason as to why this problem occurs.
Thanks for your advice.
|
|
|
|
|
But why do you need anymore the typedef (now you have a not-nested enum)?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
I only demonstrated the part which was not compiling, the template class in question does get used extensively when assigned to particular types.
for example,
typedef TemplateClass<int> IntVersion;<br />
typedef TemplateClass<float> FloatVersion;<br />
<br />
IntVersion a;<br />
a.foo();<br />
<br />
Bar(a);
Obviously the enum can now be accessed via the appropriate namespace. Before it was accessed via the template class (which in some ways was better because it grouped it with context), but having it in the namespace isn't exactly end of the world.
The template class will still be used for its primary purposes.
|
|
|
|
|
"doesn't work"
don't provide too much information, someone might actually help you. 
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Sorry, I meant to have pasted the compiler errors  . Here they are:
error C2065: 'constant_value' : undeclared identifier
error C2653: 'TemplateClass<int>' : is not a class or namespace name
|
|
|
|
|
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi,
I'm facing a problem reading data from Serial Port using VC++. I have to read data every 12 msec from the serial port. I'm using Overlapped method and ReadFile() function to read data. The time gap between two data stream is 12.5 msec. At one streatch I'm able to read only 8 bytes. Anyone knows what could be the problem?
Please help..
|
|
|
|
|
Forget about the "real-time" aspect of it. Windows is not a real-time operating system so you'll never be able to read data every 12 msec precisely. And you don't need to. The only thing you need to do is read data when data is available. So, what you could do is read data and if you read only 8 bytes, then continue reading until you received 12 bytes.
Once this is donc, you process your data and read the next data.
|
|
|
|
|
Cedric Moonen wrote: then continue reading until you received 12 bytes
Is it a magic number or have you the CPMRU (Code Project Mind Reader Unit) turned on?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Ouch, yes I misread his message. I thought I needed to read 12 bytes. But you get the idea 
|
|
|
|
|
|
 It seems like a hard day for me today. I should really read 7 times my post before pressing the post message button.
|
|
|
|
|
I have no clue how many bytes I should read. Every 12 msec data is coming to serial port, but ReadFile() function reads only 8 bytes at one instance. Why is it so? Any idea what the EV_BREAK in WaitCommEvent() does? Please help, very urgent.
|
|
|
|
|
Susanmat wrote: I have no clue how many bytes I should read.
That's already a big problem. You should be able to know how many bytes you need to read. Where is this data coming from and what is contained in it ? Can't you send first a byte that contains the size of the 'packet' ?
Susanmat wrote: Every 12 msec data is coming to serial port, but ReadFile() function reads only 8 bytes at one instance. Why is it so?
Please post some relevant code because I don't have eyes sitting in front of your computer. Probably it is just because there is only 8 bytes in the buffer.
Susanmat wrote: Any idea what the EV_BREAK in WaitCommEvent() does?
I think it is when a break character is sent on the serial port (if it is enabled).
Susanmat wrote: Please help, very urgent
This is a forum were people help for free on their spare time. If you cannot wait and need *urgent* help, then go on rentacoder and pay for somebody.
|
|
|
|
|
Hello everyone,
I have tested try-catch works with structured exception, to my surprise. Previously I think we have to use __try and __except.
Any comments? Here is my test code and I am using Visual Studio 2008.
#include <iostream>
using namespace std;
int main()
{
int* address = NULL;
try{
(*address) = 1024;
} catch (...)
{
cout << "access violation caught" << endl;
}
return 0;
}
thanks in advance,
George
|
|
|
|
|
George_George wrote: Any comments?
Yes, you're a bit late indeed, such code works as well with VS6 compiler.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
This behaviour is not standard compliant, but then again neither is MSVC6 in many other areas in addition to this issue. See here[^].
Steve
|
|
|
|
|
Thanks CPallini,
1. You mean catch(...) is not the standard way to catch structured exception and we should use __except instead?
2. How about try? The same as catch(...) for backward compatibility? And we should use __try instead?
regards,
George
|
|
|
|
|
In section 15.1 of the C++ standard you'll find the following:
"A handler will be invoked only by a throw-expression invoked in code executed in the handler's try block or in functions called from the handler's try block."
The fact that MSVC6 catches SEH exceptions means that it's not standard compliant - this will come as no surprise to anyone who's used it for awhile and tried to get standard compliant code to work.
Later versions introduced the /EH[^] switch to switch between the old "buggy" behaviour and standard compliant behaviour.
Steve
|
|
|
|
|
Thanks Steve,
1. You mean catch(...) is not the standard way to catch structured exception and we should use __except instead?
2. How about try? The same as catch(...) for backward compatibility? And we should use __try instead?
regards,
George
|
|
|
|
|
These are difficult questions. As I pointed out earlier, the C++ keyword catch should only catch exceptions explicitly thrown by a C++ throw statement, according to the C++ standard. The ability to catch SEH exception using the C++ catch statement is switchable in later versions of MSVC, although you’re stuck with the non-standard behaviour using MSVC6. Microsoft’s SEH mechanism, accessed in C++ (on Microsoft and compatible compilers) via the __try and __except[^] keywords, is Microsoft specific but then again so is the ability to catch these exceptions using the C++ catch statement. Also note that __try and __except[^] does not result in destructors being called as the stack is unwound, so it doesn’t place nice with C++ in many cases.
Steve
|
|
|
|
|
Hi Steve,
From the link, I have not found the statement you mentioned "__try and __except[^] does not result in destructors being called as the stack is unwound".
So, RAII model can not work with structured exception?
regards,
George
|
|
|
|
|
George_George wrote: So, RAII model can not work with structured exception?
Exactly.
Steve
|
|
|
|
|
Hi Steve,
Sorry for asking this question again.
I re-read your statement below agian,
--------------------
Also note that __try and __except[^] does not result in destructors being called as the stack is unwound, so it doesn’t place nice with C++ in many cases.
--------------------
Should it be __try and __except which block us from stack unwinding or more exactly should say structured exception blocks us from stack unwinding?
(I have this confusion because in Visual Studio we still can use catch to catch structured exception.)
regards,
George
|
|
|
|
|
Hi Steve,
Sorry for interrupting you again. I have tested that structured exception could also trigger stack unwinding, looks like either you are wrong or my understanding is not correct?
Here is my code,
#include <iostream>
using namespace std;
class Foo
{
public:
Foo()
{
cout << "constructing Foo" << endl;
}
virtual ~Foo()
{
cout << "destrucing Foo" << endl;
}
};
int main()
{
int* address = NULL;
try{
Foo foo1;
(*address) = 1024;
} catch (...)
{
cout << "access violation caught" << endl;
}
return 0;
}
</iostream>
Output:
constructing Foo
destructing Foo
access violation caught
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
