How to write C program in VS2012 without using Microsoft specific extension C library?
For Example scanf_s() is Microsoft specific implementation. But if we use it we can't compile the code in Linux.
So should we use Linux VM in parallel the compile the code in gcc.
OR
we can setup gcc on windows.
OR
is there any better option or tweak in VS 2012 itself to achieve this?
Setting "Disable Language Extensions" just removes certain language features. A list of these features is here here.
However, extra functions provided by Microsoft aren't language features - they are just optional functions that are there if you want to use them. They are not disabled by that setting. The secure versions of standard functions, suffixed by _s, are in this category.
Having said that, if you navigate to the definition of scanf_s in the header, you can see that Microsoft have provided a way of disabling this particular family of functions.
If you define the following in your code before your header #includes
#define __STDC_WANT_SECURE_LIB__ 0
then scanf_s will no longer compile.
If you want to achieve this through your compiler switches, go to your project properties, and find the Preprocessor definitions. Add the following definition to the end:
__STDC_WANT_SECURE_LIB__#0
You can probably find similar ways to disable other additional Microsoft functions which are not part of 'standard' C.
Related
I've got a question regarding writing applications for Windows. Can I use WinAPI and DWMApi (aero glass, ribbon, etc.) when programming in ANSI C? I'm looking at MSDN right now and they use c++.
The Windows API is a C API and can be used with any compiler that supports the 'standard' calling convention.
Microsoft has made the strategic decision to put their own C compiler on life support, though, and you're stuck with C90 (with some specific extension) when using Visual Studio. You can use 3rd party compilers (GCC and Clang via MinGW, Pelles C) which support more modern language dialects.
Try it.
Most APIs actually ARE C-APIs; they just call it C++ because "nobody" really uses C anymore. I've also noticed the occasional struct with additional functions attached to them, but definitely not in Win32, and they might just #ifdef that away for C.
The thing I don't know right away is whether the headers are "safe" when used with just C, and whether the libraries have unmangled symbols. I would assume they are, but one never knows. However, making a simple C program that just calls a single Win32 API function should clarify that.
The Win32 API is accessible from many different toolsets. All C compilers for Windows that I have ever come across can call all Win32 APIs. What's more all these C compilers can call COM APIs and even GDI+ which is a very C++ centric library. But MS provided a bridge for C clients to use.
So, in summary, choosing to use C will not deprive you of access to any part of Win32.
I'm attempting to compile a sample c file that was given to me, but unfortunately, it's missing several libraries as some of the include files cannot find them. Namely: stropts.h, netdb.h, sys/socket.h, sys/ioctl.h, netinet/in.h, pthread.h, and unistd.h.
I've researched where I could fix these problems, but surprisingly there have been little to no results on this problem strangely. The Visual Studio command prompt isn't able to compile it until I can find these libraries. Anything I need to download/ link to fix this?
Those header files are not part of standard C or C++. Do not attempt to download the headers from other sources; even if you can get them to compile, they won't link properly since you don't have the implementations of the functions declared therein in a static library or DLL.
The simple fact of the matter is that the code you're trying to compile was written for Unix/Unix-like systems and it's not portable to Windows. You'll need to either significantly rewrite the code to use the equivalent Windows functionality or a 3rd-party platform-independent library (e.g. Winsock or Boost sockets for sockets), compile it on a Unix system (you could use a virtual machine if you want), or use a Unix compatibility layer such as Cygwin.
I need to verify something for which I have doubts. If a shared library ( .dll) is written in C, with the C99 standard and compiled under a compiler. Say MinGw. Then in my experience it is binary compatible and hence useable from any other compiler. Say MS Visual Studio. I say in my experience because I have tried it successfully more than once. But I need to verify if this is a rule.
And in addition I would like to ask if it is indeed so, then why libraries written completely in C, like openCV for example don't provide compiled binaries for every different OS? I know that the obvious reason would be to set all the compile-time parameters, but other than that there is none right?
EDIT: I am adding an additional question which I see as a logical extension to the original. Isn't this how one would go and create a closed source library? Since the option of giving source goes out of the window there, giving binaries is the only choice. And in that case providing binaries for as many architectures as possible is the desired result, with C being an obvious choice for having the best portability between systems and compilers. Right?
In the specific case of C compilers (MSVC and GCC/MinGW) in the Windows world, you are correct in the assumption of binary compatibility. One can link a C interface DLL compiled by GCC to a program in Visual Studio. This is the way C99 projects like ffmpeg allow developers to write application wiht Visual Studio. One only needs to create the import library with lib.exe found in the Microsoft toolchain from the DLL. Or vice versa, using mingw.org's pexports or better, mingw-w64's gendef tool, one can create a GCC import lib for a MSVC produced DLL.
This handy interoperability breaks down when you enter the C++ interface world, where the ABI of MSVC and GCC is different and incompatible. It may work, it may not, no guarantees are made and no effort is (currently) being done in changing that. Also, debugging info is obviously different, until someone writes a debug information generator/writer in GCC that is compatible to MSVC's debugger (along with gdb support of course).
I don't think C99 specifically changes anything to function declarations or the way arguments are handled in symbol definitions, so there should be no problem here either.
Note that as Vijay said, there is still the architecture difference, so a x86 library can't be used when linking to an AMD64 library.
To also answer your additional question about closed source binaries and distributing a version for all available compilers/architectures.
This is exactly the way you would create a closed source binary. In addition to the import library, it is also very important to hide exports from the DLL, making the DLL itself useless for linking (if you don't want client code to use private functions in the library, see for example the output of dumpbin /exports on a MSOffice DLL, lots of hidden stuff there). You can achieve the same thing with GCC (I believe, never used or tried it) using things like __attribute(hidden) etc...
Some compiler specific points:
MSVC comes with four (well, actually only three remaining in newer versions) different runtime libraries through /MT, /MD, and /LD. On top of this, you would have to provide a build for each version of Visual Studio (including Service Packs) to assure compatibility. But that is closed source binary and Windows for you...
GCC does not have this problem; MinGW always links to msvcrt.dll provided by Windows (since Windows 98), equivalent with /MD (and maybe also a debug library equivalent with /MDd). But I there are two versions of MinGW (mingw.org and mingw-w64) which do not guarantee binary compatibility. THe latter is more complete as it provides 64-bit options as well as 32-bit, and provides a more complete header/library set (including a substantial part of DirectX and DDK).
The general rule is that IF your OS/CPU combination has a standard ABI, and IF that ABI is powerful enough for your language, most compilers will follow that ABI and as a result will be binary compatible, allowing you to link libraries (shared or static) compiled with different compilers to programs compiled with other compilers just fine.
The problem is that most ABIs are fairly weak -- they're designed around low-level languages like C and FORTRAN and date back to the days before object oriented languages like C++. So they tend to lack support for things like function overloading, user-defined operators, exceptions, global contructors and destructors, virtual functions, inheritance, and such that are needed by C++.
This lack was recognized when C++ was designed which is why C++ has extern "C" -- which causes the compiler to limit itself to the standard ABI for certain functions, while disabling all the extra C++ features that the ABIs generally don't support.
A shared library or dll compiled to a particular architecture can be linked to applications compiled by other compilers that target the same architecture. (By architecture, I mean a processor/OS combination). But it is not practical for a library developer to compile against all possible architectures. Moreover, when a library is distributed in source form, users can build binaries optimized to their specific requirements.
I have implemented semaphores in Linux last year. But for that I have to use -lpthread.
Now while implementing log10() function in C, I surfed the INTERNET and I saw that I have to use -lm.
I want to know why these kind of command line arguments are necessary in Linux.And Does this rule is compiler oriented?
(In windows Turboc compiler, I never used these kind of arguments.)
You are instructing the compiler to look for certain libraries and use them to try and produce a final object file.
When you were doing your threading code, you used threading primitives. These threading primitives are implemented in a library called pthread, -lpthread tells the linker to use the library pthread, without providing this switch the compiler will not be able to produce a valid object file as it is missing threading code implementation.
On the file system the libraries can be found in /usr/lib and lib (among others) when you look in these directories you will see files start with the lib prefix. for example libpthreadxxxxxx. You will have to do your own research to figure out what the xxxx means.
The development cycle using unix style tools is very granular on the surface, when you use heavyweight IDE's (read: visual studiio for C++), the IDE implicetly links against loads of standard libraries, so often you do not need to supply the name of the libraries you will commonly use. However, when you start doing more advanced programming you will probably have to install and configure your IDE to use external code libraries. If you were to use threading primitives in visual studio, you most likely will not have to provide the compiler with information on where to look for threading primitives, Microsoft considers this a common library and every new project will implicitly link against it.
A little discussion on GCC
GCC is a very diverse compiler producing code for various different usage scenarios. As such they try to be neutral and do not make assumptions. For example pthread is a particular threading primitives implementation. However, even through now on Linux at least it is the defacto standard, it is not the only one. Other Unix implementation have had different implementation. When such choices exist it is not fair for the compiler developers to implicitly link against libraries. They do however implicitly link against standard libraries; for example G++ is just a wrapper command to the internal compiler code, it is a C++ front-end so it implicitly links against an implementation of the C++ standard library. Similarly the C front end links against a the standard C library.
People often do not want to use certain standard library implementation, and instead they might want to use another implementation, in such cases you have to explicetly inform the compiler to use an implementation that you provide. Such use cases are very granular and are surface level issues with G++. In visual studio, you would have to tinker a lot to make such changes generally, since it is not an anticipated use-case anymore.
wikipedia will provide you with more information.
Edit: I'll fix the spelling and Grammatical issues later :D
The option -l indicates to gcc what libraries must be used for linking. -lpthread stands for "use the pthread library", and -lm stands for "use the m library" which is the math library. These commands are relative to gcc, not linux.
Because by default, gcc only links the C library (libc), which contains the well-known functions printf, scanf, and many more.
log10 exists in a different library called libm, and thus you need to explictly tell gcc to link that library, with -lm. The same logic applies for -lpthread.
This is purely a backwards, harmful practice. Separating parts of the standard library into separate .so files does nothing but increase load time and memory usage. Good luck getting anyone to change it though... Just accept that you have to do it (and that POSIX specifically allows, but does not require, that an implementation require -lm for using the math functions and -lpthread for using threads, etc.) and move on to more important things.
Or, go pester Drepper about it on the glibc bug tracker/mailing list. He won't change his mind, but if you enjoy flamewars you can get some kicks...
If I'm compiling a C program with gcc, I can safely assume that the functions in regex.h are available. Is there a regex library I can assume is there if someone is compiling with microsoft's C compiler?
C++ only, but may be something you can use (or wrap):
Visual C++ 2010 includes the TR1 regex library support.
http://msdn.microsoft.com/en-us/library/bb982382.aspx
It's also available for VC++ 2008 in a feature pack:
http://www.microsoft.com/downloads/details.aspx?FamilyId=D466226B-8DAB-445F-A7B4-448B326C48E7&displaylang=en
No, I don't think MSVC comes bundled with any regex library.
Regex isn't part of the C/C++ standard library, so you shouldn't rely on any compiler providing such a library by default. It's best to get hold of a separate regex library for C (I'm sure there are tons available) and include it with your code.
Try Boost or wait for release of C++1x...
There's no C/C++ regexp library bundled with msvc. C++/CLI have access to the .NET regexp classes though.
Perhaps you can use PCRE
If you want POSIX-compatible regular expression semantics (and the same API too!) then the best regex library is TRE: http://laurikari.net/tre/
Unlike most regex implementations, it follows POSIX exactly in regards to the matches it returns for parenthesized subexpressions, and it's O(n) whereas most implementations are O(2^n) in time.
Google also has a new regex implementation that uses Perl-compatible syntax if you prefer that. You can find a link on the TRE website.
Edit: By the way, TRE seems to come with project files to build it under MSVC.