|
toxcct wrote: on a 64 bits environment : sizeof(int) returns 8
This is not currently the case, and many on the standards committee are arguing against making it so for backwards compatibility reasons. Currently, on 64-bit compilers, sizeof(int) will return 4 (just like on 32-bit compilers). sizeof(long long), which most compilers support and is being discussed as part of the next standard, will return 8. sizeof(void*) will return 8 on a 64-bit compiler.
Note that much of that is still subject to change ... we should know for sure when/if the standard's committee is able to agree on things by 2008.
As a side note, it is best to declare the type of integer you actually want (or typedef it) instead of declaring "int" for precisely this reason. If you need low numbers (less than 255/127), use unsigned char/char; if you need larger numbers, use unsigned short/short; and if you need huge numbers, use unsigned long/long. Finally, on 64-bit systems, if you really need the massive numbers, use unsigned long long/long long. It will help save you some portability issues down the road.
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
-- modified at 13:30 Thursday 22nd June, 2006
|
|
|
|
|
Zac Howland wrote: use unsigned long long/long long. It will help save you some portability issues down the road.
I'd recommend using typedefs and __int64. That's far easier to maintain, should long long mean anything else than 64 bits on a specific platform/compiler.
My 2 cents. 
--
100% natural. No superstitious additives.
|
|
|
|
|
I agree with the typedefs, but __int64 only means something for Microsoft's compiler. If you use any other compiler, it is meaningless (or you would have to typedef it to long long).
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
|
|
|
|
|
I see that I didn't really express what I meant. I really meant that the typedef should be changed to alias to the platform specific 64 bit type. (And not just the microsoft __int64 type)
--
100% natural. No superstitious additives.
|
|
|
|
|
That standard is so stupid... they should use long as synonym for char *, which makes pointer arithmetic easier. At the moment there is a big problem when you want to cast a pointer to an integer, especially if you are creating source code for different platforms and compilers. Windows defines ULONG_PTR etc, but I've never heard of a Linux equivalent 
VC++ and GCC are also very different in some cases, that's getting on my nerves...
Thanks for your answers!
Don't try it, just do it! 
|
|
|
|
|
That assumption is why we have the problems with int, long, and void* today. In the 32-bit standard, they were all the same size, so programmers would take advantage of that and cast 32-bit pointers to integers. The problem is now that when you want to run a 32-bit application on a 64-bit platform, that assumption breaks your code (not desirable).
To prevent this from happening, one of the proposals being discussed is to create a long long datatype for 64 bits, long and int would still be 32 bits, short would still be 16 bits, and char woudl still be 8 bits. void* would be 64 bits.
As for the ULONG_PTR and INT_PTR ... those are just typedefs (use to be #define's). They are handy for recompiling in 64 bit mode, but still run into the same problems when you try to run a 32 bit application on a 64 bit platform. The presense or absense of those definitions has nothing to do with the actual compiler and everything to do with the utility libraries. You can VERY easily create your own.
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
|
|
|
|
|
Alexander M. wrote: Using a 32-bit compiler, sizeof(long) = 4.
But what about 64-bit?
On Windows, still 4.
On most Unix-like systems: 8
In general: implementation dependent.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
there are 2 dsw
each one has a resource file
I want to new a project to use these two resource from that 2 dsw
what shall I do ?
(is it many conflicts to merge these resource files?)
Is it difficult?
Just my interest for these common things
|
|
|
|
|
My best experience with this has been to open the *.rc files as text files and to copy the blocks 1 by 1 into a new file and handle naming conflicts as I go along. After that, I would do the same with the resource.h file.
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
|
|
|
|
|
If you are using vc++6, try this:
1) Open the first dsw project. Click on the 'ClassView' tab. The classes of the resource you have created are listed there.
2) Right-click with the mouse on the resource class that you want to add to your new project (You can select multiple classes too). Select 'Add to gallery' in the menu that appears.
3) Open your new project. Go to ‘Project’ from the main menu and then -Add to Project-Components and controls.
4) You will find a folder having the name of your previews project. Inside this folder you will find .ogx files. Select them. They automatically get added to your new project.
Follow the same procedure for the second dsw that you have.
Hope this helps!
Fortitudine Vinsinues!
|
|
|
|
|
I have done it !
but the bitmap , icons ,menu , and other resource are not included in!
it made me annoyed!
Is there any other easy way?
Just my interest for these common things
|
|
|
|
|
I do not know of any other way. But I guess, it would'nt be difficult to add the bitmaps.If you have the bitmap somewhere just import it into your new project.
Fortitudine Vinsinues!
|
|
|
|
|
Hey guys, I am trying to understand some codes and came across this.
In the code below, I don't know if its a pointer to RTIambassador object. I don't see why there is RTI:: in front of RTIambassador* and also ms_rtiAmb is not a method of class ObjectRoot. I don't see why they have ObjectRoot:: in front of ms_rtiAmb.
Thanks,
Jay
RTI::RTIambassador* ObjectRoot::ms_rtiAmb = NULL;
-- modified at 12:00 Thursday 22nd June, 2006
|
|
|
|
|
Jay03 wrote: ...ms_rtiAmb is not a method of class ObjectRoot.
Right, it's a member variable.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Jay03 wrote: RTI::RTIambassador
if RTI is a namespace, "RTI::" says "look in this namespace for the following item".
if RTI is a class, RTIambassador is either a typedef or an encapsulated class or struct. you need the "RTI::" to tell the compiler to look inside that class.
ObjectRoot::ms_rtiAmb is most likely a member variable of a class.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
actually, the code you quoted initializes a pointer to an RTIambassador object (located in the RTI namespace). the pointer is called ms_rtiAmb (and is certainly a static member of the class ObjectRoot, and is then initialized to NULL (pointed to the address 0x0).
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
|
it seems that you need to take a C++ book to understand the language mechanisms...
BTW, a namespace is a scope space in which some symbol names can be resolved...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
It's just a region of code that has been assigned a name.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Are you, by chance, looking at the RTI-s or RTI-ng codebase?
If you are, RTI is the namespace with a type RTIambassador in it. This line of code is initializing a static member variable in the class ObjectRoot called ms_rtiAmb to NULL. If you look in the ObjectRoot declaration, you should see a line that looks like the following somewhere:
static RTIambassador* ms_rtiAmb;
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
|
|
|
|
|
I am actually looking at RTI-ng codebase.
Actually, there is no declaration anywhere saying static RTIambassador* ms_rtiAmb;
I still dont know why there are so many declarations in the ObjectRoot file like this:
ObjectRoot::ms_numInstances = 0;
Why do we declare variable ms_numInstances with ObjectRoot:: in front of it. Still unclear
Thanks for your help Zac,
Jay
|
|
|
|
|
Jay03 wrote: Actually, there is no declaration anywhere saying static RTIambassador* ms_rtiAmb;
search for 'RTIambassador' .
Jay03 wrote: Why do we declare variable ms_numInstances with ObjectRoot:: in front of it.
because ms_numInstances lives inside a namespace or a class, and 'ObjectRoot::' tells the compiler where to look to find the variable.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Ah, I don't have the ng codebase on me ... the RTI-s codebase shouldn't be too much different though (that is what we use where I work ... at least for now -- a new contract is coming that may require the use of ng).
Typically, anytime you see m_ in front of a variable name, it means it is a member variable. When you see ms_ it means it is a static member variable. To initialize static member variables, you have to place a line somewhere in the implementation (typically at the top of the .cpp file) that looks like the following:
VariableType ClassName::ms_VariableName = SomeValue;
The ObjectRoot:: in front of the ms_numInstances states that it is a member of the ObjectRoot class (it could also mean a namespace, but in this case, I happen to know it is a class).
Do a grep on the ObjectRoot declaration and you should see where those variables are declared (or, if you are using a decent IDE, click the variable and tell the IDE to go to the declaration). You should see them as static members of the ObjectRoot class in the RTI namespace.
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
-- modified at 12:59 Thursday 22nd June, 2006
|
|
|
|
|
Well explains what I wanted to know...........
Your help may be needed in the future Zac because Im working on an RTI project
|
|
|
|
|
If you don't mind me asking, who do you work for and what SAF are you interfacing with?
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
