Hiho,
I have implemented a singleton class in C++ which has got a problem with an initialization within its constructor where I try to initialize a member with a custom constructor but instead the compiler thinks I want to call the default constructor (without arguments) and (of course) can't find it as I don't need a default constructor for that class.
Here is the code:
class CionTokenTypes final {
private:
CionTokenTypes();
TokenType init_tt(TokenType token_type, bool skipped = false);
std::vector<TokenType> m_all_token_types;
std::vector<TokenType> m_skipped_token_types;
static const CionTokenTypes c_instance;
public:
CionTokenTypes(CionTokenTypes const&) = delete;
CionTokenTypes(CionTokenTypes &&) = delete;
static CionTokenTypes const& get_instance();
std::vector<TokenType> const& get_all() const;
std::vector<TokenType> const& get_skipped() const;
TokenType const my_custom_token_type;
};
Here is the source file:
const CionTokenTypes CionTokenTypes::c_instance = {};
TokenType CionTokenTypes::init_tt(
TokenType token_type,
bool skipped
) {
m_all_token_types.push_back(token_type);
if (skipped) {
m_skipped_token_types.push_back(token_type);
}
return std::move(token_type);
}
CionTokenTypes const& CionTokenTypes::get_instance() {
return c_instance;
}
std::vector<TokenType> const& CionTokenTypes::get_all() const {
return m_all_token_types;
}
std::vector<TokenType> const& CionTokenTypes::get_skipped() const {
return m_skipped_token_types;
}
CionTokenTypes::CionTokenTypes():
m_all_token_types{},
m_skipped_token_types{},
my_custom_token_type{init_tt({"bracket: closing bracket ]", "\\]"})}
{}
And you might also want to see the TokenType class:
class TokenType final {
public:
enum class MatchType : uint8_t {
non_greedy,
greedy
};
TokenType(
std::string const& name,
std::string const& regex = "",
TokenTypeStore store_type = TokenTypeStore::empty,
MatchType match_type = MatchType::non_greedy);
TokenType() = delete;
TokenType(TokenType const& other) = default;
TokenType(TokenType && other) = default;
TokenType & operator=(TokenType const& other) = default;
TokenType & operator=(TokenType && other) = default;
};
And its source file:
TokenType::TokenType(
std::string const& name,
std::string const& regex,
TokenTypeStore store_type,
TokenType::MatchType match_type
):
m_data{
std::make_shared<TokenType::Data>(
name,
regex,
store_type,
match_type
)
}
{}
I have cut out the not important parts as these files would have been just too huge for a complete paste at StackOverflow.
The compiler error:
/home/robbepop/coding/c++/projects/cion/src/token/cion_token_types.cpp: In constructor ‘cion::CionTokenTypes::CionTokenTypes()’:
/home/robbepop/coding/c++/projects/cion/src/token/cion_token_types.cpp:207:69: error: use of deleted function ‘cion::TokenType::TokenType()’
closing_brack {init_tt({"bracket: closing bracket ]" , "\\]"})}
^
In file included from /home/robbepop/coding/c++/projects/cion/include/token/cion_token_types.hpp:4:0,
from /home/robbepop/coding/c++/projects/cion/src/token/cion_token_types.cpp:1:
/home/robbepop/coding/c++/projects/cion/include/token/token_type.hpp:56:3: note: declared here
TokenType() = delete;
^
/home/robbepop/coding/c++/projects/cion/src/token/cion_token_types.cpp:207:69: error: use of deleted function ‘cion::TokenType::TokenType()’
closing_brack {init_tt({"bracket: closing bracket ]" , "\\]"})}
^
In file included from /home/robbepop/coding/c++/projects/cion/include/token/cion_token_types.hpp:4:0,
from /home/robbepop/coding/c++/projects/cion/src/token/cion_token_types.cpp:1:
/home/robbepop/coding/c++/projects/cion/include/token/token_type.hpp:56:3: note: declared here
TokenType() = delete;
^
src/CMakeFiles/cion_compiler.dir/build.make:1066: recipe for target 'src/CMakeFiles/cion_compiler.dir/token/cion_token_types.cpp.o' failed
make[2]: *** [src/CMakeFiles/cion_compiler.dir/token/cion_token_types.cpp.o] Error 1
CMakeFiles/Makefile2:75: recipe for target 'src/CMakeFiles/cion_compiler.dir/all' failed
make[1]: *** [src/CMakeFiles/cion_compiler.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2
make 62.10s user 5.93s system 98% cpu 1:08.80 total
I hope you can help me as I really don't know why the compiler thinks that I want to call the default constructor instead of my custom one ...
I finally found out what's the source of this strange compiler error:
It is in fact really strange. The source of the problem was that the header file declared about one hundred members of the CionTokenTypes class but they got initialized in the wrong order and some got even left out in the source file of the class which resulted in the error that the compiler can't find the default constructor for the last member.
So I guess this confusing was mainly caused by a poor error handling for this situation.
Could be wrong, as I do not seem to have enough of your code to properly reproduce the error in ideone.
From the looks of things your are attempting to invoke the default constructor of TokenType at line 210 and because none is being automatically generated by the compiler, you get an error. It is not being generated because you have declared another constructor and the rules of C++ then skip generation of the default constructor.
Solutions include (one of):
You weren't supposed to be calling a default constructor, so investigate line 210 and stop that.
You actually did want a default constructor, add the line TokenType() = default; to your TokenType struct.
Related
#include <iostream>
#include <set>
using namespace std;
class StudentT {
public:
int id;
string name;
public:
StudentT(int _id, string _name) : id(_id), name(_name) {
}
int getId() {
return id;
}
string getName() {
return name;
}
};
inline bool operator< (StudentT s1, StudentT s2) {
return s1.getId() < s2.getId();
}
int main() {
set<StudentT> st;
StudentT s1(0, "Tom");
StudentT s2(1, "Tim");
st.insert(s1);
st.insert(s2);
set<StudentT> :: iterator itr;
for (itr = st.begin(); itr != st.end(); itr++) {
cout << itr->getId() << " " << itr->getName() << endl;
}
return 0;
}
In line:
cout << itr->getId() << " " << itr->getName() << endl;
It give an error that:
../main.cpp:35: error: passing 'const StudentT' as 'this' argument of 'int StudentT::getId()' discards qualifiers
../main.cpp:35: error: passing 'const StudentT' as 'this' argument of 'std::string StudentT::getName()' discards qualifiers
What's wrong with this code? Thank you!
The objects in the std::set are stored as const StudentT. So when you try to call getId() with the const object the compiler detects a problem, mainly you're calling a non-const member function on const object which is not allowed because non-const member functions make NO PROMISE not to modify the object; so the compiler is going to make a safe assumption that getId() might attempt to modify the object but at the same time, it also notices that the object is const; so any attempt to modify the const object should be an error. Hence compiler generates an error message.
The solution is simple: make the functions const as:
int getId() const {
return id;
}
string getName() const {
return name;
}
This is necessary because now you can call getId() and getName() on const objects as:
void f(const StudentT & s)
{
cout << s.getId(); //now okay, but error with your versions
cout << s.getName(); //now okay, but error with your versions
}
As a sidenote, you should implement operator< as :
inline bool operator< (const StudentT & s1, const StudentT & s2)
{
return s1.getId() < s2.getId();
}
Note parameters are now const reference.
Member functions that do not modify the class instance should be declared as const:
int getId() const {
return id;
}
string getName() const {
return name;
}
Anytime you see "discards qualifiers", it's talking about const or volatile.
Actually the C++ standard (i.e. C++ 0x draft) says (tnx to #Xeo & #Ben Voigt for pointing that out to me):
23.2.4 Associative containers
5 For set and multiset the value type
is the same as the key type. For map
and multimap it is equal to pair. Keys in an associative
container are immutable.
6 iterator of
an associative container is of the
bidirectional iterator category. For
associative containers where the value
type is the same as the key type, both
iterator and const_iterator are
constant iterators. It is unspecified
whether or not iterator and
const_iterator are the same type.
So VC++ 2008 Dinkumware implementation is faulty.
Old answer:
You got that error because in certain implementations of the std lib the set::iterator is the same as set::const_iterator.
For example libstdc++ (shipped with g++) has it (see here for the entire source code):
typedef typename _Rep_type::const_iterator iterator;
typedef typename _Rep_type::const_iterator const_iterator;
And in SGI's docs it states:
iterator Container Iterator used to iterate through a set.
const_iterator Container Const iterator used to iterate through a set. (Iterator and const_iterator are the same type.)
On the other hand VC++ 2008 Express compiles your code without complaining that you're calling non const methods on set::iterators.
Let's me give a more detail example. As to the below struct:
struct Count{
uint32_t c;
Count(uint32_t i=0):c(i){}
uint32_t getCount(){
return c;
}
uint32_t add(const Count& count){
uint32_t total = c + count.getCount();
return total;
}
};
As you see the above, the IDE(CLion), will give tips Non-const function 'getCount' is called on the const object. In the method add count is declared as const object, but the method getCount is not const method, so count.getCount() may change the members in count.
Compile error as below(core message in my compiler):
error: passing 'const xy_stl::Count' as 'this' argument discards qualifiers [-fpermissive]
To solve the above problem, you can:
change the method uint32_t getCount(){...} to uint32_t getCount() const {...}. So count.getCount() won't change the members in count.
or
change uint32_t add(const Count& count){...} to uint32_t add(Count& count){...}. So count don't care about changing members in it.
As to your problem, objects in the std::set are stored as const StudentT, but the method getId and getName are not const, so you give the above error.
You can also see this question Meaning of 'const' last in a function declaration of a class? for more detail.
I am using a std::shared_ptr to point to a Node
template<typename T>
class A
{
class Node
{
T data;
std::shared_ptr<Node> link;
Node(T data, std::shared_ptr<Node> link);
};
void push(T data);
std::shared_ptr<Node> top;
};
template<typename T>
A<T>::Node::Node(T data, std::shared_ptr<typename A<T>::Node> link) :
data(data), link(link)
{
}
template<typename T>
void A<T>::push(T item)
{
if (top == nullptr)
{
top = std::make_shared<typename A<T>::Node>(new typename
A<T>::Node(item, nullptr));
}
else
{
top = std::make_shared<typename A<T>::Node>(new typename A<T>::Node(item, top));
}
}
The resulting declarations and definitions results in the compiler error
Severity Code Description Project File Line Suppression State
Error C2664 'Stack::Node::Node(const Stack::Node &)': cannot convert argument 1 from 'Stack::Node *' to 'const Stack::Node &' memory 901
What do I need to change to conform to <memory>?
A constructor of std::shared_ptr<T> accepts a pointer to T which you have created with new.
The function std::make_shared<T>(args...) does the new for you instead. The arguments you pass to make_shared will be passed on to the constructor of T. So you should almost never pass it a pointer created by new (unless you really want to new a T, and then pass that pointer as an argument to create another T!).
So for example, instead of:
std::make_shared<typename A<T>::Node>(
new typename A<T>::Node(item, top))
do just:
std::make_shared<typename A<T>::Node>(item, top)
(By the way, you don't actually need most of those typename A<T>:: qualifiers. Just plain Node is in scope whenever you're in the scope of A<T> or A<T>::Node, both in the class definitions and member definitions of that class after the member name. A<T>::Node without the typename would also work in those contexts because of the "member of the current instantiation" rule.)
Suppose there is a class with a few data members, such as this:
struct s {
char c;
int i;
};
If I need a const-pointer to a member, it's simple enough:
auto s::* const ptr = &s::c;
If I try to create a static member of the same type, some weird things start happening...
For instance, this segfaulted the compiler (gcc 4.9.3):
struct s {
char c;
int i;
static auto s::* const static_ptr = &s::c;
};
// internal compiler error: Segmentation fault
// static auto s::* const static_ptr = &s::c;
// ^
Using it as a static member of a different class at least finishes compiling:
struct t {
static auto s::* const static_ptr = &s::c;
};
// error: 'constexpr' needed for in-class initialization of static data member 'char s::* const t::static_ptr' of non-integral type [-fpermissive]
// static auto s::* const static_ptr = &s::c;
// ^
That last error I don't understand, isn't &s::c a constexpr?
I do have a way to make it work, eg:
// also works with `struct s` this way, `struct t` is not needed for this
struct t {
static char s::* const static_ptr;
};
char s::* const t::static_ptr = &s::c;
But for several reasons this is undesirable:
auto cannot be used except in the definition, if it is initialized outside the class then the type must be declared.
Declaring the type explicitly means either repeating the type or repeating the member name (as decltype(s::c)) - more places to maintain the same name = more mistakes possible.
The above is even more of a nuisance with specialized class templates, where for each specialization this would need to be done inside and outside the class.
From this I have a two part question.
1. Why isn't &s::c a constexpr? Is there a way to make it one?
2. Is there a way to specify a static member that is a fixed pointer to a member of another class, with the type automatically determined, without resorting to decltype?
I have tried this as a member of struct s and get the same error (constexpr needed):
static constexpr auto s::* const member_c () {
return &s::c;
}
So I'm at a loss as to what the compiler's issue is with this sort of syntax, it just doesn't make sense to me why a reference to a data member (not an instance member reference) is not a constant at compile time.
Say I have a struct (in real life, that's an automaton):
struct automaton
{
bool get_final() const { return final; }
void set_final() { final = true; }
bool final = false;
};
for which I want to provide a view that sees it transposed (iow, reversed, or mirrored). Because I have more than just a single automaton class, I have a class template that wraps my automaton (I really want composition, not inheritance), and bounces all the function calls to the wrapped automaton, reversing what needs to be. For sake of simplicity, here, it just forwards the calls.
By hand, I'd get
template <typename Aut>
struct transposed_by_hand
{
Aut& aut;
auto get_final() const -> bool
{
return aut.get_final();
}
auto set_final() -> void
{
aut.set_final();
}
};
But there are many functions, and I don't want to hard-code so much information (the function signature) in the wrapper. Thanks to variadic templates and perfect forwarding for the incoming arguments, and decltype for the result, it's quite easy to have one macro to factor the definition of all the const member-functions, and another macro for non-const member functions (the difference being precisely the const). Basically, in this case it boils down to this:
template <typename Aut>
struct transposed_with_decltype
{
Aut& aut;
auto get_final() const -> decltype(aut.get_final())
{
return aut.get_final();
}
auto set_final() -> decltype(aut.set_final())
{
aut.set_final();
}
};
This works well for non-const automata, but breaks if I wrap a const automaton:
int main()
{
const automaton aut;
transposed_by_hand<const automaton> trh = { aut };
transposed_with_decltype<const automaton> trd = { aut };
}
My compilers complain that (G++ 4.9):
f.cc: In instantiation of 'struct transposed_with_decltype<const automaton>':
f.cc:44:49: required from here
f.cc:34:12: error: passing 'const automaton' as 'this' argument of 'void automaton::set_final()' discards qualifiers [-fpermissive]
auto set_final() -> decltype(aut.set_final())
^
and (Clang++ 3.3):
f.cc:42:23: error: default initialization of an object of const type 'const automaton' requires a user-provided default constructor
const automaton aut;
^
f.cc:34:36: error: member function 'set_final' not viable: 'this' argument has type 'const automaton', but function is not marked const
auto set_final() -> decltype(aut.set_final())
^~~
f.cc:44:49: note: in instantiation of template class 'transposed_with_decltype<const automaton>' requested here
transposed_with_decltype<const automaton> trd = { aut };
^
f.cc:6:12: note: 'set_final' declared here
void set_final() { final = true; }
^
2 errors generated.
And they are right! The expression in the decltype is breaking the const-ness of the wrapped automaton. Yet, I am not going to use this function, I swear. Just like I will not use the corresponding one wrapped by hand.
So my question is: is there a means to write the definition of the wrapping set_final so that I don't have to spell out its signature (input and output)? I have tried to use std::enable_if, but it changes nothing to the problem here. And anyway, it would need that the compiler be lazy, and accepts not to evaluate the second parameter of std::enable_if if it does not need to...
template <typename Aut>
struct transposed_with_decltype
{
Aut& aut;
auto get_final() const -> decltype(aut.get_final())
{
return aut.get_final();
}
auto set_final() -> typename std::enable_if<!std::is_const<Aut>::value,
decltype(aut.set_final())>::type
{
aut.set_final();
}
};
Thanks in advance.
I can get it to work (using GCC 4.6) just by using the advice Xeo mentions in his comment. That is, I turn the function into a trivial template, like so:
template<typename = void>
auto set_final() -> decltype(aut.set_final()) {
return aut.set_final();
}
== EDIT ==
Luc Danton comments below that a more recent GCC may reject the code, complaining that the decltype isn't dependent. I only have 4.6 here, but perhaps this could be worked around using something like this:
template<typename KLUDGE = int>
auto set_final() -> decltype((&aut+KLUDGE(0))->set_final()) {
return aut.set_final();
}
YMMV.
I'm building a large project on Debian 6.0.6 (with gcc 4.4.5) that was initially built in Microsoft VS (2008, I think).
What seems to be the problem is that when I declare a member as
typedef typename std::set<T>::iterator iterator, and then later use this iterator, gcc appears to interpret this as (const T*).
The part of the class containing the typename designation:
template <class entityType>
class entityArray
{
private: std::set<entityType> m_array;
public: typedef typename std::set<entityType>::iterator iterator;
...
public:
entityType* At( const char* name);
...
};
plus a few other classes that are needed for the discussion:
class entity
{
private:
entity* m_parent;
int m_ncid;
std::string m_name;
public:
entity () { m_ncid = 0; m_parent = NULL;}
virtual ~entity () {};
...
};
class attribute : public entity
{
public:
attribute(){};
virtual ~attribute(){};
};
class var : public entity
{
private:
entityArray<attribute> m_atts;
public:
var(){}
virtual ~var(){}
...
};
class dim : public entity
{
public:
dim() {};
virtual ~dim() {};
};
class group : public entity
{
private:
entityArray<var> m_vars;
entityArray<dim> m_dims;
...
public:
dim* DimAt( const char* dimname ) { return m_dims.At(dimname);}
};
Now an iterator is initialized through a call to the function DimAt which in turn calls At. The At function in the first class is defined as:
template <class entityType>
entityType* entityArray<entityType>::At( const char* name )
{
entityType dummy;
iterator iter;
entityType* ptr;
... define dummy ...
iter = m_array.find( dummy );
ptr = (iter != m_array.end()) ? &(*iter) : NULL;
return ptr;
}
Compiling the above produces
error: invalid conversion from const dim* to dim*., referring to &(*iter).
I realize that typename is required for declaring iterator, since the type is a dependent and qualified name, but I don't see why this substitution (const *) is being performed by the compiler. I would appreciate any help that you could provide. Thanks!
This has absolutely nothing to do with typename.
The standard allows std::set<T>::iterator and std::set<T>::const_iterator to be the same type, and with GCC the types are the same.
The reason is that modifying an element of a std::set e.g. by *iter = val might invalidate the ordering of the set elements, breaking the invariant that the elements of the set are always in order. By making the iterator type a constant iterator instead of a mutable iterator it's not possible to alter the element, preventing you from corrupting the set's ordering.
So with GCC's implementation, when you dereference the iterator using *iter you get a const entitType& and when you take its address using &*iter you get a const entityType*