C / C++ / MFC

9-Feb-03 1:05

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

Tim Smith9-Feb-03 1:25

Tim Smith

9-Feb-03 1:25

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.

George29-Feb-03 1:35

9-Feb-03 1:35

Thanks, Tim buddies!

Your reply helps a lot.

Best regards,
George

Gary R. Wheeler9-Feb-03 5:00

Gary R. Wheeler

9-Feb-03 5:00

<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>
Roll eyes | :rolleyes:

Software Zen: delete this;

Nitron9-Feb-03 9:49

Nitron

9-Feb-03 9:49

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

Question about const int&

Gary R. Wheeler9-Feb-03 11:34

Gary R. Wheeler

9-Feb-03 11:34

Thanks

Software Zen: delete this;

George28-Feb-03 23:30

8-Feb-03 23:30

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

Stephane Rodriguez.8-Feb-03 23:45

Stephane Rodriguez.

8-Feb-03 23:45

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.

George28-Feb-03 23:49

8-Feb-03 23:49

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.) Smile | :)

Thanks in advance,
George

Stephane Rodriguez.9-Feb-03 0:13

Stephane Rodriguez.

9-Feb-03 0:13

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&.

George29-Feb-03 0:33

9-Feb-03 0:33

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. Smile | :)

Thanks in advance,
George

Stephane Rodriguez.9-Feb-03 0:47

Stephane Rodriguez.

9-Feb-03 0:47

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.

George29-Feb-03 0:58

9-Feb-03 0:58

Thanks, .S.Rod. buddies!

Your reply have made me clear!

Best regards,
George

includeh109-Feb-03 0:38

includeh10

9-Feb-03 0:38

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

George29-Feb-03 0:41

9-Feb-03 0:41

Thanks, includeh10 buddies!

Your reply helps a lot.

Best regards,
George

Gary R. Wheeler9-Feb-03 5:06

Gary R. Wheeler

9-Feb-03 5:06

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;

What means cout.precision (4)?

Jambolo9-Feb-03 22:39

Jambolo

9-Feb-03 22:39

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 ) { ... } // Neither of these ...
void foo( int const * x ) { ... } // ... functions change x (or *x)
...
foo( bar );    // This call does not appear to change bar
foo( &bar );   // This call appears that it could change bar
               // but it doesn't

ESC closing dialog

S O S8-Feb-03 23:18

S O S

8-Feb-03 23:18

How can I prevent ESC(or any other special key) from closing a dialog?

Re: ESC closing dialog

skaanji9-Feb-03 0:47

skaanji

9-Feb-03 0:47

If you use MFC you should overwrite OnCancel function in your dialog message map.
In W32API remove case IDCANCEL from your dialog callback function.

Re: ESC closing dialog

S O S9-Feb-03 3:22

S O S

9-Feb-03 3:22

Thanks!

DirectX HELP!!!

Ehsan Baghaki8-Feb-03 22:15

Ehsan Baghaki

8-Feb-03 22:15

Hi i am starting to learn DirectX 8 and i am searching about 3 days for Books and Sites and articles about DirectX 8 (or even 9) but i find nothing Special to be helpful for the Basics of DX. Frown | :(

i have searched Kazaa too and i found Teach yourself DirectX 7 in 21 days(Sams publishing). but it seems that the structure of DirectX has completely changed and for example DirectDraw dose not exist in DirectX 8. (if you thing that this book is still helpful tell me plz. i dunno how much DirectX changed from Ver7 to ver8)

So if u know and Resources for learning DirectX Basics plz tell me.

thanks for your suggestion

-=Ehsan-de-Burge=-

Re: DirectX HELP!!!

Anonymous8-Feb-03 23:03

Anonymous

8-Feb-03 23:03

try gamedev.net they have some directx tutorials

there are many parts to directx 2d, 3d, audio, video, input etc

George28-Feb-03 22:09