|
The double cast is very dangerous as it can lead to buffer overruns if you are not absolutely careful. That is why CString has the GetBuffer() and ReleaseBuffer() member functions.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
Alan C. Balkany wrote:
When I first encountered CStrings, I found it annoying that they cannot be cast directly to (char*) strings, e.g.
There are very good reasons for that.
Alan C. Balkany wrote:
CString str = "...";
char* c = (char *) str; // WON'T COMPILE!
True, the code above won't compile, but the following will:
CString str = "...";
const char* c = str;
That is, unless you are using Unicode, in which case, you'd write that piece as follows:
CString str = L"...";
const wchar_t* c = str;
Or, if you want to write your code so that it compiles with either Unicode or non Unicode settings, you can use the T macros, and code it like this:
CString str = _T("...");
const TCHAR* c = str;
The T macros (i.e.: _T, TCHAR, LPTSTR, LPCTSTR, etc.) will take care of resolving to the appropiate character type (i.e.: char o wchar_t), depending of your Unicode settings. For example, if you don't use Unicode, TCHAR resolves to char; if you use Unicode settings, TCHAR resolves to wchar_t.
Getting back to the point, the key is that CString defines a cast operator that works as an automatic convertion to a const pointer to its internal buffer. So, whenever the compiler expects a const TCHAR*, you can put a CString and it will work without problems, and without the need of any explicit cast. That includes assigning a CString to a const TCHAR*, or passing a CString to a function that declares its argument as a const TCHAR*.
When you declare a const TCHAR* you are saying you won't modify the content of the string, and most importantly, the compiler will enforce that:
CString str = _T("...");
const TCHAR* c = str;
printf("The string contains: %s\n", c);
TCHAR buffer[10];
_tcsncpy(buffer, c, sizeof(buffer)/sizeof(buffer[0]));
_tcsncpy(buffer, str, sizeof(buffer)/sizeof(buffer[0]));
c[2] = 'a';
_tcsncpy(c, buffer, 1);
So, when CString declares a cast operator for const TCHAR* you can think about it as if CString were telling you
"All right, I'll give you access to my internal buffer, but only if you promise to be a good boy and do not alter it in any way, that is, only if you declare the pointer through which you'll receive it as a const one, so that my friend the compiler can verify you don't do any kind of nasty things to MY poor little beloved internal buffer."
Now, let's look again at what your STOC macro is doing. The first thing it does is an explicit cast to a const char*, making the CString reveal its internal buffer, with full confidence in your good and honest intentions, and trusting you'll keep your word and won't try to tamper with it. And what's your very next action? You cheat! You betray the CString! You ruthlessly cast the pointer to an uncontrolled non const char pointer, so that the compiler won't catch you if you intend to do what you aren't supposed to do. Man, that's not fair, that's not fair at all...
Then again, why is CString so worried about what you do with its buffer, you may ask. After all, it's just a buffer; what's the big deal? Well, as it happens, CString keeps not only a buffer, but among other things, a record of the current length of the allocated buffer, and the current length of the string contained in it, so that it can better serve YOU, whenever you ask for operations like GetLength(), or a concatenation of another string to its end. For example, keeping a record of the current length, means it doesn't need to waste YOUR time searching from the start for a terminating zero, for each operation you ask. You see? CString is just trying to be as efficient as possible in responding to your requests. I still can't believe the way you betrayed it!
If you happened to, for example, alter the length of the string, then when you request a new operation to the CString, it may fail miserably to fulfill your request:
CString str = _T("I love you so much, honest!");
char* p = STOC(str);
strcpy(p, "I cheat");
str += " no one, ever.";
prinf("str knows that %s\n" str);
Maybe you expected the above code to print
str knows that I cheat no one, ever.
Instead, the output will be the actual truth
str knows that I cheat
CString doesn't like things like this to occurr to you, or even worse things:
CString str = _T("I love you");
char* p = STOC(str);
strcpy(p, "I love you so much");
And that's why I told you before there are good reasons why CString doesn't define an automatic conversion to non const char pointers.
In any case, why would you want to convert a CString to a char*? Do you intend to modify the buffer? If you really don't need to modify the buffer, you can just use a const char*, as was shown above, and everything will be fine. No need to play tricks.
If you do need to alter the buffer, though, you can still have a char* to do that. The only thing you'll have to do is asking for it. That's right, you just need to be polite!
CString does offer you a way to politely ask for a pointer to its internal buffer that you can modify: GetBuffer(int nMinBufferLength)
In the documentation, CString is telling you:
Here's the deal: you can ask me for a modifiable buffer and I'll give it to you. But you must tell me what's the minimum length you need. After you are done, please let me know, so that I can adjust my internal variables according to the new state.
To me, that's like saying "Yes, honey, I'll do that. But please do respect me in the morning, will you?"
As the gentleman you are, I'm sure you don't want to hurt CString feelings, so how do you show your respect? Just calling ReleaseBuffer after you are done. While releasing the buffer, you may just let CString figure out by itself how many characters you left in there (passing -1), or you may kindly save it the trouble by informing that yourself (passing the exact count).
CString str;
char* p = str.GetBuffer(1000);
strcpy(p, "I'm a good boy. I mean it");
str.ReleaseBuffer(-1);
Now, be a good boy, delete that horrible STOC macro, and promise not to do it anymore, will you? 
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
char buffer[1000];
sprintf(buffer, "%S", (TCHAR*)unicodeCString)
|
|
|
|
|
|
I'm trying to write a small and simple GUI library in C++. Kind of like CDialog in MFC and all.. The problem is, I learnt C, and I've always had problems getting into the C++ part. I know the syntax and all, but it's rather the concept I can't always grasp. Now this may seem trivial, but it matters to me. My problem is this:
Let's say I want to encapsulate a Window class into its own class, and also a normal overlapped window.
Now my reasoning would be something like this: A window is based on a window class, so to make a window we'll need to pass our window object a windowclass object when we create it.
Now I have several questions. First of all, look at two different approaches to implement the WindowClass class:
WindowClass::WindowClass(HINSTANCE hInstance)
{
if(!RegisterClassEx(&_wcex))
}
As u can see we call api function RegisterClassEx() to register the class in the constructor, so this class would only have a constructor and a destructor, and perhaps some additional constructors to allow more parameters to be passed to the WNDCLASSEX structure for greater customisation.
Great idea, u just pick the constructor u need and ur window class is registered just by creating the object.
Now the other approach:
WindowClass::WindowClass(HINSTANCE hInstance)
{
_wcex.hInstance = hInstance;
}
void WindowClass::Register()
{
if(!RegisterClassEx(&_wcex))
}
In this implementation the only difference is we put the actual api call in a seperate method, so we can add Set() methods to the class for any field of the WNDCLASSEX structure, so we can customize the entire class. The only downside is it will result in more method calls depending on how much we want to customize.
Now I realize this probably doesn't make much difference in practice, it both works, but I was wondering what you feel is the right way to do it. Personally I feel the right thing to do is to actually avoid API calls in constructors/destructors. I suppose it's more of a OO philosophical question though. If you could share your opinions on it, or direct me to some articles about this I'd be very grateful.
I have another problem, but seeings this post is already kind of longwinded, I think i'll hold it back until i've had this one answered.
P.S.: I've already read Relisofts tutorials, and though I think they're great, I don't always agree on their methods, they're taking it a bit too far if u ask me.
Kuniva
--------------------------------------------
|
|
|
|
|
What you want to do is to encapsulate all low level API details, so that your library can be used anywhere. Right?
Well, if that's the case, you should not create a light wrapper. What you are doing is coupling the API calls in one object.
What you want to be doing is define a set of styles for the window. Define all the other stuff yourself also (windows messages, controls, etc..) and in your code, translate this stuff into windows API calls. This way, you can provide different implementations (makes your project portable). In the ideal case, you don't have to modify your application when you compile it under Linux or whatever GUI. The only thing that has to be done is to use a different implementation of your library!
To get back on track here and to answer your question: I think that you should go for the two stage window construction. One rule is to never throw an exception from a constructor. So here you have almost no way of notifying the caller of your code that creation failed.
One other suggestion though. For abstraction purposes, you should hide implementation details. The win API is an implementation detail. So hInstance variables should be hidden. The raw styles should be hidden. Try to hide as much handles as you can, etc, etc..
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Hi, Im developing a speaker identification security system for my computer. I've created the software but I need help in making it block the screen while it runs. Your suggestions will be highly appreciated.
|
|
|
|
|
Perhaps you should explain in more detail what "block the screen" means.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Yeah, because at first I was thinking he could stand in front of it 
My wife often proclaims, "You make a better door than a window!' whilst I stand in front of the TV when her soap opera is on 
|
|
|
|
|
My best guess is a "how to lock" a screen. You can draw a big form, maximized, borderless, on top of all the rest.
michael.code.ae
|
|
|
|
|
Can anyone point out the differences between Visual C++ 7.0 (.Net) and Visual C++ 6.0?
Thanks
|
|
|
|
|
For strict C++/MFC code, the compiler is a lot more compliant and strict; I believe there are minor changes to MFC and ATL to merge some classes ( I think the CString is one of them ).
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
|
I am a c++ beginner programmer
I want to take an image from my webcam and put it in buffer using directshow,
and any directshow tutorial.
Please help me.
Gohary
|
|
|
|
|
Here are several Tutorials to DirectShow, also for Capturing. Perhaps you also want to have a look at the DirectShow Docs coming with your DXSDK.
http://www.codeguru.com/Cpp/G-M/directx/
rya.
Scorcher24
|
|
|
|
|
when variable i increase to some value(not definite),exception occurs,is it a bug of ie6.0? Thx a not!
Source code goes as follows:
IHTMLDocument2* pDoc2=NULL;
IHTMLElementCollection* ppCollection=NULL;
IDispatch* ppvdispOption=NULL;
pDoc2->get_all(&ppCollection);
Assert(ppCollection);
ppCollection->get_length(&Count);
for (long i=0;i<count;i++)
{
=""
="" _variant_t="" index="" ;
="" try
="" ppcollection-="">item(index,index,&ppvdispOption);
}
catch (...)
{
tagstr.Format("%d",i);
AfxMessageBox(tagstr);
return FALSE;
}
if(!ppvdispOption)
continue;
ppvdispOption->QueryInterface(IID_IHTMLElement,(void **) &pElement);
ppvdispOption->Release();
//.........
}
|
|
|
|
|
123ivan123 wrote:
IHTMLDocument2* pDoc2=NULL;
IHTMLElementCollection* ppCollection=NULL;
IDispatch* ppvdispOption=NULL;
PROBLEM IS HERE
pDoc2->get_all(&ppCollection);
pDoc2 haven't got any memory!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
u r there but "not" luking at my problem... i meant it,, but toxxct gave the answer for that ..
V
|
|
|
|
|
if he doesn't know the answer, why would he overload the servers ?
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Vivekuniq wrote:
u r there but "not" luking at my problem.
Yeah i looked at your problem, But when I see Tox already given you the answer, So i think there is no need of redundancy .
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
toxcct wrote:
if he doesn't know the answer
Usually I don't answer when somebody already given the answer 
toxcct wrote:
why would he overload the servers ?
 , Hain Tox i would be working On VC Forum Q&A 5 now (i.e. 2 and 3 is on you).
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
ThatsAlok wrote:
On VC Forum Q&A 5 now
ok... i'm on a now project at work, but i'm doing my best to mix everything in time...
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Hi,
I downloaded a sample mfc project that builds and runs fine. But when I add any ActiveX control on one of the forms, it fails to start. What could be the problem?
Emmanuel Mwesigwa @ Mwemat
|
|
|
|
|
Could it be that the ActiveX control has not been registered? You can confirm this by ensuring that the dialog has the DS_NOFAILCREATE style.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Hi all.
I have a dialog, that is a plugin for another application.
The problem is that my dialog works nice when i launch it from the other application, except TASB navigation and shortcuts.
When i test the dialog from Layout->Test, the TAB navigation works nice, but when i try to use tab navigation from my dialog launched from the host application i am not able to navigate with the TAB key.
In addition accelerators keys don't work with my dialog.
Any clues, maybe i have to explicitely get the TAB control? how can i do this?
Thanks
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
