|
Hi all,
I am doing a graphics project in Embedded VC++.
For drawing dashed ellipse, I use the BeginPath(), Endpath(), BezierTo() functions.
But these functions are not supported in WinCE.
Is there any alternative way for drawing a dashed ellipse(width > 1) compatible to WinCE.
Please help me.
With Thanks and Regards,
arun a.c.
|
|
|
|
|
Compute the line segments yourself and call Polyline.
You could also try drawing an ellipse using a solid black pen into a memory buffer, then use that as a mask with MaskBlt to blit a hatch pattern into the screen buffer.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
hi guys,
is it possible to use serialize to read a text file?
i got text file which is just as:
standard1 name1
standard2 name2
......
how can i use serialize function in doc class to read it and store it seperately in two CString Arrays(CString standard[100], CString name[100])?
thank u in advance!
|
|
|
|
|
Can I pop up a Doc/view window by clicking a button on a dialog? they must be within the same project space.
|
|
|
|
|
|
hi, thank you for your advice, but it seems you misunderstand me, actually I don't want the Doc/View to be nested inside the Dialog. what I want is sth like: after I click 'ok' on a messagebox, a IE window (Doc/View)pop up. However, I don't want to use shell comment to call a compiled execuatable file from a Dialog based application, I want Doc/View and Dialog be within the same project because there will be some parameter passing staff.
|
|
|
|
|
hello,
I want to use the SysSysColors-function to change some system-colors. how can I write this changes permanent to the user-profile (registry: HKEY_CURRENT_USER...)?
thanks in advance for your replies.
regards, thilo.
|
|
|
|
|
Consider this snippet:
CFoo* p = new CFoo[10];
.
.
.
delete [] p;
My understanding of the delete [] p above is that it
- calls the destructor of each of the 10
CFoo instances,
- frees all memory allocated for the 10
CFoo instances.
Right?
Therefore, when allocating memory for simple data types, e.g., C-style strings, I tend to do this:
char* p = new char[10];
.
.
.
delete p;
i.e., I skip [], since there's no destructor for char.
Is this wrong to do?
(Yes, I could probably look it up in the book shelf behind me, but then I wouldn't get the wonderful diverse insights of the Cpians...)
--
Dad, how strange it is that the pig can speak.
*thoughtful pause* It must have lost its "oink".
(my 3-year old daughter Moa, while watching Babe)
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. (Douglas Adams)
|
|
|
|
|
Its a bad practice to do so.
I would say check the difference in the assembly generated in both cases.
This article explains it well
http://www.codeproject.com/cpp/compout.asp[^]
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
Johann Gerell wrote:
Is this wrong to do?
Yes it is, as the delete [] operator instructs the function to deallocate an array of data types, not just a single object. I think using only a delete function on an allocated array may have unpredictable results (possibly memory leaks!).
Johann Gerell wrote:
i.e., I skip [], since there's no destructor for char.
Having a destructor has nothing to do with the functionality of the delete [] operator. Working on a complex object, such as a class, delete will call the destructor, if it has one, before deallocating the object itself.
When working on simple data types, it just deallocates the memory space occupied.
The general rule I tend to live by when allocating memory using new and delete is to use its complement; i.e. if you started out with new [], then end with delete [].
I Dream of Absolute Zero
|
|
|
|
|
RChin wrote:
Having a destructor has nothing to do with the functionality of the delete []
I think what he is saying is why bother with delete [] when char doesn't have a d'tor - ie it doesn't matter that scalar delete doesn't call all the d'tors as a char doesn't have one.
In general
What happens if you allocate with scalar "new" and free with vector "delete[]"?
The scalar "new" will allocate a single object with no hidden counter. The vector "delete[]" will look for the hidden counter, which isn't there, so it will either crash (accessing nonexistent memory) or grab a random number and attempt to destruct that many items. If the random number is greater than one, you will start corrupting memory after the object. If the random number is zero, you fail to destruct anything. If the random number is exactly one, then the one object is destructed.
Next, the vector "delete[]" will attempt to free the memory block starting one size_t in front of the actual memory block. Depending on how the heap feels today, this may be detected as an invalid parameter and ignored, or this can result in heap corruption.
What happens if you allocate with vector "new[]" and free with scalar "delete"?
The vector "new[]" allocates several objects and stores the "howmany" in the hidden counter. The scalar "delete" destructs the first object in the vector. If it was a vector of zero objects, you corrupted memory. If it was a vector of two or more objects, then objects 2 an onward will not be destructed. (Result: Memory or other leak.)
Next, the scalar "delete" will free the memory block directly, which will fail because the memory block actually starts at the hidden size_t in front of the vector. This again corrupts the heap since you are freeing memory that is not a valid heap pointer.
For more info:
http://weblogs.asp.net/oldnewthing/archive/2004/02/03/66660.aspx
RChin wrote:
The general rule I tend to live by when allocating memory using new and delete is to use its complement
Errrr yeah well they wouldn't bother having both scalar and vector deletes and new's if that wasn't the case eh.
The general question was why thats the case. Many people seem under the misconception that the difference between delete and delete[] is just that delete[] will call all d'tors, not just the one for the first object - and hence it's safe to use delete on a new[] if your object doesn't have a d'tor. That web link explains what else happens when you mix/use scalar and vector new/delete.
|
|
|
|
|
Great link!
Man, there sure are some goodies on Raymond's blog!
--
Dad, how strange it is that the pig can speak.
*thoughtful pause* It must have lost its "oink".
(my 3-year old daughter Moa, while watching Babe)
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. (Douglas Adams)
|
|
|
|
|
Thanks for that link, (P?) Diddy. 
I've already put it in my Fav. list.
I Dream of Absolute Zero
|
|
|
|
|
No problem,
I teach C++/MFC/COM during evenings (while doing it for a profession during the day - mad - yes thats me) and regulary hand a print out of that site as is to explain the difference between scalar and vector delete - it expalins it pretty well i think.
|
|
|
|
|
Using delete without [] causes memory leaks when you're dealing with an array because actually you only get the first element destructed and released memory for, I think. You won't get much optimization by doing so anyway, so why risk?
|
|
|
|
|
Johann Gerell wrote:
char* p = new char[10];
.
.
.
delete p;
What if you changed char to CString? Then you'd have to remember to also change the delete statement.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
DavidCrow wrote:
What if you changed char to CString?
I wouldn't.
Off the top of my head... hmmm... I don't think I've ever created a CString on the heap.
But I get your point.
--
Dad, how strange it is that the pig can speak.
*thoughtful pause* It must have lost its "oink".
(my 3-year old daughter Moa, while watching Babe)
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so. (Douglas Adams)
|
|
|
|
|
|
WRONG WRONG WRONG WRONG WRONG...
Just because it sometimes works ok doesn't mean it is a good thing to do. The standard specifically states that you must pair new with delete and new [] with delete []. On some implementations it might work ok, but on others it might totally fail. Also, if someone overrides new[]/delete[] for your object in question, you would be invoking the wrong delete method.
VERY VERY VERY BAD IDEA!!!!!!
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I skip [], since there's no destructor for char
You're wrong on this count. All types - internal plus user defined, all have constructors and destructors.
For example, ever tried:
int y(10);
which is the same as:
int y = 10;
The () indicates that it is a call to int's constructor.
each type also has predefined assigment(=), +, - etc. operators.
Bikram Singh
|
|
|
|
|
Nooooo.
int y = 10:
mov dword ptr [ebp-4],10
int y(10):
mov dword ptr [ebp-4],10
Simple - move "10" onto the stack. In contast to a C'tor call which would look something like this for class CBase:
lea ecx, [ebp-4]
call @ILT + X(CBase::CBase)
Note the call  )
There is no difference between y(10) and y = 10 - they are primitive types - built into the language and supported by CPU registers - this is not Java!
|
|
|
|
|
i am using OLE IPicture interface to load images but i am having troublr with the foolowing line of code
"OleLoadPicturePath(OlePathName,NULL,0,0,&IID_IPicture,(void *)(&Ipic));"
when i try to compile it the compile genertes a type casting error for parameter 5.
i think i am using the correct syntax. Can any one tell me what the problem is.
Aizaz
|
|
|
|
|
Aizaz wrote:
OleLoadPicturePath(OlePathName,NULL,0,0,&IID_IPicture,(void *)(&Ipic));
You only fed it 6 arguments for that function. No wonder~~~ 
Maxwell Chen
|
|
|
|
|
Its defined as :
STDAPI OleLoadPicturePath{
LPOLESTR szURLorPath,
LPUNKNOWN punkCaller,
DWORD dwReserved,
OLE_COLOR clrReserved,
REFIID riid,
LPVOID *ppvRet
}
So parm 5 is of type REFIDD - in C that expands to IID* or in C++ it expands to IID&. Your passing &IID_IPicture - IE IID*. Change it to:
OleLoadPicturePath(OlePathName,NULL,0,0,IID_IPicture,(void *)(&Ipic));
On a side note, 6 is also wrong. Its of type LPVOID* - or void**. So persuming your IPic is IUnknown* (or whatever) you pass (void**)&Ipic - so in total
OleLoadPicturePath(OlePathName, NULL, 0, 0, IID_IPicture,(void**)&Ipic);
|
|
|
|
|
It should be IID_IPicture and not &IID_IPicture
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
