soft and program: comp.lang.c++ - 17 new messages in 4 topics

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

* ◆⊙→Www.toptradea.com Best mobile phones supplier Hot sale Nokia,8800arte,
8600,6300,5800,6500,E series E71,E66,E75, N seies N97,N96,N95,N86,N85,N81,N79,
N78,N72 //Our policy: order 1-3pce brand mobile with a free polo Tshirt - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/e81307217ccf57d1?hl=en
* New release of the Dynace OO extension to C - 10 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
* static inline functions - possible? - 5 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/0386357e12bd0064?hl=en
* ===Welcome to comp.lang.c++! Read this first. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f889a3e4648a1046?hl=en

==============================================================================
TOPIC: ◆⊙→Www.toptradea.com Best mobile phones supplier Hot sale Nokia,8800
arte,8600,6300,5800,6500,E series E71,E66,E75, N seies N97,N96,N95,N86,N85,N81,
N79,N78,N72 //Our policy: order 1-3pce brand mobile with a free polo Tshirt
http://groups.google.com/group/comp.lang.c++/t/e81307217ccf57d1?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 1 2009 7:32 pm
From: "www.toptradea.com Toptradea"

==============================================================================
TOPIC: New release of the Dynace OO extension to C
http://groups.google.com/group/comp.lang.c++/t/ee8689156295093c?hl=en
==============================================================================

== 1 of 10 ==
Date: Sat, Aug 1 2009 7:41 pm
From: luserXtrog

On Aug 1, 8:25 pm, "Tech07" <tec...@nospam.hia> wrote:
> jacob navia wrote:
> > You just
> > replace malloc by GC_malloc, and forget about free
>
> Keywords one hears all over the place: "you just...". Well, personally, "I
> don't wanna just.. " anything. :P
>
> Trying to sell "you don't have to think about it!" to thinkers (yes, the IQ
> on here is way above the average Joe/Jane) on USENET is doomed to failure. I
> suggest you not pursue a marketing career, cuz you really suck at it.

Agree wholeheartedly. I'd rather learn how to manage memory well
than to give it over to "the machine".

--
luxotro

== 2 of 10 ==
Date: Sat, Aug 1 2009 8:21 pm
From: "Tech07"

Juha Nieminen wrote:
> Nick Keighley wrote:
>> what coding conventions does C typically use that C++ typically
>> doesn't?
>> Isn't the use of RAII a massive coding convention?
>
> No. RAII is certainly not a coding convention. It's a compiler
> technique and has little to do with coding conventions. A coding
> convention is something the *programmer* does, while RAII is something
> the *compiler* does automatically.
>
> If, for example, I instantiate and manipulate a std::string in a
> function, I don't need *any* coding conventions to make sure that the
> string gets freed: The compiler is going to free it for me. I don't
> have to do anything to achieve that.
>

Well la di da. Babies need their butts wiped also. Grow up!

== 3 of 10 ==
Date: Sat, Aug 1 2009 8:26 pm
From: "Tech07"

