WIll thread-safe be a feature of STL in the future? - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

WIll thread-safe be a feature of STL in the future?
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

cai
Guest

Posted: Fri Aug 08, 2003 10:06 pm Post subject: WIll thread-safe be a feature of STL in the future?

Hi, when I'm programming in mutithread environment,I have so trouble in synchronizing the STL container such as vector and string. Will the standard commitee consider to add thread safe into STL? {Possibly but I believe that there are thread safe implementations available. -mod} [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow
Guest

Posted: Fri Aug 08, 2003 11:24 pm Post subject: Re: WIll thread-safe be a feature of STL in the future?

In message <bgvh9q$t96oq$1 (AT) ID-147672 (DOT) news.uni-berlin.de>, cai
<aladdin_sh (AT) asus (DOT) com.cn> writes

Quote:

Hi, when I'm programming in mutithread environment,I have so trouble in
synchronizing the STL container such as vector and string. Will the standard
commitee consider to add thread safe into STL?

Thread safety is (I think) an implementation detail and so outside the
remit of the Standard. I would expect people wanting thread safety would
use thread safe implementations, or was there something else that you
wanted?

--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Sebastian Moleski
Guest

Posted: Sat Aug 09, 2003 9:26 am Post subject: Re: WIll thread-safe be a feature of STL in the future?

"cai" <aladdin_sh (AT) asus (DOT) com.cn> wrote

Quote:

Hi, when I'm programming in mutithread environment,I have so trouble in
synchronizing the STL container such as vector and string. Will the standard
commitee consider to add thread safe into STL?

Most popular STL implementations provide both ST and MT versions. This is
definitely true for STLport and Dinkumware's STL (the one that comes with MSVC).
The Standard is relatively mute on the subject of multi-threading so STL
implementations are largely free to decide about that on their own.

sm

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ulrich Eckhardt
Guest

Posted: Sat Aug 09, 2003 11:24 pm Post subject: Re: WIll thread-safe be a feature of STL in the future?

cai wrote:

Quote:

Hi, when I'm programming in mutithread environment,I have so trouble in
synchronizing the STL container such as vector and string. Will the
standard commitee consider to add thread safe into STL?

Up to now, C++ doesn't adress threads, let alone thread safety. However,
you are not the first to notice that, and people seem to be really working
on it (from what I gleaned by lurking in comp.programming.threads).

Back to your problem: most stdlibraries _are_ thread-safe. However, this
does not mean that you can randomly modify containers from different
threads, this kind of internal synchronization has been (afaik)
implemented in early Java, but was abandoned for practical reasons. Search
the web and you will find exactly why and how to do it properly.

Uli

--
Questions ?
see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first !

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

llewelly
Guest

Posted: Sun Aug 10, 2003 10:35 am Post subject: Re: WIll thread-safe be a feature of STL in the future?

Francis Glassborow <francis.glassborow (AT) ntlworld (DOT) com> writes:

Quote:

In message <bgvh9q$t96oq$1 (AT) ID-147672 (DOT) news.uni-berlin.de>, cai
[email]aladdin_sh (AT) asus (DOT) com.cn[/email]> writes
Hi, when I'm programming in mutithread environment,I have so trouble in
synchronizing the STL container such as vector and string. Will the standard
commitee consider to add thread safe into STL?

Thread safety is (I think) an implementation detail and so outside the
remit of the Standard. I would expect people wanting thread safety would
use thread safe implementations, or was there something else that you
wanted?

FWIW, all thread-safe implementations I know of require the user to
know and do appropriate locking. (This is a good thing, but it
surprises some, who appear to think 'threadsafe' means 'someone
else already put locks in all the right places.)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dhruv
Guest

Posted: Sun Aug 10, 2003 10:50 am Post subject: Re: WIll thread-safe be a feature of STL in the future?

On Sat, 09 Aug 2003 05:28:57 -0400, Pete Becker wrote:

Quote:

cai wrote:

Hi, when I'm programming in mutithread environment,I have so trouble in
synchronizing the STL container such as vector and string. Will the standard
commitee consider to add thread safe into STL?

Most implementations of the C++ standard library are thread-safe. That
doesn't mean that you don't have to synchronize access, though. Suppose
you run this function in multiple threads:

void f()
{
for (int i = 0; i < 100; ++i)
std::cout << "Hello, " << "worldn";
}

