|
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
|
|
|
|
|
Georgia Tech..... what is SAF..... what's ur msn
|
|
|
|
|
SAF = Semiautomated Forces (military simulation). RTI-ng/RTI-s are used mainly to communicate using HLA (dumbest accronym ever!). Is GT doing some modelling/simulation research for the military?
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
|
|
|
|
|
We're just messing around with the RTI source code to understand what is going on. Eventually will be an open source RTI
|
|
|
|
|
Jay03 wrote: Eventually will be an open source RTI
So you'll be switching to RTI-s at some point?
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
|
|
|
|
|
What's languaue that used for write Windows OS ?
|
|
|
|
|
|
toxcct wrote: the answer is : C++ and Assembler...
Not to be too picky ... but it is actually C and ASM (for the most part). However, last I heard, Longhorn is suppose to be almost completely in C++.
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 follow the link i provided, it seems that most accord to say C++...
for Vista, it seems to be a mix of C/C++/ASM for the native part, and Managed C++/C# for managed part...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
I know what most people think, but as you know yourself, many people on this forum don't really understand the difference between C and C++.
MSDN magazine had an article about a year ago that talked about how they were trying to write almost all of Longhorn (aka Vista) in Managed C++. I'm not sure if they have abandoned that and wrote portions of it in unmanged C++ (although, from a developer's perspective, I can see some likely areas of the OS where they would not only want to, but possibly might have to).
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
|
|
|
|
|
toxcct wrote: if you follow the link i provided, it seems that most accord to say C++...
But are those folks in the lounge just guessing, or do they really know?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
you talk about this post[^] ?
well, seriously, as the lounge is a general forum, there are true folks, but some (i think of Corinna John for instance, or perterchen or code-frog) are valuable programmers, and by then, there voice is full of sense...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
Well, lets look at it this way: Every single Win32 API is in pure C (see Jeffrey Ricther's book and Petzold's book for details).
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
|
|
|
|
|
Zac Howland wrote: Not to be too picky ... but it is actually C and ASM (for the most part). However, last I heard, Longhorn is suppose to be almost completely in C++.
According to what some people from MS told me: it is C and ASM in the kernel, but most of user-space code (shell, etc) is C++.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote: but most of user-space code (shell, etc) is C++
Some of the GUI-shell is written in C++ using COM, but even some of that is written in pure C. The reasoning is that when the original design for Windows was being developed, C was the most common language for application development and they wanted to leverage that fact. It has remained that way to be compatible with both C and C++.
When you browse through MSDN looking at Win32 API documents (not MFC documents), you'll notice that there are no classes defined -- only structs defined in old-style C syntax. This is also why all window/threading/event API calls take a handle as the first paramter.
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
|
|
|
|
|
Zac Howland wrote: When you browse through MSDN looking at Win32 API documents (not MFC documents), you'll notice that there are no classes defined -- only structs defined in old-style C syntax. This is also why all window/threading/event API calls take a handle as the first paramter.
That really shows nothing. It is easy to make a C interface to a C++ implementation.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote: That really shows nothing. It is easy to make a C interface to a C++ implementation.
Yes, because in 1997 when the Win2K OS was being designed, Microsoft had enough forethought to implement the OS in C++ (which hadn't even been standardized yet) and then took the extra time to wrap the entire OS with a pure C API ... and then provided yet another wrapper around the C API written in C++ (which is known as MFC).
As twisted as Microsoft can be sometimes, even that is a stretch.
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
|
|
|
|
|
Zac Howland wrote: Yes, because in 1997 when the Win2K OS was being designed, Microsoft had enough forethought to implement the OS in C++ (which hadn't even been standardized yet) and then took the extra time to wrap the entire OS with a pure C API ... and then provided yet another wrapper around the C API written in C++ (which is known as MFC).
And yet, you are speculating here, and I have heard from people from Microsoft that more than 50% of Windows code is C++. Again, they may be lying
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote: Again, they may be lying
Doubtful that they are lying. It is more likely that they don't know the differences in the languages themselves. Read Petzold's original Programming for Windows book, followed by Programming Applications for Windows by Jeffery Richter (sp).
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
|
|
|
|
|
There is no doubt in my mind that lots of the user mode code in written in C++; I have disassembled parts of many user mode DLLs when trying to fix various bugs and you can tell it's C++. For example MSHTML.dll is C++. When you read up on writing device drivers you'll find that Microsoft recommend that they be written in C. C and assembler in the kernel and a mix of C/C++ in the user mode would be true for the most part. Obviously with Vista you'll have to add managed languages to the mix for some user mode portions.
Steve
|
|
|
|
|
Hey. I'm fairly new to MC socket programming, and had a difficult question that I've been wrestling with over the past couple weeks to find a solution.
I need to be able to make a single-threaded (or at least no more than 3 or so) TCP client/server application. I would like to try to use the CAsyncSocket and CSocket objects provided, and have on the Server side:
synchronous Accepts, asynchronous Receives/Sends
and on the Client side:
everything synchronous
So the first question is would this even be possible?
If it is, I'm thinking that I should be able to listen with a CSocket object, and pass a CAsyncSocket object to the Accept function on the Server side, while on the Client side I'm Connecting from a CSocket. Would this provide my desired functionality? Or is there something else that I need to think about?
With regards to the threading, I wasn't sure how to keep listening for accepts while receiving from/sending to multiple clients on one thread, so I thought that having three threads (one for accepting, one for sending, and one for receiving) would be the best option. Again, threading is something that I'm new to as well, so I wasn't sure how that would fair either.
If anyone could possibly give me some pointers on how to accomplish this, or where to look to get some good info (I'm about googled out on this), I would greatly appreciate it.
Thanks!
Richard Alley
Student/Software Engineer
|
|
|
|
|
You said this is for MC (multicast?) programming? That being the case, some of your options are limited. But since much of your post is about Client/Server architecture:
Typically, the way I set up my server is to have 1 listening thread and either 1 thread per connection, or 1 thread for all connections (depending on the amount of traffic I intend to be sending/receiving).
On the client side, the choice between asynchronous and synchronous depends on your goals. For example, if you are building a chat client, you don't want the receive handler blocking while you are trying to send things.
Generally, you want to stick to one method or the other (either synchronous or async). Mixing the 2 can create interesting, and hard to track down, bugs in your system.
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
|
|
|
|