Bo Persson wrote:
David Jobet wrote:
Hello,
I'm trying to compile a small example extracted from here :
http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html#ImplFlag
I compile it with gcc 4.4.3 using the following command line :
g++ --std=c++0x test.cpp
And I get the following error :
test.cpp: In function 'int main(int, char**)':
test.cpp:24: error: no matching function for call to
'atomic_flag::atomic_flag(<brace-enclosed initializer list>)'
test.cpp:13: note: candidates are: atomic_flag::atomic_flag(const
atomic_flag&)
test.cpp:12: note: atomic_flag::atomic_flag()
I'm quite new to c++0x, I know it is not finalized, but still, if
the draft says that "The macro ATOMIC_FLAG_INIT shall be de?ned in
such a way that it can be used to initialize an object of
type atomic_flag to the clear state."
I guess this should be possible to do it without having to change
the interface right ?
So, my question is the following : does gcc has a problem here or
this is the code which is actually incorrect ?
If the code is actually incorrect (which I would tend to believe)
how can one implement this macro without changing the interface of
the struct atomic_flag ? (for example, by adding the explicit
initialize_list constructor
atomic_flag(std::initializer_list<bool> list))
Tx for the help
David
PS : This is the extract
---
enum memory_order
{
memory_order_seq_cst // should have more members, but this is
enough to compile the example
};
typedef struct atomic_flag
{
bool test_and_set( memory_order = memory_order_seq_cst )
volatile; void clear( memory_order = memory_order_seq_cst )
volatile; void fence( memory_order ) const volatile;
atomic_flag() = default;
atomic_flag( const atomic_flag& ) = delete;
atomic_flag& operator =( const atomic_flag& ) = delete;
private:
bool __f__;
} atomic_flag;
#define ATOMIC_FLAG_INIT { false }
int main(int argc, char **argv)
{
atomic_flag af = ATOMIC_FLAG_INIT;
return 0;
}
I believe you need at least version 4.5 for the compiler to realize
that atomic_flag is a trivial type despite its private member.
http://gcc.gnu.org/projects/cxx0x.html
Otherwise, try to make the member variable public as a temporary
workaround.
Bo Persson
Hello Bo,
tx for the help.
I did not try yet using gcc 4.5, however I tried using the "public
hack" thing : still same behaviour.
I'm not very clear on why gcc would accept it anyway : since I'm
defining explicitly the default constructor, it would mean I don't
want the instance to be created without using it ? At least this is
how I would interpret it.
So allowing to build the instance using classic POD initialization,
completly bypassing the allowed constructors, seems couterintuitive
to me.
Unless of course, "default constructor" means also explicitly
accepting POD- style initialization list.
I tried removing the default constructor, still same error though
;-)
David
I am sure that used to work, but I might misremember. The POD version
That sure helps. :-)