|
If I remember well, you cannot do such specializations, i.e. functions having the same name, the same number and type of arguments but different return types.
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.
|
|
|
|
|
For instance, you cannot do the following:
int foo(){return 1;}
double foo(){return 1.;}
while the code snippet below:
int foo(int i){return 1;}
double foo(char c){return 1.;}
compiles fine.
If I remeber well this is related to the C++ Mangling scheme (return parameters are not used when mangling).
[added] There is a better argument: how the hell the compiler will distinguish which flavour of the function you're calling?
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.
|
|
|
|
|
probally you are rjght!
I was only hoping that templates could be very very powerful, but probally doesn't.
tnx
Russell
|
|
|
|
|
In fact they are very powerful. But, anyway, you cannot do that.
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.
|
|
|
|
|
CPallini wrote: how the hell the compiler will distinguish which flavour of the function you're calling?
mmm...but I think that you are not understanding that I'm using templates , Am I rigth?
Templates are elaborated during pre-compiler step! There you can write different member definitions according to some conditions, like #if #else ...
The compiler comes after that processing.
Russell
|
|
|
|
|
I understand, understand...
But template specializations are eventaully standard C++ functions (or methods) hence what you cannot do with the latter you cannot do with the former.
_Russell_ wrote: Templates are elaborated during pre-compiler step! There you can write different member definitions according to some conditions, like #if #else ...
The compiler comes after that processing
I don't agree: templates, AFAIK, are not pre-processor stuff.
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.
|
|
|
|
|
Ok,
I'll surrender.
Russell
|
|
|
|
|
Hello _Russell_,
U can specify the return type as T.
Come online at:-
jubinc@skype
|
|
|
|
|
|
If you need different function for int and double you need two different classes for they, and one template for others.
Why do you want your class todo different things width different types? This is not a application of templates. Templates are useful when types are diffrent and actions are same.
Hope will help you.
|
|
|
|
|
progDes wrote: Why do you want your class todo different things width different types?
The class is very big...many function are in common...but I need to differentiate the code in this 2 cases
...the problem is that I'm inside the class, I haven't found nothing into manuals/online helps. But I really need to solve this problem
Russell
|
|
|
|
|
Maybe reformulating the problem will help: what do you really need to do?
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.
|
|
|
|
|
Probally ...got a way!
T Foo(){
T FakeParam;
return Foo(FakeParam);
}
private:
double Foo(double){
}
int Foo(int){
}
T Foo(T){
}
Needed some tests
Russell
|
|
|
|
|
In your case the only decision I see is macro class generation, not templates, macros. And of course #ifdef, #endif. But this is ugly, think about program design. This is bad approach.
|
|
|
|
|
I will maybe say something without sense... but... Why don't you make a way of trick to the compiler? I mean...
I make some additions to the SmartList of Simon Hughes here in codeproject. You can look for my article. The fact is...
If a CList can return whatever you give in the TYPE, ARG_TYPE.... Why don't you use that possibility? You can have some intermediate class that use your "typename T" as entry parameter and then you shouldn't have any problem more to return one type or another type of element. The return will depend on what you give to the ARG_TYPE.
I.E:
CMyList < TYPE, ARG_TYPE >& Foo (T tTemp)
{
return tTemp;
}
With that you return T independantly of what type of variable T is, being possible for complex classes too.
In my project I have some main ObjClass that have member variables and methodes that use secondary SubObjClass that have parameters and methodes that use third type of SubSubObjClass, so on till 5 steps in the hierarchy. And The main objects are saved in one of this list. The list can save different type of things and returns what it has saved in. No matter of what.
Im not meaning you should a CList with your elements, but maybe you can rewrite your template to return whatever you need using something like that.
I hope not saying silly things and that it helps you
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
Nelek wrote: I will maybe say something without sense
No!! Why?
Interesting idea,
Thank You.
Russell
|
|
|
|
|
Hi,
My mainframe window has close,mini amd maxi buttons.
But it does not work.
I cannot close or minimize the window.
Whats the reason.
My Precreatewindow codes like
BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs)
{
cs.style = WS_POPUP | WS_OVERLAPPED | WS_CAPTION | FWS_ADDTOTITLE
| WS_SYSMENU | WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_MAXIMIZE;
return CMDIFrameWnd::PreCreateWindow(cs);
}
Whats the reason?
Anu
|
|
|
|
|
I keep wonderring why you totally replace the cs.style value, convention is you should OR the desired extra styles with the passed in cs.style value. It is also unconventional to have a popup overlapped window, refer to MSDN CWnd::CreateEx Remarks section where it states "Creates an overlapped, pop-up, or child-window ...".
|
|
|
|
|
In addition to Roger's reply...
How do you know calling CMDIFrameWnd::PreCreateWindow() AFTER setting your values to cs won't completely overwrite yours?
You should call the base class first and THEN modify the appropriate values.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I modify my MainView style as follows:
BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs)
{ if( !CMDIFrameWnd::PreCreateWindow(cs) )
return FALSE;
cs.style = cs.style | WS_MAXIMIZE;
return TRUE;
}
and it works fine.
Hope it helps
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
Hi,
I have MFC code written on VC6 platform.Now im trying to build the same code in VS2005 platform.Im getting following linking error.
Error 1 error LNK2005: "public: char const * __thiscall std::basic_string<char,struct std::char_traits<char="">,class std::allocator<char> >::c_str(void)const " (?c_str@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEPBDXZ) already defined in MyCtrl.obj MY_FileIO.lib
Where MyCtrl.cpp is in the application project and MY_FileIO is a project for DLL used by application.
Whats the cause and whats the solution for the same?
|
|
|
|
|
Probably you are trying to use both iostram library and std library.
Your dll and application should use same type of libraries.
If your dll uses MFC then modify the project setting accordingly.
I have not used VS 2005, but here is the way to set application use MFC in VS 6.0
Project > Settings > General tab. "Select Use MFC in Shared Dll"
|
|
|
|
|
Verify that both your dll and axecutable use the same run-time library. For that, open the project properties -> "C/C++" and verify that "Runtime Library" is the same for both projects.
|
|
|
|
|
My Application and DLL has "Multi-threaded Debug (/MTd)" setting set in RunTime library.Still it has the linking error.
|
|
|
|
|
is
#include "stdafx.h"
writed on the top of that file ?
Russell
|
|
|
|