According to the manual YY_BUF_SIZE is 16K and we need to override it. However, the manual does not specify how to override it, nor could I find any command line option for this. Can someone please indicate how to change this. In the generated source YY_BUF_SIZE is defined as follows:
#ifndef YY_BUF_SIZE
#define YY_BUF_SIZE 16384
#endif
so there may be a way to override it before this.
In your own code, simply #define YY_BUF_SIZE to whatever value you want. As long as you compile your code so the compiler sees your definition first, the #ifndef guard will prevent the default value from being set.
Using -DYY_BUF_SIZE=99999 (for whatever number, of course) on the command line is the only way to completely override the value, it seems to me.
The built-in flex skeleton/preamble precedes any %{...%} code given in the first (definitions) section of the .l source, and the skeleton is where the #ifndef YY_BUF_SIZE is. Therefore, to override within the .l file, it's best (to avoid possible warnings, etc.) to do
#undef YY_BUF_SIZE
#define YY_BUF_SIZE 99999
The potential pitfall of doing the override this way is that the skeleton also has the line
#define YY_STATE_BUF_SIZE ((YY_BUF_SIZE + 2) * sizeof(yy_state_type))
and therefore that value will not be affected by the redefinition. In my case that did not matter, but it's something to be aware of.
Unfortunately there is no way, as far as I know, to insert code before the built-in preamble. If there is, I'dbe grateful to learn.
Related
I'd like for the clang-format to check that each of my headers have the proper include guard.
For example, for the file dopelib/dopestuff/whatitisyo.h, I'd like the code to be formatted like this:
#ifndef DOPELIB_DOPESTUFF_WHATITISYO_H
#define DOPELIB_DOPESTUFF_WHATITISYO_H
/** Code here. **/
#endif // DOPELIB_DOPESTUFF_WHATITISYO_H
Can clnag-format check this structure and make sure that the include guard is there and that it is named appropriately with the file name in the #ifndef (sort of what cpplint does)?
As far as I know, clang-format doesn't currently support this.
However, you can do exactly this with clang-tidy (documented here). Invoke it like this:
clang-tidy -checks='-*,llvm-header-guard' -fix-errors myIncludeFile.h
Explanation:
The -* tells clang-tidy to disable all checks
The llvm-header-guard tells clang-tidy to enable the check which deals with include guards (documented here)
The -fix-errors tells clang-tidy to fix any resulting issues, even if it runs into other errors parsing the file
The llvm-header-guard expected format of the include-guards is exactly what you requested above; for example the file mydir/myfile.h would use MYDIR_MYFILE_H. I don't see any documentation which actually specifies that this is the format it uses, but I've verified at least version 6.0.0 does use that format.
Also see: clang include fixer, which does something similar.
The accepted solution may not work if
The project has a different file structure
Uses some extensions that clang does not understand
I have a script here: https://github.com/milasudril/texpainter/blob/master/devtools/include_guard_fix.py
I'm developing a C/C++ library that uses ImageMagick (using/supporting both libMagickCore and libMagick++), for reading and writing image data (not for processing).
Now, I would also like to support IM's GraphicsMagick fork (e.g. using Debian's graphicsmagick-libmagick-dev-compat package).
Unfortunately, the APIs have diverged enough, so that I cannot use one as a drop-in replacement of the other. Since they are still quite similar, I plan to use a number of #ifdefs for the API specific parts.
Now my problem is, that it seems quite complicated to detect which API is actually used via pre-processor directives, right after including the generic header (which is called the same for both variants).
Basically, I'm looking for something like a #define (provided by the IM/GM headers) that can be used to tell the two APIs apart. Something like:
#include <Magick++.h>
#ifdef GRAPHICSMAGIC_DEFINE
// GM-specific code
#else
// IM-specific code
#endif
or, for the C-API:
#include <magick/MagickCore.h>
#ifdef GRAPHICSMAGIC_DEFINE2
/* GM-specific code */
#else
/* IM-specific code */
#endif
Ideas?
Autoconf, or CMake.
Really - there's no simpler way around it, but you need to package your solution with something that will ask the system what library is present, and will then generate config.h with the correct pre-processor definitions.
The difference between GraphicsMagick & ImageMagick seem simple enough to do something clever, BUT now that we're a year into the release of IM 7, we now need to check which version & adjust definitions as needed. For example
// IM 6
#include <magick/MagickCore.h>
// IM 7
#include <MagickCore/MagickCore.h>
I would suggest reviewing existing m4 scripts used by other projects available online.
So back to the original question, the generic include headers my look something like this... (and I quote from Imagick library, but can be expanded to cover GM)
#if defined (IM_MAGICKWAND_HEADER_STYLE_SEVEN)
# include <MagickWand/MagickWand.h>
#elif defined (IM_MAGICKWAND_HEADER_STYLE_OLD)
# include <wand/magick-wand.h>
#else
# include <wand/MagickWand.h>
#endif
flex yy_fatal_error exist just like that. But I want handler back to my application. How to avoid exist call? from yy_fatal_error. whether this problem addressed in any version? your suggestion is highly appreciated. help me on this issues.
You can override the function, by #defineing your own. Note that in the generated code there is
/* Report a fatal error. */
#ifndef YY_FATAL_ERROR
#define YY_FATAL_ERROR(msg) yy_fatal_error( msg )
#endif
If you #define the macro YY_FATAL_ERROR(msg) to call your own function, the lexer will call that function rather than the one from the template.
However, the lexer template is written to assume that this function does not return. You can make it do that by using setjmp and longjmp to prepare a predictable place to return in your application and jumping back (from your own yy_fatal_error function) to that when a "fatal" error is used.
vi like emacs does this for instance, because it uses lexers for syntax highlighting. If a fatal error is generated by the lexer, you would not want the editor to stop.
Here are a few links discussing setjmp and longjmp:
Practical usage of setjmp and longjmp in C
setjmp and longjmp - understanding with examples
I have a few projects that share a lot of common code, but sometimes I need to not include certain parts of the common code depending on the project.
I've tried creating a separate file called project_names.hh, containing this:
// list of project names
#define FIRSTPROJECT 0
#define SECONDPROJECT 1
// PROJECT_NAME must be set to one of the above names in the project's main.cc file
#define PROJECT_NAME
Then in one of the projects' main files I do this:
#define PROJECT_NAME FIRSTPROJECT
The problem is that even though I include project_names.hh in another file, I can't seem to get this statement to compile:
#if PROJECT_NAME == FIRSTPROJECT
I get this error:
error: operator '==' has no left operand
Does anyone have a good way to do this?
Thanks!
Marlon
That's because you've defined PROJECT_NAME to be the empty string with your line
#define PROJECT_NAME
you want to change it to
#define PROJECT_NAME FIRSTPROJECT
This needs to be in a header file that all the files of that project #include.
Alternatively, you could get rid of the #define PROJECT_NAME and instead use
-DPROJECT_NAME=FIRSTPROJECT on the compiler command line for all the files in that project. Note that if the same file is used in multiple projects, you'll need to compile it mulitple times with different options, and have it put the output in different places...
If I were in your situation I would simply define either FIRSTPROJECT or SECONDPROJECT instead of setting PROJECT_NAME to either of those values. I would then use #ifdef to check whether that value is set.
rather than #define PROJECT_NAME FIRSTPROJECT,
use #define FIRSTPROJECT,
then check its existence with #ifdef FIRSTPROJECT
You should include project_names.hh in the file in which you're running the #if PROJECT_NAME == FIRSTPROJECT. The preprocessor might not have loaded and executed the statements setting PROJCET_NAME in the first place.
This is most probably because the PROJECT_NAME isn't set. You should check, which file is being compiled and check if the #define is set there.
It might help to set the define as a compiler option for the whole building process. For most compilers that I know (gcc, MSVC, clang, xlC), the compiler option would be
-DPROJECT_NAME=FIRSTPROJECT
This isn't really clearly documented, but a shallow search reveals that RIM's RAPC compiler does support preprocessor statements (with some project file modification).
We've been using the simple #ifdef, #else, and #endif directives for quite some time now, as supporting platforms 4.1 through 4.7 with one code base is nearly impossible without them, but I began wondering recently if there are other supported directives which aren't quite as well documented; something akin to C's #elif for example, or even rudimentary equivalency directives?
Here's a complete listing of commands for the RAPC preprocessor. The preprocessor's not very robust, but that's on purpose.
//#preprocess - Used to specify that the file should be preprocessed. It must be the first line of the file.
//#implicit tag - This needs to be on the second line of the file. If tag is part of the command line, then the whole file should be compiled. If not, then it should be excluded.
Then there's the //#ifdef tag ... #else ... #endif and the //#ifndef tag ... #else ... #endif directives that you mentioned.
Also note, there is no nesting of preprocessed blocks and no macros.
RIM Help Center Doc:
http://docs.blackberry.com/en/developers/deliverables/21065/Specifying_preprocessor_directives_657636_11.jsp