Bo Persson wrote:
> BGB / cr88192 wrote:
>> "Juha Nieminen" <nospam@thanks.invalid> wrote in message
>> news:NlEcm.129$sW4.42@read4.inet.fi...
>>> Nick Keighley wrote:
>>>> what coding conventions does C typically use that C++ typically
>>>> doesn't?
>>>> Isn't the use of RAII a massive coding convention?
>>>
>>> No. RAII is certainly not a coding convention. It's a compiler
>>> technique and has little to do with coding conventions. A coding
>>> convention is something the *programmer* does, while RAII is
>>> something the *compiler* does automatically.
>>>
>>> If, for example, I instantiate and manipulate a std::string in a
>>> function, I don't need *any* coding conventions to make sure that
>>> the string gets freed: The compiler is going to free it for me. I
>>> don't have to do anything to achieve that.
>>>
>>> In C, however, if I use a dynamic string in a function, I have to
>>> free it myself, and to avoid leaks in complicated functions I have
>>> to use some coding principles to make sure that the string gets
>>> freed no matter how the function is exited.
>>>
>>> That's precisely what I'm talking about: RAII aids me in avoiding
>>> a useless coding convention which I would have to use in C to make
>>> the my code safer.
>>
>> as a side note:
>> WRT strings, this is why I typically very rarely use strdup...
>> strdup is a memory leak just waiting to happen (likewise for
>> malloc...).
>> so, as part of my little "convention", I tend to use functions
>> which intern all the strings (typically, these are localized to
>> particular libraries).
>> char *basm_strdup(char *str);
>> char *sxil_strdup(char *str);
>> ...
>>
>> then again, I guess the "strdup" could be a hurdle, since the
>> resultant string is interned, rather than allocated...
>>
>> so, my usual approach:
>> any work on a string is done in a buffer;
>> the string is interned, and regarded as immutable.
>>
>> granted, one doesn't want to use this with any large chunk of text,
>> since typically these interned strings are not going away (making
>> it "sort of like a memory leak"). some sort of GC-mechanism for
>> interned strings could be done, but I have typically not done so
>> (since short strings have a tendency of being very repetitive, and
>> the total number of them being finite).
>>
>> it is worth noting, however, that a partial solution to this has
>> been the use of the "allocate, bulk-free" strategy (or, in Quake
>> terms, the "Hunk" strategy). basically, where the strings are
>> interned into a temporary local heap, and upon leaving the general
>> region, the entire strings-table is destroyed as well.
>>
>> this is actually the strategy typically used in my compilers (many
>> of my compiler stages each use their own localized heaps).
>>
>> the reason for doing this was that compilers tend to produce huge
>> amounts of "garbage" all at once, and because using the main
>> heap/GC tended to hurt performance too badly...
>>
>> if there is one thing the "hunk" strategy is good at, it is being
>> fast (since an entire heap can be torn down nearly all at once, vs
>> having to manage and individually free particular items...).
>>
>>
>> so, alas, maybe this is why "conventions" are disliked...
>> the idea of each separate major library and subsystem having its
>> own mini subset of the C runtime...
>>
>> but, hell, it works for me...
>>
>> one just has to understand my naming conventions.
>>
>> simple hint:
>> if using anything that does not use my "library" notation, and does
>> not have the same name prefix as the other code around it, take
>> caution...
>> SXIL_
>> BASM_
>> BGBCC_
>> ...
>>
>> if in "SXIL" one sees a function call with a "BGBCC" prefix, this
>> itself is a flag for alarm...
>>
>> note "sxil" or "basm" is not as bad (since these are typically
>> simple utility functions), but still cause for concern (for
>> example, in the case of the string functions, they may intern the
>> string in the wrong heap, or potentially none at all...).
>>
>> but, alas, a good portion of my "style" revolves around naming
>> conventions...
>
> So that's why we C++ guys prefer std::string, which solves all of
> this. :-)

Said the "metrosexual"? (It's not your father's C++ anymore, son... be
careful out there!)

== 4 of 10 ==
Date: Sat, Aug 1 2009 8:30 pm
From: "Tech07"

