|
DavidCrow wrote: If the structure was declared globally, it would always exist on the stack. If it was declared within a class, it would only exist if an instance of the class also existed.
The above is true for an instance of the struct not for the struct type itself.
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.
|
|
|
|
|
but a type itself doesn't exist in memory... only instances of this type.
|
|
|
|
|
OK. But the OP, IMHO, refers to the struct type declaration (i.e. to the memory usage of the instances of either globally declared struct type or the class nested struct type).
BTW your sentence isn't completely true (missing static members? ).
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: BTW your sentence isn't completely true (missing static members? ).
nope, my sentence is still valid. even statics are concerned.
for global statics, types don't exist in memory, only instances.
for static class members, same is true.
modified on Monday, December 17, 2007 11:06:49 AM
|
|
|
|
|
Well this is a rather philosophic debate and technically I'm surely wrong... What I mean is that whenever you declare a static class member, you implicitely force that member instatiation hence memory usage without class instances around.
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.
|
|
|
|
|
Of course, but since the OP did not specify, I opted for the former since most folks asking such a question would not be able to differentiate between the two.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: ince most folks asking such a question would not be able to differentiate between the two
Uhm, I think you're right.
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.
|
|
|
|
|
I have the free download version of Visual C++ 2008.
I asked the above question recently, and was told to read http://msdn2.microsoft.com/en-us/library/zebw5zk9(VS.80).aspx . However, that page is for Visual C++ 2005, which uses different DLL's and mentions things that my Visual C++ 2008 does not have. So, please:
Which of the relevant Visual C++ 2008 DLL's do what and are needed for what?
Can they be merely put in the same directory/folder as the .EXE file, or do they have to be in a particular directory structure?
|
|
|
|
|
|
Thanks.
I tried it: I installed it; I dragged typecase_vc.exe into it, and it made a massive list of names of DLL's.
I then tried it on typecase.exe, which was compiled on my old Borland C++ 4.5 compiler, and I know that it only needs a Borland DLL called CW3215.DLL to make it run on other computers; but for typecase.exe Dependency Walker also made a massive list of names of DLL's. Of those, the rest are presumably permanent Windows DLL's.
Please how do I tell Dependency Walker not to list DLL's which are in Windows?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I compiled typecase_vc.exe under Windows Vista. When it is accompanied by the necessary DLL's, which versions of Windows would it run under?
|
|
|
|
|
actually, Depends.exe returns every dependency... but most of the time, the DLLs needed are Windows DLL (so, no need to provide them once again).
|
|
|
|
|
toxcct wrote: actually, Depends.exe returns every dependency...
There's no way for Depends.exe to know of DLLs that are linked explicitly.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Anthony Appleyard wrote: However, that page is for Visual C++ 2005, which uses different DLL's and mentions things that my Visual C++ 2008 does not have.
So read the page MSDN has that discusses deploying VS2008 applications which the other one you supposedly read has a link for.
|
|
|
|
|
Thanks. On top right corner of the Determining Which DLLs to Redistribute" page, I found and followed a link to the "Determining Which DLLs to Redistribute" page for 2008, which lists these DLL's: atl90.dll (Active Template Library); msvcm90.dll msvcp90.dll msvcr90.dll (C Runtime and Standard C++ Libraries); mfc90.dll mfc90u.dll mfcm90.dll mfcm90u.dll mfcmifc90.dll . But of those, atl90.dll mfc90.dll mfc90u.dll mfcm90.dll mfcm90u.dll mfcmifc90.dll do not seem to be anywhere in my C:\Program Files\Microsoft Visual Studio 9.0\ directory tree.
That page says "This page is specific to Microsoft Visual Studio 2008/.NET Framework 3.5", but also "Redist.txt is located in the Program Files\Microsoft Visual Studio 2005 directory on the second Visual Studio 2005 product CD or on the DVD.". Please what is happening. I am sorry to take up so muc of your time.
|
|
|
|
|
Anthony Appleyard wrote: But of those, atl90.dll mfc90.dll mfc90u.dll mfcm90.dll mfcm90u.dll mfcmifc90.dll do not seem to be anywhere in my C:\Program Files\Microsoft Visual Studio 9.0\ directory tree.
But do they exist in your c:\windows\system32 folder?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
They are not in my c:\windows\system32\ folder.
|
|
|
|
|
They'll be in a subfolder of your Windows\winsxs folder.
Take a look at the manifest file generated by your project. There you can get the
version of the VC runtime DLLs your app is using. That will tell you which winsxs
folder to find the DLLs in.
You really need to study the deployment docs if you want to do anything beyond
just running the end-user redistributable installer on other machines.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Anthony Appleyard wrote: do not seem to be anywhere in my C:\Program Files\Microsoft Visual Studio 9.0\ directory tree.
What difference does that make to your deployment problem?
Anthony Appleyard wrote: Please what is happening.
I can't be sure. Maybe you are assuming that all you need to find is a magic list of files and you can take it from there. Deploying VS2008 C++ applications may not work as you assume.
Starting from that first page you posted the URL of you can follow links to many pages of information regarding deployment of a VS2008 VC++ application. I suggest you stop typing questions into forums and start reading the documentation.
|
|
|
|
|
Hello everyone,
I do not know how in the following code, rvalue -- return of X(), could result in a lvalue finally and binded to a non-const reference input parameter of function f.
Any ideas?
struct X {
};
void f (X& x) {}
int main()
{
f (X() = X());
return 0;
}
thanks in advance,
George
|
|
|
|
|
Hey man, what are you trying to do with the following statement?
George_George wrote: f (X() = X());
f(X());
isn't enough for you?
BTW
You're passing a reference to a temporary object to function f .
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.
|
|
|
|
|
Thanks CPallini,
Why you change my code from f(X() = X()) to f (X())? Are they the same? Could you try to compile my code please?
If you change my code to f (X()), the code can not compile. But my code can compile, why? It is a question to you.
regards,
George
|
|
|
|
|
The code compiles (as it should do) in both cases. I've already made a test.
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.
|
|
|
|
|
Hi CPallini,
Could you disable the language extension and have a try please?
regards,
George
|
|
|
|
|
I've done and indeed only your dirty trick compiles. Probably (I have no certainties at this point) you're stressing a dark corner of the C++ standard: the assignment operator breaks the r-value nature of X() .
And IMHO it is weird since you cannot do that on built-in 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.
|
|
|
|
|
George_George wrote: Why you change my code from f(X() = X()) to f (X())?
because he asked a question.
Do you have a problem with questions ?
Do you fear that simple '?' character ?
can't you just answer when we need more informations about what you're trying to do ?
George_George wrote: It is a question to you
lammer
writing f(X() = X()) just has no sense. so re-read CPallini's question again, and reply to him.
George_George wrote: If you change my code to f (X()), the code can not compile
WTF have you ever written ? that's impossible and makes merfect sense to pass a brand new object as a function parameter.
Thanks to answer.
|
|
|
|