|
Naveen Khanna wrote: can u tell me about these lower lever API's
Check out the Windows Media Format SDK[^].
Combined with DirctShow, you can get pretty low latency if you dig into the settings 
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
|
Yes - link your app statically to MFC and CRT.
|
|
|
|
|
Thanks for replying Hans, are you referring to the following:
C Run-time and Standard C++ Libraries
msvcm80.dll
msvcp80.dll
msvcr80.dll
Microsoft Foundation Classes
mfc80.dll
mfc80u.dll
mfcm80.dll
mfcm80u.dll
Many Thanks
Regards,
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r
My Blog: ^_^
|
|
|
|
|
In Visual Studio 2005, the options to statically link to MFC is under General - under Use Of MFC, select Use MFC In A Static Library. To statically link the C runtime, under C/C++, set Runtime Library to Multi-Threaded (/MT) for the release build and Multi-Threaded Debug (/MTd) for the debug build.
Statically linking increases the size of your binary and means that if Microsoft release any security fixes, your application will have to recompiled to include the fixes, rather than picking them up directly from the updated DLL. The Visual C++ runtime updates for Visual Studio 2002 and later are distributed as side-by-side assemblies for Windows XP and later, but include publisher policy files to force applications to run on the latest installed version, unless the application opts out by specifying a specific version in its configuration file.
|
|
|
|
|
A very newbie question:
I have two classes for drawing images in windows:
<br />
<br />
class Win<br />
{<br />
public:<br />
void DrawImage(Image *img, int x, int y);<br />
void DrawPixel(int x, int y);<br />
}; <br />
<br />
class Image<br />
{<br />
private:<br />
<br />
XImage *ximage;<br />
Win *win;<br />
<br />
public:<br />
Image(Win *window, int w, int h);<br />
<br />
};<br />
The internals of the Image class depend on the properties of the window on which it is to be drawn, so the Image constructor needs to be passed a Window pointer. The code to draw an image, in the Window class, needs to be passed an Image pointer. A the moment, this doesn't compile (with G++), since the compiler doesn't know about the Image class when it reaches the prototype of the Win::DrawImage method. Swapping around the class definitions obviously doesn't help since it then doesn't know about the Win class when it reaches the constructor of Image.
One solution is to make the image drawing a method of the Image class, but since drawing requires the use of a lot of private data in the Win class, I'd rather keep drawing as part of the Win class.
What is the best way of resolving this problem? I get the feeling that there is some feature of C++ that I don't know about which will tell the compiler about the Image class, and get it to accept an Image *, before it reaches the class definition.
Cheers
|
|
|
|
|
Pur those classes in separate files. Each class with one header file and one cpp file. In the header files, you can use forward declaration:
class Image;<br />
<br />
class Win<br />
{<br />
.....<br />
};
This will tell the compiler that the class Image exists and will be defined elsewhere. This works only because you are working with pointers and you don't use anything specific from the class (you just declare a pointer). This won't work if you use a class instance instead of a pointer.
Then in the cpp file of the Win class, you will need to include the header file of the Image class.
You'll need to do that for both classes.
|
|
|
|
|
Why does it work only when u use pointers?
|
|
|
|
|
it's not a matter of work, it's a matter of compilation.
the compiler won't let you compile a class or a function of even a variable declaration involving a Data Type it doesn't know.
but to let it know, a declaration (and not the full definition) is sufficient.
but if you declare without defining, the compilation will pass, but the linking will fail...
|
|
|
|
|
Because if you do something like that:
class Win<br />
{<br />
...<br />
...<br />
Image img;<br />
};
The compiler will need to know the size of the object in order to generate the Win class. Thus, the only way to know the size of the object is to know what's inside (thus, including the header file).
If you use pointers, the compiler always knows the size of a pointer and it doesn't need to know more.
|
|
|
|
|
as Cédric stated, you just have to declare the class before where it's used, and define it later (in a separate file preferably)...
|
|
|
|
|
Where does the scope of the below statement apply to?
#ifdef __cplusplus
extern "C"{
#endif
|
|
|
|
|
It says that everything between the brackets ( '{' ) will have a C linkage type. The difference between a standard C++ linkage is that in C, you don't have function overloading. The linker generates name to identify the different functions and for C, this generated name is the same as the function name. In C++, it is different: as you can have function overloading, having only the name of the function to identify it is not sufficient. The compiler will add some information (it is called name mangling) depending of the arguments of the function.
When you specify this, you force the compiler to generate the functions names as a C compiler would do. That means also that you won't be able to overload a function.
It is used mainly for DLL's: when you want to be able to load a function using GetProcAddress, the name of the function you will need to pass to GetProcAddress is the 'mangled name'. Thus, it is very difficult to use. If you specify that the function has a C linkage, the name that you will pass to the GetProcAddress function will be the function name only, which makes it far easier to use.
Hope it was clear...
|
|
|
|
|
Cedric Moonen wrote: the name of the function you will need to pass to GetProcAddress is the 'mangled name'
actually, it's the exported name, that means, the mangled name mainly, unless the DLL has a .def file with an EXPORTS block which redefines the exported symbols.
|
|
|
|
|
Yes right, I forgot about the DEF file.
|
|
|
|
|
I know the implication of it but what significance does it have over here
#ifdef __cplusplus
extern "C"{
#endif
It does not apply on any function neither does it have any group of functions. Does it mean the following expansion
__cplusplus int function(int a, int b) is equivalent to
extern "C"{ int function(int a, int b)
Am I missing something here?
|
|
|
|
|
tom groezer wrote: Does it mean the following expansion
__cplusplus int function(int a, int b) is equivalent to
extern "C"{ int function(int a, int b)
Am I missing something here?
actually, yes .
the directives block
#ifdef __cplusplus
extern "C" {
#endif have an equivalent block which closes the opened parenthesis, down the file :
#ifdef __cplusplus
}
#endif
it seems that you confused a bit about #ifdef and #define.
#define defines a macro, but #ifdef performs just a test to know if the macro tested has already been defined or not.
#ifdef __cplusplus
extern "C" {
#endif
int function(int a, int b);
#ifdef __cplusplus
}
#endif
in the sample above, it meens the following if __cplusplus is defined :
extern "C" {
int function(int a, int b);
}or only
int function(int a, int b); if not...
|
|
|
|
|
Hello,
I am implementing a utility through which i want to populate list of all devices attached with a system & then user can select any device & get information regarding device name,version ...
Please help me out as soon as possible.
Thanks & Regards
Pankaj
Regards,
Pankaj Sachdeva
|
|
|
|
|
pan_angel wrote: Please help me out as soon as possible.
I got to this as quickly as I could. Sorry for the inconvenience. Now, what exactly did you need help with?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
|
Hi,
I am having trouble removing an object from a std::list.
I have got a Line object and a list structure in the form
std::list<line> lines;
and am trying to remove a particular Line object from the list by
Line * selectedLine;
// code to determine what line is selected
lines.remove(*selectedLine);
I get the error
c:\program files\microsoft visual studio 8\vc\include\list(908) : error C2678: binary '==' : no operator found which takes a left-hand operand of type 'Line' (or there is no acceptable conversion)
c:\program files\microsoft platform sdk for windows server 2003 r2\include\guiddef.h(192): could be 'int operator ==(const GUID &,const GUID &)' [found using argument-dependent lookup]
while trying to match the argument list '(Line, const Line)'
c:\program files\microsoft visual studio 8\vc\include\list(898) : while compiling class template member function 'void std::list<_Ty>::remove(const _Ty &)'
with
[
_Ty=Line
]
c:\documents and settings\kevin\my documents\visual studio 2005\projects\sdl_001\sdl_001\main.h(391) : see reference to class template instantiation 'std::list<_Ty>' being compiled
with
[
_Ty=Line
]
I have tried searching google but all I can find is examples of how to remove integers and strings from lists
Any help would be appreciated
Kevin
|
|
|
|
|
I never used remove before but I suppose that you need to supply an ==operator for your Line class. Otherwise, the compiler cannot know if two Line objects are the same.
|
|
|
|
|
ah thats solved my problem. i thought the == operator was implicitly defined to check if two objects were equal
thanks
kevin
|
|
|
|
|
hi!i am trying to implement a code in c for cyclic reduction method.any one can help me (with an algorithm or the code itself)
|
|
|
|
|
hi!i am trying to implement a code in c for cyclic reduction (tridiagonal matrix).any one can help me (with an algorithm or the code itself)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
