I read someone's code.
#include "send_input.h"
#include <stdlib.h>
#include <math.h>
#include <windows.h>
#include <winuser.h>
/* function definition
* function definition
* function definition
* ...
*/
I found windows.h at 'C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um'
#if defined(RC_INVOKED) && !defined(NOWINRES)
#include <winresrc.h>
#else
/* ... */
#include <windef.h>
#include <winbase.h>
#include <wingdi.h>
#include <winuser.h>
/* ... */
#endif /* RC_INVOKED */
windows.h has #include <winuser.h>(so the former is superset of the latter) although it depends on #if defined(RC_INVOKED) && !defined(NOWINRES). Is there a special meaning in below fragment? Is it just style matter to emphasize functions in winuser.h are frequently used?
#include <windows.h>
#include <winuser.h>
The rules are simple: You include the header files you need. The documentation for any API call includes information on which header to include.
I don't know whether it is always an error to include both <windows.h> and <winuser.h>. You would have to consult the documentation for every symbol used by the code to verify.
As noted, though, the Windows SDK header files aren't exclusively used by a C or C++ compiler. The Resource Compiler is another client of those header files. Including <winuser.h> after <windows.h> is potentially not even superfluous in this case.
Related
Is there any way to disable code insight in Clion for only one file in the project?
I have a swig file with just a few lines. But every time when I go into the file clion complains about header and freeze for long time. I have to open this file in phpstorm or other editor which can't parse c++.
complain messages from Clion
//anal.swig
%module anal
%{
#include "anal.cpp"
%}
void anal(char *str, int size);
The are several ways to do it:
1. Change the file extension from ".h/.cpp" to ".templ" (non C++ related)
2. Clion has special IDE macros, so you can add guard
#ifndef __CLION_IDE__
//anal.swig
%module anal
%{
#include "anal.cpp"
%}
#endif
void anal(char *str, int size);
CLion has #pragma ide diagnostic ignored for selective switch off.
I am learning how to write Ruby C extensions and I'm past the simplest examples. I was trying to achieve something with sockets so I attempted to create an extension which would define a class under rb_cIPSocket.
At the top of my C file I have:
#include "rubysocket.h"
And I am receiving:
...s.c:3:31: error: rubysocket.h: No such file or directory
Which is most probably the case. However, I tried all possible paths:
#include "rubysocket.h"
#include "socket/rubysocket.h"
#include "ext/socket/rubysocket.h"
#include <rubysocket.h>
#include <socket/rubysocket.h>
#include <ext/socket/rubysocket.h>
And this is my extconf.rb:
require 'mkmf'
dir_config("my_ext")
have_library("c", "main")
create_makefile("my_ext")
And so on. What am I actually missing here? Why can't I include that header file?
I am using OSX with RVM and Ruby 1.9.3-p448.
Thank you.
where does rubysocket.h live? If it's in the heart of ruby's source code then odds are it is "private" for ruby's use, but you can look it up like...
VALUE ipSocketClass = rb_const_get("IPSocket");
or the like.
GL!
I porting code from a windows machine to a Mac. I am using OS X 10.6 with Xcode 3.2.5
I have a header file called api.h which has the following code:
namespace ocip {
#include "onan/ocip/ocip.h"
}
ocip.h includes #include stdint.h
which has the following typedef:
typedef unsigned int uint32_t;
Now back to api.h I have class with following in it:
ocip::uint32_t m_nMode;
The compiler tells me that uint32_t in namespace 'ocip' does not name a type.
Any ideas what I am doing wrong?
I don't know if this will help, but a type of "uint32_t" may already be declared. There is already a typedef of the same name if you are including "stdint". This could be causing a problem with redefining it in opic.h.
dll export header
extern "C"
void _declspec(dllexport) __stdcall foo();
.def file
EXPORTS
foo #1
When I build the dll by 64bit build config, I meet this warning.
warning LNK4197: export 'foo' specified multiple times; using first specification
But If I build the dll by 32bit build config, the warning never occurs.
What is the problem? What is the difference.
In dll header for interface, we usually use this technic,
#ifdef EXPORT_DLL
#define BASICAPI _declspec(dllexport)
#else
#define BASICAPI _declspec(dllimport)
#endif //_EXPORT_DLL
But if def file also exists, we always will be meet the warning when we are building 64bit dll.
So, should we write the codes like this?
#ifdef EXPORT_DLL
#define BASICAPI
#else
#define BASICAPI _declspec(dllimport)
#endif //_EXPORT_DLL
It works well. But it's not familiar to me.
Give me any your opinions.
It's generally not good practise to specify exports twice for the same function. If you already have __declspec(dllexport) then you do not need to specify the export in a .def file as well. Conversely, if you have the export listed in a .def file, then there's no need for a __declspec(dllexport).
I believe the reason for the warning is that in x86 builds, the __declspec(dllexport) is exporting the decorated name with a leading underscore, but the 64-bit compiler does not decorate names with a leading underscore, leading to the duplicate. To verify this, you could look at the 32-bit DLL in Dependency Walker and you should see two exported functions, "foo" and "_foo".
__declspec(dllexport) and .def files are two different ways to export symbols from a dll. You don't need both and should omit ono of them. The __declspec method is far more versatile for c++ programs as it exports names with c++ mangling, allowing overloaded functions to be exported, but conversely that does make the names harder to import via GetProcAddress.
Also, using a generic macro like EXPORT_DLL is dangerous as it means that you can't build a dll, that uses another dll, without the one one dll trying to export all the symbols of both dlls.
DevStudio automatically creates a symbol on dll projects: <PROJECT>_EXPORTS making it easy and safe to create a EXPORT macro:
#ifdef EXPORT
#undef EXPORT
#endif
#ifdef PROJECTNAMEHERE_EXPORTS
#define EXPORT __declspec(dllexport)
#else
#define EXPORT __declspec(dllimport)
#endif
EXTERN_C EXPORT void __stdcall Function1(void);
EXTERN_C EXPORT void __cdecl Function2(...);
EXPORT void Function3(void);
Functions 1 & 2 can be gotten with GetProcAddress as _Function1#0 and Function2 respectively. Function3 is going to be exported via a compiler specific mangled name that will look something like: #Function3##UAG_DB#Z. This name is different for each overload of the function, which is how it allows overloading to work.
Its important to know the name mangling of __declspec as .def files don't care and would just export Function1, Function2 and Function3.
When using autotools (with a config.h file) for both a library, and a software built on that library, the compiler complains about a redefinition of some macros (PACKAGE_NAME, PACKAGE_TARNAME and so on).
How can I prevent this?
The config.h file is needed in the library to propagate it's setting to the software that use it.
Right now I have a wrapper script library_config.h that includes the original config.h and provides defaults when the user is not using autotools, but even undefining the macros in that package I get the redefinition warning from gcc.
#ifndef LIB_CONFIG_H
#define LIB_CONFIG_H
#ifdef HAVE_CONFIG_H
# include "config.h"
# undef PACKAGE
# undef PACKAGE_BUGREPORT
# undef PACKAGE_NAME
# undef PACKAGE_STRING
# undef PACKAGE_TARNAME
# undef PACKAGE_VERSION
# undef VERSION
#else
# if defined (WIN32)
# define HAVE_UNORDERED_MAP 1
# define TR1_MIXED_NAMESPACE 1
# elif defined (__GXX_EXPERIMENTAL_CXX0X__)
# define HAVE_UNORDERED_MAP 1
# else
# define HAVE_TR1_UNORDERED_MAP 1
# endif
#endif
#endif
I believe the best option would be to have a library without that macros: How can I avoid the definition of PACKAGE, PACKAGE_NAME and so on in the library when using autotools?
EDIT: attemp to explain better.
When using the AC_CONFIG_HEADER macro in the configure.ac of the library I produce a config.h file with a lot of useful defines. This defines are useful for the library itself (both for it's compiled part and for its header files) AND for the client software. It's a pity however that the AC_CONFIG_HEADER mixes the useful macros that I need with other generic defines with fixed names (PACKAGE, PACKAGE_NAME) that clash when autotools are used also for the client software configuration.
If your application might dynamically link to the library, it makes no sense to have the static strings from the library statically built into the application.
Otherwise, you might want to look for ax_prefix_config_h.m4.
I would still just try to avoid installing a config.h file and define the library's API without resorting to config.h:
/* library.h */
const char library_version[];
/* library.c */
#include "library.h"
#include "config.h" /* the library's config.h */
const char library_version[] = PACKAGE_VERSION;
/* application.c */
#include "library.h"
#include "config.h" /* the application's config.h */
int main()
{
print("This is app version %s.\n", PACKAGE_VERSION);
print("The library is version %s\n", library_version);
return 0;
}
Make sure that the public library header files do not #include "config.h", and that the library does not install its config.h.
You should be able to designate the library as a "subpackage" of the software by calling AC_CONFIG_SUBDIRS([library]) in the software's configure.ac. That should eliminate the conflicts, and the settings from the top-level configure will still propagate down to the subpackage.
Here is the link to the page of the Autoconf manual describing this feature: http://www.gnu.org/software/hello/manual/automake/Subpackages.html