Google is full of C-ish answers. I'm looking for std::string way to accomplish this task
Google is full of C-ish answers.
Those answers will work in C++ as well. C++ doesn't have features that would make this easier... yet 1.
An overview of options that are available:
Copy the content into a compiled object file. This is not portable across language implementations. May be achieved with a tool such as objcopy.
Include the file with a linker script. This is not portable across language implementations.
Generate a source file (based on the input file) which initialises an array of bytes that have the content. xxd tool (from the vim editor) can be used to do this. This is portable, although there may be implementation specific limits to how large files can be included like this.
It is also worth it to re-consider whether importing text file at compile time is even a good idea for your use case. Often, it is more useful to read the file at runtime because it allows the file to easily be changed without requiring re-compilation.
1 There is a proposal to add such feature to a future standard.
Related
I'm writing an embedded application, and the environment I use does not, unfortunately, have C++11 support at present.
I need to implement a hash/unordered map (a regular std::map won't do for performance reasons), but can't seem to find a way to do it cleanly.
Boost doesn't want to work without bringing in practically the whole library. Even the original STL hash_map from SGI wants several headers, and duplicates standard library functionality, causing ambiguous function calls. It's a real mess.
For ease of implementation, versioning, quality control, V&V, etc. I really need something that leverages the existing standard library and exists in only a few header files that I can put right in the same folder as all the other source/header files. Does such a thing exist, or am I without hope? I've searched for a long while, but have come up empty-handed.
Thanks very much for any help. I can certainly clarify further if necessary.
Did you look at the GNU implementation? On my Ubuntu Machine, unordered_map.h does not include anything. This file is located at
/usr/include/c++/4.6/bits/unordered_map.h
which is about 400 lines although the file "unordered_map" in /usr/include/c++/4.6/ has more headers but you can tweak those I guess.
I think you can find the source code for implementation from GNU.org (?) and compile it yourself?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
our project is really big. the source codes size is about 620KLOC in one module. So I want to check which function is the biggest in a directory/module? Is there any tool can support it?
SourceMonitor only has "Average Statements per Method", not maximum statements per method.
CCCC doesn't support it either.
example. This function length is 1.
unsigned short get()
{
return 1;
}
Thanks.
The easiest thing I can think of is scripting your way through it.
Use e.g ctags to get a list of functions in the file
Use perl/python/awk/grep to split your source file into separate files,
one file per function
Simply count the lines of each file, take the maximum length.
If you need more details, feed each file into a loc-counter e.g. sloccount to
get more refined information. Use grep again to get the output you are
interested in
Another tool that might be of help:
Lazy C++: Is is a code generator that splits files that are very similar to c++ into header and source. If you write you transform your code into a lzz file the generated code includes line counter tags per function. The differences in those numbers would show you how big your functions are
You can scan your project with our SourceMeter tool, and for your needs it provides CSV files containing functions/methods with metrics (among others size metrics you are looking for) and also the containing module (e.g. library, shared object, executable). Using a spreadsheet editor you can easily find the biggest functions/methods per module.
I think that many static analysis tools may not give you what you need since they don't necessarily take into account things like template instantiations, header inclusions (including those pulled in by precompiled headers) and the code generation characteristics of the compiler.
I've faced a similar problem in the past, with a large executable whose size was dominated by a particular library. The way I got to the bottom of it was simply to look at the size of the object files for each .cpp. That won't give you the full story as the linker will optimise out unused portions (though it's worth checking you've got that option set - /OPT:REF for Visual Studio). It will though allow you to focus your search. Find the two or three largest object files and then look at the corresponding .cpp files. You've then got two options - write a script that takes the output of objdump (VisualStudio) or nm -C (gcc) where you can extract the offsets of each function in the module, so you can diff each with the previous to get an idea of the size of each function.
Or the simplest method is just to use binary search on the cpp file. #ifdef out all the code after the end of the #includes and compile it. That will give you an idea of the overhead of the includes (if that itself is huge then you can drill down into the header inclusions to find which contributes the most). Next, disable each half the code with #ifdef and find which half is the larger. Using this method you can quickly find the functions that contribute most to the size of the library.
In the case of the library I had which had this same problem, the cause turned out to be a very large templated function that was instantiated every time a member variable was saved. The solution in that case was to make the function concrete so that all the code that didn't require type-specific behaviour is only instantiated once, and the template functions are localised for the bits of logic that are type-specific.
CppDepend give you this info, it's based on Clang and with CQLinq you can request your code as you want.
This is a potentially dangerous question because interdisciplinary questions and answers will be biased, but I'll have a stab at it anyway. All in good spirit!
So, here we go. I'm writing a major editing mode for Emacs for the language that it has almost no support for yet. And I'm at the point, where I have to decide on a way to generate project files. Below is the syllabus of the task ahead:
The templates have to represent project directory tree, not only single files.
The resulting files are of various formats, potentially including SGML-like languages, but not limited to this variety. They also have to generate C-like source code and, eLisp source code and plain text files, like README, for example.
The templates must be processed in a batch upon user-initiated action (as in user wants to create a project - several files must be created in the user-appointed directory). It may be beneficial to have an ability to supervise the creation, but this is less important then the ability to run the process entirely automatically.
Bonus features:
The template language has already a user base (with a potential of reuse of existing templates).
The templates can be used for code snippets (contain blanks which are filled interactively once the user invokes code-generating routine while editing the file).
Obvious things like cross-platform-ness, ease of use both through graphical interface and command line.
I made a research, but I won't share my results (yet) so I won't bias the answers. The problem with answering this question is not that the answer is hard to find, but that it is hard to chose one from many.
I'm developing a system based on Mustache for exactly the use case that you've described. The template language itself is a very simple extension of Mustache called Groome.
I also released a command-line tool called Molt that renders Groome templates. I'd be curious to know if it does everything that you need. I'm still adding features to the tool and haven't yet announced it. Thanks.
I went to solve a similar problem several years aback, where I wanted to use Emacs to generate code out of a UML diagram (cogre), and also generate Makefiles from project specifications. I first tried to use Tempo, but when I tried to get the templates to nest, I ran into problems. I also looked into skeleton, but that didn't quite fit the plan either.
I ended up using Google Templates for a little bit, and liked the syntax, and developed SRecode instead, and just borrowed the good bits from Google templates. SRecode was written specifically for machine-generated code. The interaction for template insertion (aka - what tempo was written for) isn't first class in SRecode. For generating code from a data structure, however, it is very robust, and has a lot of features, and automatically filled variables. It works closely with your major mode, and allows many nested templates, with control over the nested dictionary values. There is a subsystem that will use Semantic tags and generate code from them for a couple languages. That means you can parse code in one language with Semantic, and generate code in another language with SReocde using those tags. Nifty! Many parts of CEDET Reference manuals were built that way.
The templates themselves allow looping, if statements, and include statements. There are a couple examples in SRecode for making an 'application', such as the comment writer, and EDE uses it to create Makefiles, which is almost exactly what you are trying to do.
Another option is Generator, which offers “language-agnostic project bootstrapping with an emphasis on simplicity”. Installation requires Node.js and npm.
Generator’s emphasis on simplicity means it is very easy to learn how to make a template. Generator also saves you from having to reference templates by file paths – it looks for templates in ~/.generator.
However, there is no way to write README or LICENSE files for the template itself without those files being copied to the generated project. Also, post-generation commands written in the Makefile will be copied to the generated Makefile, even after they are no longer of use. Finally, the ad-hoc templating language doesn’t provide a way to escape its __lowercasevariables__ – though I can’t think of a language where that limitation would be a problem.
Rationale: In my day-to-day C++ code development, I frequently need to
answer basic questions such as who calls what in a very large C++ code
base that is frequently changing. But, I also need to have some
automated way to exactly identify what the code is doing around a
particular area of code. "grep" tools such as Cscope are useful (and
I use them heavily already), but are not C++-language-aware: They
don't give any way to identify the types and kinds of lexical
environment of a given use of a type or function a such way that is
conducive to automation (even if said automation is limited to
"read-only" operations such as code browsing and navigation, but I'm
asking for much more than that below).
Question: Does there exist already an open-source C/C++-based library
(native, not managed, not Microsoft- or Linux-specific) that can
statically scan or analyze a large tree of C++ code, and can produce
result sets that answer detailed questions such as:
What functions are called by some supplied function?
What functions make use of this supplied type?
Ditto the above questions if C++ classes or class templates are involved.
The result set should provide some sort of "handle". I should be able
to feed that handle back to the library to perform the following types
of introspection:
What is the byte offset into the file where the reference was made?
What is the reference into the abstract syntax tree (AST) of that
reference, so that I can inspect surrounding code constructs? And
each AST entity would also have file path, byte-offset, and
type-info data associated with it, so that I could recursively walk
up the graph of callers or referrers to do useful operations.
The answer should meet the following requirements:
API: The API exposed must be one of the following:
C or C++ and probably is "C handle" or C++-class-instance-based
(and if it is, must be generic C o C++ code and not Microsoft- or
Linux-specific code constructs unless it is to meet specifics of
the given platform), or
Command-line standard input and standard output based.
C++ aware: Is not limited to C code, but understands C++ language
constructs in minute detail including awareness of inter-class
inheritance relationships and C++ templates.
Fast: Should scan large code bases significantly faster than
compiling the entire code base from scratch. This probably needs to
be relaxed, but only if Incremental result retrieval and Resilient
to small code changes requirements are fully met below.
Provide Result counts: I should be able to ask "How many results
would you provide to some request (and no don't send me all of the
results)?" that responds on the order of less than 3 seconds versus
having to retrieve all results for any given question. If it takes
too long to get that answer, then wastes development time. This is
coupled with the next requirement.
Incremental result retrieval: I should be able to then ask "Give me
just the next N results of this request", and then a handle to the
result set so that I can ask the question repeatedly, thus
incrementally pulling out the results in stages. This means I
should not have to wait for the entire result set before seeing
some subset of all of the results. And that I can cancel the
operation safely if I have seen enough results. Reason: I need to
answer the question: "What is the build or development impact of
changing some particular function signature?"
Resilient to small code changes: If I change a header or source
file, I should not have to wait for the entire code base to be
rescanned, but only that header or source file
rescanned. Rescanning should be quick. E.g., don't do what cscope
requires you to do, which is to rescan the entire code base for
small changes. It is understood that if you change a header, then
scanning can take longer since other files that include that header
would have to be rescanned.
IDE Agnostic: Is text editor agnostic (don't make me use a specific
text editor; I've made my choice already, thank you!)
Platform Agnostic: Is platform-agnostic (don't make me only use it
on Linux or only on Windows, as I have to use both of those
platforms in my daily grind, but I need the tool to be useful on
both as I have code sandboxes on both platforms).
Non-binary: Should not cost me anything other than time to download
and compile the library and all of its dependencies.
Not trial-ware.
Actively Supported: It is likely that sending help requests to mailing lists
or associated forums is likely to get a response in less than 2
days.
Network agnostic: Databases the library builds should be able to be used directly on
a network from 32-bit and 64-bit systems, both Linux and Windows
interchangeably, at the same time, and do not embed hardcoded paths
to filesystems that would otherwise "root" the database to a
particular network.
Build environment agnostic: Does not require intimate knowledge of my build environment, with
the notable exception of possibly requiring knowledge of compiler
supplied CPP macro definitions (e.g. -Dmacro=value).
I would say that CLang Index is a close fit. However I don't think that it stores data in a database.
Anyway the CLang framework offer what you actually need to build a tool tailored to your needs, if only because of its C, C++ and Objective-C parsing / indexing capabitilies. And since it's provided as a set of reusable libraries... it was crafted for being developed on!
I have to admit that I haven't used either because I work with a lot of Microsoft-specific code that uses Microsoft compiler extensions that i don't expect them to understand, but the two open source analyzers I'm aware of are Mozilla Pork and the Clang Analyzer.
If you are looking for results of code analysis (metrics, graphs, ...) why not use a tool (instead of API) to do that? If you can, I suggest you to take a look at Understand.
It's not free (there's a trial version) but I found it very useful.
Maybe Doxygen with GraphViz could be the answer of some of your constraints but not all,for example the analysis of Doxygen is not incremental.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Where is it customary to write the in-code documentation of classes and methods?
Do you write such doc-blocks above the corresponding class/method in the header (.hpp) file, or within the source (.cpp) file?
Is there a widely respected convention for such things? Do most C++ projects do it one way rather than the other?
Or should documentation be written on the two sides (i.e. in the .hpp and the .cpp files), maybe with one short description one one side and a longer one on the other side?
Most importantly, are there any practical considerations that makes it more convenient to write it one way rather than the other way ? (E.g. the use of automatic documentation parsers and generators like Doxygen...)
Both:
Describe the API design and usage in the header: that's your public interface for clients.
Describe the implementation alternatives / issues and decisions in the implementation: that's for yourself - later - and other maintainers/enhancers, even someone reviewing the design as input to some next-gen system years hence.
Comment anything that's not obvious, and nothing that is (unless your documentation tool's too stupid to produce good documentation without).
Avoid putting implementation docs in the headers, as changing the header means makefile timestamp tests will trigger an unnecessary recompilation for client apps that include your header (at least in an enterprise or commercial library environment). For the same reason, aim to keep the header documentation stable and usable - good enough that you don't need to keep updating it as clients complain or ask for examples.
If you make a library, you typically distribute the compiled library and the header files. This makes it most useful to put documentation in the header files.
Most importantly, are there any
practical considerations that makes it
more convenient to write it one way
rather than the other way ?
Suppose that you want to add a clarification to one of your comments without changing the code. The problem is that your build system will only see that you changed the file, and unnecessarily assume that it needs to be recompiled.
If the comments are in the .cpp file, it will just recompile that one file. If the comments are in the .hpp file, it will recompile every .cpp file that depends on that header. This is a good reason to prefer having your comments in the .cpp files.
(E.g. the
use of automatic documentation parsers
and generators like Doxygen...)
Doxygen allows you to write your comments either way.
Again, both. As for the public documentation, it is nice to be in the .h with a format extractable with Doxygen, for example, as other commented. I like very much the Perl way of documenting things. The .pl (or .pm) file includes documentation in itself that can be extracted using a tool similar to what Doxygen does for C++ code. Also, Doxygen allows you to create several different pages, that allow you to include user manuals, etc., not just documenting the source code or API. I generally like the idea of a self-contained .h/.hpp file in the philosophy of literate programming.
I personally like documentation in the header files. However, there are some that believe that documentation should be put in the source files. The reason being that when something changes, the documentation is right there reminding you to update it. I somewhat agree, as I personally have forgotten to update the Doxygen comments in the header when I changed something in the source files.
I still prefer the Doxygen comments to be in the header file for aesthetic reasons, and old habits are hard to change. I've tried both and Doxygen offers the flexibility of documenting either in source or header files.