Few qestions.......

[Tom Backton]

1.Can a 64-bit OS tell whether a given EXE file is a 32-bit program or a 64-bit program and run it correctly?

2.Can a 32-bit OS run a 64-bit program if the processor supports 64-bit programs?

3.Do I specify default values for template parameters only in the general class definition or it's legal/relevant (or has a special use) to specify them in specifications?

4.Which is better/correct for a member function, MyClass& func() const; or const-ness overloading using two functions MyClass& func(); and const MyClass& func() const;? And what if the return value is a value instead of a reference (MyClass instead of MyClass&) ?

[Tom Backton]

Can someone please help me with these questions?

[Null]

1. I think yes.
2. No

[jsmith]

3. If your specialization does not specialize all default parameters, then it is probably best to respecify the same default values. I did not try either way to see if one compiled and one didn't though.

4. It depends on what func() does. Presumably, since func() is returning a reference to something, that something is probably a data member of the containing object. That being the case, would you want the user to be able to call non-const methods on MyClass, thus changing the contents of MyClass and effectively the containing object as well? The general answer is no, but as for any rule, there are always exceptions. On the other hand when returning by value, you are returning a copy. At that point whether you return a const copy or a non-const copy is essentially irrelevant.

EDIT: And the answer to #1 has to be yes. Obviously it is possible to run 32-bit apps on 64-bit processors, just the same as in the days of Windows 95 when you could run "older" 16-bit apps in a (largely) 32-bit OS.

[mcleano]

2.Can a 32-bit OS run a 64-bit program if the processor supports 64-bit programs?

If that were true what would be the point in a 64-bit OS?

[Tom Backton]

(("what would be the point in a 64-bit OS?" - It can be twice as fast as an equivalent 32-bit OS...))

Thanks for the answers!
I have 3 new questions:

const int& ref();
const int* ptr();

These functions return a private object, which cannot be accessed directly. But I'd like functions to only have the ability to get the value, not change the object. If these functions were global, I wouldn't need them, because I can simply return the object by value. But what if they are const member functions? This possibility exists:

int& f();
int f() const;

1. Is the return type part of the signature, at least in this case? In other words, will this work like const-ness oveloading? Will the first function run for non-const objects the the second for const objects?

I won't be surprised if the answer to no. 1 is no, because the following method is sometimes used (actually, I never saw code that uses the first method(the above one)):

int& f();
const int& f() const;

or this:

int* f();
const int* f() const;

I know const-ness overloading will work here and that const pointers and references won't allow changing the object.

Can the object still be changed by getting its address? I'm guessing some low-level methods can write to memory belonging to a const object, but I'm only asking about copying the address to a non-const pointer. For example, there's a class called MyClass. It has an int data member called memb and two member functions: ref() returns a const reference to memb and ptr() returns a const pointer to memb.
2. Is the following code legal:

MyClass myObj;
myObj.data = 5;
int* p1 = &myObj.ref();
int* p2 = myObj.ptr();
*p1=3;
*p2=4; 

3. In general, can const pointers and addresses of const references be copied into non-const pointers?

[helios]

It can be twice as fast as an equivalent 32-bit OS...

Only if the CPU is twice as fast. 64-bit mode is not inherently faster than 32-bit mode.

1. No. Two functions can't differ by just their return type.

2. No.

3. Only if you explicitly cast the pointer, which is something you shouldn't do.

[Bazzy]

1. They differ also by not/being const members so it should work

[jsmith]

Just to further clarify #1, while the return type is not part of the function signature, the const/non-constness of the function is, so that

iterator begin();
const_iterator begin() const;

in fact have two different signatures (return type aside, of course).

[Tom Backton]

Thanks for the answers :)
I have 2 new questions...

1. What is extern "C"? What is the difference between extern and extern "C" ?

2. There are 2 files for MyClass: myclass.cpp and myclass.h . Do I need to #include "myclass.h" in myclass.cpp ?

[helios]

1. extern "C" tells the compiler that the functions declared inside are defined in C, so the declarations shouldn't be mangled. extern tells it the symbol it applies to is defined in a different compilation unit.

2. Yes.

[Tom Backton]

As a C++ programmer, do I need to use extern "C" when dealing with C source code written for libraries by other people? Or extern "C" is of no interest to me (as I program in C++, not C)?

[helios]

Only if the headers for those libraries aren't prepared to be included in C++ sources:

#ifdef __cplusplus
extern "C"{
#endif
/*declarations*/
#ifdef __cplusplus
}
#endif 

Ten you need to either modify them, or do this:

extern "C"{
#include <header.h>
}

[Tom Backton]

So I need to choose one of these two options?

If I use header files like OpenGL's or Linux sys headers, that already have extern "C" inside them, Can I simply include them with #include<GL/gl.h> , etc.? (since the extern "C" is already in the header file itself)

[kbw]

extern means this variable is only declared here, it's defined elsewhere. The linker is expected to tie things together.

extern "C" defines C linkage.

Although C and C++ functions look the same, they are given different names internally. In C, the name is largely unchanged. In C++ the names are mangled with the signature to support typesafe linkage.

In C, the linker only matches on function name, in C++ the linker matches on the name, parameters and return types to catch silly programmer mistakes.

If a C module is to be linked with a C++ module, the C++ naming must be relaxed. extern "C" does the relax.

The problem is that C and C++ programs use the same extensions. In the beginning, C used .h/.c and C++ used .H/.C; but when it moved off UNIX onto DOS, new conventions were required as FAT is case-insensitive. Moves to .hpp/.cpp and hxx/.cxx happened, but we seem to have settled with .h/.cpp. This means you cannot determine if a source file is C or C++ without peering into it, which means that header files that support both languages need the pattern helios showed.

[z05DSL3A]

2. Can a 32-bit OS run a 64-bit program if the processor supports 64-bit programs?

Mac OS boots to a 32-bit kernel by default but will happily run 64-bit software.

[helios]

Are you sure it doesn't just use an emulator? I'm pretty sure running 64-bit code requires both hardware and software support.

[z05DSL3A]

I'm not 'sure' about what it does, but I have read it at several sources, have not looked into it that much though.