|
hi all -
I just started working with all this so my terminology may be bad.
Im using VC++ with winsock2.h and glut.h
A piece of software is outputting a signal via TCP/IP; I initialize a socket and can read data from it by using recv() within a while loop.
however, when I put the data acquisition code within the display function of an openGL loop, the data acquisition stalls (no error message). I think this is because the server is sending data faster than the client can receive so it stops. I was thinking of perhaps using an asynchronous implementation where the TCP/IP data is retrieved by a function running in parallel with the display loop. Do you happen to know a way of doing this? It seems like there are similar mechanisms used within the OpenGL loop to get input from the keyboard, which suggests to me that the GLUT display loop isnt blocking the main function.. is this true?
ga
|
|
|
|
|
synapticleft wrote: I was thinking of perhaps using an asynchronous implementation where the TCP/IP data is retrieved by a function running in parallel with the display loop. Do you happen to know a way of doing this?
http://www.codeproject.com/opengl/GLBase.asp[^]
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
thanks.
If i increase the buffer length of the argument i pass recv(), i can prevent the connection from being dropped. there is still a little stuttering in the graphics, i presume from when the program is waiting for recv() to complete, so perhaps ill look into threads.
Gautam
|
|
|
|
|
Have you considered using non-blocking sockets?
Speaking about socket concepts, possible alternatives are from the view of a client:
a) blocking (read data available then wait blocking until more is available)
b) threaded (one ore multiple threads per socket, comes with inter-thread communication)
c) asynchronous (handling multiple sockets, application is typically event based)
The concept always depends on your requirements, I prefered last one in my past projects because it is flexible. There are of course more variants, such as polling (regular check if more data is there and then read it, however then you could also use the asynchronous concept and save CPU cycles).
Hope it helps
|
|
|
|
|
Hello All !!
I am using visual studio 6.0
I tried to access the private class member outside the class using #define macro.
here is the code. I was able to access private member outside the class? why did this work? This should be allowed or not?
<code>
#define private public
class A
{
private:
int i;
public:
A()
{
i = 44;
}
};
int main()
{
A obA;
cout<<"\ni = "<<obA.i;
cout<<"\n";
return 0;
}
</code>
sanket
|
|
|
|
|
Defnitely It is not a bug.
Because Pre-processing happens before the compilation process.
So first the pre-processor would process your #define and replaces the text "private" with the text "public", and then it would be processed by the compiler.
Cheers
|
|
|
|
|
Thanks!!
but dont you think this should not be allowed??
sanket
|
|
|
|
|
It is the responsibility of the developer not to use such constructs.
Cheers
|
|
|
|
|
sanket.patel wrote: but dont you think this should not be allowed??
play VB if you're age to play with a plastic hammer.
if you code in C/C++, know that you can break much more than that.
don't code what you can regret later...
|
|
|
|
|
VB and C# are languages written to cater to the lowest common denominator. C++ assumes a level of skill in the developer. #define is a hangover from C, which C++ is derived from. The designer of C++ would prefer it was not there, but it's still true that his design philosophy is to give the language powerful features and assume his users know how to use them.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: #define is a hangover from C, which C++ is derived from. The designer of C++ would prefer it was not there, but it's still true that his design philosophy is to give the language powerful features and assume his users know how to use them.
A hangover, maybe, but it is o so powerful. But with every powerful it should be used with care.
#define is a dangerous tool in the hands of the unexperienced.
codito ergo sum
|
|
|
|
|
BadKarma wrote: hangover, maybe, but it is o so powerful.
I agree with Stroustrup. I try to avoid using it whever I can, I think it's a poor tool. But, it is powerful, and no doubt can be used effectively at times.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
You got sig-ed. 'nce again.
VB and C# are languages written to cater to the lowest common denominator. C++ assumes a level of skill in the developer. - Christian Graus
|
|
|
|
|
sanket.patel wrote: #define private public
sanket.patel wrote: I was able to access private member outside the class? why did this work?
of course you could !! you told it (with the #define) to replace each private keyword occurence by public... so that every private member is actually public.
why on earth where you trying to do with such horror ?!
|
|
|
|
|
Actually !!
I was asked to find the ways to access private members outside the class?
so one method is using friends....
and i thought of this as the other way...
Thanks,
sanket
|
|
|
|
|
sanket.patel wrote: I was asked to find the ways to access private members outside the class
and you chose the worst...
if members are private, it's to deliberately hide them from the outside.
look. if you have an object engine, do you know how it works internally ? certainly not. you only see the apis (accelerator, starter, etc...).
anyway, have you thought to members accessors (getters, setters) ?
|
|
|
|
|
Thank you very much!
yeah I know about getters and setters and I know I choose the worst!
but the the question is about that only.. i.e. the unusual ways to access the private data.
Thanks,
sanket
|
|
|
|
|
GIGO - if you pull stunts like that, don't be surprised when you get odd results.
|
|
|
|
|
sanket.patel wrote: #define private public
My opinion is that you will *EXCEL* in the "Coding Horros" forum. Well, what are you waiting for? Post some of your fantastic code there!
Nobody can give you wiser advice than yourself. - Cicero
ப்ரம்மா
|
|
|
|
|
To make the most of your coding experience, you probably should try:
To save testing:
<br />
#define true false<br />
this always happens anyway:
<br />
#define this NULL<br />
to avoid accidental deletion
<br />
#define delete /##/<br />
avoid wasting loop iterations:
<br />
#define break continue<br />
just in case the others are boring:
<br />
#define try do<br />
#define catch while<br />
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
EXCELLENT!
These fixed a bunch of my problems.
Thanks!
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I have just upgraded from 6.0 to Visual studio 2005. None of my code from programs written under C++ 6.0 will build. I get all sorts of errors "cannot convert perameters" etc... Is there a way to set my project so I can use my original code?
|
|
|
|
|
You're getting those errors because the compilers in VC 7 and 8 are vastly improved over VC 6, and don't accept code that VC 6 did. You'll need to bite the bullet and fix up the code.
|
|
|
|
|
Thanks for your response. I am able to open the original project with VC 8 and it builds fine but, uses the old visual styles. I would just like to be able to use the new styles without re-writting the whole program. I was hoping there were some depecndancies or something along those lines that would accomplish this. Seems kinda harsh to have re-write the whole thing
Thanks Again,
Terry
|
|
|
|
|
Google for "common controls manifest" - there's info about the visual styles all over the place.
|
|
|
|