Topic: comp.std.c++ is for standards discussion


Author: osinski@valis.cs.nyu.edu (Ed Osinski)
Date: 1995/04/20
Raw View
In article <3n4b01$s5e@giga.bga.com>, jamshid@ses.com (Jamshid Afshar) writes:
|> In article <3met0e$9mi@cmcl2.NYU.EDU>, Ed Osinski <osinski@cs.nyu.edu> wrote:
|> >This group is *not* for topics such as:
|> >
|> >* problems with writing a C++ program (see comp.lang.c++)
|> >* problems with using MFC or OWL (see comp.lang.c++)
|> >* problems with accessing the mouse (see the appropriate platform-related
|> >      newsgroup)
|>
|> MFC and OWL questions should go in a comp.os.ms-windows.programmer.*
|> newsgroup, not comp.lang.c++.  Would you recommend people post UNIX,
|> X, or Windows SDK questions to comp.lang.c simply because those APIs
|> are written in the C language?

I'll have to plead ignorance (wrt MFC and OWL :-) ); I wasn't quite sure
what the right newsgroup was for MFC and OWL questions, since I don't use
either.  I thought that comp.lang.c++ might be appropriate for those that
were C++ specific (e.g. how should I derive a subclass to get a certain
effect).  Anyway, the pointers to newsgroups were not meant to be
definitive, just rough examples.

--
---------------------------------------------------------------------
 Ed Osinski
 Computer Science Department, New York University
 E-mail:  osinski@cs.nyu.edu
---------------------------------------------------------------------
In the early years of the 16th century, to combat the rising tide of
religious unorthodoxy, the Pope gave Cardinal Ximinez of Spain leave
to move without let or hindrance throughout the land, in a reign of
violence, terror and torture that makes a smashing film.  This was
the Spanish Inquisition...
    -- Monty Python's Flying Circus





Author: jamshid@ses.com (Jamshid Afshar)
Date: 1995/04/20
Raw View
In article <3met0e$9mi@cmcl2.NYU.EDU>, Ed Osinski <osinski@cs.nyu.edu> wrote:
>This group is *not* for topics such as:
>
>* problems with writing a C++ program (see comp.lang.c++)
>* problems with using MFC or OWL (see comp.lang.c++)
>* problems with accessing the mouse (see the appropriate platform-related
>      newsgroup)

MFC and OWL questions should go in a comp.os.ms-windows.programmer.*
newsgroup, not comp.lang.c++.  Would you recommend people post UNIX,
X, or Windows SDK questions to comp.lang.c simply because those APIs
are written in the C language?

Here's the reply I mail to people posting questions in comp.lang.c++
that are more appropriate for other (existing, very active)
newsgroups.  Note that the text I include is directly from the
comp.lang.c++ Frequently Asked Questions list.

It's a very good idea to mention what other newsgroups are out there
instead of simply telling someone "your post doesn't belong here".
You should also mention that a newsgroup's FAQ list should always be
read before making a post to that newsgroup.

--Jamshid

--- canned reply to a question more appropriate in a system-specific group ---

I don't know the answer to your question, but you might want to try a more
appropriate newsgroup.  See the appended section from the comp.lang.c++
Frequently Asked Questions list for some suggestions.  A newsgroup's FAQ
list should always be read before posting to that newsgroup.  FAQ lists are
available anytime at ftp://rtfm.mit.edu/pub/usenet/ and on the World Wide
Web at http://www.cis.ohio-state.edu/hypertext/faq/usenet/top.html.

Thanks,
Jamshid Afshar
jamshid@ses.com

==============================================================================
SUBSECTION 1B: "Is this the right newsgroup?" (PLEASE READ BEFORE POSTING)
==============================================================================

