Implementing c++0x's ATOMIC_FLAG_INIT

D

David Jobet

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;
}
 
B

Bo Persson

David said:
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
 
D

David Jobet

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
 
B

Bo Persson

David said:
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
(public member) for sure works with MSVC.

Looking at gcc 4.5.1 atomic (atomic_0.h), I see that they have added
an extra constructor

atomic_flag(bool __i);

That sure helps. :)


Bo Persson
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,578
Members
45,052
Latest member
LucyCarper

Latest Threads

Top