|
Im creating a GUI which has multiply pages of info, each of which has dialog boxes that display information ( simple cstring ), and from coding it seems apparent you cant update a dialog box when its not the current window, so I've created a way to hold all the info in the page (.cpp file) and now i wondering if its possible to add a calling method when the tab is clicked for that page. That way, when you click the tab for the page, it will call this method and pull all the latest data from my struct. Is this possible or is there a better way to do all of this? Im kinda new to .NET and C++
|
|
|
|
|
Does anyboday know any C++ function which can create an instance
by given a class name? In C#, we know that the function
Activator.CreateInstance(string className, BOOL ) does this job.
In C++, it is hard to find.
Any clue, hint and helpful resource link are very welcomed!
Thanks!!!
|
|
|
|
|
A thing like that is rarely used in C++! Can you describe why you need such things (give as many details as possible)? I'm almost sure this is a flaw in your design and that it can be done in another way.
|
|
|
|
|
No such thing in C++, unless you are using some plug-in framework.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
what you need is a "class factory". there are many ways to do it, one of the simplest is this:
CBaseClass * MakeObject(CString & className)
{
if (className == "CObject1") return new CObject1;
else if (className == "CObject2") return new CObject2;
else if (className == "CObject3") return new CObject3;
else return NULL;
}
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
ling_shen2002 wrote:
In C++, it is hard to find.
That's because it doesn't exist. You can write something similar for your own purposes, but there really isn't anything in C++ that works like the reflection support in .NET.
As cedric moonen wrote, you may want to reconsider your design.
|
|
|
|
|
I often use the inline keyword for simple functions (i.e. get/set members). e.g.
class CFoo
{
...
inline std::string GetString(void) const { return m_str; }
};
However, I have noticed that MS tends to use a special .INL file for in-lined code. For example:
class CFoo
{
...
std::string GetString(void) const;
};
inline std::string GetString(void) const
{
return m_str;
}
My question is ... why? Is there anything inherently wrong with inlining code directly in the class header? Are there compiler compatibility or performance reasons for splitting inline code out of the body of the class definition?
Just curious. Thanks in advance.
The Rob Blog
Google Talk: robert.caldecott
|
|
|
|
|
I don't know the response to your question but I just wanted to make a remark: when you define a function in your header file, it is always considered as an inline function.
From MSDN website:
A class's member functions can be declared inline either by using the inline keyword or by placing the function definition within the class definition.
Example 2
#include <iostream><br />
using namespace std;<br />
<br />
class MyClass<br />
{<br />
public:<br />
void print() { cout << i << ' '; }
private:<br />
int i;<br />
};<br />
<br />
int main()<br />
{<br />
}
|
|
|
|
|
Agreed. I like to include it for completeness/readability.
The Rob Blog
Google Talk: robert.caldecott
|
|
|
|
|
I think in some cases, especially with some MFC code, I see the functions inline at release build, but regular functions when building as debug. You would not have that option when declaring them in the header file.
|
|
|
|
|
Robert Edward Caldecott wrote:
My question is ... why?
Can't talk about MS, but at my work we have the same standard. Apparently, this is to better separate interface from implementation (personaly, I don't like it that much, but stick to the standard anyway).
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I've never heard or read about a MSFT policy regarding how inline member functions should be declared, but I suspect that it's due to readability reasons. Like Nemanja said "separating the interface from the implementation" in order not to clutter the interface and make it hard to read.
Regarding the syntax of the language there is nothing wrong with defining the member function in the class definition. It would make the function inline implicitly as Blake said.
In order for clients to use the inline function, the definition has to be included to make it possible for the compiler to extract the body in place. The most straight forward way to accomplish this is by have the definition in the header file. As I understand it the compiler does the same thing regardless of whether the function was defined inside the class definition or not.
Sometimes in MFC code, e.g. CDocument::GetDocument, the debug version of the function is not inline in order to step into the function. Otherwise one has to step through the assembler code to know what happens.
To write the preprocessor directive (#ifdef _DEBUG) inside the class definition wouldn't be a very beautiful code to look at for my eyes. 
But that's a matter of taste and the compiler doesn't seems to have any.
--
Roger
|
|
|
|
|
Robert Edward Caldecott wrote:
My question is ... why?
Portability.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Could you elaborate? Portability is potentially a big-deal for me at the moment...
|
|
|
|
|
I simply read it near the bottom of this.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Do you mean this sentence:
Furthermore you can declare it in the header (with inline keyword) and seperate easally from them (with .inl files). Microsoft often use the same technique because it's better compatible with many compilers.
This make sense only if the poster was referring to poor support for member template functions in VC6, but templates are a separate issue when it comes to source code organization anyway.
Otherwise, this has nothing to do with portability.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote:
Otherwise, this has nothing to do with portability.
Being able to move code and/or files over to another compiler has nothing to do with being portable?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
I looked into this in detail a few years ago and came to the conclustion that the best thing to do is make nothing inline and let the optimiser inline things as it sees fit.
|
|
|
|
|
The inline keywords is a suggestion to the compiler. If you use it the compiler may or may not inline the function code ("as it sees fit"). If you do not use it, then the function is not inlined (even if it should be).
Of course there may be an optimization command line argument that tell the compiler to treat all functions as if they have been designated as inline, but I doudt it.
Designate any function that just returns a simple value as inline, or place the code for that function in the class body (which makes it implicitly inline).
INTP
Every thing is relative...
|
|
|
|
|
John R. Shaw wrote:
Of course there may be an optimization command line argument that tell the compiler to treat all functions as if they have been designated as inline, but I doudt it.
It's /Ob2.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Robert Edward Caldecott wrote:
Is there anything inherently wrong with inlining code directly in the class header?
No!
Robert Edward Caldecott wrote:
Are there compiler compatibility or performance reasons for splitting inline code out of the body of the class definition?
No! (well no preformance reasons)
The only reason for splitting the inline code out of the body in this way is so they can change the inline code (file) without touching the class body. In other words they can change the inline code without changing the class definition in the header file.
This is simular to providing a header file for a library which contains the class definition, but not the function bodies. The developer can change how the functions do their jobs and release an update to the library without changing the header files that contains the class deffinitions.
INTP
Every thing is relative...
|
|
|
|
|
I just encountered these words, Skinning, GDI/+, OpenGL, DirectX, Bitmaps and Palletes. Which among these topics do I have to study if I'm going to change the overall look or design of my project (SDI/MDI or Dialog)? It sounds like a theme because even the buttons, edit boxes, other controls or even the background, toolbars, menu, etc, will be changed.
|
|
|
|
|
Hello,
I think that skinning your application will suit you best. This enables certain themes to be used by your users. It even enables them to make their own themes might they want to do that...
GDI/+, OpenGL and DirectX are more for heavy graphics. GDI is more to draw graphs and simple stuff while OpenGL and DirectX are more for the type of graphics you see in games.
Bitmaps and Palletes may come in handy if you want to change colors and things like that at runtime without changing the actual files etc.. You might want to look more into these subjects.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Ok, now I know what these stuffs is all about. Thanx 
|
|
|
|
|
You're welcome 
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