Comp.lang.c++ is the best place to discuss the C++ language itself (eg,
C++ code design, syntax, style).  Other newsgroups exist for discussion of
topics which are specific to a particular system (eg, MS Windows or UNIX)
or topics which are not directly related to the C++ language (eg, how to
use your compiler).  Here's a list of some very active newsgroups and
excerpts from their Frequently Asked Questions lists.  These excerpts
should give you an idea of the type of topics frequently discussed there.

  comp.os.ms-windows.programmer.tools
     This group is intended for discussions about the selection and use of
     tools for Windows software development.
  comp.os.ms-windows.programmer.misc
     This group is for all other discussions about Windows software
     development.
  [There's one FAQ list for all the comp.os.ms-windows.programmer.* groups]
     FAQ 5.7.1.  Accessing C++ classes in a DLL
     FAQ 6.1.1.  A dialog as an MDI child window [with OWL]
     FAQ 6.2.1.  Disabled menu choices become enabled [with MFC]
     FAQ 8.1.5.  Using STRICT with windows.h
     FAQ 10.  A programmer's bibliography

  comp.os.msdos.programmer
     Much of our traffic is about language products (chiefly from Borland
     and Microsoft).
     FAQ 301. How can I read a character without [waiting for] the Enter key?
     FAQ 412. How can I read, create, change, or delete the volume label?
     FAQ 504. How do I configure a COM port and use it to transmit data?
     FAQ 602. How can a C program send control codes to my printer?
     FAQ 606. How can I find the Microsoft mouse position and button status?
     FAQ 707. How can I write a TSR (terminate-stay-resident) utility?
     FAQ B0. How can I contact [Borland, Microsoft]?
     [note: this FAQ is not available at rtfm.mit.edu; it is at Simtel
            (eg, oak.oakland.edu) in /pub/msdos/info/faqp*.zip and Garbo
            (garbo.uwasa.fi) in /pc/doc-net/faqp*.zip]
  comp.os.msdos.programmer.turbovision [Borland's character-mode framework]

  comp.unix.programmer
     FAQ 4.5)  How do I use popen() to open a process for reading AND writing?
     FAQ 4.6)  How do I sleep() in a C program for less than one second?

  comp.unix.solaris (covers SunOS 4.x and Solaris)
     FAQ 4)  Signal Primer
     FAQ 5)  Waiting for Children to Exit

  gnu.g++.help
     FAQ: Where can I find a demangler?
     FAQ: Getting gcc/g++ binaries for Solaris 2.x
     FAQ: What documentation exists for g++ 2.x?
  gnu.g++.bug [bug reports for g++ -- see the g++ docs]

  comp.lang.c
     FAQ 1.10: I'm confused.  NULL is guaranteed to be 0, but the null
               pointer is not?
     FAQ 2.3:  So what is meant by the "equivalence of pointers and
               arrays" in C?
     FAQ 4.2:  [Why doesn't `printf("%d\n", i++ * i++);' work?]
     FAQ 7.1:  How can I write a function that takes a variable number
               of arguments? [stdarg.h or varargs.h]
     FAQ 10.4: How do I declare an array of pointers to functions returning
               pointers to functions returning pointers to characters?

Also check out the newsgroups comp.graphics, comp.sources.wanted,
comp.programming, and comp.object (its FAQ is an excellent introduction and
overview of OOP terms and concepts).  Remember that comp.std.c++ is for
discussion *directly* related to the evolving ANSI/ISO C++ Standard (see
Q5).

There's rarely a need to crosspost a question to one of the above
newsgroups and comp.lang.c++ (readers in the system-specific newsgroups
aren't programming in machine language, ya know).  It's bad netiquette to
crosspost widely because your problem is "really important".  If you don't
get an answer in the "right" newsgroup and feel you must post here, at
least consider redirecting followups back to the appropriate newsgroup.

Before posting a question to any newsgroup you should read it's FAQ list.
An answer to your question is likely to be there, saving you the time of
posting and saving thousands of other people around the world the time of
reading your question.  People answering an FAQ are likely to be annoyed for
having to answer it for the umpteenth time, or they're likely to be giving
you a wrong or incomplete answer since they haven't read the FAQ either.

Frequently Asked Questions lists are available 24-hours a day via anonymous
ftp (rtfm.mit.edu in /pub/usenet/comp.what.ever) or e-mail server (send a
message with the line "help" to mail-server@rtfm.mit.edu).  See the article
"Introduction to the *.answers newsgroups" in the newsgroup news.answers or
news.announce.newusers (which contains many other must-read articles) for
more information.





Author: kriss@cao-vlsi.ibp.fr (Christophe GROSJEAN)
Date: 1995/04/18
Raw View
Is comp.std.c++ a place to speak of moderation ?
I thought it was a place to speak of c++.
Why almost half posting are about group policy ?
Please, those who dislike one's behavior, don't answer it,
(not even by mail, you encourage them).
Answering trouble makers is becoming one yourself.
(OK, I do it myself right now, I stop.)





Author: schuenem@Informatik.TU-Muenchen.DE (Ulf Schuenemann)
Date: 1995/04/12
Raw View
In article <D6sLLv.M4H@ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
[..]
|>  If this group is to be moderated, the kind of moderation
|> we need is automatic acceptance of articles unless they are
|> clearly from newbies who don't know what the group is for,
|> (which should be redirected to comp.std.c++)
|> or deliberate attempts to thwart the general aims of the _people_
|> who use the group.

As we want to protect us ( = comp.std.c++ ) against newbies:
We could all include a magic-cookie in all our postings. Postings
without it should then be returned to the sender automatically.
Information about the "magic-cookie" can be obtained by reading the
periodical posting "comp.std.c++ is for standards discussion".
This way a newby has to read the newsgroup before beeing able to
successfully post an article.

I just wonder how such a mechanism can be installed.

[...]
|>  An unmoderated comp.std.c++ is a way I can be in contact with
|> a group of like minded people. One thing about anarchy is that people working
|> and talking together with a common interest usually manage to
|> limit such things without any hard and fast rules.

I agree wholeheartedly (also with the [...] above).

[..]
|>  Even the occasional invasion by trouble makers is usually
|> handled without the need for "police" activity. There is
|> more than one way to skin a cat. And trouble makers sometimes
                        ^^^^^^^^^^
Irony (for insiders) is so refreshing :-)