No amount of "thread safe" code in the library will prevent splitting
the two insertions, so the output could very well look a bit like this:

Hello, Hello, world
world

Ok, since we are at the topic of thread safety, in context of the STL, or
anything else, when you talk about thread safety about something, like for
example, if you say that (function X, or container Y) is thread safe, what
exactly do you mean by that? I currently have a choice of 2 from which I
cannot make out. I tried searching a lot, but could not reach any
conclusions.

1. I can use that function freely from any new threads that I spawn, that
may be running concurrently, so something like:

Thread A:
std::copy (...)

Thread B:
std::copy (...)

2. I can use the function form more than 1 thread running concurrently,
but provided that I put some sort of mutex protection around it, so it
would mean that at a time, only 1 (instance???) of the function is
currently running......

Something like this:

Thread A:
M = create_mutex ("some string");
std::copy (...);
stop_mutex (A);

Thread B:
M = create_mutex ("some string");
std::copy (...);
stop_mutex (A);

So, when you say that (function X, or container Y) is thread safe, which
mode of usage are you exactly talking about form out of 1 and 2.

Regards,
-Dhruv.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Kanze
Guest

Posted: Sun Aug 10, 2003 7:14 pm Post subject: Re: WIll thread-safe be a feature of STL in the future?

Francis Glassborow <francis.glassborow (AT) ntlworld (DOT) com> writes:

Quote:

In message <bgvh9q$t96oq$1 (AT) ID-147672 (DOT) news.uni-berlin.de>, cai
[email]aladdin_sh (AT) asus (DOT) com.cn[/email]> writes
Hi, when I'm programming in mutithread environment,I have so
trouble in synchronizing the STL container such as vector and
string. Will the standard

Thread safety is (I think) an implementation detail and so outside
the remit of the Standard. I would expect people wanting thread
safety would use thread safe implementations, or was there
something else that you wanted?

That is the current situation, but IMHO, threading is an issue the
standard will have to address sooner or later. At that time, of
course, the rules of thread safety will have to be defined. (Like
exception safety, there is no absolute concept of thread safety. The
class must, however, definir the contract that it guarantees.)

--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Kanze
Guest

Posted: Sun Aug 10, 2003 7:14 pm Post subject: Re: WIll thread-safe be a feature of STL in the future?

Pete Becker <petebecker (AT) acm (DOT) org> writes:

Quote:

cai wrote:

Hi, when I'm programming in mutithread environment,I have so
trouble in synchronizing the STL container such as vector and
string. Will the standard commitee consider to add thread safe
into STL?

Most implementations of the C++ standard library are
thread-safe. That doesn't mean that you don't have to synchronize
access, though. Suppose you run this function in multiple threads:

void f()
{
for (int i = 0; i < 100; ++i)
std::cout << "Hello, " << "worldn";
}

No amount of "thread safe" code in the library will prevent
splitting the two insertions, so the output could very well look a
bit like this:

Hello, Hello, world
world

That's not quite true. The first operator<< could grab a lock, and
return a temporary which maintained the lock until the end of the full
expression.

Not that that buys you anything, of course (except in exceptional
cases). The granularity is still too low.

--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Kanze
Guest

Posted: Sun Aug 10, 2003 7:17 pm Post subject: Re: WIll thread-safe be a feature of STL in the future?

"Dhruv" <dhruvbird (AT) gmx (DOT) net> writes:

Quote:

You mean that the function's contract covers the responsibilities of
the function and of the caller with regards to behavior in a
multi-threaded context.

Quote:

I currently have a choice of 2 from which I cannot make out.

There is only one basic concept: the function covers threading in its
contract. There are an infinity of different solutions which it can
adopt, however.

Quote:

I tried searching a lot, but could not reach any conclusions.

1. I can use that function freely from any new threads that I
spawn, that may be running concurrently, so something like:

Thread A:
std::copy (...)

Thread B:
std::copy (...)

I think that thread safety is *usually* more an issue for objects. I
would certainly hope that I could call std::copy on different objects
in different threads without problems.

Quote:

2. I can use the function form more than 1 thread running
concurrently, but provided that I put some sort of mutex
protection around it, so it would mean that at a time, only 1
(instance???) of the function is currently running......

Something like this:

Thread A:
M = create_mutex ("some string");
std::copy (...);
stop_mutex (A);

Thread B:
M = create_mutex ("some string");
std::copy (...);
stop_mutex (A);

