|
JockeP wrote:
("INSERT INTO Table1 VALUES ('3', 'Olga')");
INSERT INTO Table1 (Field1, Field2) VALUES VALUES ('3', 'Olga')");
where field1 and field2 are obviously part of your table
(you didnt tell us the structure of your table)
Bryce
|
|
|
|
|
Pls Using:
CDaoDatabase::Execute
Learning and Working
|
|
|
|
|
Hi,
it simply doesn't work... I'm right?
Imagine somthing like this.........
template <class T> class CDialogView : public CDialog
{
} It will all compile fine until compiler hits the MFC message macros. At BEGIN_MESSAGE_MAP macro the template specification for the class causes the compiler to fail. A CDialog without message handlers makes no sense, that's why you can't simple skip the message macros. *sigh*
I had a look on Google's Usenet archive and found no solution.
|
|
|
|
|
Check Yury Golstman's article Colored/Blinking Controls and Dialogs with any Font[^]. He features a most interesting technique to implement message maps for template class (view TemplDef.h in the source code).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
interesting technique to implement message maps for template class (view TemplDef.h in the source code)
looks very promising, thanks for the good help Joaquín!
|
|
|
|
|
Hi guys?
is it true that OpenGL is better than DirectX ?
-=Ehsan-de-Burge=-
|
|
|
|
|
-=Ehsan-de-Burge=- wrote:
is it true that OpenGL is better than DirectX ?
no
Moak (who is actually using OpenGL because he likes it more)
|
|
|
|
|
-=Ehsan-de-Burge=- wrote:
is it true that OpenGL is better than DirectX ?
That is an all too common question, that almost as often isn't qualified with "for this particular area" with an explanation of the area, making a "correct" answer impossible.
As a general 3D visualization API, OpenGL is most certainly better than DirectX. Actually, it's the only 3D visualization API widely recognized, and if you in any way or form would like to run your application on anything but Windows (including Wine) OpenGL is again the only recognised API.
If you on the other hand are prepared to limit your application to Windows only, and it seems you are prepared to do just that, DX is currently with the ATI 9700 a little ahead of OpenGL in terms of features - you can use more whistle and bells on todays highest-end PC consumer 3D card, the 9700 (Pro). But if you were interested in those "features" you'd already be knowing them, not having to ask this question. 
For a more thorough examination, may I suggest you search the "advanced" forum over at opengl.org? There was a thread (a rather long thread, some months ago IIRC) a developer basically started with "This is it. I'm going DX". At the end of the thread he wrote something to the effect "OK, I'm convinced. Maybe DX wasn't such a great idea after all. OpenGL it still is for me".
But it still boils down to: What are you going to use it for, and are you prepared to pay the price if you go with DirectX?
|
|
|
|
|
Hi, everyone!
What is the difference between %ld and %d? In most cases,
they are the same. Who can give me an example in which the
two output formats act differectly?
Thanks in advance,
George
|
|
|
|
|
Back in the old WIN16 days, an int was 16 bits and a long was 32 bits. %d was for ints and %ld was for longs. These days, it makes no difference.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Thanks, Tim buddies!
Your reply helps a lot.
Best regards,
George
|
|
|
|
|
<purist_anal_retentive_viewpoint>
The "%d" format is for printing variables of type int. The "%ld" format is for printing variables of type long int. For the Win32 versions of Visual C++ (4.0 and greater), int's and long int's are both 32 bits. It's better 'form' to not rely on their being the same size.
</purist_anal_retentive_viewpoint>
Software Zen: delete this;
|
|
|
|
|
Gary,
I love how you always break things down to their bare essentials and lay out the basics. Good info, and always a nice thing to know, as always.
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
Thanks  ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif) !
Software Zen: delete this;
|
|
|
|
|
Hi, everyone! Please look at the following piece of codes,
--------
template<class t="">
const T* binary_search (T* first, T* last, const T& value) {
const T* lo = array, *hi = array + n, *mid;
while(lo != hi) {
mid = lo + (hi - lo) / 2;
if (value == *mid) return mid;
if (value < *mid) hi = mid; else lo = mid + 1;
}
return last;
}
--------
My puzzle arises from the third parameter of the function,
--------
const T& value
--------
Since there is a const before the variable "value", so the value of
variable "value" can not be changed. But there is also a & before
variable "value", I think it is useless. Because value of
variable "value" can not be changed. (So, a reference type is no use.)
In my mind, a reference type is useful only when its value can be changed.
Am I correct?
What are your options?
Thanks in advance,
George
|
|
|
|
|
George2 wrote:
In my mind, a reference type is useful only when its value can be changed.
Am I correct?
For performance reasons, passing a reference is better since the passed object is not copy-constructed on the stack.
The combination of const and & is good, and reflects the will to produce robust code, ie the compiler will either warn or simply not compile if the API you expose is badly used by your clients.
The side effect of this is that MS changed APIs in MFC7/ATL7 and added const in some places, causing older code to either warn or not compile anymore.
|
|
|
|
|
Hi, .S.Rod. buddies!
I do not understand what means
"the compiler will either warn or simply not compile if the API you expose is badly used by your clients"
in your reply?
Can you give me an explanation? (Better with an example.)
Thanks in advance,
George
|
|
|
|
|
Let's see an example where the compiler won't compile because of the combination of const and & :
Assume that we have an array :
class CArray
{
...
CString GetAt(long i);
};
We can use the GetAt(i) method in our code :
p.DoIt( myarray.GetAt(i) );
where DoIt is declared as : BOOL DoIt(CString &szString);
Now, our array is made more robust and we don't want its content to be changed by calling routines :
class CArray
{
...
const CString &GetAt(long i);
};
The consequence of that is the p.DoIt( myarray.GetAt(i) ); call does not compile anymore, since it's not "legal" to pass a const CString& as if it was a simple CString&.
|
|
|
|
|
Hi, .S.Rod. buddies!
In your reply, you mentioned,
--------
The side effect of this is that MS changed APIs in MFC7/ATL7 and added const in some places, causing older code to either warn or not compile anymore.
--------
when you are talking about the side effect, do you mean older functions without const keyword will not compile? If I am not correct, please show
me the correct explanation.
Thanks in advance,
George
|
|
|
|
|
George2 wrote:
when you are talking about the side effect, do you mean older functions without const keyword will not compile? If I am not correct, please show
me the correct explanation
It depends if you are talking about your functions, or functions from the MFC that you use.
If that's about your functions, then I don't know : of course I don't know your code so it's not possible to tell if there is anything wrong.
If that's functions from the MFC that you use, then yes, the MFC7 collections (CStringArray, CPtrArray, ...) have now const & everywhere (as a result of the integration of STL), which was not the case with MFC6. If you intend to upgrade to MFC7 someday, be prepared to have tons of problems.
|
|
|
|
|
Thanks, .S.Rod. buddies!
Your reply have made me clear!
Best regards,
George
|
|
|
|
|
const and & are two different things
const = "can not be modified" - no problem
& is a must here:
1. "value" is real object passed, not a copy of real object.
2. as template params, reference is a must because we don't know what kind of objects will be used as template params. in other words, we don't know if operator= and copy constructor have been defined in these objects.
for all of MFC collection, operator= and copy constructor are not defined (actually they are defined as "private" to protect to be used.) so if no &, don't hope any MFC collection can be passed as template params.
includeh10
|
|
|
|
|
Thanks, includeh10 buddies!
Your reply helps a lot.
Best regards,
George
|
|
|
|
|
The keyword const indicates that the function may not change the value. The "&" indicates that the value is passed by reference (e.g. the address of the value is passed, not a copy of the value). Without the const keyword, the function would be free to modify the caller's copy of value, which is not desired. If the "&" is left out, value is passed by value, and any changes the function makes to it does not affect the caller's copy.
Software Zen: delete this;
|
|
|
|
|
Ahhh, the beauty of const & parameters! I use these two conventions:
1. If a parameter is passed as a reference, it must always be a const reference.
In the following code, does foo change the value of bar or not?
foo( bar );
Most people would say no, but foo could be defined like this:
void foo( int & x ) { ++x; }
Since people are suprised when something like that happens, it is a source of bugs, so it is a bad idea. Don't change the value of parameters passed by reference. And since the reference is never going to change, you might as well make it const.
If the code looks like this...
foo( &bar );
...then people are not be surpised if the value of bar is changed by foo. So, if the value is changed, use *, If it isn't, use const &.
2. Prefer const & to const *.
So, why use const & when you can use const *? There are other reasons, but here is mine: A function call that doesn't change the value of a parameter should look like it doesn't change the value and vice versa.
void foo( int const & x ) { ... }
void foo( int const * x ) { ... }
...
foo( bar );
foo( &bar );
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