|> have valid points to make.
|>
|>  Anyhow, somehow I missed the straw "moderated or unmoderated"
|> poll. I'd probably have voted against moderation. I'd support
|> a separate moderated group, however: that way I have a choice.

Me too.


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Fakult   t f   r Informatik, Technische Universit   t M   nchen, Germany.
email: schuenem@informatik.tu-muenchen.de





Author: Joe Kraska <jkraska@bbn.com>
Date: 1995/04/12
Raw View
> |>  If this group is to be moderated, the kind of moderation
> |> we need is automatic acceptance of articles unless they are

> As we want to protect us ( = comp.std.c++ ) against newbies:
> We could all include a magic-cookie in all our postings. Postings
> without it should then be returned to the sender automatically.
> Information about the "magic-cookie" can be obtained by reading the
> periodical posting "comp.std.c++ is for standards discussion".
> This way a newby has to read the newsgroup before beeing able to
> successfully post an article.

Now this I like! This I like!

Joe.














Author: osinski@valis.cs.nyu.edu (Ed Osinski)
Date: 1995/04/11
Raw View
In article <D6sLLv.M4H@ucc.su.OZ.AU>, maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
|> >Tom O Breton (tob@world.std.com) wrote:
|> >: comp.std.c++ is for technical announcements and discussion of the
|> >: ANSI/ISO C++ standardization process and the forthcoming C++ standard.
|> >: (This wording has been endorsed by several members of this newsgroup.
|> >: Feel free to suggest appropriate changes.)
|>
|>  Sure. I'd like the charter to be for discussion of
|> the design and standardisation of the C++ language and libraries.
|> Mention of "the _forthcoming_ C++ standard" is not appropriate,
|> it implies the group will die after we have a Standard which is
|> silly.
|>
|>  The reason I'd include "design" in the  charter is that
|> this group IS in my opinion a suitable place for high level
|> discussions of design issues. That is because progress in these
|> areas is intimately connected with standardisation: the existing
|> C++ committee is involved in a Research task, it is not
|> merely standardising "existing practice".

