|
I'm gonna disagree with you here VuNic. The CString has an LPCTSTR operator, which means that casting to a TCHAR* is automatic. If you want to convert it explicitely to a char*, then it probably means you did something wrong with the code and you don't know how to use anycode properly.
Anyway, calling GetBuffer/ReleaseBuffer is NOT something I would suggest, because as I said the CString already has an LPCTSTR operator, so the GetBuffer call returns exactly the same.
|
|
|
|
|
Cedric Moonen wrote: If you want to convert it explicitely to a char*, then it probably means you did something wrong with the code and you don't know how to use anycode properly.
No recommendations?? 
Regards,
Sandip.
|
|
|
|
|
SandipG wrote: No recommendations??
Yes, try to understand what you are doing  . For instance by reading this excellent article[^] (but I think Hamid already provided a link to the article).
|
|
|
|
|
Strings A-to-Z[^]
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
lol that's why I called it a crude way.  But it's not going to make any terrible impact there as he's coping the buffer. But a bad practice I agree.
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
VuNic wrote: But it's not going to make any terrible impact
Yes it is: if UNICODE is enabled, then you just copy a unicode string into a non-unicode string. That's why it is much better to understand what's going, otherwise you will end up with unexpected results.
|
|
|
|
|
When he said CString to char[] it looked apparent it's non-unicode. Otherwise he'd have used TCHARs. But as I said it's still a bad way.
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
VuNic wrote: When he said CString to char[] it looked apparent it's non-unicode.
No, because when you never heard about UNICODE (like me when I started) and if you are using the latest visual studio versions where UNICODE is enabled by default, then you are in trouble.
When I didn't understand anything about all that stuff, I was still using char* everywhere (instead of TCHAR*) and was forcing casts between everything. I can tell you that my code was a big mess 
VuNic wrote: Otherwise he'd have used TCHARs
TCHAR is the generic type, it is not specifically UNICODE. You should use TCHAR as often as possible...
Anyway, my whole point was: do not use GetBuffer/ReleaseBuffer and explicit casts, unless you exactly know what you are doing .
|
|
|
|
|
Yep that would be really a mess in particular if you had used char* specific library functions.
Cedric Moonen wrote: Anyway, my whole point was: do not use GetBuffer/ReleaseBuffer and explicit casts, unless you exactly know what you are doing
Agreed. . I feel lazy at times & use these crude ways but only when I'm sure nobody else handles the code.
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
Cedric Moonen wrote: Anyway, calling GetBuffer/ReleaseBuffer is NOT something I would suggest, because as I said the CString already has an LPCTSTR operator, so the GetBuffer call returns exactly the same.
Noone should suggest GetBuffer/ReleaseBuffer (unless Mark is nearby...) just because of LPCTSTR operator return value isn't the same.
(Carlo the Nitpick)
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
VuNic wrote: You can also use GetBuffer, ReleaseBuffer
These are reserved: can be used only when Mark Salsbery is logged in. 
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
So we can use it. My instinct says Mark is logged in and coming.
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
That's right!
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
CPallini wrote: These are reserved: can be used only when Mark Salsbery is logged in.
These are reserved: can be used only when Mark Salsbery or Gary Wheeler is logged in.
There; fixed that up for ya.
|
|
|
|
|
Thank you for fixing.
BTW: who the hell is 'Gary Wheeler'?
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Why, he's my mild-mannered alter ego, of course.
|
|
|
|
|
VuNic wrote: strcpy(ch, (LPSTR)(LPCTSTR)cs);
Why the unnecessary casts?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Valid question. Actually I typed my reply with a char* .
char* ch = (LPSTR)(LPCTSTR)cs;
But knew that's a bad example. So changed that to char[] & and put the example as copy-the-buffer but had left the LPSTR caste unremoved . LPSTR is not need actually in this case.
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
VuNic wrote: LPSTR is not need actually in this case.
Neither cast is needed. Just use:
strcpy(ch, cs);
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
 Yes we've been discussing that it returns a const char by default. The reason why I used LPCTSTR is that I couldn't cast it straight to char*. As CString doesn't support non-const version. I'm stupid I didn't think before typing. So we don't need all these caste craps when you are copying the buffer.
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
I have the following codes:
double Length0(double x1, double y1, double z1, double x2, double y2, double z2)
{
double dx = x2 - x1;
double dy = y2 - y1;
double dz = z2 - z1;
return (dx*dx + dy*dy + dz*dz);
}
double Length1(double x1, double y1, double z1, double x2, double y2, double z2)
{
return ((x2 - x1)*(x2 - x1) + (y2 - y1)*(y2 - y1) + (z2 - z1)*(z2 - z1));
}
Assume all other conditions are the same, which one (Length0 or Length1) theoretically executes faster?
A bit explanation is highly appreciated.
|
|
|
|
|
With optimisations on, both the same - common sub-expression elimination should reduce Length1 to the equivalent of Length0, except with the variables in registers rather than on the stack.
With optimisations off...probably Length0 is more efficient.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
probably negligible with modern compilers.
This signature was proudly tested on animals.
|
|
|
|
|
Below is the assembly code generated by Visual Studio 2008 for both the functions.
The code was generated with full optimization.
?Length0@@YANNNNNNN@Z PROC
fld QWORD PTR _x2$[esp-4]
fsub QWORD PTR _x1$[esp-4]
fld QWORD PTR _y2$[esp-4]
fsub QWORD PTR _y1$[esp-4]
fld QWORD PTR _z2$[esp-4]
fsub QWORD PTR _z1$[esp-4]
fld ST(1)
fmulp ST(2), ST(0)
fld ST(2)
fmulp ST(3), ST(0)
fxch ST(1)
faddp ST(2), ST(0)
fmul ST(0), ST(0)
faddp ST(1), ST(0)
ret 0
?Length0@@YANNNNNNN@Z ENDP
?Length1@@YANNNNNNN@Z PROC
fld QWORD PTR _x2$[esp-4]
fsub QWORD PTR _x1$[esp-4]
fld QWORD PTR _y2$[esp-4]
fsub QWORD PTR _y1$[esp-4]
fld QWORD PTR _z2$[esp-4]
fsub QWORD PTR _z1$[esp-4]
fld ST(1)
fmulp ST(2), ST(0)
fld ST(2)
fmulp ST(3), ST(0)
fxch ST(1)
faddp ST(2), ST(0)
fmul ST(0), ST(0)
faddp ST(1), ST(0)
ret 0
?Length1@@YANNNNNNN@Z ENDP
Here you will notice that both are exactly the same.
The compiler has taken away the responsibility from the programmer about optimizing code. At least a lot of it.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
yellowine wrote: double Length0(double x1, double y1, double z1, double x2, double y2, double z2)
{
double dx = x2 - x1;
double dy = y2 - y1;
double dz = z2 - z1;
return (dx*dx + dy*dy + dz*dz);
}
You can see no specific improvements with that change there. but on the other hand There would be some improvements with the first case (length0), If the calculations happen inside a loop. just a rough example:
double y1, double z1, double x2, double y2, double z2)
{
double dx = x2 - x1;
double dy = y2 - y1;
double dz = z2 - z1;
double result =0.0;
for(int i=xx;i<yx;i++)>
{
result += (dx* i + dy * i + dz * i);
}
return result;
}
There it would make sense to keep them out of the loop and see some performance improvements.
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
