I'm using cpp to generate a configuration file for a window manager.
The configuration file syntax uses "#" to introduce comments,
the closest thing that I've found is
...
#ident "this is a comment"
...
that, when feed through cpp, generates
...
#ident "this is a comment"
...
but I'd like to get
...
# this is a comment
...
Is it possible?
I found a better solution w/r to #ident ...
#define coMMent(hash, c) hash c
...
coMMent(#, pippo si taglia)
...
gives
...
# pippo si taglia
...
(note the blank in first column) that is close enough.
I'm still interested in the perfect (no blanks) solution...
Related
Having seen Fossil's code [ https://fossil-scm.org/home/annotate?filename=src/schema.c&checkin=b03652382a327740 L27.. ]:
/*
** The database schema for the ~/.fossil configuration database.
*/
const char zConfigSchema[] =
# -- This file contains the schema for the database that is kept in the
# -- ~/.fossil file and that stores information about the users setup.
# --
# CREATE TABLE global_config(
# name TEXT PRIMARY KEY,
# value TEXT
# );
#
# -- Identifier for this file type.
# -- The integer is the same as 'FSLG'.
# PRAGMA application_id=252006675;
;
I'm wondering what is #... syntax is for. I have never seen it before, and I do not know how to call it to search the web for it. "string literal extensions in C" and various rephrasing of that yield no result.
Please consider leaving this question be, despite its triviality, for the purpose of better discoverability. Thanks.
From "BUILD.txt" of the project:
Most *.c source files are preprocessed using a program called
"translate". The sources to translate are found in src/translate.c.
A header comment in src/translate.c explains in detail what it does.
More information can be found directly in the referenced file, but it seems to be used to better handle CGI capabilities in C, particularly in generating HTML.
The synopsis provided in that "src/translate.c" is as follows:
** Input lines that begin with the "#" character are translated into
** either cgi_printf() statements or string literals and the
** translated code is written on standard output.
**
** The problem this program is attempt to solve is as follows: When
** writing CGI programs in C, we typically want to output a lot of HTML
** text to standard output. In pure C code, this involves doing a
** printf() with a big string containing all that text. But we have
** to insert special codes (ex: \n and \") for many common characters,
** which interferes with the readability of the HTML.
**
** This tool allows us to put raw HTML, without the special codes, in
** the middle of a C program. This program then translates the text
** into standard C by inserting all necessary backslashes and other
** punctuation.
What I understood from the documentation is that what is between %{ %} is inserted into the wrapper, what about %inline %{ %} ?
Is it the same? If it is not, what are the differences?
Maybe we can find many occurences of %inline %{ %} but only one occurence of %{ %}?
Thank you a lot!
You can have any number of occurrences of either types of block. The %{ ... }% just inserts what is in the block verbatim in the file generated by SWIG. It is used so that the generated file will compile, i.e. you normally put there whatever includes and defines and such that are required in order to get the generated file to compile.
OTOH, From the docs:
The %inline directive inserts all of the code that follows verbatim into the header portion of an interface file. The code is then parsed by both the SWIG preprocessor and parser.
So the %inline %{ ... %} does two things rather: it puts the declaration in the generated wrapper file, AND it causes SWIG to generate the wrapper code so that functions etc in the block can be called from the target language (Python, Lua, whatever). This is not the case for %{ ... }%: code in such block does not get wrapped, just gets dumped verbatim in the generated wrapper file.
Don't be afraid to open up the *_wrap.cpp that SWIG generates: put some easily searchable code in the two types of blocks and look at where they end up in the wrapper file, and what additional code got generated.
I have C function prototypes (certain windows api header files) that look like:
int
foo
(
int
a
,
int
*
b
)
;
(they seem to have no coding convention)
which I am trying to programmatically turn into a one-line prototype of the form (or something close to it):
int foo(int a, int * b);
I have looked into programs like ctags ( ctags multi-line C function prototypes ) and into various settings in uncrustify ( http://uncrustify.sourceforge.net/ ) however I haven't been able to make any headway in either. (any insight would be great, or perhaps one of the 385 uncrustify options that I missed does what I want).
Programmatically, I am trying to look for unique markers that signify a function prototype so that I can write a script that will format the code to my liking.
Without using a lexer and a parser this seems like it could get very convoluted very quickly; any suggestions?
run them through indent -kr or astyle --style=kr
Solution using vim?
put marker on int and do 11J
sed ':a;N;$!ba;s/\n/ /g' prototypes.file | sed 's/; */;\n/g'
The first command - before the pipe - will replace all new-lines to spaces, and the next will put a new-line back after every semicolon.
Of course this will only work if there are nothing else but these prototypes in the file. If there are some other stuff that you want to keep as they are, you can use vim's visual selection and two substitution commands:
Select the region you want to join, than
:s/\n/ /
Select the joined line and
:s/; */;\r/g
Another solution using vi:
do a regex search removing all newlines. Then take the resulting mess and do another regex search replacing each ; with ; \n\n. That should leave you with a list of prototypes with a line skipped between each one. Since we're marking the ends of the prototypes instead of the beginnings and all prototypes end the same way, we don't have to worry about not recognizing special cases.
I have this problem in a header macro expansion under Microsoft C Compiler Preprocessor:
custom.h
.
.
# define _OTHER_INCLUDE_DIR C:\3rdparty\usr\include
# define _3RD_PARTY_HEADERS(headername) <_OTHER_INCLUDE_DIR\headername>
.
.
With a header test:
headertest.h
.
.
#include _3RD_PARTY_HEADERS(stdint.h)
.
Microsoft C preprocessor expand second line like(custom.h):
#include <C:\3rdparty\usr\include\headername>
If I set :
# define _3RD_PARTY_HEADERS(headername) <_OTHER_INCLUDE_DIR\ headername>
The result is:
#include <C:\3rdparty\usr\include\ stdint.h>
How I can fix that?
It looks like you want to juxtapose your directory and your header name. You use ##, like this:
# define _3RD_PARTY_HEADERS(headername) <_OTHER_INCLUDE_DIR\\##headername>
Is there no way to have the \ character sequences to be represented differently? The problem is that this is an escape character for C and C++. C99 explicitly states
If the characters ', \, ", //, or /*
occur in the sequence between the <
and > delimiters, the behavior is
undefined.
(There is a similar phrase for "..." includes.)
and I imagine that for C++ there must be something similar. So maybe you just could use / and the compiler would replace them internally to refer to the correct file on your system.
You know, most compilers have a command-line argument to add to the include path... -I or /I most likely for the Microsoft one. One doesn't usually do what you're doing here, never mind whether or not you can make it work.
When I try to precompile a *.pc file that contains a #warning directive I recieve the following error:
PCC-S-02014, Encountered the symbol "warning" when expecting one of the following: (bla bla bla).
Can I somehow convince Pro*C to ignore the thing if it doesn't know what to do with it? I can't remove the #warning directive as it's used in a header file that I can't change and must include.
According to the Pro*C/C++ Programmer's Guide (chapter 5 "Advanced Topics"), Pro*C silently ignores a number of preprocessor directives including #error and #pragma, but sadly not #warning. Since your warning directives are included in a header file, you might be able to use the ORA_PROC macro:
#ifndef ORA_PROC
#include <irrelevant.h>
#endif
For some reason, Pro*C errors out if you try to hide a straight #warning that way, however.
use option parse=none with proc
You can't. Pro*C only knows #if and #include. My best advice would be to preprocess the file as part of your build process to remove stuff Pro*C won't like. Something like
grep -v -E '^#(warning|pragma|define)' unchangeable.h >unchangeable.pc.h
My other advice would be to avoid the abomination which is Pro*C, but I'm guessing you're stuck with it...
Jons Ericsons answer is correct.
There is a second circumstance where you may need to use that trick.
Some versions of Pro*c can't deal with include files that don't have a file extension.
The ORA_PROC constant is one workable solution to that problem as well.
/bin/make -f /css/hwmig/pcprg/proc9i32.mk PROCFLAGS="sqlcheck=SEMANTICS userid=cssd/india09" PCCSRC=bic I_SYM=include= pc1
proc sqlcheck=SEMANTICS userid=cssd/india09 iname=bic include=. include=/oracle/Ora92/precomp/public include=/oracle/Ora92/rdbms/public include=/oracle/Ora92/rdbms/demo include=/oracle/Ora92/plsql/public include=/oracle/Ora92/network/public
Pro*C/C++: Release 9.2.0.6.0 - Production on Tue Dec 2 14:05:38 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
System default option values taken from: /oracle/Ora92/precomp/admin/pcscfg.cfg
Syntax error at line 135, column 2, file /usr/include/standards.h:
Error at line 135, column 2 in file /usr/include/standards.h
warning The -qdfp option is required to process DFP code in headers.
.1
PCC-S-02014, Encountered the symbol "warning" when expecting one of the followin
g:
a numeric constant, newline, define, elif, else, endif,
error, if, ifdef, ifndef, include, line, pragma, undef,
an immediate preprocessor command, a C token,
The symbol "newline," was substituted for "warning" to continue.
Syntax error at line 30, column 7, file bic.pc:
Error at line 30, column 7 in file bic.pc
FILE fp;
......1
PCC-S-02201, Encountered the symbol "" when expecting one of the following:
; , = ( [
The symbol ";" was substituted for "*" to continue.
Error at line 0, column 0 in file bic.pc
PCC-F-02102, Fatal error while doing C preprocessing
Remove below two lines from /usr/include/standards.h
warning The -qdfp option is required to process DFP code in headers.
else
Modify /usr/include/standards.h.
Delete the line #warning The -qdfp option is required to process DFP code in headers. The proc does not support the #warning，just #else #if etc.