|
Just wondering what the most compact way of writing this code is and how the c++ compiler implements the evalution order.
ps is a ptr to an unsigned char *
Under gcc-3.3.4 with -Wall there are no warnings with
*ps++=0xFF-*ps;
*ps++=0xFF-*ps;
*ps++=0xFF-*ps;
Under gcc-4 ps might be used unitialised.
The code below fixes the ordering problem But I was wondering if the LHS and RHS are evaluated in parallel in non deterministic order?
*ps=0xFF-*ps; ps++:
*ps=0xFF-*ps; ps++;
*ps=0xFF-*ps; ps++;
I would be interested in faster / more compact ways of doing this. Assembly?
I was also wondering without going to assembly if this is the fastest way of accessing the values in the register.
Thanks,
|
|
|
|
|
You're using ps in two parts of the expression, one of which has a side-effect. Don't do that.
Don't try to hand-optimize code unless you've profiled it and you know it's a bottleneck. You are not a better optimizer than the compiler writers. Making the code clear and readable is a much better goal.
|
|
|
|
|
Yes . The ps being on both sides has a side effect. I looked up the c++ standard but could not get any clarification on the order of the lvalue and rvalue computation in this case. Can you clarify?
It is most definately true that I am not a better optimiser than the compiler writers however apparently is is difficult for the compiler implementors to do very complex algebraic reductions as the following link shows. Experimenting with gcc -S and toggling -O2 yields some interesting results.
C++ Optimisation
Regards,
|
|
|
|
|
I tend to agree with Michael, probably not the place to worry about optimizing.
That said, i'd hate you to go away with nothing.
You could replace:
*ps = 0xff - *ps;
with:
*ps = ~*ps;
In assembly this will convert:
mov edx, 0ffh
sub edx, ecx
to:
not ecx
So, seeing as mov, sub and not are usually ~1 cycle you are probably only saving 1 cycle per use. Where you place the ps++ isn't likely to effect the resulting assembly, so make it clear rather than clever.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Thanks for the tip. I will take both your advice on board, however Optimisation does seem to be important in large scale image processing.
Regards,
|
|
|
|
|
i use WINAPI to built a DLL.There's a main dialog in it . when i want to open a new dialog according to a button on it, it failed . However i can if i use dynamic DLL to do it. How can I do? Thanx a lot.
|
|
|
|
|
hi
how i can create activex control include ather controls and activexs?
i user visual c++ 6
|
|
|
|
|
In the SQLExecute(hstmt) the hstmt is being passed to the Oracle ODBC 8i driver as an SQL_CHAR which is limited to 255 charaters. So if you have a large table requiring say 300-500 characters then your inisert or select statement will fail. Can anyone tell me if there is a way to fix this limitation? The Visual C++ side is using a CString object so it has more then enough size to handle the large statement. The problem is definately on the ODBC side. Any help on this matter would be greatly appreciated.
Thanks,
Charlie
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
Charlie Curtis wrote: ...as an SQL_CHAR which is limited to 255 charaters...
Where do you find this limitation documented? The text length parameter passed to
SQLPrepare()/SQLExecDirect()/etc. is a long integer - 32 bits.
Mark
|
|
|
|
|
Hi Mark,
Haven't really found any documentation per say I am going by the fact that when I trace through the code and I look at the string being passed to SQLExecute(hstmt) it is in fact limited to 255 characters. I have tried both the SQLPrepare() and SQLExecDirect() funtions as well, but always the same the string passed is 255 characters. So any further help here would be appreciated.
Thanks for replying to this message,
Charlie
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
Charlie Curtis wrote: when I trace through the code and I look at the string being passed to SQLExecute(hstmt) it is in fact limited to 255 characters
The string being passed or are you tracing into SQLExecute() and seeing it being truncated??
Are you passing the correct string length or SQL_NTS for the text length parameter?
Mark
|
|
|
|
|
Hey Mark,
I am passing SQL_NTS is that my problem?
Thanks,
Charlie
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
Not unless there's a _T('\0') at index 255 in your buffer 
So the string is already truncated before the call to ODBC? If put a breakpoint at the call what's
in the string?
Mark
|
|
|
|
|
Yes Sir that is correct it is being truncated prior to the SQLExecute. It has 255 charaters of the string in it. It has 253 readable characters and I am assuming the \0 at the end. However, there is no reason for it to truncate at that point as it is a CString object. So it is reall freaking me out that it is doing that...
Charlie
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
hmm Can you show the code used to construct the string?
If you do this do you get more than 255 chars in your string?
CString str(_T(""));
for (int i = 0; i < 16; ++i)
{
str += _T("0123456789012345");
}
str += _T("This is past 256 chars");
|
|
|
|
|
No I get the same a truncated string ending at 901. I even created a brand new project to see if maybe it was something specific to the project I am workingon, but it truncates in the new project the same... Not getting it. I wouldn't think it would, but maybe you know better then I. Could it have something to do with this computer having a 64 bit processor? Just grasping at straws now...
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
Charlie Curtis wrote: No I get the same a truncated string ending at 901
Well I am clueless at this point
It's not ODBC if that helps any 
I don't know whether or not there's issues with CString in 64-bit.
Here's an article about a CString-like implementation that maybe you can use
CString-clone Using Standard C++[^]
If I come up with something I'll let you know!
Mark
|
|
|
|
|
OK, I appreciate your time, and if I come up with what it is I will try to remember to let you know what it was...
Charlie
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
I had similar problem before but with a different driver and different database using Visual C++ 6.0.
Found out that the debugging facilities cannot show more than 256 char not the driver. It was a problem with the sql statement after the 256th char.
Try 'MessageBox'ing the sql statement before and after execution. See if you get a truncated text. And check ur sql syntax there.
|
|
|
|
|
Hi Onn,
Thank you very much for your reply! I did the MessageBox thing and sure enough you are right it shows the whole statement! That helps me very much as now I can find out what is wrong with the statement.
For anyone reading this and wondering what the actual problem turned out to be; Well it turned out that it was in the formatting of the statement itself. If you miss one little quote or comma then there is hell to pay! As for the truncated string Onn was absolutley correct. The full string is being passed and the truncating has to do with the debugger only being able to show the first 255 characters.
Hope this helps anyone else who might have run up against this!
I'm sure most everyone knows, but just in case someone is new it might help! If you can't get the code working in your c/c++, Visual c++ code it helps me alot in many cases to work with the statements using SQLPlus and when I get it to work there it maost likely translates right over to my code.
Thank You Very Much!
Charlie
-- modified at 23:40 Thursday 2nd November, 2006
Everything is Free... Until You Have to Pay for it...
Platforms Windows 2000/XP Professional using Visual C++ 6.0
|
|
|
|
|
Okay, I'l try my best to describe the problem at hand. This is what the relations looks like:
CQuad :
implements CNodeInterface
CNodeInterface :
knows of CScene
CScene:
knows of CQuad
knows of CNodeInterface
I have some nasty circular dependency here, I know, but I can't seem to design it away. Anyway, the problem is that CNodeInterface needs to be defined before CQuad gets defined, however no matter how I tinker I can't seem to get this to happen. With forward declarations I still get errors in CQuad that CNodeInterface is undefined. Part of the problem is that I don't even know what decides which gets defined first when there's circular dependency. I'm using Visual Studio 2005.
Any help appreciated.
|
|
|
|
|
A forward declaration isn't going to work if you are calling functions from within that class. Did you try adding an extern forward declaration?
|
|
|
|
|
Yupp, and I'm still geting the same compilation error 
|
|
|
|
|
If you post some of the relevant code, someone may be able to offer you an alternative design. Circular dependencies should be avoided, and doing so will also avoid your compilation problem.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
CScene is a scene graph. CNodeInterface is an abstract class that defines the interface for nodes in the scene graph. CQuad in turn is a type of node that lies at the top of the scene graph and creates a quad tree for sub nodes that later on implements CNodeInterface lies in.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