BGB / cr88192 wrote:
> "Bo Persson" <bop@gmb.dk> wrote in message
> news:7dgu1rF2cak0cU1@mid.individual.net...
>> BGB / cr88192 wrote:
>>> "Juha Nieminen" <nospam@thanks.invalid> wrote in message
>>> news:NlEcm.129$sW4.42@read4.inet.fi...
>
> <snip>
>
>>>
>>> as a side note:
>>> WRT strings, this is why I typically very rarely use strdup...
>>> strdup is a memory leak just waiting to happen (likewise for
>>> malloc...).
>>> so, as part of my little "convention", I tend to use functions
>>> which intern all the strings (typically, these are localized to
>>> particular libraries).
>>> char *basm_strdup(char *str);
>>> char *sxil_strdup(char *str);
>>> ...
>>>
>>> then again, I guess the "strdup" could be a hurdle, since the
>>> resultant string is interned, rather than allocated...
>>>
>>> so, my usual approach:
>>> any work on a string is done in a buffer;
>>> the string is interned, and regarded as immutable.
>>>
>>> granted, one doesn't want to use this with any large chunk of text,
>>> since typically these interned strings are not going away (making
>>> it "sort of like a memory leak"). some sort of GC-mechanism for
>>> interned strings could be done, but I have typically not done so
>>> (since short strings have a tendency of being very repetitive, and
>>> the total number of them being finite).
>>>
>>> it is worth noting, however, that a partial solution to this has
>>> been the use of the "allocate, bulk-free" strategy (or, in Quake
>>> terms, the "Hunk" strategy). basically, where the strings are
>>> interned into a temporary local heap, and upon leaving the general
>>> region, the entire strings-table is destroyed as well.
>>>
>>> this is actually the strategy typically used in my compilers (many
>>> of my compiler stages each use their own localized heaps).
>>>
>>> the reason for doing this was that compilers tend to produce huge
>>> amounts of "garbage" all at once, and because using the main
>>> heap/GC tended to hurt performance too badly...
>>>
>>> if there is one thing the "hunk" strategy is good at, it is being
>>> fast (since an entire heap can be torn down nearly all at once, vs
>>> having to manage and individually free particular items...).
>>>
>>>
>>> so, alas, maybe this is why "conventions" are disliked...
>>> the idea of each separate major library and subsystem having its
>>> own mini subset of the C runtime...
>>>
>>> but, hell, it works for me...
>>>
>>> one just has to understand my naming conventions.
>>>
>>> simple hint:
>>> if using anything that does not use my "library" notation, and does
>>> not have the same name prefix as the other code around it, take
>>> caution...
>>> SXIL_
>>> BASM_
>>> BGBCC_
>>> ...
>>>
>>> if in "SXIL" one sees a function call with a "BGBCC" prefix, this
>>> itself is a flag for alarm...
>>>
>>> note "sxil" or "basm" is not as bad (since these are typically
>>> simple utility functions), but still cause for concern (for
>>> example, in the case of the string functions, they may intern the
>>> string in the wrong heap, or potentially none at all...).
>>>
>>> but, alas, a good portion of my "style" revolves around naming
>>> conventions...
>>
>> So that's why we C++ guys prefer std::string, which solves all of
>> this. :-)
>>
>
> yep...
>
> C++ is for those who can safely use it though...

