|
Suppose I have a template class (Hash) which receives 4 types. The following template declaration is the find method of the template class:
template <class Key, class Data, class HashFunc, class KeyEqualFunc>
CsHash<Key, Data, HashFunc, KeyEqualFunc>::listIter CsHash<Key, Data, HashFunc, KeyEqualFunc>::find(const key_type& key)
How can I make these declarations shorter?
|
|
|
|
|
Are you sure you want to define find outside the definition body of CsHash? Due to well known problems with template instantiation, standard practice is to define methods in place:
template<...>
class CsHash
{
...
listIter find(const key_type& key)
{
}
};
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thank you for your response.
In the book I read, the definitions of the methods are outside the body of the class. Furtheremore, the definitions of these methods are quite long (almost the whole window in VC++). In this case, should I still define them inside the body of the class? Isn't there some other way using typedefs to accomplish this? I tried but got strange compiler errors.
Any suggestions?
|
|
|
|
|
You can move the definitions of your methods out of the class body by declaring them inline. But this gets you back to the long names problem. typedefs are of little help here, since they should have to be declared as part of the class, thus forcing you again to instantiate them with template parameters.
This is the way C++ syntax is. I'm afraid you'll have to live with overwhelming template declarations and/or bloated class bodies. In case this makes you happier, everybody else just resorts to the second solution and provides some sort of documentation where the class interface is stated in clearer terms.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi, everyone!
In the following functions, I want to push a new object into a
vector. The vector is a global vector (variable). I have seen
two ways of doing this. I simply want to know which way is correct
and which way is more efficient? Are there some potential problems
in either of the two methods?
Source code:
--------
Function1 (T& NewElement)
{
GlobalVector.push_back (NewElement);
}
Function2 (T NewElement)
{
GlobalVector.push_back (NewElement);
}
--------
Thanks in advance,
George
|
|
|
|
|
std::vector::push_back() makes a copy of the object you give it - all STL containers do. (It is worth to keep that in mind, because you are responsible to provide working copy-constructors and assignment operators.)
The best way would be the one you did not write:
Function0 (const T& NewElement)
{
GlobalVector.push_back (NewElement);
} using a const reference.
A non const reference would be OK here, but if you do not intend to manipulate NewElement, you can as well tell that, and make your Function1 able to cope with constant NewElements.
By-value arguments (Function 2) would result in an additional temporary local copy, which is in turn copied into the vector. Maybe the compiler optimiser would get rid of the unneeded copying, but is wise to rely on that?
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
Thanks, jhwurmbach buddy!
From your reply, I think I must supply my class
a copy constructor if I want to push it in STL
container. Am I correct?
But, what form of copy constructors should I
define? Since copy constructor has many form.
regards,
George
|
|
|
|
|
George2 wrote:
From your reply, I think I must supply my class
a copy constructor if I want to push it in STL
container.
If you do not, the compiler will automagically do that for you.
But what the compiler provides is very basic: It copies each element of your object.
Bitwise copying with basic types (int, double etc.) and calling the copy constructor with objects.
That may well be exactly what you want - then there is no need to write one yourself.
But if you need complicated stuff you need to write that yourself. And while you are at it, you also need to make an assignment operator, doing the same.
George2 wrote:
Since copy constructor has many form
No. it has exactly one form:
NewElement(const NewElement& rhs);
The ones I write are mostly very small, because I only call the assignment operator in them:
NewElement::NewElement(const NewElement& rhs)
{
*this = rhs;
} My assignment operator then does all the copying. So the two are always consistent.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
Thanks, jhwurmbach buddy!
I think in your case, when vector.push_back is called,
the copy constructor and assignment operator will be
called. I think in your case, copy constructor will be
called first and then copy constructor will invoke the
assignment operator. Am I correct?
regards,
George
|
|
|
|
|
George2 wrote:
copy constructor will be
called first and then copy constructor will invoke the
assignment operator
Yes. That is the way it is intended. There is only one place I have to update if I add another member variable.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
Thanks, jhwurmbach buddy!
I know that the system will supply me a default copy ctor.
It copies member-wise. My question is, if I supplied my
own version of copy ctor. Must I supply the assignment
operator? Why? How can I decide the case?
regards,
George
|
|
|
|
|
George2 wrote:
if I supplied my
own version of copy ctor. Must I supply the assignment
operator?
I am not totally sure if you must, but I am sure that you absolutly should! How do you guarantee consistence, between construction and assignment when you have written only one of them?
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
Thanks, jhwurmbach buddy!
George
|
|
|
|
|
NewElement::NewElement(const NewElement& rhs)
{
*this = rhs;
}This is not, IMHO, good practice. It works for sure, but you are incurring the innecesary overhead of default constructing your object prior to assignment. For small classes this could be negligible, not so if the default constructor is heavier.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi, Joaquín buddy!
Hmmmm... I do not understand what you mean. But I think
you are correct. 
So, can you show me an example?
regards,
George
|
|
|
|
|
You say that you would have sparate code in the copy c'tor and the assignment operator?
For me, this looks dangerous:
NewElement::NewElement(const NewElement& rhs)
: m_One(rhs.m_One), m_Two(rhs.m_Two), m_Three(rhs.m_Three)
{
}
NewElement& NewElement::operator=(const NewElement& rhs)
{
if (this != &rhs)
{
m_One=rhs.m_One;
m_Two=rhs.m_Two;
m_Three=rhs.m_Three;
}
return *this;
} If I had to insert NewElement::m_twoA, I would need to update the copy c'tor and the assignment-operator. Two places to edit for one functionality change - sounds ugly.
I'd say do optimisation only where you have proven (that is profiled) benefit. Everywhere else clarity is the way to go.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
Quick question -
If I am writing a project using only the Win API,
is it possible to use classwizard in conjunction with
this project?
Currently if I try to run classwizard, it informs me that the database
does not exist and prompts me to build it - I have tried this, but
it seems to fail. 
Should this be possible?
Thanks.
|
|
|
|
|
There's no help files in my project. And I want to make the help button invisible,or get rid of it.
How can I do?
Thanks.
Hi guys. I'm a very fat man. Do you like fat men?
|
|
|
|
|
in the constructor of the property page and for each property page inserted:
this->m_PropertyPageInsideThePropertySheet.m_psp.dwFlags &= ~PSP_HASHELP; and also:
this->m_psh.dwFlags &= ~PSH_HASHELP;
this should do the trick...
hope this helps...
|
|
|
|
|
See the MSDN article Q141039. It's about the Apply button but it does mention that any of the buttons can be hidden in the same fashion.
You can deactivate the Help button capability by modifying m_psh in the property sheet object as follows:
mySheet.m_psh.dwFlags &= ~(PSH_HASHELP);
|
|
|
|
|
Hello
I am porting a huge source from unix to win32, and I need to build dll from the source, is there a way to ask linker to export all funtions and classes without going into the code and put the __declspec(dllexport) to every functions and cleases? I am using VC7
psksvp
|
|
|
|
|
:(No but I do have a suggetion.
In sted of using __declspec(dllexport) use a .def file that way you will not have to modify the code.  You will still have to enter all the function names in the EXPORT section.
You might also try a document generator like Doxygen, you should be able generate .html documents then (1)find the list of functions (2)strip the HTML code (3)cut and copy to .def file (4)ether add the ordinal values (foo @1) manualy or write a small program to do it for you (my personal choice).
My second choice would be to write a small program that takes a list of header files (or allows you to select a list) and parse them to generate a list of function names (or generate a .def file).
May the code gods be with you!
|
|
|
|
|
Also, there is one thing worth mentioning..
When exporting from a DLL, you should use both __declspec(dllexport) calling convention and the .def file. When you use both, you can use the DLL with run-time linking (LoadLibrary() and GetProcAddress()). If you use only __declspec, it doesn't work for some strange reason. Might be a bug, but using both makes sure.
Also, an interesting thing in exporting classes is that you can export a function from the DLL, which returns a class generated during the CRTStartup (DllMain) of the DLL. This way, you can generate COM-like objects, which are external, and for which you only need to provide the header files. When the DLL is loaded (LoadLibrary), get the address of the function returning the class address, and take it to a local pointer in your program. Then you can utilize the class within the DLL without creating a local copy.
Most interesting thing to do with this is to create classes, which generate windows and window procedures. I myself made two small DLLs, one which creates a main window, and one which provides support for left and right mouse clicks within this window. Then in the main application, I just loaded these DLLs and utilized them. Useless, but interesting 
-Celorfie
|
|
|
|
|
Is there a way to send a BN_CLICKED notice to an edit box.
Thanks
|
|
|
|
|
I do not recommend it.
But one of the following should work.
SendDlgItemMessage(ID_EDITBOX,WM_COMMAND,(WPARAM)MAKELONG(ID_EDITBOX,BN_CLICKED),(LPARAM)GetDlgItem(ID_EDITBOX).GetSafeHwnd());
or
::SendDlgItemMessage(hWnd,ID_EDITBOX,WM_COMMAND,(WPARAM)MAKELONG(ID_EDITBOX,BN_CLICKED),(LPARAM)::GetDlgItem(ID_EDITBOX));
Trust in the code Luke. Yea right!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