Good points, but if the word "design" is inserted, (or even if it isn't)
it should subsequently be made crystal clear that questions about the
"*design* of my program which happens to be written in *C++* and uses
*libraries*" is not appropriate.  Yes, I know this is clear if you read
the first paragraph, but many budding programmers don't yet even realize
the difference between a language question and a platform related
question.  Some don't even know there's more than one platform.  (Oh,
you mean there's like two?  Pentium *and* 486?)  They are not likely to
read the aforementioned paragraph too carefully.  Appending a short
list of topics this group is *not* about (and appropriate redirections)
would help.  Something like:

This group is *not* for topics such as:

* problems with writing a C++ program (see comp.lang.c++)
* problems with using MFC or OWL (see comp.lang.c++)
* problems with accessing the mouse (see the appropriate platform-related
      newsgroup)

|>  If this group is to be moderated, the kind of moderation
|> we need is automatic acceptance of articles unless they are
|> clearly from newbies who don't know what the group is for,
|> (which should be redirected to comp.std.c++)

I think you meant comp.lang.c++ :-)

|> or deliberate attempts to thwart the general aims of the _people_
|> who use the group.

Agreed.

 -snip-

|> --
|>         JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
|>  Maxtal Pty Ltd,
|>         81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
|>         NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

--
---------------------------------------------------------------------
 Ed Osinski
 Computer Science Department, New York University
 E-mail:  osinski@cs.nyu.edu
---------------------------------------------------------------------
In the early years of the 16th century, to combat the rising tide of
religious unorthodoxy, the Pope gave Cardinal Ximinez of Spain leave
to move without let or hindrance throughout the land, in a reign of
violence, terror and torture that makes a smashing film.  This was
the Spanish Inquisition...
    -- Monty Python's Flying Circus





Author: maxtal@Physics.usyd.edu.au (John Max Skaller)
Date: 1995/04/10
Raw View
>Tom O Breton (tob@world.std.com) wrote:
>: comp.std.c++ is for technical announcements and discussion of the
>: ANSI/ISO C++ standardization process and the forthcoming C++ standard.
>: (This wording has been endorsed by several members of this newsgroup.
>: Feel free to suggest appropriate changes.)

 Sure. I'd like the charter to be for discussion of
the design and standardisation of the C++ language and libraries.
Mention of "the _forthcoming_ C++ standard" is not appropriate,
it implies the group will die after we have a Standard which is
silly.

 The reason I'd include "design" in the  charter is that
this group IS in my opinion a suitable place for high level
discussions of design issues. That is because progress in these
areas is intimately connected with standardisation: the existing
C++ committee is involved in a Research task, it is not
merely standardising "existing practice".

 I can cite as evidence a mathematical proof that a certain
class of pointer conversions is safe was published by Pat Smith
in the WG21 mailings and was subsequently used as a basis
for a resolution that all these conversions be adopted
as standard conversions in the C++ WP.

 Similarly, discussions about library architectures
such as STL -- but not limited to STL -- belong in this group
and not comp.lang.c++. I for one haven't got the time to
read comp.lang.c++ anymore, it is too flooded by the kind
of questions most of us who have been hanging around
in this group for a while do not want to see.

 If this group is to be moderated, the kind of moderation
we need is automatic acceptance of articles unless they are
clearly from newbies who don't know what the group is for,
(which should be redirected to comp.std.c++)
or deliberate attempts to thwart the general aims of the _people_
who use the group.

 But being too officious about it would not be such a good
thing. For example I myself occasionaly may need some stupid
question answered and I may well apologetically request
assistance from a group of people I know have the kind of
expertise to help me.

 I may well write an article about a new book,
and I would not want to see it thrown out because it appears
to the moderator to be off topic. Would I be able to argue
my point _in_ the newsgroup or would the moderator throw
such articles out too?

 An unmoderated comp.std.c++ is a way I can be in contact with
a group of like minded people. One thing about anarchy is that people working
and talking together with a common interest usually manage to
limit such things without any hard and fast rules.

 Even the occasional invasion by trouble makers is usually
handled without the need for "police" activity. There is
more than one way to skin a cat. And trouble makers sometimes
have valid points to make.

 Anyhow, somehow I missed the straw "moderated or unmoderated"
poll. I'd probably have voted against moderation. I'd support
a separate moderated group, however: that way I have a choice.

 I'd like it to continue to be _my_ choice what I post
to comp.std.c++. Its one of the reasons I post at all.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189





Author: matt@physics7.berkeley.edu (Matt Austern)
Date: 1995/04/10
Raw View
In article <D6sLLv.M4H@ucc.su.OZ.AU> maxtal@Physics.usyd.edu.au (John Max Skaller) writes:

>  Anyhow, somehow I missed the straw "moderated or unmoderated"
> poll. I'd probably have voted against moderation. I'd support
> a separate moderated group, however: that way I have a choice.

The vote hasn't happened yet; if the issues gets to that stage at all,
the vote will be probably be in mid to late May.

The procedure for adding or changing newsgroups is (deliberately) slow
and cumbersome.  The discussion phase is supposed to take at least
three weeks, and, officially, we haven't yet even started the
discussion.

If we do hold a vote on moderating comp.std.c++, nobody who reads
this group will miss it.
--

                               --matt





Author: scurry@shore.net (Scott Curry)
Date: 1995/04/08
Raw View
Tom O Breton (tob@world.std.com) wrote:
: comp.std.c++ is for technical announcements and discussion of the
: ANSI/ISO C++ standardization process and the forthcoming C++ standard.
: (This wording has been endorsed by several members of this newsgroup.
: Feel free to suggest appropriate changes.)

I would not suggest any changes to the wording, but I would suggest
posting this periodically (weekly, perhaps), since many of the posts
belong to comp.lang.c++ and not here. :)

[I guess we all are going to have to get used to all the newbies
arriving in the droves to newsgroups like this one.  Patience.]

Scott


--
Scott Curry, Principal              Over 8 years of Internet experience...
Curry Computer Consulting           installation, access to the Internet &
scurry@currycc.com                  WWW authoring services.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





Author: tob@world.std.com (Tom O Breton)
Date: 1995/04/08
Raw View
comp.std.c++ is for technical announcements and discussion of the
ANSI/ISO C++ standardization process and the forthcoming C++ standard.
Other discussion that is directly related to the C++ standard (not
related only to C++ programming techniques) is also welcome.

Questions about C++ _programming techniques_ should instead be posted to
comp.lang.c++, and questions that are specific to some particular
platform should be posted to a group devoted to that platform.

(This wording has been endorsed by several members of this newsgroup.
Feel free to suggest appropriate changes.)