top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

GNU "cpp -P" portability

0 votes
422 views

Is "cpp -P" POSIX? I poked around at

http://www.opengroup.org/onlinepubs/**********

and could find only matches to "preprocessor" rather than "cpp" in the search facility, and so surmise "no", but thought i'd ask here anyway. I suppose a portable workaround would be:

cpp FILENAME | sed '/^#/d'

but have fingers crossed nonetheless...

posted Jun 8, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+1 vote
 
Best answer

No, it's much the same as gcc -P, as far as I could tell by looking it up.

answer Jun 8, 2013 by anonymous
0 votes

No "cpp -P" is not POSIX, it's much the same as gcc -P, as far as I could tell by looking it up.

answer Jun 10, 2013 by anonymous
Similar Questions
+2 votes

GCC gives a warning for this program:

int main()
{
    int x;
}

test.cpp: In function 'int main()':
test.cpp:3:9: warning: unused variable 'x' [-Wunused-variable]

If I add an "unused" attribute with the GNU syntax:

int x __attribute__((unused));

the warning goes away.

However, if I use the C++11 syntax:

int x [[unused]];

the warning remains, and I also get:

test.cpp:3:20: warning: 'unused' attribute directive ignored [-Wattributes]

Does anyone know about gcc plans to support the attributes with C++11 syntax.

0 votes

is it possible to add a private extension to the core language (C/C++) by writing a gcc plugin?

The extension in mind is something like this

[variable_definitions;]

Later I want this be possible also inside statement headers, for example

for ([double d = 1.0; bool f = false;] size_t i = 0; i < vec.size(); ++i)
 ...

The scope of the so-defined variables shall be the same scope they are in, ie. in the for-loop case just the scope of the for-loop itself, much like the case with i.

0 votes

I have the following operator delete replacements:

void operator delete[](void* p)
{
 /* Implementation does not matter. */
}

void operator delete[](void* p, std::size_t size)
{
 /* Implementation does not matter. */
}

My question is why, in the following code, GCC 6.2 calls void operator delete[](void*) and not the second replacement:

char* str = new char[14];
delete[] str;

According to 5.3.5 Delete [expr.delete]:
(10.3) If the type is complete and if, for the second alternative (delete array) only, the operand is a pointer to a class type with a non-trivial destructor or a (possibly multi-dimensional) array thereof, the function with a parameter of type std::size_t is selected.

Therefore, I believe operator delete[](void*, std::size_t) must be called, doesn't it?

+1 vote

I wanted to ask what is the GCC C++ equivalent implementation of Windows _ MyFirst and _MyLast vector pointers?

These give direct access to the vectors first and last element, but they are not present in the GCC implementation of the vector class.

+1 vote

I have an oversight in my code where I'm declaring & defining a function
with C-linkage, though it's not possible.

Example snippet:

#ifdef __cplusplus
extern "C"
{
#endif

// ... some functions which are compatible with C linkage

// Intended to be a helper function not exposed from library
std::string GetEngineVersion()
{
 // ...
}

#ifdef __cplusplus
}
#endif

Obviously the GetEngineVersion function cannot have C linkage because it returns a C++ class.

My question is: does GCC have a warning for this scenario? Specifically, can it warn when something is declared extern "C" that's incompatible with C linkage?

I compile with the following warning flags and I didn't get a warning:

-Wall -Wunused-parameter -Wextra -Weffc++ -Wctor-dtor-privacy
-Wnon-virtual-dtor -Wreorder -Wold-style-cast -Woverloaded-virtual
-Werror

Incidentally, when I compile the same code in VS2013 I get this warning:

warning C4190: 'GetEngineVersion' has C-linkage specified, but returns UDT 'std::basic_string' which is incompatible with C
...