So, I believe I understand the concept of the header method C++. But I read a post which become confusing. If I decide to avoid using directive in my programming I.E (using namespace std), how can I supplement other libraries that I may not be familiar with or where can I find a digital resource to help me resolve scope problems. I know that the "std" part in a std::cout statement resolves the the function from the iostream when I choice to include it. However, I am not getting the convention here. What would the scope parameter for be in a situation where I wanted to use the it but did not want to use the std namespace and how would this affect un-conventional classes?
Files which contain standart functions declarations - like iostream for example, are kept in directories depending on what ide you are using. For example, for Visual c++ studio 2008 these files are in [visual studio folder]/VC/include.
To find all files containing std namespace functions declarations you probably will need to search for all files containing _STD_BEGIN macro.
Related
I've been trying to follow lazy foo's productions tutorial on sdl2 and I keep on running into the same issue. I made a template that links to the correct files and all and it worked for a while. But now when I create a project and include iostream for example, it tells me #using need c++/cli mode enabled.
So I then tried enabling it in the project settings but then it gave another error : "Cannot open metadata file iostream"
I tried :
Rebuilding the project and solution
Cleaning the project and solution
I read this question and its answers : Visual studio - getting error "Metadata file 'XYZ' could not be found" after edit continue
Tried this too : IntelliSense: "#using" requires C++/CLI to be enabled
All of the above did not work
Don't confuse #include, using and #using.
#using is used to import class libraries in C++/CLI, which is something you won't ever need unless you work with .NET libraries (but then usually you are better off just using C#, unless you are writing interop code).
#include is for including header files, which is what you normally do in "regular" C++. <iostream> is a regular standard library header, so you need #include (as in #include <iostream>).
using instead is used to bring names in the current scope (either the whole content of a namespace - as in the dreaded using namespace std;) or single names (as in using std::cout;). From C++11 it's also used to enable constructors inheritance and to create type aliases, but for the moment I don't think you need to worry about these uses.
But most importantly: please take the time to first learn the basics of the language from reputable sources before trying random stuff. All this #using mess wouldn't have arisen if you even just looked first at the classic hello would example you can find everywhere on the Internet.
I want to take a peek inside of namespace std but, i'm not able to actually find the file on my computer where it is defined. I tried googling this but, i haven't had much luck.
On most Unix systems, the C++ headers are usually stored in /usr/include/c++/<version>/, where <version> is the GCC/libstdc++ version (i.e. 4.9 or 4.9.2), or else the libc++ version i.e. v1.
Within that directory are all (or just most?) of the standard-mandated headers, which are mostly just ordinary C++ code. For libstdc++, note in particular that most of the older headers just include something in bits/; few of the C++11-specific headers do this.
A list of every thing included in namespace std can be found here.
If you are using Visual Studio you can find it locally here :
~\Microsoft Visual Studio\VC\crt\src
There is also an online representation here.
NOTE : Edit the src files at your own risk, I'd recommend not editing them at all.
Many of the things implemented in the std namespace are templated, which means their entire implementation will be in the header files. For example, std::vector should be in the vector header file. Simply look at the options for your compiler to find out where those header files are located.
There may be some non-templated parent classes and free standing functions, which will not be in the headers. Again, look at the compiler documentation to see if the source files are included somewhere and where they would be.
I can use using namespace directive to avoid identifier/variable name collision, but what happens when file names or library names collision happens in large projects.
In C the conventional approach is to add files recursively using #include_next directive. How can I achieve the same in C++ without using the #include_next directive and address the issue of duplicate file names among applications and shared libraries. An example, a work around the class() function in AIX math.h clashing with identifiers named "class".
/* GNU Lesser GPLv2.1 or later */
#ifndef FFMPEG_COMPAT_AIX_MATH_H
#define FFMPEG_COMPAT_AIX_MATH_H
#define class some_text
#include_next <math.h>
#undef class
#endif /* FFMPEG_COMPAT_AIX_MATH_H */
EDIT:
Can I use, for example class machine-instruction-set where the binary has to run on multiple platforms? Can there be namespace collision in such case?
I can use using namespace directive to avoid identifier/variable name collision
Quite to the contrary, using namespace directive introduces collisions. You resolve collisions by specifying scopes, e.g. std::vector<> vs. boost::numeric::ublas::vector<>.
... but what happens when file names or library names collision happens in large projects?
Filename collisions are easy to prevent by being systematic: organize your headers so that they mimic your namespaces, e.g. boost::numeric::ublas::vector<> comes from #include <boost/numeric/ublas/vector.hpp>. And don't pile headers and sources of different libraries in one directory, so that you can include headers with the same name using a different directory prefix, e.g. #include <lzma/version.h> vs. #include <linux/version.h>.
The correct way to deal with this is to setup your build environment in a way that name clashes become less likely.
Guidelines for writing libraries
For example, most third party libraries do not introduce plain files to the compiler's include path. Instead they introduce a directory that contains the files. You can increase flexibility by introducing subdirectories for different modules.
Consider the directory structure of Boost. On the top-level, Boost only introduces a single name to the include search path: The boost directory. That way, even though boost introduces a number of header filenames which are likely to clash (like array.hpp, thread.hpp, or function.hpp), they are all wrapped away in the subdirectory:
#include <boost/thread.hpp> // this is boost's header
#include "thread.hpp" // some header specific to my current project
// no name clash :)
The same concept is used for the different libraries that ship with Boost. For example, both Boost lockfree and Boost assign have a queue.hpp header. But they live in different subdirectories, so there is no clash:
#include <boost/lockfree/queue.hpp>
#include <boost/assign/std/queue.hpp> // no clash :)
To make finding the right header file easy, Boost uses the same structure for include files and namespaces: The lockfree queue lives in boost::lockfree namespace, while the functions from the assign queue header go to boost::assign. That way it is not only straightforward to find the matching namespace from an include file and vice versa, it also decreases the likelihood of namespace clashes, as a namespace clash is also likely to manifest in a physical name clash on the file layer.
You can adapt these guidelines for your own project
Don't introduce bare include files directly to the include path. Instead group them together in a directory to avoid polluting the include path with names.
Use directory trees to further structure the include files of modules inside a single library.
Try to match the physical structure with the logical structure. Filesystem include paths should resemble namespace hierarchies if possible.
This avoids most of the nameclashes in the first place. The question is what if you have to use a third-party libraries that do not follow these rules and you get a clash that is outside your control?
Guidelines for dealing with name clashes by third-party libraries
The answer is to be brutal and enforce the separation through the build environment. Reorganize the include paths by moving conflicting libraries into uniquely identifiable subdirectories to resolve physical conflicts. This is usually non-critical. Logical conflicts require patching and recompiling, which is a lot more inconvenient. But if you really run into name clashes here, it is a sure indication that at least one of the library vendors did not do their job too well and you should consider filing a bug.
Stay away from ad-hoc fixes like #include_next to fix physical clashes or preprocessor defines to fix logical clashes. They are dirty hacks and while they might solve your problem temporarily, they are very likely to come back and bite you eventually.
File Name Collisions
Put libraries in separate subdirectories, and set the parent directory as the search location. So instead of:
#include "zerz.h" // supposed to be from libfoo
#include "zerz.h" // supposed to be from libbar
You can do this:
#include "libfoo/zerz.h"
#include "libbar/zerz.h"
Identifier Collisions
Use the pimpl idiom to isolate the code that interacts with each library so that the conflicting identifiers aren't dragged into zillions of projects due to transitive includes.
For example, if libfoo and libbar both have a function called Frobnicate, then you want to isolate any code that depends on those libraries so that nothing else has to include those libraries' headers and thus end up with a conflict. Only the .cpp (or .c) file that actually calls Frobnicate should #include the library's header file. That prevents unintended transitive includes, which is usually how you would end up with conflicting declarations of Frobnicate being included in a single compilation unit.
The pimpl idiom is usually presented terms of C++, but you can play the same game in C. The point is to define your own API to the library in a header. Your API should have the same functionality but using names that don't conflict (e.g., by adding a unique prefix if you can't use namespaces). All code should be able to include that header without conflicts. You then provide an implementation file (.cpp or .c), which is the only file that #includes the actual library header. This implementation file essentially forwards calls of the prefixed functions to the actual library functions. All you have to do is avoid collisions in this one file, which should be doable.
First of all, #include_next is not standard, is a gcc extension, also supported by Clang, but I don't know if any other compilers support it.
The only way to deal with filename collisions is to properly use either #include "foo.h" or #include <foo.h>. The former is meant to be local to the current project, while the latter is used for system libraries. Usually #include "foo.h" will also search system libraries, but not the other way around.
Anyway, #include "foo.h" should start by looking in the source file directory, you can use #include "../foo.h" etc. to do relative includes. If you have filename collisions within the same project, you're going to have to use different compile flags to set different search paths (basically make subprojects).
For symbol conflicts, #define before #include is the standard way.
Of course, the best way is to take care to avoid these kind of problems in the first place.
A useful method to use when using C includes in C++ programs is to use the following code snippet in your .h files.
#ifdef __cplusplus
extern "C" {
#endif
<your code here...>
#ifdef __cplusplus
}
#endif
This will allow your C++ objects to link with the C objects. I don't know about going the other way though, so perhaps this is a partial answer.
"I can use using namespace directive to avoid identifier/variable name collision": Nope! You should avoid using that directive in order to avoid name collisions.
I am trying to compile a Visual Studio / C++ code snippet I have found on the internet containing the function:
Marshal::SizeOf()
When compiling the snippet, I get the error message:
error C2653: 'Marshal' : is not a class or namespace name
so I think I need to include a header file with the definition of this namespace or class, and the SizeOf() function.
When I look up Marshal::SizeOf C++ in Google I find this help page, however on this page there is no information regarding which header file must be included in order to use this function.
Is there a documentation page where one can look up all .NET classes and functions and easily find the C++ header file that must be included in order to use them?
You need to understand what C++/CLI is. It is a proprietary extension to C++ by Microsoft to make the interfacing between native and managed code (i.e. .Net) easy.
Marshal is not a C++ class, it's a C++/CLI class. As such, there's no header to include. It's #import you are looking for.
I am using a C library (libgretl) from C++ and some of its functions conflict with my code, so I wanted to wrap it in a namespace, like this:
namespace libgretl {
extern "C" {
#include <gretl/libgretl.h>
}}
However, this does not compile, I get "undefined" errors from gcc files (using mingw32 with gcc 4.5.2 on Windows).
The first errors come from the following code block of file c++/cstddef:
_GLIBCXX_BEGIN_NAMESPACE(std)
using ::ptrdiff_t;
using ::size_t;
_GLIBCXX_END_NAMESPACE
where the macros expand respectively to namespace std { and }. There are more errors after these.
Omitting the extern "C" directive does not help. Using an anonymous namespace reduces the amount of errors, but it still won't compile.
My question is therefore if there is some way to include such a C library and place its functions into a namespace, without changing the gcc or the library's source files?
Thanks.
Michal
You can't do it. Namespaces are not just source code decorations, they are mangled to object symbols by compiler.
Native C function foo() in library will be available by symbol _foo in object file, but calling bar::foo() will generate reference to, for example, #N3barfoo. As result, linker error will occur.
You may create "proxy" functions in separate source file, including original library header only in this source and putting all proxy functions to namespace.
You don't get to simply wrap a namespace around an external declaration and have it appear within that namespace... the item (function, global) must have been built within that namespace from the start. Since C doesn't support namespace resolution, this could not have been the case.
You need to change your own code to accommodate this library, unless you're willing to chante the library itself.
In order to refer to a non-namespace'd item that conflicts with your own namespace'd item, refer to ::item().
I guess the C library was compiled as C, which means namespaces are not included and not supported in the compiled code. Thus, your compiled C library cannot be in a namespace. Altering the header by encapsulating the include will not change that.
You can still encapsulate your own code in a namespace.