|
Thanks, this works.
However, instead of selecting each item by index number, is there a way to "select all"? (instead of having to do individual SetItemState)
|
|
|
|
|
|
Does anyone know what is going on here???
typedef void UpdateHandler(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
|
|
|
|
|
|
Why do we have a typedef in front of this function of type void
typedef void UpdateHandler(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
|
|
|
|
|
It is defining a function pointer. The syntax is a bit quirky since most people try to write it like this:
typedef (void UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
It is basically declaring a type called UpdateHandler that will be able to point to functions with the following signature:
void f(ObjectRootPtr, const RTI::AttributehandleValuePairSet&);
These are typically used as callback functions.
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
|
|
|
|
|
Jay03 wrote: typedef void UpdateHandler(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
That is odd, usually you'd write it as:
typedef void (*UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&); which makes the new function pointer type UpdateHandler
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
VB > soccer
|
|
|
|
|
It might be useful to declare the calling convention if you are exporting these pointers from DLLs for example.
typedef void (__cdecl *UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
typedef void (__stdcall *UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
...
Don't try it, just do it! 
|
|
|
|
|
Hello everyone,
I have a question concerning the long data type. Using a 32-bit compiler, sizeof(long) = 4.
But what about 64-bit?
Regards,
Alex
Don't try it, just do it!
|
|
|
|
|
long is still 32-bits in a 64-bit compiler. If you want to have a 64-bit integer, use long long (platform independent) or __int64 (Windows).
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
|
|
|
|
|
short int is the same as short
long int is the same as long
sizeof(short) returns 2
sizeof(long) returns 4
on a 16 bits environment : sizeof(int) returns 2
on a 32 bits environment : sizeof(int) returns 4
on a 64 bits environment : sizeof(int) returns 8
sizeof(long long) is supposed to return 8, but it is not provided by the standard, and not every compilers know that type.
sizeof(__int64) is quite the same as long long, but AFAIK, it is a microsoft specific type, so, not portable either...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
