|
Do you mean like this?
class B
{
};
class A
{
B b;
};
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Kindof, except I want B to be an internal class of A. In your sample B is it's own separate class. (going to quickly edit my original post)
|
|
|
|
|
Your first version looked right. I guess I'm not sure what you meant by "I would like to change
it to something where class B is defined outside" 
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
yeah it was right... I just had to recheck it (I thought I had a typo but I didn't).
what I mean is I want class B to still be an internal class of class A. Yet I would like the definition for it to be outside class A (ie. in a different file).
That is to say, I don't want class B to be defined between the curly brackets of class A.
|
|
|
|
|
R Thompson wrote: yeah it was right... I just had to recheck it (I thought I had a typo but I didn't).
Just a missing semicolon.
R Thompson wrote: That is to say, I don't want class B to be defined between the curly brackets of class A.
It has to be there if that's the scope you want it to have. Scope is the only effect nesting a
class has on the class.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
May I suggest something like this:
class BInternal<br />
{<br />
};
class A<br />
{<br />
class B : public BInternal<br />
{<br />
};<br />
};
If you hide the definition of BInternal then from an external perspective this is the same as what you want I think.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Actually, I Think I understand what you mean. In C you would declare A as an element of B. CPP is Object Oriented, that means that the lingo changed, from Sub Structure to Inheritance. To achieve the same effect, you derrive class B from class A. This Typically means that you can downcast a pointer to class B as a Pointer to class A. It has it's benefits though, In general a Downcast is not required, and the Syntax is a lot less involved.
LateNightsInNewry
|
|
|
|
|
I'm probably one of the few last remaining hungarian notation users around but if anyone out there still writes code using hungarian notation, would you happen to have a link for the latest recommended forms that would include 64-bit pointer precision types like LONG_PTR.
Or,
if anyone has any ideas on how to name
LONG_PTR
INT_PTR
that would be consistent with past practices. I'm at a loss on how to do it (nicely) without confusing myself later on.
|
|
|
|
|
I'm a closet 'hugarian' as well  although I never did use f... for bools. My latest practice is to use names like INT64 or LONG32 where the sizes are genuinely fixed and won't change depending on the platform where this code is compiled and ULONG_PTR and the like for types that are sized according to the word size of (bitage as I prefer) of the system. Of course if you're defining these types yourself and intending others to use them then you probably shouldn't polute the default namespace with such generic names anyway so in my latest project I use mxUINT32, mxINT64, mxUINT_PTR, mxULONG_PTR. I don't have mxLONG_PTR defined because as far as I'm concerned pointers are never signed but that's probably a matter of taste. I use this style of names for anything #define(ed) or typedef(ed) from fundamental types either directly or via windows headers.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
thanks for the response.
interesting technique. The "m" might catch me offguard from time to time if just glancing or skimming code as if it were a member variable.
Matthew Faithfull wrote: I'm a closet 'hugarian' as well
we are indeed an endangered species.
|
|
|
|
|
The problem with LONG_PTR is that I see many people using it when there is no need to - the variable will never contain a pointer to anything. If you're dealing with fixed-size variables, you should mark them as i32 or i64. If you really need LONG_PTR, then use lp.
|
|
|
|
|
Thanks for the guidance.
CArray::GetSize() returns INT_PTR in MFC 7.1
This unfortunately is not a pointer so using "lp" can be confusing here since anytime I see "lp", an arrow operator is always dancing in my head.
With GetWindowLongPtr(), it returns LONG_PTR and can on occasion, such as when using GWLP_USERDATA possibly represent a pointer if the user squirreled one away in there for use in a static callback method.
I'm finding it more common anymore to come across things that use it for items of size and occasionally for pointers so I'm not sure a naming convention that mixes with a plain old pointer convention wouldn't confuse others and myself later on.
I've been toying with "np" but it just doesn't flow.
|
|
|
|
|
Just to be clear. The purpose of types like LONG_PTR is to store non pointer data that will always be the same size as a pointer so that for example reinterpret_cast<LONG_PTR>(CMyObject*) will work without changing it on both 32bit systems where sizeof(CMyobject*)==4 and on 64bit platforms where sizeof(CMyobject*)==8. In other words it's a long that's the same size as a pointer.
This is different from the lpName convention which goes right back to the old days of memory models and far-pointers and near-pointers / long-pointers. Please don't ask me to explain it, it was before my time but you can see that np would definitely not be a good idea especially when there's oldies around. So when the API says lpData it means a full size pointer on the current system i.e. 32 bits or 64 bits and when it says LONG_PTR it means a 32 bit or 64 bit numeric that is always the same size as a pointer. void* lpData and LONG_PTR PtrData will always be the same size so conversions will maintain all the data. I hope that's cleared it up 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Why my code:
<br />
pStorage->CreateStream( lpszW, STGM_DIRECT|STGM_CREATE|STGM_READWRITE|STGM_SHARE_EXCLUSIVE|STGM_FAILIFTHERE, 0, 0, &pStream) <br />
returns error STG_E_INVALIDNAME (Invalid value for pwcsName) [pwcsName => lpszW]?
I use this befor calling CreateStream:
<br />
LPWSTR lpszW = new WCHAR[255];<br />
LPTSTR lpStr = strFilePath.GetBuffer( strFilePath.GetLength() );<br />
int nLen = MultiByteToWideChar(CP_ACP, 0,lpStr, -1, NULL, NULL);<br />
MultiByteToWideChar(CP_ACP, 0, lpStr, -1, lpszW, nLen);<br />
where strFilePath is e.g. "Slika000.jpg"??
I use this for storage a file.
THX to all
|
|
|
|
|
In this case, you know the size of your WCHAR buffer so you don't need to check the result string
length. An alternative is to actually use the destination length.
Also the much-overused GetBuffer() is not necessary when you need a const TCHAR pointer to a
string
int nLen = MultiByteToWideChar(CP_ACP, 0, strFilePath, -1, NULL, 0);<br />
LPWSTR lpszW = new WCHAR[nLen];<br />
MultiByteToWideChar(CP_ACP, 0, strFilePath, -1, lpszW, nLen);
Regardless, that doesn't explain what's wrong with the string - what's in lpszW after the second
MultiByteToWideChar() call?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I get it to work anyway. I think the reason was in strFilePath which contain a '\' characters e.g. "C:\something\something_else\...\...".
What I did is I caled CFile::GetFileName() now it works!
But now I can't use this regarding directories, and I can't use listing directory for files.
You see, I'm trying to record CD using IMAPI and users should be able to select directories as well as files to record them to CD. Now it would be vainly for users to see on their CD only files and no directories as they heve selected!
Could I open a stream (put folder name) and add numerous files one by one until all files are added from directory??
THX for help
|
|
|
|
|
Were you using single backslashes in a string literal?
If you're working with files and folders then you can construct full pathnames for each file.
SHBrowseForFolder() could be used to let the user select a folder.
Once you have a path to a folder, append the filename to it for each file (which makes a full
pathname) and create the stream from that pathname.
Is that what you're trying to do?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I already use SHBrowseForFolder() for folder selection.
"Were you using single backslashes in a string literal?"Re: Backslashes are in folder/files path's. I was doing it wrong, I've used the whole path name for CreateStream calls and I think that was the reason for errors. Now I use only filenames GetFileName() and it's all OK. But there is still issue of preparing a folder storage for burning on CD.
Now I'm working on an function which will be recursive, it will go in the folder and crating streams for all files in all folder inside the root folder.
My main concern is how, and is it posible, to create that much storage and stereams to pass to those storages and at the end write such storage on CD. I know it can be done. As I understand that storage are like folders and streams like files, is that means I should use storages for folders and streams for files. On example if I had a folder 'F1' and in side folder 'F2' and two files. And in 'F2' one file.
F1-->F2-->file3<br />
->file1<br />
->file2
I should do something like this: create a storage for 'F1', go inside and search for files, find 'F2' which is a folder (recursion call) I create another storage for 'F2' and go inside, where is a file named 'file3'. Now I create stream for 'file3' and add it to storage for folder 'F2', go back add and create two streams for 'file1' and 'file2' and all that plus storage for 'F2' add to storage for 'F1'! If this is so, how can I add storage to storage?
Thanks
|
|
|
|
|
I'm not sure why you're using structured storage if you are putting the results on a disk.
All the streams go into one file so you can arrange the heirarchy of the storage object any
way you want
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
|
why on hell are you modifying a function of the C runtime ??? 
if your compilation fails, it's because of your code, not the sources provided with the compiler (even if the compiler reported the error in memcpy()) 
|
|
|
|
|
No No this is a question I have to answer, I am just checking to make sure the function code show doesnt cause cause any problems and it is efficient code.
|
|
|
|
|
You delete your question!?
|
|
|
|
|
Yeah they said that I didnt need to post it twice but the question basically was:
What is wrong or how can I improve this function:
void* memcpy( void* dest, void* src, size_t size )
{
byte* pTo = (byte*)dest;
byte* pFrom = (byte*)src;
assert( dest != NULL && src != NULL );
while( size-- > 0 )
*pTo++ = *pFrom++;
return (dest);
}
|
|
|
|
|
Hi Josh,
You're copying a byte at a time... it is not as efficient as it could be on architectures such as x86 which has SIMD instructions.
Jeff
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
