As per my code in filename.c,
#include "FOUNDATION/FOUNDATION.h"
Actually I have to run the vector cast (unit testing tool) for the filename.c.
so since the "FOUNDATION.h" is not present in the corresponding path mentioned,
vector cast compilation provides the error like no such file/directory.
can we replace
#include "FOUNDATION/FOUNDATION.h"
with my specified path where actually the "FOUNDATION.h" is present.
Related
#include <iostream>
#include<eigen3/Eigen/src/Core/Matrix.h> // does not define Eigen::StorageOptions
// need something like this
#include<eigen3/Eigen/src/ everything_in_here >
int main()
{
Eigen::Matrix<double,2,2> mat;
std::cout << mat(0,0) <<std::endl;
return 0;
}
In there, I'm trying to build a matrix object and it always asks 6 template parameters with error message:
wrong number of template arguments (3, should be 6)
So I started adding them, 4th one is Eigen::StorageOptions and is not defined in the Matrix.h header. Also there are too many headers to search. So, can I include all files in there with a single #include?
You are not supposed to include anything from Eigen/src/... directly. If you need only the core components of Eigen, use
#include <Eigen/Core>
If you want to include everything related to dense matrix operations (e.g., decompositions and the Geometry module):
#include <Eigen/Dense>
If you also want to include the Sparse module
#include <Eigen/Sparse>
// or this to include Dense+Sparse:
#include <Eigen/Eigen>
You should make sure via compilation options, that the top-level Eigen-directory is in your include-path, e.g. on many Linux-environments, add -I/usr/include/eigen3 as an argument. Your IDE probably also has an option for that. If you use something like CMake there are lots of related questions for that.
If for whatever reason this does not work or you just need a quick-and-dirty work-around, you can write
#include <eigen3/Eigen/Core> //etc
No, there isn't. Only individual files can be included. (Though technically what that means is implementation-defined.) The preprocessor has no filesystem/directory concept. It considers the file names used in #include directives only as strings, not paths.
I am also not aware of any compiler extension to support this (although there may be ones).
You can generate the necessary #include directives in a script as a preparation step in the build process.
Initial problem:
I have a bug caused by an old debug MSVCRT library.
It throws an exception in debug mode for std::string initialization:
std::string str{vecBuff.cbegin(), vecBuff.cend()};
The old debug runtime library detects that std::vector<char>::cend() points to an invalid address and causes an error about HEAP Courruption. It only happens within a MSI Custom Action invocation (and there's an old runtime version which I can do nothing about).
In the comments to this answer there is a solution to set _ITERATOR_DEBUG_LEVEL 1.
I don't want to do that for the whole library. Unfortunatelly, I can't manage to do it for the single .cpp either.
This .cpp uses a precompiled header and disabling it for a single file in the properties changes nothing. I still get an error about stdafx.h missing.
// stdafx.h
#pragma once
#include <string>
// the .cpp file
// Can't include before. Get a lot of warnings.
#include "stdafx.h"
// will not have any effect since <string> is already included in "stdafx.h"
#if _MSC_VER && \
!__INTEL_COMPILER && \
_DEBUG
#define _ITERATOR_DEBUG_LEVEL 1
#endif
#include <string>
Though I am initially trying to solve the std::string initialization problem, I'd like to know the answer to a more generic topic, since there are some other places where I might require to customize preprocessof definitions AND use a precompiled header.
Defining _ITERATOR_DEBUG_LEVEL to either 1 or 2 changes the representation of iterators. Instead of being lightweight wrappers for e.g. plain pointers into container data, iterators compiled with this option contain a pointer into the data and a pointer to a container proxy object, which contains more info about the container. Thus a program where some object are compiled with _ITERATOR_DEBUG_LEVEL set to 0 and others with _ITERATOR_DEBUG_LEVEL set to something else contains two incompatible versions of each iterator type. This is not a good idea. The compiler therefore tries to detect a mix of different debug levels and introduce a deliberate linker error if a mismatch is found. Even if you manage to inhibit this check somehow, passing iterators between functions compiled with different _ITERATOR_DEBUG_LEVEL value is usually fatal.
I am using clang ast matcher to extract some information fromt the source file. Now, I would also like to know the list of headers and dependency headers that the source file is using. For example, the source file abc.c has following header:
#include <def.h>
//#include <def_private.h>
During clang matcher, I need to make sure clang knows about the def.h, which is in the same directory. The def.h includes the following headers:
#include <iostream.h>
#include <string.h>
#include <float.h>
#include <math.h>
/*#include <boost>
* #inclde <fstream>*/
I do ast matcher to extract or identify information from abc.c. Now, I would like to extract all the headers or includes. This should include all of them:
#include <def.h>
#include <iostream.h>
#include <string.h>
#include <float.h>
#include <math.h>
I did some online research to do this, unfortunately all of them are involving regex (Regular expression to extract header name from c file) or how to do in visual studio (Displaying the #include hierarchy for a C++ file in Visual Studio).
I wonder if it is possible using clang. Also, please let me know if there is any other way to programmatically extract the headers that is more than just using regular expression.
OP says Any other way to programmatically extract the headers that is more than just using a regular expression. .... without clang is ok.
We both agree that regexes are simply incapable of doing this right. You need the source text parsed as a tree with the #include directives explicitl appearing in the tree.
I'm not a Clang expert. I suspect its internal tree reflects preprocessed source, so the #include constructs have vanished. The problem is then one of insisting on preprocessing the source text to parse it.
Our DMS Software Reengineering Toolkit with its C++17 capable parser can handle such parsing without expanding the directives. It can do this two ways: a) where preprocessor directives are "well structured" with respect to the source code, the C++ front end can be configured to capture a parse tree with the directives also parsed as trees in appropriate places; this works pretty well in practice at the price of sometimes having to hand-patch a particularly ugly conditional or macro call to make it "well structured, or b) parse capturing the preprocessor directives placed in (almost) arbitrary way; this captures the directives sometimes at the price of automatically duplicating small bits of code to in essence cause the good restructuring liked by case a).
In either case, the #include directives now appear explicitly in the AST, with the included file pretty much built as an auxiliary tree representing the included file. Such tree nodes easily found by a tree walk looking for such explicit include nodes.
DMS's ASTInterface provides ScanTree to walk across nodes and taking actions when some provided predicate is true of a node; checking for #include nodes is easy. It is useful to note that becaause the conditional directives are also retained, by walking up the tree from a #include onr can construct the condition under which that include file is actually included.
Of course, the header file itself is also parsed, producing a tree. Any includes it has appear in its tree body. One would have to run ScanTree over each of these trees to collect all the includes.
OP didn't say what he wanted to do with the #includes. DMS provides a lot beyond parsing to help OP achieve her purpose, including symbol table construction, control and dataflow analysis, tree pattern matching, tree-to-tree transformations expressed in terms of source language (C++) syntax, and finally source code (re)generated from a modified syntax tree.
I want to use the std::string namespace + member, but I do not want the size of my file to increase by the size of the #include <string> file.
Is there anywhere that I can find the source code of the std:: namespace so I can just extract the string member and put it in my source so I don't get the increase in my binary size?
Please give me some suggestions, thank-you!
If using GCC on Linux (thru g++), it is free software and the source code of the standard library is available. So you could study its <string> header (some of which might perhaps use compiler magic like builtins or attributes).
Notice that if you #include <string> and ask the compiler to optimize (for size using -Os, or for speed using -O2) it is very likely that uneeded functions won't come in. At last, usually the libstdc++ is dynamically linked (as a shared object) so does not consume space in every program (but is shared across several processes)
I'm having a really nasty problem with some code that I've written. I found someone else that had the same problem on stackoverflow and I tried the solutions but none worked for me.
I typedef several common STL types that I'm using and none of the others have any problem except when I try to typedef a map.
I get a "some_file.h:83: error: expected initializer before '<' token" error when including my header in a test program.
Here's the important part of the header(some_file.h):
#ifndef SOME_FILE_H
#define SOME_FILE_H
// some syntax-correct enums+class prototypes
typedef std::string str;
typedef std::vector<Column> col_vec;
typedef col_vec::iterator col_vec_i;
typedef std::vector<Row> row_vec;
typedef row_vec::iterator row_vec_i;
typedef std::vector<str> str_vec;
typedef str_vec::iterator str_vec_i;
typedef std::vector<Object> obj_vec;
typedef obj_vec::iterator obj_vec_i;
typedef std::map<Column, Object> col_obj_map; // error occurs on this line
typedef std::pair<Column, Object> col_obj_pair;
The includes in some_file.cpp are:
#include <utility>
#include <map>
#include <vector>
#include <iostream>
#include <string>
#include <stdio.h>
#include <cc++/file.h>
#include "some_file.h"
The test file simply includes string, vector, and my file in that order. It has a main method that just does a hello world sort of thing.
The funny thing is that I quickly threw together a templated class to see where the problem was (replacing the "std::map<Column..." with "hello<Column...") and it worked without a problem.
I've already created the operator overload required by the map if you're using a class without a '<' operator.
You are getting this problem because the compiler doesn't know what a map is. It doesn't know because the map header hasn't been included yet. Your header uses the STL templates: string, vector, map, & pair. However, it doesn't define them, or have any reference to where they are defined. The reason your test file barfs on map and not on string or vector is that you include the string and vector headers before some_file.h so string and vector are defined, but map is not. If you include map's header, it will work, but then it may complain about pair (unless your particular STL implementation includes pair in map's header).
Generally, the best policy is to include the proper standard header for every type you use in your own header. So some_file.h should have, at least, these headers:
#include <string>
#include <map>
#include <utility> // header for pair
#include <vector>
The downside to this approach is that the preprocessor has to load each file every time and go through the #ifdef ... #endif conditional inclusion processing, so if you have thousands of files, and dozens of includes in each file, this could increase your compilation time significantly. However, on most projects, the added aggravation of having to manage the header inclusion manually is not worth the miniscule gain in compilation time.
That is why Scott Meyers' Effective STL book has "Always #include the proper headers" as item #48.
Is there a #include <map> somewhere in your header file?
Put that in there to at least see if it works. You should be doing that anyway.
You should shift some of those includes into your header file. These need to be placed before your typedef statements.
i.e.
#include <map>
#include <string>
#include <map>
Otherwise, anything else including some_file.h (such as your main program) won't know what they are unless it also places these includes before the #include "some_file.h" include directive in your main program source file. If you do this, the problem should go away.
As several people have pointed out, the compiler isn't finding the definition for map. Since you appear to be including the map header, there's 2 other possible causes i can think of:
Another header file called map is being loaded instead of the std map header. I think this is unlikely.
Another header is #define'ing map to be something else.
One way to check for either is get your compiler to generate the post-processed file, i.e. the source file after it has been run through the C pre-processor but before it has been compiled. You should then be able to find your offending line and see if the map type has been replaced with something else. You should also be able to search back up the file and see what header the #include opulled in.
How you generate the post-processed file is compiler dependent - check the cmd-line flags in the docs for your compiler.