GCC : "definition of BLAH is not in namespace enclosing" - c++

I'm trying to figure out something in VCVRack.
In Template.hpp
using namespace rack;
...
struct SlowSliderWidget : public OpaqueWidget {
void draw(NVGcontext *vg) override;
};
then in MyWidget.cpp
#include "Template.hpp"
namespace rack {
void SlowSliderWidget::draw(NVGcontext *vg) {
nvgBeginPath(vg);
nvgRect(vg, 0, 0, 100, 100);
nvgFill(vg);
}
} // namespace rack
This gives me the following compiler error :
g++ -Wsuggest-override -std=c++11 -DSLUG=Template -fPIC -I../../include -I../../dep/include -DVERSION=0.6.0 -MMD -MP -g -O3 -march=nocona -ffast-math -fno-finite-math-only -Wall -Wextra -Wno-unused-parameter -DARCH_LIN -c -o build/src/MyWidget.cpp.o src/MyWidget.cpp
src/MyWidget.cpp:6:43: error: definition of ‘void SlowSliderWidget::draw(NVGcontext*)’ is not in namespace enclosing ‘SlowSliderWidget’ [-fpermissive]
void SlowSliderWidget::draw(NVGcontext *vg) {
^
../../compile.mk:64: recipe for target 'build/src/MyWidget.cpp.o' failed
Now, searching around I find various complaints about this type of error in GCC.
But all of them seem to be about attempts to redefine the meaning of the same class name in the same namespace.
But if I understand my C++ here, I am NOT trying to redefine the name. I declare the name SlowSliderWidget and the SlowSliderWidget::draw in the Template.hpp file and I simply try to define the function body of draw in the MyWidget.cpp file.
So why am I getting an error message? The wording seems to imply I'm not in the same namespace. But in both files I am in namespace rack. Aren't I?

Related

wchar.h: error: '__FILE' was not declared in this scope' error with gcc 5.2.0

I am having trouble compiling code
before it ever gets to the linker. Can anyone point me in the right
direction?
Here is the very simple code of source to reproduce this issue.
// CpxCryptoIfSimClientC.cpp //
#include <iostream>
// end
Compilation command line:
powerpc64-wrs-linux-g++ -c -o CpxCryptoIfSimClientC.o -m64 --sysroot=/proj/platform_cs/linux/deliveries/sdk_install/sysroots/ppc64e6500-wrs-linux -ggdb -O3 -Wextra -Wall -DPOWERPC64 -DLNX -D_GNU_SOURCE -Os -fno-unit-at-a-time -pedantic -Wall -Wno-long-long `xml2-config --cflags` -std=gnu++98 -DINLINE=__inline__ -I../inc CpxCryptoIfSimClientC.cpp
Output:
In file included from /proj/platform_cs/linux/deliveries/sdk_install/sysroots/ppc64e6500-wrs-linux/usr/include/c++/5.2.0/cwchar:44:0,
from /proj/platform_cs/linux/deliveries/sdk_install/sysroots/ppc64e6500-wrs-linux/usr/include/c++/5.2.0/bits/postypes.h:40,
from /proj/platform_cs/linux/deliveries/sdk_install/sysroots/ppc64e6500-wrs-linux/usr/include/c++/5.2.0/iosfwd:40,
from /proj/platform_cs/linux/deliveries/sdk_install/sysroots/ppc64e6500-wrs-linux/usr/include/c++/5.2.0/ios:38,
from /proj/platform_cs/linux/deliveriessdk_install/sysroots/ppc64e6500-wrs-linux/usr/include/c++/5.2.0/ostream:38,
from /proj/platform_cs/linux/deliveries/sdk_install/sysroots/ppc64e6500-wrs-linux/usr/include/c++/5.2.0/iostream:39,
from ../../TestHelperStrategy_ppc64_linux/SimTestHelper.h:29,
from ../CpxCryptoIfSimClientC.h:25,
from ../CpxCryptoIfSimClientC.cpp:20:
/proj/platform_cs/linux/deliveries/sdk_install/sysroots/ppc64e6500-wrs-linux/usr/include/wchar.h:582:8: error: '__FILE' does not name a type
extern __FILE *open_wmemstream (wchar_t **__bufloc, size_t *__sizeloc) __THROW;
/proj/platform_cs/linux/deliveries/epb/epb_epb2_v1.52/sdk_install/sysroots/ppc64e6500-wrs-linux/usr/include/wchar.h:589:19: error: '__FILE' was not declared in this scope extern int fwide (__FILE *__fp, int __mode) __THROW;
/proj/platform_cs/linux/deliveries/epb/epb_epb2_v1.52/sdk_install/sysroots/ppc64e6500-wrs-linux/usr/include/wchar.h:589:27: error: '__fp' was not declared in this scope extern int fwide (__FILE *__fp, int __mode) __THROW;
and many similiar errors which are "undeclared in this scope".
Here I am using gcc version 5.2.0 for powerpc64. Is there anything wrong with wchar.h or any other header file with this gcc version? or am I missing any flag here?

C++ function not declared after DLL linkage with g++ at CentOS7

I am trying to link a dll with a very simple testing program, but I am getting an error, that I will describe at the end of the post.
frvt11.h - Interface (just relevant code) I need to implement to create my dll
namespace FRVT {
class Interface {
public:
static std::shared_ptr<Interface>
getImplementation();
}
}
implementation.h - Header of my implementation of Inteface
#include "frvt11.h"
namespace FRVT {
class Implementation : public FRVT::Interface {
public:
static std::shared_ptr<Interface>
getImplementation();
}
}
implementation.cpp - My implementation of Interface
UPDATE: change from Implementation::getImplementation to Interface::getImplementation
#include "implementation.h"
using namespace FRVT;
std::shared_ptr<Interface>
Interface::getImplementation() {
std::cout<<"getImplementation";
return std::make_shared<Implementation>();
}
main.cpp
UPDATE: Explicitly indicate the namespace Interface::
#include "frvt11.h"
using namespace FRVT;
int main(){
auto obj = Interface::getImplementation();
return 0;
}
compilation directives
UPDATE: include of -L/dll-directory where are all .h, .cpp and dll
g++ -std=c++11 -c -Wall -Werror -m64 -fPIC implementation.cpp
g++ -std=c++11 -shared -m64 -o libimplementation.so implementation.cpp
g++ -std=c++11 -Wall -m64 -o main main.cpp -L/dll-directory -limplementation
error
UPDATE: Original problem solved
main.cpp: In function 'int main()':
main.cpp:6:34: error: 'getImplementation' was not declared in this scope
auto obj = getImplementation();
How to solve this error? I was expecting that the linker would do the "magic" to say to main.cpp, that the implementation of referred function would be at the dll. What am I doing wrong?
At implementation.cpp I've changed from:
Implementation::getImplementation()
to:
Interface::getImplementation()
At main.cpp I've explicitly indicate the interface, like bellow:
auto obj = Interface::getImplementation();
And finally I've used the -L directive to indicate where was the the generated dll.

g++ warning about missing imlementation of pure virtual destructor

In CentOS 6.5, I have a class List like:
// list.hpp
namespace foo
{
class List
{
public:
virtual int reserveMem ( int size) = 0;
virtual int Insert ( int val) = 0;
virtual int Find ( int val) = 0;
virtual bool Empty() = 0;
};
}
It's part of the source code of a shared library. And I can build the whole library without any error or warning messages with g++ (version 4.4.7). The compiling flags used are
-g -fPIC -Wall -Wextra -Werror
Then we have another app which just includes a header file which includes this header file and got:
list.hpp:14: error: 'class List' has virtual functions and accessible non-virtual destructor
The warning message is valid. But g++ never complains about it when I build the library. Does anyone know why?
The warning is controlled by the -Wnon-virtual-dtor option, which is not included in -Wall or -Wextra. Presumably you are using different warning options to build the app and the library. Building the app seems to be done with -Wnon-virtual-dtor enabled, or maybe the -Weffc++ option which includes -Wnon-virtual-dtor
I consider that warning to be annoying and unhelpful, the -Wdelete-non-virtual-dtor is much more useful because it only warns if you actually try to delete a foo::List*, and is included in -Wall

Forcing GCC 4.x to treat -Wreturn-type as an error without enabling -Werror?

Suppose we have the following code:
#if !defined(__cplusplus)
# error This file should be compiled as C++
#endif
#include <stdio.h>
#include <string>
//#define USE_CXX_CLASS
#ifdef USE_CXX_CLASS
class SomeClass
{
public:
SomeClass() {}
~SomeClass() {}
std::string GetSomeString()
{
// case #1
}
};
#endif // USE_CXX_CLASS
int foo()
{
// case #2
}
int
main (int argc, char *argv[])
{
(void)argc;
(void)argv;
#ifdef USE_CXX_CLASS
SomeClass someInstance;
someInstance.GetSomeString();
#endif // USE_CXX_CLASS
foo();
return 0;
}
And suppose that it were to be compiled the C++ compiler (and not the C compiler) from GCC version 4.2.1 with the options -Wreturn-type -Werror=return-type. If the above code is compiled as is without first uncommenting the //#define USE_CXX_CLASS line above, then you will see a warning but no error:
.../gcc-4.2.1/bin/g++ -g -fPIC -Wreturn-type -Werror=return-type test.cpp -c -o test.o
test.cpp: In function 'int foo()':
test.cpp:26: warning: control reaches end of non-void function
But if the //#define USE_CXX_CLASS line is uncommented, then the warning is treated as an error:
.../gcc-4.2.1/bin/g++ -g -fPIC -Wreturn-type -Werror=return-type test.cpp -c -o test.o
test.cpp: In member function 'std::string SomeClass::GetSomeString()':
test.cpp:18: error: no return statement in function returning non-void [-Wreturn-type]
gmake: *** [test.o] Error 1
Yes, one is a non-member function (case #2), and the other is a C++ function (case #1). IMO, that should not matter. I want both conditions treated as an error, and I don't want to add -Werror or -Wall at this point in time (probably will do so later, but that is out of scope of this question).
My sub-questions are:
Is there some GCC switch that I am missing that should work? (No I do not want to use #pragma's.)
Is this a bug that has been addressed in a more recent version of GCC?
For reference, I have already poured through other similar questions already, including the following:
Why does flowing off the end of a non-void function without returning a value not produce a compiler error?
C question: no warning?
Is a return statement mandatory for C++ functions that do not return void?
It has been fixed, it works well with g++ 9.3: both member functions and free functions are treated as error with -Wall -Werror=return-type
I do see an error even w/o the USE_CXX_CLASS flag. i.e. g++ is consistent with the error for both class member functions and non member functions.
g++ (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
It seems to me that what you need is a shell script wrapper around gcc.
Name it something like gcc-wrapper and g++-wrapper.
In your Makefile set CC and CXX to the wrappers.
Have the wrapper invoke GCC and pipe its output to another program which will search for your desired warning strings.
Have the search program exit with an error when it finds the warning.

Compilation error while compiling an existing code base

While building an existing code base on Mac OS using its native build setup I am getting some basic strange error while compilation phase.
Does any of you have any idea, as I have seen it's been discussed earlier as well in this forum without any good reason. I can not see any conflicting files being included.
But still I am unable to compile the code because this error appears.
Source are like the code given below and compilation error appears
$ cat a.h
#include <string>
#include <sstream>
namespace brijesh {
typedef std::string String;
template<class T>
String toString(T value) {
std::ostringstream buffer;
buffer << value;
return buffer.str();
}
$ cat b.h
#include "a.h"
namespace brijesh {
class Platform {
public:
static String getName();
};
}
$ cat b.cpp
#include "b.h"
namespace brijesh {
String Platform::getName()
{
String name = "UNKNOWN";
#ifdef LINUX
name = "linux";
#endif
#ifdef MACOSX
name = "Mac";
#endif
return name;
}
}
flags used for compilation
g++ -c -o test.o -DRELEASE_VERSION -ggdb -arch ppc -mmacosx-version-min=10.4 -pipe -fpermiss ive -nostdinc -nostdinc++ -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3 .3 -I/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++ -I/Developer/SDKs/MacOS X10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/ppc-darwin -isystem /Developer/SDKs/MacOSX10.3.9. sdk/usr/include -F/Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks -Wreturn-type -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -Wall -Wno-multichar -Wno-unk nown-pragmas -Wno-long-double -fconstant-cfstrings -MP -MMD x.cpp
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/bits/locale_facets.h: In constructor 'std::collate_byname<_CharT>::collate_byname(const char*, size_t)':
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/bits/locale_facets.h:1072: error: '_M_c_locale_collate' was not declared in this scope
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/messages_members.h: In constructor 'std::messages_byname<_CharT>::messages_byname(const char*, size_t)':
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/messages_members.h:79: error: '_M_c_locale_messages' was not declared in this scope
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits: At global scope:
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits:897: error: 'float __builtin_huge_valf()' cannot appear in a constant-expression
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits:897: error: a function call cannot appear in a constant-expression
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits:897: error: 'float __builtin_huge_valf()' cannot appear in a constant-expression
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits:897: error: a function call cannot appear in a constant-expression
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits:899: error: 'float __builtin_nanf(const char*)' cannot appear in a constant-expression
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits:899: error: a function call cannot appear in a constant-expression
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits:899: error: 'float __builtin_nanf(const char*)' cannot appear in a constant-expression
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits:899: error: a function call cannot appear in a constant-expression
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits:900: error: field initializer is not constant
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/gcc/darwin/3.3/c++/limits:915: error: field initializer is not constant
It looks like you're trying to use OS X 10.3 developer tools (Xcode et al) and are trying to target OS X 10.4, which is obviously not going to work. Either change your build command to remove incompatible flags, such as -mmacosx-version-min=10.4, or upgrade to a more current version of OS X + Xcode + SDKs.