I encounter this error when I am trying to compile a c++ code via a Makefile.
error: expected initializer before ':' token
I have checked the compatibility of the compiler of my system
I also checked the paths etc. I also did some test; such as adding a semicolon after the 2nd declaration of class but didnt work. I have little to no experience with c++, the script is not even written by me; it is part of vtk library (Visualisation toolkit). Part of the script from where
the error generates is:
#ifndef __vtkProcessObject_h
#define __vtkProcessObject_h
#include "vtkAlgorithm.h"
class vtkDataObject;
class VTK_FILTERING_EXPORT vtkProcessObject : public vtkAlgorithm
{
public:
vtkTypeRevisionMacro(vtkProcessObject,vtkAlgorithm);
void PrintSelf(ostream& os, vtkIndent indent);
I get the error in line 8.
Probably it is something really straightforward, but as I said I have no clue how this language works.
The VTK_FILTERING_EXPORT macro is defined in a header, and is largely there for Windows and/or GCC symbol visibility. You don't mention what version of VTK you are compiling, but using CMake to generate the Makefiles would ensure the correct include paths are set up. If this is Linux, and the GCC visibility functionality has not been activated you could define the macro to nothing, but I suspect you would hit many other issues once you got past this point in the compilation.
Related
So I am trying to compile this flip fluids addon with blender, so I followed this tutorial, https://www.youtube.com/watch?v=TVKM1egDoGs , So I first ran cmake.exe -G "MinGW Makefiles" .. and it was telling me that it was missing a CMakeLists File... So I added one... then I ran cmake.exe --build . and it got to 3 percent than showed me errors like ...
In file included from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/threadutils.h:29,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshlevelset.h:65,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshobject.h:30,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/fluidsimulation.h:38,
from C:\Users\N\Downloads\Blender-FLIP-Fluids-master\src\engine\c_bindings\fluidsimulation_c.cpp:25:
C:/PROGRA~2/MINGW-~1/I686-8~1.0-P/mingw32/lib/gcc/i686-w64-mingw32/8.1.0/include/c++/mutex:93:9: note: previous definition of 'class std::recursive_mutex'
class recursive_mutex : private __recursive_mutex_base
^~~~~~~~~~~~~~~
In file included from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/mingw32_threads/mingw.condition_variable.h:25,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/threadutils.h:31,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshlevelset.h:65,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshobject.h:30,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/fluidsimulation.h:38,
from C:\Users\N\Downloads\Blender-FLIP-Fluids-master\src\engine\c_bindings\fluidsimulation_c.cpp:25:
C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/mingw32_threads/mingw.mutex.h:142:44: error: conflicting declaration 'typedef class std::_NonRecursive<std::recursive_mutex> std::mutex'
This is the full error https://pastebin.com/KTnALG1E, where is this coming from?? is it a mingw error or what? Can someone help please?
Your full error message includes a more interesting bit:
C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/mingw32_threads/mingw.thread.h:32:2:
error: #error This version of MinGW seems to include a win32 port of
pthreads, and probably already has C++11 std threading classes
implemented, based on pthreads. It is likely that you will get class
redefinition errors below, and unfortunately this implementation can
not be used standalone and independent of the system header,
since it relies on it for std::unique_lock and other utility classes.
If you would still like to use this implementation (as it is more
lightweight), you have to edit the c++-config.h system header of your
MinGW to not define _GLIBCXX_HAS_GTHREADS. This will prevent system
headers from defining actual threading classes while still defining
the necessary utility classes.
So either install a different version of mingw or edit your mingw files according to the instructions above.
So, I built boost with the following script conveniently posted by toma
and it compiles and I can add the respective frameworks in Xcode6 to my iOS target and my OSX target.
It runs properly on iOS, but when I try compiling on OSX I get errors in has_binary_operator.hpp in the following lines:
template < typename Lhs, typename Rhs >
struct operator_exists {
static ::boost::type_traits::yes_type check(has_operator); // this version is preferred when operator exists
static ::boost::type_traits::no_type check(no_operator); // this version is used otherwise
BOOST_STATIC_CONSTANT(bool, value = (sizeof(check(((make<Lhs>() BOOST_TT_TRAIT_OP make<Rhs>()),make<has_operator>())))==sizeof(::boost::type_traits::yes_type)));
};
Error messages:
.../boost.framework/Headers/type_traits/detail/has_binary_operator.hpp:155:42: Expected member name or ';' after declaration specifiers
.../boost.framework/Headers/type_traits/detail/has_binary_operator.hpp:156:41: Expected member name or ';' after declaration specifiers
Screenshot:
PS: My stdlib is libc++ and I want to use C++11 and Clang in both iOS and MacOSX. I mean it works perfectly for iOS, so why is it not working with the MacOSX target?!?
Quickfix:
Undefining 'check' seems to solve the error, as this seems to be a keyword reserved on MacOSX. Still it seems a weird solution to just undefine an OSX keyword, wouldn't this cause problems later?
#undef check
#include <boost/multi_array.hpp>
check is not a keyword, but an unfortunately named macro in a file supplied by Apple.
This has been an ongoing problem for boost (and other library vendors) for many years.
The header file <AssertMacros.h> is where this macros is defined.
See https://svn.boost.org/trac/boost/ticket/2115 for some history on this.
The latest version of this file (that Apple ships with the 10.9 SDK) contains the following text:
Prior to Mac OS X 10.6 the macro names used in this file conflicted with some
user code, including libraries in boost and the proposed C++ standards efforts,
and there was no way for a client of this header to resolve this conflict. Because
of this, most of the macros have been changed so that they are prefixed with
__ and contain at least one capital letter, which should alleviate the current
and future conflicts. However, to allow current sources to continue to compile,
compatibility macros are defined at the end with the old names. A tops script
at the end of this file will convert all of the old macro names used in a directory
to the new names. Clients are recommended to migrate over to these new macros as
they update their sources because a future release of Mac OS X will remove the
old macro definitions ( without the double-underscore prefix ). Clients who
want to compile without the old macro definitions can define the macro
__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES to 0 before this file is
included.
So, you could add -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 to your build commands to fix this problem.
Alternately, you could get a newer version of boost, where those calls have been renamed from check to s_check.
I am working with Code::Blocks and C++ GNU GCC and trying to port my Visual Studio Project to GNU GCC.
And while I am trying to compile I get stuck with my define macro from a Defines.h file:
#define out &
And when compiling I get this error:
error: expected unqualified-id before '=' token
On this line:
// Open for output. Default for #c ofstream and fstream.
static const openmode out = _S_out;
In ios_base.h
As I know, that file is a part of a libstd library. Can I disable it? If so, how can I do that?
My library doesn't requiring any std c++, just c library.
There are two main options:
Don't define a macro using the word out.
Declare the macro after you include all of your headers.
But seriously, a macro named out that becomes & is a pretty awful macro. It's going to make it difficult to understand the code very quickly.
I've recently started diving into the code of an open source project, which is largely written in C++. I'm using Eclipse 3.8 in Ubuntu 12.10.
THE PROBLEM:
Eclipses is incorrectly flagging fields as unresolved because of a particularly elaborate convention used to separate field declarations out of the header files.
someclass.h
class SomeClass
{
public:
#define MACRO_CLASS_PARAM(Name) SomeType m_##Name;
#include "fields.h"
#undef MACRO_CLASS_PARAM
};
fields.h
MACRO_CLASS_PARAM(Field1)
MACRO_CLASS_PARAM(Field2)
...
Now in the cpp file, if I want to do something like instanceOfSomeClass.Field1 Eclipse will flag it as an error with "Field 'Field1' could not be resolved".
THE QUESTION: Is there any way to get Eclipse to correctly handle this situation?
The inability to correctly process #include statements that are not at global scope is a long-standing deficiency in Eclipse's indexer.
Things you could do about it:
Revise your code to avoid this pattern. Once the textual header inclusion model is superseded by C++ Modules, it's going to be invalid anyways.
Contribute a fix for this deficiency to Eclipse CDT.
Use a different IDE that can parse this pattern. (I don't know of one off the top of my head, but I also haven't spent a lot of time looking.)
I have the following very simple application that compiles and runs fine:
EDIT: changed the example to be simpilar to end confusion of the real issue
int main() {
return 0;
}
As soon as I add #include <string> (and not even reference std::string), it fails to compile and I get the following error:
/usr/include/c++/4.1.2/bits/allocator.h:82 error: expected template-name before '<' token
Along with about 456 other, similar errors.
Any ideas? Thanks!
UPDATE:
Line 82 of /usr/include/c++/4.1.2/bits/allocator.h references the template __glibcxx_base_allocator at the location of the error. That template is defined in bits/c++allocator.h. When I search the system for that file, I get 3 hits, but none of them are in /usr/include/c++/4.1.2/bits/ as one would expect.
I have version 3.1.6, 4.1.1, and 4.3.2, but not 4.1.2 as the rest of the includes I am using. I am not sure which one is being used (if any, however, I don't get any error for an unknown file), but it seems the problem may stem from this.
The problem appears to be the installed development packages are not correct or incomplete (not to be confused with corrupt). Forcing g++ to use different include versions corrects that:
g++ -nostdic++ hello.cc -o hello -I/usr/include/c++/3.4.6
All the alternative directories (4.1.1, 4.1.2 and 4.3.2) are incomplete causing inappropriate files to be included causing the unusually errors. For example:
/usr/include/c++/4.1.2/bits/allocator.h requires __glibcxx_base_allocator located in bits/c++allocator.h which is being included from either /usr/include/c++/4.1.1 or /usr/include/c++/4.3.2 and appear to be incompatible. Forcing the compiler to use the only complete set of includes rectifies this.
Almost certainly g++ is detecting .cc as a C source file, not C++ and passes it through to gcc instead of compiling as C++. You can easily test by renaming your file to hello.C. There's also a language parameter to g++ you can use.
EDIT: This seems to work fine in g++ 4.2 with a .cc extension so that might not be it. Do you have any other headers included you aren't showing us? They could be interfering with <string>.
EDIT2: Alternatively your headers might not be set up right. Does this work:
#include <string>
int main()
{
return 0;
}
Errors like this have been heard of to occur when the C++ standard library headers are corrupted/not fully installed – maybe there is even a message referring to a missing include among your 456 other errors.
In any case, make sure that libstdc++-devel, resp. the package containing the C++ standard library header files of your distribution, is properly installed.
Check your include path. The paths can be specified as environment variables or specified on the command line. You could be using an include file from a different compiler or different version of the same compiler.
Also, try using <cstdio> rather than <stdio.h>.
Another suggestion: change <> to "".
This could be error caused at preprocess stage. Just preprocess your cpp file by passing flag -E to gcc and Look at the place the compiler complains.