Does doxygen predefine any macros? - doxygen

Apart from the PREDEFINED configuration option, where I could always put DOXYGEN=1, does doxygen predefine any preprocessor macros prior to reading C++ files?
My train of thought is that GCC predefines macros such as __GNUC__, and MSC predefines macros such as _MSC_VER. Does doxygen predefine macros at all, such as _DOXYGEN_VER?
I don't want to use the PREDEFINED configuration option at all.

No, Doxygen does not predefine any self-identifying tokens.
If you don't want to litter your code with preprocessor #ifdef _DOXYGEN_VER / #endif blocks you can use the \cond command. The \cond command is an easier way to define sections that may be conditionally included/excluded similar to what you used to have to do with the C preprocessor tokens.

Related

Using C macros in Swift

Have my own macro defined in myProject.pch file,
For example:
#define Enable_Analytics
And i want to enclose few statements of code at multiple places inside
#ifdef Enable_Analytics
// Code statements which has to executed only if Enable_Analytics is defined
#endif
This is useful to include/remove code based on the macro.
In Objective-C this works but in swift i get error. How to use #ifdef in swift?
You can call the C preprocessor on just about and kind of file even if it is not C or a C like language.
It is usually available as cpp on most Unix like systems. Just run cpp your-file.swift and the C preprocessor should preprocess the file just as it would C.
However I do not know of a way to make the preprocessor use defines within a project file. So you probably will have to manually specify them on the command line like -DMACRO_NAME=somevalue.
Alternatively you could #include a file containing the defines within each of your swift files and the preprocessor will insert them.