Again, mutexes protect objects, not (necessarily) functions.

Quote:

So, when you say that (function X, or container Y) is thread safe,
which mode of usage are you exactly talking about form out of 1
and 2.

When you say that function X is thread safe, it normally means that
the function itself uses no unproected static data (other than that
whose address or reference has been furnished by the user) in
implementation. Typically, this is automatically the case of a well
designed function; on the other hand, it is not the case of strtoken,
or a certain number of Posix interfaces.

When you say that a class Y is thread safe, it normally means that it
has taken threads into consideration when it specifies its contract.
Thus, for example, the STL containers at the SGI site are thread
safe. The contract can vary -- the SGI containers, for example, state
that the user is responsible for locks concerning accesses to a single
container, but that the library is responsible for locking resources
(such as the allocator) shared between several objects.

--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Pete Becker
Guest

Posted: Sun Aug 10, 2003 7:21 pm Post subject: Re: WIll thread-safe be a feature of STL in the future?

Dhruv wrote:

Quote:

Neither. That's why I gave a higher-level example. Writing correct
multi-threaded applications requires that threading be designed into the
application from the top down. It's not something you can patch in by
adding thread-safe libraries, regardless of how you define thread-safe.

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Dennett
Guest

Posted: Mon Aug 11, 2003 12:08 am Post subject: Re: WIll thread-safe be a feature of STL in the future?

Dhruv wrote:

Quote:

On Sat, 09 Aug 2003 05:28:57 -0400, Pete Becker wrote:

cai wrote:

Hi, when I'm programming in mutithread environment,I have so trouble in
synchronizing the STL container such as vector and string. Will the standard
commitee consider to add thread safe into STL?

Most implementations of the C++ standard library are thread-safe. That
doesn't mean that you don't have to synchronize access, though. Suppose
you run this function in multiple threads:

void f()
{
for (int i = 0; i < 100; ++i)
std::cout << "Hello, " << "worldn";
}

No amount of "thread safe" code in the library will prevent splitting
the two insertions, so the output could very well look a bit like this:

Hello, Hello, world
world

Ok, since we are at the topic of thread safety, in context of the STL, or
anything else, when you talk about thread safety about something, like for
example, if you say that (function X, or container Y) is thread safe, what
exactly do you mean by that? I currently have a choice of 2 from which I
cannot make out. I tried searching a lot, but could not reach any
conclusions.

1. I can use that function freely from any new threads that I spawn, that
may be running concurrently, so something like:

Thread A:
std::copy (...)

Thread B:
std::copy (...)

2. I can use the function form more than 1 thread running concurrently,
but provided that I put some sort of mutex protection around it, so it
would mean that at a time, only 1 (instance???) of the function is
currently running......

Something like this:

Thread A:
M = create_mutex ("some string");
std::copy (...);
stop_mutex (A);

Thread B:
M = create_mutex ("some string");
std::copy (...);
stop_mutex (A);

So, when you say that (function X, or container Y) is thread safe, which
mode of usage are you exactly talking about form out of 1 and 2.

There are more forms of thread-safety than just these 2.

SGI used to have a good webpage describing the thread-safety
guarantees offered by their STL implementation. Functions can
be used freely from multiple threads, concurrently, and data
structures such as std::list only when the user supplies appropriate synchronization.

This is usually the best compromise between safety and speed.
Even if the library ensured that containers remained valid when
accesses simultaneously (without additional higher-level
synchronization) from multiple threads, the code using those
containers would usually still need to add synchronization to
make its own operations work correctly, and it turns out that
the containers' built-in synchronization is then pure overhead.

About the only good argument I can think of for having the
containers do internal synchronization is to catch bugs in
debug builds.

-- James.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Pete Becker
Guest

Posted: Mon Aug 11, 2003 12:26 am Post subject: Re: WIll thread-safe be a feature of STL in the future?

James Kanze wrote:

Quote:

Pete Becker <petebecker (AT) acm (DOT) org> writes:

|> cai wrote:

|> > Hi, when I'm programming in mutithread environment,I have so
|> > trouble in synchronizing the STL container such as vector and
|> > string. Will the standard commitee consider to add thread safe
|> > into STL?

|> Most implementations of the C++ standard library are
|> thread-safe. That doesn't mean that you don't have to synchronize
|> access, though. Suppose you run this function in multiple threads:

