I've noticed that several of our projects do the whole
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
thing in their stdafx.h.
Will this memory leak detection work as intended when specified in the stdafx?
Don't put it in stdafx.h. Doing so can give you undesired side effects.
Here's why.
In most cpp files, you have something like this:
#include "stdafx.h"
#include <AcmeHeader.h>
#include "MyHeader.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
Note that the redefinition of new is explicitly supposed to happen after all headers are included. If you define DEBUG_NEW in stdafx.h, then that definition will also be applied to AcmeHeader.h and MyHeader.h, which can cause problems with headers that try to redefine operator new.
I've also run into cases where I've wanted to remove the redefinition of "new" for just one or two files, but that's a rare situation.
Related
Is there a way to apply _CRT_SECURE_NO_WARNINGS only to s fragment of code? I tried the obvious
#define _CRT_SECURE_NO_WARNINGS
// some code here
#undef _CRT_SECURE_NO_WARNINGS
It seems it doesn't work.
The _CRT_SECURE_NO_WARNINGS flag is applied to the declarations of the relevant functions when they're included in your source code. You can't really turn them on or off on a per-call basis, it's an all-or-nothing setting. That's why the #define _CRT_SECURE_NO_WARNINGS directive must come before the #include directives that include the relevant function declarations.
As an alternative, you can bracket your calls with #pragma warning directives to turn off that specific warning:
#pragma warning(push)
#pragma warning(disable:4996)
printf("Look Ma, no warnings!\n");
printf("This is awesome!\n");
#pragma warning(pop)
// or for just one call,
#pragma warning(suppress:4996)
printf("We'll look the other way just this once.\n");
I am trying to create a UDP multicast socket program using VS2015 (C++ console application).
I got the following error,
Error C4996 'inet_addr': Use inet_pton() or InetPton() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings mulitcast_listener
I tried to add _WINSOCK_DEPRECATED_NO_WARNINGS symbol to my project settings via "Project"->"Properties"->"Configuration properties"->"C/C++"->"Preprocessor"->"Preprocessor definitions"
.. But still it says the same.
And then I tried to add symbol above #include "stdafx.h"
like
#define _WINSOCK_DEPRECATED_NO_WARNINGS 1
and then No(/sdl-) on "Project"->"Properties"->"Configuration properties"->"C/C++"->General->SDL checks
now I get a error message saying
Warning C4603 '_WINSOCK_DEPRECATED_NO_WARNINGS': macro is not defined or definition is different after precompiled header
Finally I tried to implement
inet_pton(AF_INET, HELLO_GROUP, (PVOID *)(&mreq.imr_multiaddr.s_addr));
instead of
mreq.imr_multiaddr.s_addr = inet_addr(HELLO_GROUP);
I need to understand why the error didn't resolved even after adding the _WINSOCK... macro.
Thanks in advance.
As noted in the comments, the solution is to make sure that the line
#define _WINSOCK_DEPRECATED_NO_WARNINGS
is placed after
#include "stdafx.h"
but before the other #include statements.
While the previous advice works, it is ignoring the purpose of stdafx.h. The idea is that you place #include statements for header files that don't change frequently inside stdafx.h in order to make use of precompiled headers. Therefore you should ideally place
#define _WINSOCK_DEPCRECATED
inside stdafx.h, before other #include statements that it affects, in particular before including winsock2.h or other winsock related headers.
// pch.h
#ifndef PCH_H
#define PCH_H
#define _WINSOCK_DEPRECATED_NO_WARNINGS // defined here and it worked
#include "framework.h"
#include "xxx.h"
HI,
I am converting my project from vc6 to latest using vs 2010. I get problem on compiling my code
Error 931 error C2065: 'ostrstream' : undeclared identifier
1100 IntelliSense: identifier "fstream" is undefined
I have included the required files as told in Google
#if ! defined(_FSTREAM_)
#include <fstream>
#endif
#if ! defined(_STRSTREAM_)
#include <strstream>
#endif
When i press F12 on the fstream or ostrstream it takes to the respective files where these class are defined. Is there any other includes i have to do, i have been searching for this for long time with no luck :(
Thanks
Arvind
Add these to your library list:
#include <stdio.h>
using namespace std;
Forget all the preprocessor stuff; it's redundant at best (the files in questiion will have reinclusion guards) and at worst an error (you're assuming the #defines used, which are arbitary). Just use code like this:
#include <fstream>
#include <strstream>
Also note that the strstream header is deprecated. You should use sstream instead, but note the newer classed in this file word differently to the deprecated ones).
Without using namespace std; as its good practice.
#include<fstream>
std::fstream fileio;
Where the fileio is the object created by fstream. The fstream class needs to be created using the std keyword as it is part of the standard library.
Hence using : using namespace std; in the code makes it work.
NOW using using namespace std; can cause conflicts in shared libraries.
#include <fstream>
using namespace std;
fstream fileio;
What worked for me was a combination of two answer. After some trial and error, fstream squiggly red lines vanished when I added,
#include <fstream>
using namespace std;
I am writing a program that is cross platform. There are a few spots where I have to specify an operating system dependent call.
#ifdef WINDOWS
..do windows only stuff
#endif
#ifdef LINUX
..do linux only stuff
#endif
Are there any preprocesser directives that get defined by the compiler so I don't have to explicitly define them when I use the command line compiler. ie.
cl -DWINDOWS program.cpp
or
g++ -DLINUX program.cpp
I realize I could easily write a makefile or have a shell/batch script that will do this automatically. But I would prefer to use the same ones as the compiler (if they exist) by default.
I found a complete list for all g++'s on this website.
#define __HAVE_BUILTIN_SETJMP__ 1
#define __unix__ 1
#define unix 1
#define __i386__ 1
#define __SIZE_TYPE__ unsigned int
#define __ELF__ 1
#define __GNUC_PATCHLEVEL__ 3
#define __linux 1
#define __unix 1
#define __linux__ 1
#define __USER_LABEL_PREFIX__
#define linux 1
#define __STDC_HOSTED__ 1
#define __EXCEPTIONS 1
#define __GXX_WEAK__ 1
#define __WCHAR_TYPE__ long int
#define __gnu_linux__ 1
#define __WINT_TYPE__ unsigned int
#define __GNUC__ 3
#define __cplusplus 1
#define __DEPRECATED 1
#define __GNUG__ 3
#define __GXX_ABI_VERSION 102
#define i386 1
#define __GNUC_MINOR__ 2
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __tune_i386__ 1
#define __REGISTER_PREFIX__
#define __NO_INLINE__ 1
#define _GNU_SOURCE 1
#define __i386 1
#define __VERSION__ "3.2.3 20030502 (Red Hat Linux 3.2.3-47.3)"
And Visual C++ already has Win32 defined to use for any Widnows version.
Yes, there are such pre-defined symbols but I don't recommend you use them unless you never, ever, forsee supporting more platforms, compilers or operating system versions. Here's the logic.
First, you're better off with your own minimal set of defined compilation constants for use within your code. Because you might start with things like this:
#if defined(_WIN32)
// do windows stuff
#endif
#if defined(_linux)
// linux stuff
#endif
Suppose you allow compilation under a new compiler for windows that doesn't define _WIN32 automatically? You can change every _WIN32 line to something like:
#if defined(_WIN32) || defined(ming)
Which is a real pain in the butt if you have more than one of those to change. You could put something like this at a high level:
#if defined(ming)
#define _WIN32
#endif
But you'll likely discover that some system or library header file freaks out because they happen to use _WIN32. Better you had abstracted it in a common header file:
#if defined(_WIN32) || defined(ming)
#define PLAT_WINDOWS
#endif
And then simply use #if defined(PLAT_WINDOWS) where needed.
But what about that common header file? Well, when a new compiler/OS/whatever comes along you have to start tweaking it to make sure it says the right things. Pretty soon it is a comical hairball of condition that can only be understood if you know about every version of every compiler on every operating system on the planet. And gee, who doesn't but nevertheless any changes made have to be tested everywhere and that is painful.
So, better you just have some high level setting inside the makefile or even outside it that says "if you're on windows, -DPLAT_WINDOWS" and be done with it.
Of course, all this is minimized if you use the most commonly available functions and features in your code.
All of these answers were very good. The solution that worked for me was the following.
#ifdef _WIN32
#endif
#ifdef linux
#endif
WIN32 was not defined by cl but _WIN32 was.
linux was defined by g++.
Yes. I believe WIN32 is, but I'm not on a windows right now to test it :D
See:
http://en.wikipedia.org/wiki/C_preprocessor (it mentions WIN32)
Instead of having two macros for specific platforms, you may have the code in #ifndef #else block. For example:
#ifndef _WIN32
// linux specific code
#else
// windows specific code
#endif
With this solution, the ifndef-else block will make sure that you don't accidentally add code in between the two #ifdef blocks (which supposedly be handling the program execution flow in same manner).
The above code will also give you independence of compiling this code not just for linux but any unix platform, provided it supports the call, without changing the macro label from linux to unix or something else.
I need a set of wrappers around the standard system calls-open,listen,etc.
For these i have a few "#define" as in:
#define open(a,b,c) JCL_Open(a,b,c)
But when i compile the header and associated .c files, i am getting the following warning:
/jcl_wrappers.h:114:1: warning: "open" redefined
/jcl_wrappers.h:113:1: warning: this is the location of the previous definition
How can i suppress these warnings?
Put include guards in your header file.
Basically you need to put these two lines at the beginning of your header file
#ifndef _yourincludefilename_h_
#define _yourincludefilename_h_
and
#endif /* _yourincludefilename_h_ */
at the end of you include file.
Edit:
rascher is right, that open is not a good name for a macro, as it will conflict with a library function. Usually it is good C convention to make macros all uppercase, so I would suggest to change your macro to
#define OPEN(a,b,c) JCL_Open(a,b,c)
or even better
#define XYZ_OPEN(a,b,c) JCL_Open(a,b,c)
where XYZ is a prefix specific to your code.
Leave the standard functions alone and rename the function:
#define myopen(a,b,c) JCL_Open(a,b,c)
Someone will thank you later.
You might try using compile guards. Like:
my_headers.h:
#ifndef __MY_HEADERS
#define __MY_HEADERS
#define open(a,b,c) JCL_Open(a,b,c)
#endif
This will only do do what is between the #ifndef and #endif if the '__MY_HEADERS' macro has been defined. So, everything in your .h file will only be declared once.
You could use the same construct to see if the "open" macro is already defined.
Also be aware that there is already a C function called open(): http://www.manpagez.com/man/2/open/ . May not be a great idea to use the same name for your macro!
Wrap the define in:
#ifndef JCL_WRAPPERS_H
#define JCL_WRAPPERS_H
... your macro's
#endif
This makes sure your macro's are only defined once if you including your header in multiple places.
It's generally a smart thing to do for all prototypes in headers also.