 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
cppfrontend
Guest
|
 Posted: Sun Aug 22, 2004 3:26 am Post subject: Sockets, threads and GUIs in the C++ Standard... |
 |
|
Hi.
It seems that the major revision of the next C++ Standard will be
completed pretty soon (2008-9 something?).
Hitherto, it seems that the revised Standard will include pretty
obvious additions such as: a new hash container, a new smart pointer,
regular expressions and typeof. That is always something.
Now, when developing serious applications these days, one cannot hide
from the fact that they are very often built with ingredients such as
sockets, threads and GUIs. (Please, do not reply and ask me to back
this "fact" up...) Hence, it would be very natural that these
ingredients are included in the revised C++ Standard. I guess most
other competitive languages have these features. And if C++ wants to
be competitive in the future I think these features are absolutely
mandatory. Or will C++ consciously resign and only aim to be
competitive in isolated domains where you don't network and where you
only have standard in and out?
I truly hope that this scary scenario wont take place. Hence, it makes
me very sad to figure that these extremely important ingredients in
real-world applications are still not even seriously discussed and
considered by the committee to be part of the revised Standard. At
least I have not been able to find any official ISO document that
indicates otherwise. This seems to be due to the fact that the
committee has not received such a proposal - yet. Hmm....
The other day I read a posting here on clc++m from Mr. Alexandrescu
where he pointed out that he misses threads in C++ a lot. One answer
he received from a committee member (at least, I think Mr. Glassborow
is a committee member) was to write up a proposal and present it to
them so they have something to chew on. So, am I supposed to write up
a proposal for sockets and another for GUIs then? This makes me feel a
bit stressed - I do not want to see those features left out of the
Standard just because I didn't take the time to write a proposal or
two…
Is my only other alternative to sit back and hope that some other C++
end-user in his so expensive spare-time finds time and motivation to
write a proposal to feed the committee with? The committee wont take
any initiatives of their own?
Thoughts?
To me, a revised C++ standard without sockets, threads and GUI will be
like a "fis i rymden", spelled out in plain Swedish.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Dietmar Kuehl
Guest
|
| Posted: Sun Aug 22, 2004 10:47 am Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
cppfrontend wrote:
| Quote: | It seems that the major revision of the next C++ Standard will be
completed pretty soon (2008-9 something?).
|
The working title is C++0x which seems to indicate a standard in
2009 latest. Whether the committee will make this target is a
different issue. I sure hope that there will be new revision of
the standard by 2009 or even earlier.
| Quote: | Now, when developing serious applications these days, one cannot hide
from the fact that they are very often built with ingredients such as
sockets, threads and GUIs.
|
One also cannot hide the fact that applications using sockets,
threads, and GUIs are written in C++ already. Out of these three
"ingredients", I think threads are somewhat special as threads
cannot be implemented without at least some help from the compiler.
Both sockets and GUIs are accessed through libraries and don't need
special handling from C++ compiler.
For threads I see a pretty good chance that support for them
becomes available in the next revision of the standard - at least
if people interested in threads and knowledgable about the related
techniques understand that they will have to push the issue and
have to participate in the standardization of the thread related
stuff. The major reason why I expect that threads make it into the
c++ standard is their dependency on compiler support for efficient
and reliable implementation.
Sockets may or may not make it into the next standard. There is no
proposal on the table which seems to indicate that they rather
don't make it unless somebody at least picks up the issue and
pushes it. The need for sockets in C++ is, however, IMO not that
high: there are C interfaces which are pretty similar, though not
identical, on all platforms I worked with. Maybe there is even
already a standard for sockets. Of course, it would be nice to
have it shipped with the compiler but I think there are third
party libraries, both free and commercial, which cover the
important platforms.
I don't expect that adding a GUI to the C++ standard stands any
chance at all. Just the GUI basics would exceed the capacity of
what can be done by the C++ committee by far. ... and this does
not even address the platform specific differences and approaches
of the various popular GUI systems. Java's two standard GUI
interfaces (AWT and Swing) and the fact that despite the standard
having already two libraries there is at least a third independent
GUI library (SWT) hints at the variety of different approaches.
Even if the C++ committee could come up with a specification if
everybody would agree how the interface should look like, it will
be essentially impossible to achieve this agreement.
| Quote: | Hence, it would be very natural that these
ingredients are included in the revised C++ Standard. I guess most
other competitive languages have these features. And if C++ wants to
be competitive in the future I think these features are absolutely
mandatory.
|
I disagree. What is mandatory, is to make it possible that
threads, GUIs, sockets, ... can be used from within C++. C++ does
not, like Java or .Net, define a closed environment (I know that
it is possible to extend these environments but this somewhat
defeats the goal of Java and .Net to create executable which can
run everywhere with just one executable). It defines a language
which is designed such that it is possible to access libraries.
It is no problem to leave certain things out if they are provided
by third parties already. GUIs, sockets, data base access (which
I would rate much more important than both GUIs and sockets), ...
are offered already. So why bother?
| Quote: | The other day I read a posting here on clc++m from Mr. Alexandrescu
where he pointed out that he misses threads in C++ a lot. One answer
he received from a committee member (at least, I think Mr. Glassborow
is a committee member) was to write up a proposal and present it to
them so they have something to chew on. So, am I supposed to write up
a proposal for sockets and another for GUIs then? This makes me feel a
bit stressed - I do not want to see those features left out of the
Standard just because I didn't take the time to write a proposal or
two
|
If you are interested, you should indeed write a proposal and
push the issue further: the first proposal would probably just
spell out the need and sketch how the support could look like. If
this is considered by the committee to be an issue to be persued,
you would need to push it further until it becomes part of the
standard. As mentioned above, I doubt that a GUI would make it
past the first step but this is just my own opinion and a majority
of the committee may think otherwise.
| Quote: | Is my only other alternative to sit back and hope that some other C++
end-user in his so expensive spare-time finds time and motivation to
write a proposal to feed the committee with? The committee wont take
any initiatives of their own?
|
I sense a major misconception in the above paragraph: the
committee is not a group of people paid for working in the
committee. It is actually quite the opposite: the people in the
committee pay to participate - be it in the form of membership
fees to have voting rights and/or in the form of attending the
meetings which costs at least traveling expenses (transport and
hotel) and lost opportunity to work on something else. For me
(I'm attending the meetings) that means that I'm doing the work
in my "so expensive spare-time". As a result, I'm only pushing
issues I'm interested in, none of which is threads, GUI, or
sockets. The same applies to many of the other members although
some of them get support from their companies, probably to push
the issues the company is interested in.
For the committee taking initiatives: the work has to be done by
individuals. The time at meetings is too short to do substantial
work. That is, the absolute maximum of initiative the committee
can take is requesting somebody to write a proposal - probably
in his "so expensive spare-time" unless a company is willing to
invest in the issue.
--
<mailto:dietmar_kuehl (AT) yahoo (DOT) com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
cppfrontend
Guest
|
| Posted: Mon Aug 23, 2004 10:18 am Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
| Quote: | Dietmar wrote:
I think threads are somewhat special as threads cannot be
implemented without at least some help from the compiler.
Both sockets and GUIs are accessed through libraries and
don't need special handling from C++ compiler.
|
Agreed.
| Quote: | For threads I see a pretty good chance that support for
them becomes available in the next revision of the
standard - at least if people interested in threads and
knowledgable about the related techniques understand
that they will have to push the issue and have to participate
in the standardization of the thread related stuff.
The major reason why I expect that threads make it into the
c++ standard is their dependency on compiler support for
efficient and reliable implementation.
|
Ok, seems reasonable. So, let us hope that these knowledgable
people understand that they will have to push this issue then.
Come on Andrei!
| Quote: | Sockets may or may not make it into the next standard.
There is no proposal on the table which seems to indicate
that they rather don't make it unless somebody at least picks
up the issue and pushes it.
|
Too sad.
| Quote: | The need for sockets in C++ is, however, IMO not that high:
there are C interfaces which are pretty similar, though not
identical, on all platforms I worked with.
|
It would be a Good Thing to get rid of these low level C APIs.
At least, it would be nice to safely ignore them. IMO, ACE has
laid out a very nice foundation which should be possible to
tweak into the Standard. As I recall that was Bjarne's opinion
in ‘99 or ‘00 when he gave a talk on C++0x during an sdexpo
conference. He explicitly mentioned that ACE was interesting
indeed. After that talk, I took it for granted that sockets was
going to be incorporated into the revised Standard. Hmm…
| Quote: | Of course, it would be nice to have it shipped with the
compiler but I think there are third party libraries, both free
and commercial, which cover the important platforms.
|
Yes, there are many different libraries available. This makes
the reason to standardize even greater.
| Quote: | If you are interested, you should indeed write a proposal
and push the issue further
|
Yes, if I only was knowledgeable enough and if I had the time…
Unfortunately, I'm afraid that people with the right level of
expertise is also short of time. Hence, I suspect that it is quite
likely that the revised Standard will be pretty thin when it comes
to complex but still much needed ingredients.
So, I think it is pretty obvious that the committee is relying on
efforts put in by individuals instead of taking bearing of the
C++ end-users' needs. I guess that is an inherent situation when
the language is an ISO Standard? A proprietary language OTOH
would of course listen to its customers needs… I guess that is
why Java, C# and others have stuff such as sockets.
| Quote: | I sense a major misconception in the above paragraph: the
committee is not a group of people paid for working in the
committee
Yes, I'm sorry for that. |
| Quote: | For me (I'm attending the meetings) that means that I'm doing
the work in my "so expensive spare-time". As a result, I'm
only pushing issues I'm interested in, none of which is threads,
GUI, or sockets.
|
I admire your dedication - we need more people like you! I hope
that one day soon you suddenly get interested in threads, sockets,
GUIs ;-)
I guess that my concerns pretty much boils down to the fact that
the committee doesn't have the resources needed to incorporate
complex but much needed ingredients in the revised Standard.
Too sad, but we do not live in a perfect world. I'm still glad that
C++ is not a proprietary language though…
Thank you for the explanation Dietmar! I now understand the
situation and will lower my hopes for the revised C++ Standard.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Allan W
Guest
|
| Posted: Tue Aug 24, 2004 10:47 pm Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
[email]cppfrontend (AT) yahoo (DOT) com[/email] (cppfrontend) wrote
Wow! Cool handle!
| Quote: | Yes, there are many different libraries available. This makes
the reason to standardize even greater.
|
No, you're missing the point.
Can you write a C++ program that prints your name on the printer? That
formats a hard drive and makes it bootable? That displays your login
UserID? That sends Email? That makes a "click" sound every second?
In the 21st century, most software (except embedded software) does not
work stand-alone. Your operating system is in charge of loading the
C++ program into memory in the first place. When your program reads or
writes from the disk or asks for the current time of day, the C++
run-time library passes this request on to the OS.
Your program isn't self-contained, nor should it be. Want to use
sockets? Download a sockets package and use it. Want to draw pie
charts? Download it. Neither of these is part of the C++ spec --
but what does it matter? You have the API and the documentation,
and it's even portable -- so have at it.
As for GUIs -- I think Dietmar hit it on the head. No matter what
API we build into C++ as the STANDARD GUI API, the vast majority will
say it sucks. The best we could hope for is a compromise, which could
be identified by averaging the complaints -- if half of the complaints
say we have too many bells and whistles, and the other half say we're
missing vital components, that's probably the best balance possible.
By allowing third-party packages instead, we invite you to download
any GUI you want. Find one that works exactly the way YOU want it to
work -- and if you can't, then go ahead and create one of your own.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
DZ
Guest
|
| Posted: Wed Aug 25, 2004 11:48 am Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
"Allan W" <allan_w (AT) my-dejanews (DOT) com> wrote
| Quote: | cppfrontend (AT) yahoo (DOT) com (cppfrontend) wrote
Wow! Cool handle!
Yes, there are many different libraries available. This makes
the reason to standardize even greater.
Your program isn't self-contained, nor should it be. Want to use
sockets? Download a sockets package and use it. Want to draw pie
charts? Download it. Neither of these is part of the C++ spec --
but what does it matter? You have the API and the documentation,
and it's even portable -- so have at it.
|
One could make the same argument for all the libraries that are currently
available or slated to be available in the standard C++ library. The problem
is that if I need this functionality and I choose to use C++, I must do
extra work:
- I must find an appropriate one that works on my compiler/platform.
- It must also work on other platforms and compilers that I may port to.
- I have to worry about the support that is provided for this library . If
it's prorpietary, will support be dropped in the future? (this has happened
to me) If it's open source or similar, how much work will I have to do to
support it if it's of bad quality.
- If it's a C library, I may want to wrap it in objects so that I can ensure
RAII amd take advantage of my using C++.
If it's available as part of the standard library that ships with my
compiler then all of these concerns are lessened. I would mainly then just
have to worry about the quality of my compiler's implementation.
Now clearly, we can't standardise every possible library function out there,
but I would argue that sockets and threading are conspicuously absent from
C++ since they contain a set of functionality that many modern programs
require. The fact that most OSes provide a C API to this functionality
certainly helps in these particular cases, but they are not portable, which
means that people start to wrap them - enter ACE, boost and its ilk.
Dan
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
John Torjo
Guest
|
| Posted: Wed Aug 25, 2004 8:50 pm Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
[email]cppfrontend (AT) yahoo (DOT) com[/email] (cppfrontend) wrote in message news:<86d27908.0408211626.7c9613a0 (AT) posting (DOT) google.com>...
| Quote: | Hi.
It seems that the major revision of the next C++ Standard will be
completed pretty soon (2008-9 something?).
Hitherto, it seems that the revised Standard will include pretty
obvious additions such as: a new hash container, a new smart pointer,
regular expressions and typeof. That is always something.
Now, when developing serious applications these days, one cannot hide
from the fact that they are very often built with ingredients such as
sockets, threads and GUIs. (Please, do not reply and ask me to back
this "fact" up...) Hence, it would be very natural that these
|
Note: for the threads, I tend to agree with you.
However, not so for sockets/GUIs thing. I hardly use sockets directly
(usually put a wrapper over it). But there are plenty libs. out there.
While when it comes to GUI - platform independence is almost
impossible.
In order to define a set of widgets/properties that exist on all
platforms, will make you library so small/trivial that almost nobody
will use it. In other words, there won't be much difference between a
console app. and a GUI app ;)
Not to say about generic event handling and such.
I'm all for platform independence when it comes to console apps., but
when it comes to GUI - everything becomes extremely complex. You'll
always end up wanting that extra feature that a certain OS has, and
try to emulate it for other platforms.
Take a look at existing cross-platform GUI libraries out there - they
all need to compromise, and usually the look-and-feel is a little
awquard.
As a side-note, I've started to develop a GUI library using generics
([url]http://www.torjo.com/win32gui/)[/url]. It is Windows-only (some reasons are
shown above). But it is portable to modern compilers - so far, gcc,
vc71 and como. In the future I plan to port it even more.
Another side-note: there is a hot debate on the boost list, exactly
about cross-platform GUI ;)
Best,
John
--
John Torjo
Freelancer
-- [email]john (AT) torjo (DOT) com[/email]
Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.3beta released - check out splitter/simple_viewer,
a File Explorer/Viewer all in about 200 lines of code!
Professional Logging Solution for FREE
-- http://www.torjo.com/code/logging.zip (logging - C++)
-- http://www.torjo.com/logview/ (viewing/filtering - Win32)
-- http://www.torjo.com/logbreak/ (debugging - Win32)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Alwyn
Guest
|
| Posted: Wed Aug 25, 2004 9:41 pm Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
In article <cOUWc.208834$J06.1637@pd7tw2no>, DZ
<d_zakaib_NOSPAM (AT) yahoo_nospam (DOT) com> wrote:
| Quote: | Now clearly, we can't standardise every possible library function out there,
but I would argue that sockets and threading are conspicuously absent from
C++ since they contain a set of functionality that many modern programs
require. The fact that most OSes provide a C API to this functionality
certainly helps in these particular cases, but they are not portable, which
means that people start to wrap them - enter ACE, boost and its ilk.
|
Why choose something as low-level as a wrapper for the BSD (or for that
matter, POSIX) Sockets API (which is quite trivial to write, anyway -
I've done it many times)? Why not go for an extension of IOStreams?
That's where networking code really belongs.
Personally, though, I'm a conservative sort. C++, like C, is really a
glorified assembler (and, also like C, minimally portable). First let
them knock the corners out of the language (and that will taks some
work!), then, maybe, we can consider higher-level extensions.
Alwyn
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Fri Aug 27, 2004 2:48 am Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
[email]jtorjo (AT) yahoo (DOT) com[/email] (John Torjo) wrote in message
news:<c638aac5.0408250131.da7ae73 (AT) posting (DOT) google.com>...
| Quote: | cppfrontend (AT) yahoo (DOT) com (cppfrontend) wrote in message
news:<86d27908.0408211626.7c9613a0 (AT) posting (DOT) google.com>...
It seems that the major revision of the next C++ Standard will be
completed pretty soon (2008-9 something?).
Hitherto, it seems that the revised Standard will include pretty
obvious additions such as: a new hash container, a new smart
pointer, regular expressions and typeof. That is always something.
Now, when developing serious applications these days, one cannot
hide from the fact that they are very often built with ingredients
such as sockets, threads and GUIs. (Please, do not reply and ask me
to back this "fact" up...) Hence, it would be very natural that
these
Note: for the threads, I tend to agree with you.
|
Threading requires thread-awareness on the part of the compiler. You
can't do it simply with a third party library. (The third party
libraries which exist count on the compiler being Posix conformant, or
Windows conformant, for their code to work.)
| Quote: | However, not so for sockets/GUIs thing. I hardly use sockets directly
(usually put a wrapper over it). But there are plenty libs. out there.
|
I think that there is about as much justification for putting sockets in
the standard as there is for files.
| Quote: | While when it comes to GUI - platform independence is almost
impossible. In order to define a set of widgets/properties that exist
on all platforms, will make you library so small/trivial that almost
nobody will use it. In other words, there won't be much difference
between a console app. and a GUI app 
|
The alternative is to use the Java Swing solution, and require
everything implemented in the library. Or a compromise: what the system
supports is implemented in the system, what it doesn't in the library.
That doesn't mean I'm really in favor of a GUI interface in the
standards; I'm rather undecided for the moment, and I rather suspect
that my decision would depend on the exact proposal.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Mark
Guest
|
| Posted: Fri Aug 27, 2004 3:10 am Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
John Torjo wrote:
| Quote: |
While when it comes to GUI - platform independence is almost
impossible.
In order to define a set of widgets/properties that exist on all
platforms, will make you library so small/trivial that almost nobody
will use it. In other words, there won't be much difference between a
console app. and a GUI app
|
Well I don't really buy that argument. Take the web
standards for example. They are defined in a cross
platform way and provide more than just "console"
capability.
Basically I believe it just needs someone to sit down
and do some serious requirements analysis across all
the platforms.
Any volunteers? :)
Cheers,
Mark.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
John Torjo
Guest
|
| Posted: Fri Aug 27, 2004 12:40 pm Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
| Quote: |
Well I don't really buy that argument. Take the web
standards for example. They are defined in a cross
platform way and provide more than just "console"
capability.
|
Yes, but every browser needs to implement them somehow.
That said, don't you see how many workarounds do web designers have to
do, in order to get the software to work with most of the browsers?
Even more, the web-controls are really limited in themselves. you
usually use some sort of javascript to give them some "life". And
that's just a very limited set of events they can respond to.
Thus, you'll end up with a few controls that can respond to a few
events and not be able to take advantage of the underlying OS (which
can and usually does provide much more). There are plenty
cross-platform GUI libraries now doing just this. Take a look.
Best,
John
--
John Torjo
Freelancer
-- [email]john (AT) torjo (DOT) com[/email]
Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.3beta released - check out splitter/simple_viewer,
a File Explorer/Viewer all in about 200 lines of code!
Professional Logging Solution for FREE
-- http://www.torjo.com/code/logging.zip (logging - C++)
-- http://www.torjo.com/logview/ (viewing/filtering - Win32)
-- http://www.torjo.com/logbreak/ (debugging - Win32)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Hyman Rosen
Guest
|
| Posted: Sat Aug 28, 2004 2:48 am Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
Mark wrote:
| Quote: | Basically I believe it just needs someone to sit down
and do some serious requirements analysis across all
the platforms.
|
I understand that Longhorn (the next version of Microsoft's
operating system) will incorporate advanced three-dimensional
graphics into the user interface. People are already designing
interface elements which involve translucency and arbitrary
shapes.
Think of the experience of Java, whose initial graphics package
concept was so bad that they had to design a new one. But the
original has to hang around and be supported forever because it's
part of the language.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
News Admin
Guest
|
| Posted: Sat Aug 28, 2004 11:05 am Post subject: Re: Sockets, threads and GUIs in the C++ Standard... |
|
|
Hyman Rosen <hyrosen (AT) mail (DOT) com> wrote
| Quote: | Mark wrote:
Basically I believe it just needs someone to sit down
and do some serious requirements analysis across all
the platforms.
I understand that Longhorn (the next version of Microsoft's
operating system) will incorporate advanced three-dimensional
graphics into the user interface.
|
Oh, no! Not another all singing all dancing interface foisted
upon us.
People are already designing
| Quote: | interface elements which involve translucency and arbitrary
shapes.
|
I see. Not satisfied with spaces in file names, now got to
have holes in the windows.
But listen, it's all backward compatible, yes? So yours
is no argument against the proposal at all.
Louis.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
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
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