`Is defining a macro via -D option ALWAYS equivalent to #define MACRO (except precedence)

I have a third party piece of code that works differently when I add a macro via Makefile e.g. -DMacro instead of doing #define MACRO in a top level header file
(which as their documentation implies is included in ALL files).
I Googled if there are any differences in defining it in different ways but could not come up with much except Precedence of -D MACRO and #define MACRO.
I am wondering if I am missing anything about make documentation / C standards before I start debugging and determining the issue.
Thanks for any answers.
Usually, it's exactly the same but neither make nor the ISO standard have anything to say about it. It's up to the compiler itself, some may not even have a -D option.
To make, it's just running the command (such as gcc) with whatever options it takes. ISO doesn't specify anything about how to run a compiler, just how the compiler (and the things it creates) behaves.
For gcc, the preprocessor options can be found here so it looks like it is identical to #define.

GNU Global and GTAGS can't find class definitions

I'm having trouble getting global to find class/struct definitions.
I can find them with exuberant ctags and with cscope.
All tag files are built from the same source file list.
I configured and built global, et.al., only specifying --prefix.
configure did find exhuberant and is using it.
I've been trying global periodically over the years and it's always had this problem.
Any ideas?
thanks,
davep
I've found out what I did wrong. Maybe this will help someone.
Just because configure finds exuberant ctags does not means that it makes it the default parser. My ex ctags doesn't support --gtags and maybe that's why. The default parser in my case was native/builtin.
The native parser treats .h as C only and does not look for C++ constructs. Oddly, it also does not find structs.
I found 2 fixes:
1) The best, if you have exuberant ctags, is to make it the default. The exuberant default configuration processes .h files properly. If it does not, use method 2. In .globalrc, change
default:\
:tc=native:
to
default:\
:tc=ctags:
2) If you do not have exuberant ctags, edit .globalrc and change the langmap line for the builtin-parser from
builtin-parser:\
:langmap=c\:.c.h,yacc\:.y,asm\:.s.S,java\:.java,cpp\:.c++.cc.hh.cpp.cxx.hxx.hpp.C.H,php\:.php.php3.phtml:
to
builtin-parser:\
:langmap=c\:.c,yacc\:.y,asm\:.s.S,java\:.java,cpp\:.c++.cc.hh.h.cpp.cxx.hxx.hpp.C.H,php\:.php.php3.phtml:
I.e. remove the association of .h with C and associate it with C++.
This may cause problems with C .h files. If so, you may need rename ALL C++ .h files to .hh, .hpp, .hxx, etc, as given in the langmap.
Based on my experience with C++, it looks like most people still use .h for their header files.
Just export this variable and that should pretty much do. From the man page for gtags -
GTAGSFORCECPP
If this variable is set, each file whose suffix is 'h' is treated as a C++ source file.

Tags for Emacs: Relationship between etags, ebrowse, cscope, GNU Global and exuberant ctags

I work on C++ projects, and I went through Alex Ott's guide to CEDET and other threads about tags in StackOverflow, but I am still confused about how Emacs interfaces with these different tag systems to facilitate autocompletion, the looking up of definitions, navigation of source code base or the previewing of doc-strings.
What is the difference (e.g. in terms of features) between etags, ebrowse, exuberant ctags, cscope, GNU Global and GTags? What do I need to do to use them in Emacs?
Do I need semantic/senator (CEDET) if I want to use tags to navigate/autocomplete symbols?
What does semantic bring to the table on top of these different tag utilities? How does it interface with these tools?
That's as a good question as I've recently read here, so I'll try explain the difference in more detail:
Point 1:
etags and ctags both generate an index (a.k.a. tag/TAGS) file of language objects found in source files that allows these items to be quickly and easily located by a text editor or other utility. A tag signifies a language object for which an index entry is available (or, alternatively, the index entry created for that object). The tags generated by ctags are richer in terms of metadata, but Emacs cannot interpret the additional data anyways, so you should consider them more or less the same (the main advantage of ctags would be its support for more languages). The primary use for the tags files is looking up class/method/function/constant/etc declaration/definitions.
cscope is much more powerful beast (at least as far as C/C++ and Java are concerned). While it operates on more or less the same principle (generating a file of useful metadata) it allows you do some fancier things like find all references to a symbol, see where a function is being invoked, etc (you can find definitions as well).
To sum it up:
ctags one allows you to navigate to symbol declaration/definitions (what some would call a one-way lookup). ctags is a general purpose tool useful for many languages.
On the other hand (as mentioned on the project's page) cscope allows you to:
Go to the declaration of a symbol
Show a selectable list of all references to a symbol
Search for any global definition
Functions called by a function
Functions calling a function
Search for a text string
Search for a regular expression pattern
Find a file
Find all files including a file
It should come as no surprise to anyone at this point, that when I deal with C/C++ projects I make heavy use of cscope and care very little about ctags. When dealing with other languages the situation would obviously be reversed.
Point 2.
To have intelligent autocompletion you need a true source code parser (like semantic), otherwise you won't know the types of the objects (for instance) in your applications and the methods that can be invoked on them. You can have an autocompletion based on many different sources, but to get the best results you'll ultimately need a parser. Same goes for syntax highlighting - currently syntax highlighting in Emacs major modes is based simply on regular expressions and that's very fragile and error prone. Hopefully with the inclusion of semantic in Emacs 23.2 (it used to be an external package before that) we'll start seeing more uses for it (like using it to analyse a buffer source code to properly highlight it)
Since Emacs 24.1 semantic is usable from the Emacs completion framework. The easiest way to test it is to open up a C source code file and typing M-TAB or C-M-i and watch as semantic automagically completes for you. For languages where semantic is not enabled by default, you can add it the following line to your major mode hook of choice:
(add-to-list 'completion-at-point-functions 'semantic-completion-at-point-function)
Point 3.
semantic brings true code awareness (for the few languages it currently supports) and closes the gap between IDEs and Emacs. It doesn't really interface with tools like etags and cscope, but it doesn't mean you cannot use them together.
Hopefully my explanations make sense and will be useful to you.
P.S. I'm not quite familiar with global and ebrowse, but if memory serves me they made use of etags.
I'll try to add some explanations to 1.
What is it?
Etags is a command to generate 'TAGS' file which is the tag file for Emacs. You can use the file with etags.el which is part of emacs package.
Ctags is a command to generate 'tags' file which is the tag file for vi. Universal Ctags, the successor of Exuberant Ctags, can generate 'TAGS' file by the -e option, supporting more than 41 programming languages.
Cscope is an all-in-one source code browsing tool for C language. It has own fine CUI (character user interface) and tag databases (cscope.in.out, cscope.out, cscope.po.out). You can use cscope from Emacs using xcscope.el which is part of cscope package.
GNU GLOBAL is a source code tagging system. Though it is similar to above tools, it differs from them at the point of that it is dependent from any editor, and it has no user interface except for command line. Gtags is a command to generate tag files for GLOBAL (GTAGS, GRTAGS, GPATH). You can use GLOBAL from emacs using gtags.el which is part of GLOBAL package. In addition to this, there are many elisp libraries for it (xgtags.el, ggtags.el, anything-gtags.el, helm-gtags.el, etc).
Comparison
Ctags and etags treat only definitions. Cscope and GNU GLOBAL treat not only definitions but also references.
Ctags and etags use a flat text tag file. Cscope and GNU GLOBAL use key-value tag databases.
Cscope and GNU GLOBAL have a grep like search engine and incremental updating facility of tag files.
Combination
You can combine Universal Ctags's rich language support and GNU GLOBAL's database facility by using ctags as a plug-in parser of GLOBAL.
Try the following: (requires GLOBAL-6.5.3+ and Universal Ctags respectively)
Building GNU GLOBAL:
$ ./configure --with-universal-ctags=/usr/local/bin/ctags
$ sudo make install
Usage:
$ export GTAGSCONF=/usr/local/share/gtags/gtags.conf
$ export GTAGSLABEL=new-ctags
$ gtags # invokes Universal Ctags internally
$ emacs -f gtags-mode # load gtags.el
(However, you cannot treat references by this method, because ctags don't treat references.)
You can also use cscope as a client of GNU GLOBAL. GLOBAL package includes a command named 'gtags-cscope' which is a port of cscope, that is, it is cscope itself except that it use GLOBAL as a search engine instead of cscope's one.
$ gtags-cscope # this is GLOBAL version of cscope
With the combinations, you can use cscope for 41 languages.
Good luck!
TAGS files contain definitions
A TAGS file contains a list of where functions and classes are defined. It is usually placed in the root of a project and looks like this:
^L
configure,3945
as_fn_success () { as_fn_return 0; }^?as_fn_success^A180,5465
as_fn_failure () { as_fn_return 1; }^?as_fn_failure^A181,5502
as_fn_ret_success () { return 0; }^?as_fn_ret_success^A182,5539
as_fn_ret_failure () { return 1; }^?as_fn_ret_failure^A183,5574
This enables Emacs to find definitions. Basic navigation is built-in with find-tag, but etags-select provides a nicer UI when there are multiple matches.
You can also uses TAGS files for code completion. For example, company's etags backend uses TAGS files.
TAGS files can be built by different tools
ctags (formerly known as 'universal ctags' or 'exuberant ctags') can generate TAGS files and supports the widest range of languages. It is actively maintained on github.
Emacs ships with two programs that generate TAGS files, called etags and ctags. Emacs' ctags is just etags with the same CLI interface as universal ctags. To avoid confusion, many distros rename these programs (e.g. ctags.emacs24 on Debian).
There are also language specific tools for generating TAGS files, such as jsctags and hasktags.
Other file formats
ebrowse is a C program shipped with Emacs. It indexes C/C++ code and generates a BROWSE file. ebrowse.el provides the usual find definition and completion. You can also open the BROWSE file directly in Emacs to get an overview of the classes/function defined a codebase.
GNU Global has its own database format, which consists of a GTAGS, GRTAGS and GPATH file. You can generate these files with the gtags command, which parses C/C++ code. For other languages, GNU Global can read files generated by universal ctags.
GNU Global also provides a CLI interface for asking more sophisticated questions, like 'where is this symbol mentioned?'. It ships with an Emacs package gtags.el, but ggtags.el is also popular for accessing GNU Global databases.
Cscope is similar in spirit to GNU Global: it parses C/C++ into its own database format. It can also answer questions like 'find all callers/callees of this funciton'.
See also this HN discussion comparing global and cscope.
Client/Server projects
rtags parses and indexes C/C++ using a persistent server. It uses the clang parser, so it handles C++ really well. It ships with an Emacs package to query the server.
google-gtags was a project where a large TAGS file would be stored on a server. When you queried the server, it would provide a subset of the TAGS file that was relevant to your search.
Semantic (CEDET)
Semantic is a built-in Emacs package that contains a parser for C/C++, so it can find definitions too. It can also import data from TAGS files, csope databases, and other sources. CEDET also includes IDE style functionality that uses this data, e.g. generating UML diagrams of class hierarchies.
[answer updated from shigio's]
I'll try to add some explanations to part 1 of the question.
What is it?
Etags generates a TAGS file which is the tag file format for Emacs. You can use an Etags file with etags.el which is part of Emacs.
Ctags is the generic term for anything that can generate a tags file, which is the native tag file format for Vi. Universal Ctags (aka UCtags, formerly Exuberant Ctags) can also generate Etags with the -e option.
Cscope is an all-in-one source code browsing tool for C (with lesser support for C++ and Java), with its own tag databases (cscope.in.out, cscope.out, cscope.po.out) and TUI. Cscope support is built-in to Vim; you can use Cscope from Emacs using the xcscope.el package. There are also Cscope-based GUIs.
GNU GLOBAL (aka Gtags) is yet another source code tagging system (with significant differences--see next section), in that it also generates tag files.
Comparison
Ctags and Etags treat only definitions (of, e.g., variables and functions). Cscope and Gtags also treat references.
Ctags and Etags tag files are flat. Cscope and Gtags tagfiles are more powerful key-value databases, which allows (e.g.) incremental update.
Cscope and Gtags have a grep-like search engine.
Ctags has built-in support for more languages and data formats: see the current-in-repository list of Universal Ctags parsers. UCtags also has documented how to develop your own parser.
Cscope and Gtags are editor-independent.
Gtags does not provide its own user interface, but can currently (Oct 2016) be used from commandline (CLI), Emacs and relatives, Vi and relatives, less (pager), Doxygen, and any web browser.
Gtags provides gtags.el via the GLOBAL package, but there are also many other elisp extensions, including xgtags.el, ggtags.el, anything-gtags.el, helm-gtags.el.
Combination
You can combine Universal Ctags' rich language support with Gtags' database facility and numerous extensions by using Ctags as a GLOBAL plug-in parser:
# build GNU GLOBAL
./configure --with-exuberant-ctags=/usr/local/bin/ctags
sudo make install
# use it
export GTAGSCONF=/usr/local/share/gtags/gtags.conf
export GTAGSLABEL=ctags
gtags # invokes Universal Ctags internally
emacs -f gtags-mode # load gtags.el
Note again that if you use Ctags as the parser for your Gtags, you lose the ability to treat references (e.g., variable usage, function calls) which Gtags would otherwise provide. Essentially, you trade off Gtags' reference tracking for Ctags' greater built-in language support.
You can also use Cscope as a client of Gtags: gtags-cscope.
Good luck!
I haven't actually checked, but according to CEDET manual (http://www.randomsample.de/cedetdocs/common/cedet/CScope.html):
semantic can use CScope as a back end for database searches. To enable it, use:
(semanticdb-enable-cscope-databases)
This will enable the use of cscope for all C and C++ buffers.
CScope will then be used for project-wide searches as a backup when pre-existing semantic database searches may not have parsed all your files.

C\C++ Preprocessor different arg for overloaded macros

I want to realize logging in my project.
I have macro, smth like
__LOG_TRACE(lg, expr,...) LOG_TRACE_STREAM(lg) << expr;
So I want to realize interface for this macro - another macro, but I want to support 2 types:
LOG_TRACE(msg);
LOG_TRACE(my_logger, msg);
I have some global logger, and first macro will write msg using global logger.
Second macro will take my_logger and write msg using it.
I can make it with LOG_TRACE(msg, my_logger); - but it's not good, it's harder to read in code. Order of arguments in __LOG_TRACE is not necessary.
Upd:
I don't mean overloading macros.
Look - for example I can do this
#define LOG_TRACE(...) __LOG_TRACE(__VA_ARGS__, current_active)
Now I can write
LOG_TRACE(msg);
LOG_TRACE(msg, logger);
But I want not msg,logger and logger,msg
Macro overloading is not allowed in C or C++. But there are workarounds. Here's an article that will help you "overload" your macro: http://cplusplus.co.il/2010/08/31/overloading-macros/
If you don't have a variable number of loggers, i recommend you to make a macro for each logger. ex (LOG_TRACE_XML, LOG_TRACE_OUT, LOG_TRACE_TXT). Because simpler is better.
But a better way to do this is to have LOG_TRACE_ERROR/ LOG_TRACE_WARNING/ LOG_TRACE_INFO and manage the way these macros behave using IPC or another macro (SET_MODE(XML/TXT/OUT))
You cannot overload pre-processor macros, your compiler will consider this a redeclaration, rather than an overload, and so only the 2nd will be valid.
You should attempt to name your macros differently, both for readability and because that's the only way you'll get the functionality you want.
Why not make it a function + do and stringify expression macro?
#define DO_AND_RETURN_STRING_EXPR(x) (x,#x)
ov(DO_AND_RETURN_STRING_EXPR(y))
ov(my_logger, DO_AND_RETURN_STRING_EXPR(y))
(note I haven't tested this code).
__VA_ARGS__ is an extension to the current C++ standard, but if you are willing to play with this P99 has a lot of utility macros to achieve what you want. In particular macros that implement conditionals according to the number of arguments they are called.
#define LOG_TRACE(...) \
P99_IF_EQ_1(P99_NARG(__VA_ARGS__)) \
(LOG_TRACE_(my_logger, __VA_ARGS__)) \
(LOG_TRACE_(__VA_ARGS__))
P99 is not really C++ compatible, so you'd have to adapt things a bit.
BTW, identifiers that start with _ and a capital letter or another underscore are reserved by C and C++. Double underscores in general are not allowed for C++ because they could interfere with name mangling. So you'd better chose a different name for your base macro.