This thread is getting too creepy for even my off-the-wall humor! (Do they
even make heftie bags at a mil thick enough?). (I didn't say it!).

== 5 of 10 ==
Date: Sat, Aug 1 2009 8:41 pm
From: "Tech07"

Nick Keighley wrote:
> On 31 July, 16:46, Juha Nieminen <nos...@thanks.invalid> wrote:
>> Nick Keighley wrote:
>
>>> what coding conventions does C typically use that C++ typically
>>> doesn't? Isn't the use of RAII a massive coding convention?
>>
>> No. RAII is certainly not a coding convention. It's a compiler
>> technique and has little to do with coding conventions. A coding
>> convention is something the *programmer* does, while RAII is
>> something the *compiler* does automatically.
>
> well, you've got to write your destructors correctly.
> I'd say using RAII correctly was very much a programmer
> thing.
>
> void process_pdu (const byte* pdu, size_t size)
> {
> Msg* msg = new Msg (pdu, size);
> process_msg (msg);
> delete msg;
> }
>
>> If, for example, I instantiate and manipulate a std::string in a
>> function, I don't need *any* coding conventions to make sure that the
>> string gets freed: The compiler is going to free it for me. I don't
>> have to do anything to achieve that.
>
> there are things other than strings
>
>> In C, however, if I use a dynamic string in a function, I have to
>> free it myself, and to avoid leaks in complicated functions I have
>> to use some coding principles to make sure that the string gets
>> freed no matter how the function is exited.
>>
>> That's precisely what I'm talking about: RAII aids me in avoiding a
>> useless coding convention which I would have to use in C to make the
>> my code safer.
>
> Oh,I'm not arging *against* RAII I'm simply saying using it
> and avoiding other exception unsafty requires some discipline
> (aka coding conventions)

And of course I don't believe in it one ioda until ... let's face it, it's
an it. It's history has already been written. (Y'all should have seen the
other 2 alternative posts! (yeah I saved the, I'm a saver)). ;)

== 6 of 10 ==
Date: Sat, Aug 1 2009 8:44 pm
From: "Tech07"

Juha Nieminen wrote:
> Nick Keighley wrote:

>> well, you've got to write your destructors correctly.

Now there is something for philosophers to chew on.

== 7 of 10 ==
Date: Sat, Aug 1 2009 8:49 pm
From: "Tech07"

BGB / cr88192 wrote:
> "Juha Nieminen" <nospam@thanks.invalid> wrote in message
> news:w0Hcm.217$sW4.146@read4.inet.fi...
>> BGB / cr88192 wrote:
>>> you seem to be opposing "coding conventions".
>>> coding conventions can be more or less equated with code being well
>>> written...
>>
>> I'm not opposing coding conventions. I use lots of coding
>> conventions when I develop programs.
>>
>> What I oppose are coding conventions which exist solely to get
>> around limitations of the language. These tend to make programs more
>> complex than they need to be.
>>
>> Yes, I readily admit that programming in C++ is in no way free of
>> necessary coding conventions which exist because of the limitations
>> of C++ (compared to many higher-level languages). My point is,
>> however, that in well-written C++ *less* coding conventions of this
>> type are needed compared to C, making development simpler. Also,
>> many of these coding conventions are more familiar to most
>> experienced C++ programmers and can be seen much more easily (eg.
>> because they are used by the C++ standard libraries and such). In C
>> most of these coding conventions are quite programmer-specific.
>>
>
> actually, I refer to what you call "programmer specific" as "style"...
>
> different programmers use different styles, yes, this much is granted.
>
> however, the point is that one recognize the various common styles,
> and use a style as appropriate for the code in question.
>
> I have my own style as well, which is sort of a combination of the
> Linux kernel, id, and OpenGL styles, or, another way: the Torvalds,
> John Carmack, and SGI styles...
>
>
> one can adhere to certain styles, such that their code looks nice and
> pleasing...
>
> so, beyond specific for particular coding conventions, style also
> encompasses matters like variable naming, the use of whitespace and
> other formatting issues, ...
>
> it is also a good way to spot "outsiders"...
>
>
> if (...) {
> ...
>
> "WTF is this?... go away weirdo..."
>
>
>>> why should one worry about more vs less conventions?...
>>
>> Because more coding conventions makes the program more difficult to
>> read and understand.
>>
>
> personally, I don't see it this way.
> the style and conventions are a good portion of the readability,
> IMO...
>
>> A coding convention is kind of "metalanguage" in the sense that you
>> are writing in your own "subset" of the programming language. You
>> use a kind of "meta-C" on top of the bare C programming language,
>> for the purpose of avoiding pitfalls and errors (such as memory
>> leaks, etc).
>
> granted...
>
>
>> The problem is that your "metalanguage" might not be immediately
>> obvious to someone reading your code and who doesn't know about your
>> coding conventions.
>>
>
> hence, "outsiders"...
>
> they are, naturally enough, to be viewed with suspicion, as they are
> bent on fouling up ones' code with their ways...
>
>
>> When these extra coding conventions are *not needed* (rather than
>> intentionally avoided), the code tends to be more straightforward and
>> simpler, without any hidden "metalanguage" being used.
>
> not sure why...
>
>
> my main reason for not going through all of the usual conventions is
> when quickly beating together something under the "make it work"
> goal...
> but typically, this sort of code tends to be ugly, buggy, and just
> generally horrid...
>
> and so, later, I clean it up...
>
>
>
> it is like being in a store, and noticing all the terribly ill-behaved
> children, and then being reminded of a certain rule: "children should
> be seen but not heard"...
>
> impulsive behavior and noise one year, is fornication and moral
> depravity the next...
>
> "he who spares the rod hates his son."
>

I think you two are a "match made in heaven", cuz you two are as annoying as
the show "Desperate Housewives". Bicker in private!

== 8 of 10 ==
Date: Sat, Aug 1 2009 9:01 pm
From: "Tech07"

Juha Nieminen wrote:
> Tech07 wrote:
>> My
>> secondary point was that RAII is only one stylistic approach one can
>> take in C++ as "one size fits all" is never true.
>
> Well, I have found that RAII fits at least 99% of sizes, and that's
> reason enough for me to prefer C++ over C. But that might be just me.

"There's that giant sucking sound again!". Who said that. Oh, it was me! Now
I know where to find a replacement carpet cleaner. But ya know, I don't even
like carpet. As a matter of fact, I hate it. Carpet (can you say "wall to
wall") is right up there with "paneled rec room designed by guido".

It's not just you: gold chains, chest hair, the 74 yr old guy on "America's
Got Talent". Does someone owe you something? (Read, common tactic by THEM).
"Life's a bitch, the you die". Right?

"RAII"? Let's investigate blind following by masses killed in the holocaust.
Or not.

== 9 of 10 ==
Date: Sat, Aug 1 2009 9:02 pm
From: "Tech07"

BGB / cr88192 wrote:

> GC is another strategy,

== 10 of 10 ==
Date: Sat, Aug 1 2009 9:16 pm
From: "Tech07"

Richard Herring wrote:
> In message <blocm.37761$0z7.25121@newsfe07.iad>, Tech07
> <tech07@nospam.hia> writes
>>
>> "Juha Nieminen" <nospam@thanks.invalid> wrote in message
>> news:Xsjcm.117$9g2.94@read4.inet.fi...
>>> Tech07 wrote:
>>>
>>>> but yes, C++ wrapper objects on the stack are very convenient for
>>>> this (though probably not as efficient since there is a ctor and
>>>> dtor call).
>>>
>>> There's nothing in constructors and destructors which would make
>>> them less efficient than equivalent C solutions. (For example an
>>> object with an empty inline constructor will probably produce no
>>> code at all.)
>>
>> Oh? A ctor call will be required for every auto-destroying object in
>> a function.
>>
>
> Why? If the compiler can deduce that calling the constructor will have
> no effect on observable behaviour, which it certainly can if the
> constructor i's inline and empty, by the "as-if" rule (ISO/IEC
> 14882:2003 1.9/1 [intro.execution]) it is under no obligation to call
> it.

So your stated has "achieved" putting a jump to a label into the compiler.
Whoo hoo~!!

==============================================================================
TOPIC: static inline functions - possible?
http://groups.google.com/group/comp.lang.c++/t/0386357e12bd0064?hl=en
==============================================================================

== 1 of 5 ==
Date: Sat, Aug 1 2009 7:56 pm
From: Stephen Horne

On Fri, 31 Jul 2009 14:25:05 +0200, "Balog Pal" <pasa@lib.hu> wrote:

>I worked with those separated inlines -- at a time made some myself, my net
>conclusion is it makes things worse.

From call sites, you only see the name. If the code is a better quick
description than the name, you probably shouldn't be using a function
at all - you are reducing the readability of callers for no good
reason. Having the code there at the declaration site should ideally
be redundant - clutter and distraction, rather than informative - and
therefore that clutter should be moved somewhere else.

Of course one problem with replying in threads like this is that you
can end up giving a falsely polarised misrepresentation of your actual
views. On a different day, and reading different posts first, I might
easily have made the same point you did.

Also, Java and C# require all method definitions to be kept with the
declarations, IIRC, whereas Ada takes the opposite view with strict
separation of specifications and bodies. The fact that different
languages take different extremist viewpoints without the world ending
probably suggests that it's a bit of a non-issue.

== 2 of 5 ==
Date: Sat, Aug 1 2009 8:21 pm
From: Stephen Horne

On Sat, 1 Aug 2009 00:35:32 -0500, Gerhard Fiedler <gelists@gmail.com>
wrote:

>When I have eight functions each a page long, I don't like them inside
>the declaration. Rips the context apart.

Why on Earth are you inlining page-long functions? That's a pretty
fair size limit for non-inlined functions.

For me, the issue is more width than length - can I reasonably fit the
whole definition on a single line. As soon as the one-line rule
breaks, I already need five lines, including the blank ones, as...

void mymethod1 () { ... }
void mymethod2 () { ... }

becomes...

void mymethod1 ()
{
...
}

void mymethod2 ()
{
...
}

An occasional multi-liner isn't a disaster, but if it really needs
multiple lines, it probably shouldn't be inline anyway.

== 3 of 5 ==
Date: Sat, Aug 1 2009 8:28 pm
From: Stephen Horne

On Sat, 01 Aug 2009 18:10:44 +1200, Ian Collins <ian-news@hotmail.com>
wrote:

>Gerhard Fiedler wrote:
>>
>> When I have eight functions each a page long, I don't like them inside
>> the declaration. Rips the context apart.
>
>When I have eight functions each a page long, I know I've done something
>wrong!

Not necessarily - moving complexity to the call-graph doesn't
eliminate it, and some functions really are just do-this then do-that
then do-the-other. A comment at the top of each chunk may make more
sense than splitting it up.

But page-long *inline* member functions...

To me, it suggests an ex-Java or C# programmer who hasn't absorbed a
certain key fact about C++.

== 4 of 5 ==
Date: Sat, Aug 1 2009 8:50 pm
From: Ian Collins

Stephen Horne wrote:
> On Sat, 01 Aug 2009 18:10:44 +1200, Ian Collins <ian-news@hotmail.com>
> wrote:
>
>> Gerhard Fiedler wrote:
>>> When I have eight functions each a page long, I don't like them inside
>>> the declaration. Rips the context apart.
>> When I have eight functions each a page long, I know I've done something
>> wrong!
>
> Not necessarily - moving complexity to the call-graph doesn't
> eliminate it, and some functions really are just do-this then do-that
> then do-the-other. A comment at the top of each chunk may make more
> sense than splitting it up.

One or two may be, but eight?

> To me, it suggests an ex-Java or C# programmer who hasn't absorbed a
> certain key fact about C++.

Or a PHP programmer.

--
Ian Collins

== 5 of 5 ==
Date: Sat, Aug 1 2009 9:17 pm
From: Stephen Horne

On Sun, 02 Aug 2009 15:50:24 +1200, Ian Collins <ian-news@hotmail.com>
wrote:

>Stephen Horne wrote:
>> On Sat, 01 Aug 2009 18:10:44 +1200, Ian Collins <ian-news@hotmail.com>
>> wrote:
>>
>>> Gerhard Fiedler wrote:
>>>> When I have eight functions each a page long, I don't like them inside
>>>> the declaration. Rips the context apart.
>>> When I have eight functions each a page long, I know I've done something
>>> wrong!
>>
>> Not necessarily - moving complexity to the call-graph doesn't
>> eliminate it, and some functions really are just do-this then do-that
>> then do-the-other. A comment at the top of each chunk may make more
>> sense than splitting it up.
>
>One or two may be, but eight?

I have a current example where the number is closer twenty. A DSL - a
source-to-source translater. Each method is basically just dumping out
a chunk of text with occasional substitutions etc using lots of stream
insertion.

Of course your reaction might well be that I should be using template
text files/resources with substitution markers, and getting most of
that out of the code completely. The reason I haven't done that yet is
that another DSL I'm writing is designed to handle template output
jobs such as this, and provide a bit more than a simple
substitute-these-markers transformation. Sadly, you can't use a DSL
until you've written the b*****d thing.

The worst thing is that I thought my existing regular grammar/state
machine compositing code would do the job - didn't think it through
properly. Now I have an issue which implies a significant change to
that model. What was supposed to be just-add-parser-and-text-output
has become a heada^H^H^H^H^H^H^H an interesting theory/design problem.

==============================================================================
TOPIC: ===Welcome to comp.lang.c++! Read this first.
http://groups.google.com/group/comp.lang.c++/t/f889a3e4648a1046?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 1 2009 9:30 pm
From: Shiva

Welcome to comp.lang.c++! Read this first.

This post is intended to give the new reader an introduction to reading
and posting in this newsgroup. We respectfully request that you read
all the way through this post, as it helps make for a more pleasant
and useful group for everyone.

First of all, please keep in mind that comp.lang.c++ is a group for discussion
of general issues of the C++ programming language, as defined by the ANSI/ISO
language standard. If you have a problem that is specific to a particular system
or compiler, you are much more likely to get complete and accurate answers in a
group that specializes in your platform. A listing of some newsgroups is given
at the end of this post.

The FAQ (Frequently Asked Question) list has a wealth of information for
both the new and veteran C++ programmer. No matter what your experience
level, you are encouraged to read the entire list, if only to familiarize
yourself with what answers are available to minimize redundant replies.
The comp.lang.c++ FAQ is available at http://www.parashift.com/c++-faq-lite/

If the FAQ list does not help, then many regular readers of this group
are happy to assist with problems of standard C++. We have only a few
requests that we ask be adhered to, for the benefit of all:

* Please put a short summary in the subject line. Descriptions such as
"HELP!!!!!!" are not helpful, and many regular posters ignore such
requests. A good example is, "Problem with Virtual Functions."

* State the question or the problem clearly and concisely. Describe what
you are trying to do, and the problem you are running into. Include all
relevant error messages.

* Include the smallest, complete and compilable program that exhibits your
problem. As a rule, posters in comp.lang.c++ will not do homework, but will
give helpful hints if you have shown some willingness to try a solution.

* comp.lang.c++ is forum for discussion, and as such some regular posters do
not give E-mail replies. Very often follow-ups to postings have corrections,
so plan on taking part in the discussion if you post a question. If you
do receive e-mail replies, it is considered polite to post a summary.

* Don't post in HTML format. Many readers of this newsgroup don't use
newsreaders which can handle HTML postings.

* If you have to include source code in your post, include the
source in the message body. Don't use attachments. A lot
of contributors to this newsgroup won't even notice the existence
of attachments or won't open them. You try to get any help
you can get, don't you?

Some netiquette topics which frequently crop up on comp.lang.c++ are
also answered in the FAQ.

* Should I post job advertisements and/or resumes on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.10

* What if I really need a job; should I post my resume on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.11

* What should I do to someone who posts something off-topic?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.12

A note on comp.lang.c++ etiquette: Accuracy is valued very highly in this
newsgroup; therefore posts are frequently corrected, sometimes perhaps
too harshly, and often to the annoyance of new posters who consider the
correction trivial. Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time.

This is a very busy group, so these requests are designed to make it as
pleasant and efficient an experience as possible. We hope it proves
a valuable commodity to you.

A list of some Newsgroups :
Languages and Programming
-------------------------
comp.lang.c The C Programming Language
comp.lang.asm.x86 x86 assembly language programming
comp.programming Non-language specific programming
comp.graphics.algorithms Issues of computer graphics

Operating Systems
-----------------
comp.os.msdos.programmer DOS, BIOS, Memory Models, interrupts,
screen handling, hardware
comp.os.ms-windows.programmer.win32 MS/Windows: Mice, DLLs, hardware
comp.os.os2.programmer.misc OS/2 Programming
comp.sys.mac.programmer.misc Macintosh Programming
comp.unix.programmer General Unix: processes, pipes, POSIX,
curses, sockets
comp.unix.[vendor] Various Unix vendors

Microsoft VC++
-------------
microsoft.public.vc.language VC++ issues
microsoft.public.vc.mfc MFC Issues
microsoft.public.dotnet.languages.vc C++/CLR Issues
microsoft.public.dotnet.framework .Net Framework

Borland C++ Builder
-------------------
borland.public.cppbuilder.language Borland C++ Builder
borland.public.cpp.language
borland.public.cppbuilder

-Shiva
http://www.slack.net/~shiva/welcome.txt

Sun Aug 2 00:30:00 EDT 2009

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en

To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

soft and program

Sunday, August 2, 2009

comp.lang.c++ - 17 new messages in 4 topics - digest

No comments:

Blog Archive

About Me