|> void f()
|> {
|> for (int i = 0; i < 100; ++i)
|> std::cout << "Hello, " << "worldn";
|> }

|> No amount of "thread safe" code in the library will prevent
|> splitting the two insertions, so the output could very well look a
|> bit like this:

|> Hello, Hello, world
|> world

That's not quite true. The first operator<< could grab a lock, and
return a temporary which maintained the lock until the end of the full
expression.

Sigh.

void f()
{
for (int i = 0; i < 100; ++i)
{
std::cout << "Hello, ";
std::cout << "workdn";
}

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Shannon Barber
Guest

Posted: Mon Aug 11, 2003 9:15 am Post subject: Re: WIll thread-safe be a feature of STL in the future?

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote in message

Quote:

When we say something is thread-safe we mean that it is possible to
use it correctly from multiple threads concurrently. For example,
some classes in the MFC employ thread-local-storage in such a manor
that they cannot be made thread-safe (you have to make a thread-local
copy of the object to use it).

Some early STL implementation used global variables, which does not
necessarily preclude thread-safety, but makes them rather inefficient
because every function call accessing that global has to be protected
by the same mutex. On a system that does not have recursive mutexes
(mutices?), it is quite problematic (you'd have to fake it).

If you're looking for good threaded code, you want more than safety,
you want reentrancy (you want every function to be reentrant). For
starters, that means no global variables (sometimes the use of globals
can be overcome by using thread-local-storage, for example errno or
strtok), and assignments and operations must be carefully ordered.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Randy Maddox
Guest

Posted: Tue Aug 12, 2003 10:50 pm Post subject: Re: WIll thread-safe be a feature of STL in the future?

Pete Becker <petebecker (AT) acm (DOT) org> wrote

Quote:

Dhruv wrote:

Ok, since we are at the topic of thread safety, in context of the STL, or
anything else, when you talk about thread safety about something, like for
example, if you say that (function X, or container Y) is thread safe, what
exactly do you mean by that? I currently have a choice of 2 from which I
cannot make out. I tried searching a lot, but could not reach any
conclusions.

[common but unsatisfactory definitions of thread safety snipped]

So, when you say that (function X, or container Y) is thread safe, which
mode of usage are you exactly talking about form out of 1 and 2.

Neither. That's why I gave a higher-level example. Writing correct
multi-threaded applications requires that threading be designed into the
application from the top down. It's not something you can patch in by
adding thread-safe libraries, regardless of how you define thread-safe.

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

Pete is absolutely correct that a thread-safe application must be
designed that way from the beginning and that, regardless of how you
define thread-safe, there is no way that thread-safe libraries can
accomplish this goal for you.

I would go even further and state that thread-safe libraries are, in
most cases, worse than useless because:

1. The granularity of thread-safety that can be provided in a library
is not correct for ensuring a thread-safe application. That is, a
thread-safe library generally means that the library itself is
re-entrant and synchronized so as to protect its own internal data
structures. The former is necessary, but not sufficient, for a
thread-safe application.

2. In a properly designed thread-safe application it is almost always
the case that internal library synchronization is redundant, i.e., you
pay the cost for it but receive no benefit in return.

The problem is that only simple data structures with limited
interfaces can be made thread-safe at a level that is useful to the
application. For example, a queue, which is often used to communicate
between a producer and consumer thread, can be made suitably
thread-safe by merely ensuring that push() and pop() are atomic
operations. A producer thread can happily push() stuff onto the queue
without worrying about the consumer thread pop()ing stuff off that
same queue. Everybody is happy. :-)

The saving grace for a queue is that there is no way to iterate over
the contents of the queue. As soon as you get into a list, vector,
map, or anything else that supports iteration, you have thread
synchronization issues that cannot be solved in the library. For
example, posit a "thread-safe" list. What does this mean? We assume
all list functions will be re-entrant, and the list insert and remove
functions will be atomic. That's really all that can be provided at
the library level. But, while the re-entrancy is necessary,
re-entrancy and atomicity of add/remove are not sufficient to
guarantee correct operation when multiple threads may be iterating
over a single non-const list since an operation by one thread may
invalidate an iterator in use by another thread. For example, thread
A erases several elements in the middle of a list, while thread B
happens to be iterating over those very elements. Ooops! The list
class cannot help with this.

For most containers, and many other types of resources, the only way
to ensure appropriate application level thread-safety is for the
application to synchronize access on its own. Once the application
does so correctly, then any additional synchronization provided within
a library is simply redundant.

Other than correctly designing a multi-threaded application I don't
know of any library level solution to thread-safety. A re-entrant
library implementation is necessary, but not sufficient. Redundant
synchronization within a library is a cost for no benefit that should
be avoided.

Randy.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dhruv
Guest

Posted: Wed Aug 13, 2003 4:03 pm Post subject: Re: WIll thread-safe be a feature of STL in the future?

James Kanze <kanze (AT) gabi-soft (DOT) fr> wrote

Quote:

"Dhruv" <dhruvbird (AT) gmx (DOT) net> writes:

|> On Sat, 09 Aug 2003 05:28:57 -0400, Pete Becker wrote:

|> > cai wrote:

|> >> Hi, when I'm programming in mutithread environment,I have so
|> >> trouble in synchronizing the STL container such as vector and
|> >> string. Will the standard commitee consider to add thread safe
|> >> into STL?

|> > Most implementations of the C++ standard library are
|> > thread-safe. That doesn't mean that you don't have to
|> > synchronize access, though. Suppose you run this function in
|> > multiple threads:

|> > void f()
|> > {
|> > for (int i = 0; i < 100; ++i)
|> > std::cout << "Hello, " << "worldn";
|> > }

|> > No amount of "thread safe" code in the library will prevent
|> > splitting the two insertions, so the output could very well
|> > look a bit like this:

|> > Hello, Hello, world
|> > world

|> Ok, since we are at the topic of thread safety, in context of the
|> STL, or anything else, when you talk about thread safety about
|> something, like for example, if you say that (function X, or
|> container Y) is thread safe, what exactly do you mean by that?

You mean that the function's contract covers the responsibilities of
the function and of the caller with regards to behavior in a
multi-threaded context.

|> I currently have a choice of 2 from which I cannot make out.

There is only one basic concept: the function covers threading in its
contract. There are an infinity of different solutions which it can
adopt, however.

|> I tried searching a lot, but could not reach any conclusions.

|> 1. I can use that function freely from any new threads that I
|> spawn, that may be running concurrently, so something like:

|> Thread A:
|> std::copy (...)

|> Thread B:
|> std::copy (...)

I think that thread safety is *usually* more an issue for objects. I
would certainly hope that I could call std::copy on different objects
in different threads without problems.

Ok, so thread safety applies mainly to objects (that hold data), and

not to functions. Only if the functions have a static variable that
they modify (global or local static), then thread safety comes
in. Otherwise, the function is usually thread safe. What about classes
without any fields (data members). Does thread safety apply even to
them. Assuming that the class does not contain any static data
members, and the menber functions do not modify any static data.

Quote:

|> 2. I can use the function form more than 1 thread running
|> concurrently, but provided that I put some sort of mutex
|> protection around it, so it would mean that at a time, only 1
|> (instance???) of the function is currently running......

|> Something like this:

|> Thread A:
|> M = create_mutex ("some string");
|> std::copy (...);
|> stop_mutex (A);

|> Thread B:
|> M = create_mutex ("some string");
|> std::copy (...);
|> stop_mutex (A);

Again, mutexes protect objects, not (necessarily) functions.

|> So, when you say that (function X, or container Y) is thread safe,
|> which mode of usage are you exactly talking about form out of 1
|> and 2.

When you say that function X is thread safe, it normally means that
the function itself uses no unproected static data (other than that
whose address or reference has been furnished by the user) in
implementation. Typically, this is automatically the case of a well
designed function; on the other hand, it is not the case of strtoken,
or a certain number of Posix interfaces.

Yes, so as I said above. Am I right?
By address or reference, you mean parameters right?

Quote:

When you say that a class Y is thread safe, it normally means that it
has taken threads into consideration when it specifies its contract.
Thus, for example, the STL containers at the SGI site are thread
safe. The contract can vary -- the SGI containers, for example, state
that the user is responsible for locks concerning accesses to a single
container, but that the library is responsible for locking resources
(such as the allocator) shared between several objects.

So, suppose I make a claim that container X is thread thread safe, I
will have to specify what level of thread safety I'm talking about
right. I was thinking that there is some sort of globally accepted
definition of thread safety, just like there is a C++ standard, so I
got a bit confused :-)

Regards,
-Dhruv.

BTW, what is 'granurality'?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum