comp.lang.c - 25 new messages in 14 topics - digest

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

comp.lang.c@googlegroups.com

Today's topics:

* Letter sent to Apress with concerns about Peter Seebach's online behavior -
3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en
* Shorter Rot13 Pure-C Implementation - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/01d6c3202b93f929?hl=en
* Has thought been given given to a cleaned up C? Possibly called C+. - 2
messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* help,about the regular expression - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ffcb7bf9a8149a2f?hl=en
* Find the top level domain name from subdomain - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/6d0297d38b6cde6f?hl=en
* Container library (continued) - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
* Does GCC optimize variadic functions to death? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/00b2bccdde28fde4?hl=en
* Is allocating large objects on the stack a good practice? - 2 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/ce22843b03b7665b?hl=en
* posting to comp.lang.c - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/65d5493aa70b6031?hl=en
* Cheap Wholesale Chanel Handbags Purses LV GUCCI free shipping (www.
vipchinatrade.com) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/85fabbeb94e2c1f8?hl=en
* Idiotic programming style edicts - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
* Another style/readability question... - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/aeb4dff89a1caa49?hl=en
* VC 2005 died on template (part I) - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/c134c7676e673a28?hl=en
* VS 2005 died on template (part II) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/6e0ed54a8d2e8f9f?hl=en

==============================================================================
TOPIC: Letter sent to Apress with concerns about Peter Seebach's online
behavior
http://groups.google.com/group/comp.lang.c/t/482b38643777da3c?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 16 2010 11:46 pm
From: spinoza1111

On Mar 17, 11:58 am, Keith Thompson <ks...@mib.org> wrote:
> Bill Reid <hormelf...@gmail.com> writes:
>
> [...]
>
> > It's like the mating calls of two cuckoos between
> > those two...I saw that cuckoos were an endangered
> > species in the "C" group and wanted them to cross-breed
> > with our large population in misc.invest.stocks...
>
> So you thought comp.lang.c didn't have enough trolls, and
> deliberately brought us more?

Kiki, the case of the persecution of Java author Kathy Sierra by
www.meankids.org (look it up) shows that your mental model is
completely wrong.

In your mental model, good techs are sitting around in a newsgroup
discussing technology when in walk "trolls" who intend to disrupt, and
this attracts more trolls and soon enough, the newsgroup is filled
with burning tires and dancing trolls.

What appears to me to happen is that the "good" techs are corporate-
socialized to ignore their dark side, and they start over-reinforcing
a high opinion of their skills because of their success at dealing
with each other online. They unconsciously come to believe in a
seniority system as if in fact all sorts of people come here, with
wildly different educational attainments, natural ability, and time to
spend on questions and project. They come to expect subservience from
"newbies" as if this environment is like the company where they work
where often in fact new hires no less, about programming and/or the
company's way of doing business.

Not in touch with their darkness, and oversocialized to be, not polite
but repressed sexually and socially, they unconsciously put down
people who come in here more experienced in some or all areas than
they, or with programming styles, tics and shibboleths at variance
from their favorite. These people react, and in the resulting "flame
war" are blamed for exercising what would seem to be a human right of
verbal self-defense, the absence of which implies violence and chaos.

It's especially bad when people like you start running your foolish
mouths about these newbies being "trolls", because, as I shall not
cease from reminding you, that word is Nordic racism and was also used
as a slur in California against homeless people. If you call a person
a "n*r" he fights back. Likewise when you call a poster from mainland
China, asking good questions and taking a risk, a "troll".

Your lack of emotional control, which results directly from your
sexual and emotional repression, then attracts, as the www.meankids.org
attacks attracted, real loonies and thugs like Reid and Herbert
Rosenau here, because these people like blood and glass.

Kiki, last January, you reviewed and approved one line of C code
without finding an off by one bug. I suggest you start showing some
collegiality and humility, and stop using racist name-calling. It's
"reasonable, rational" people like you who are the problem, like the
so-called "good" Germans of the Holocaust who ignored the smoke from
Auschwitz.
>
> *PLONK*
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
> Nokia
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

== 2 of 3 ==
Date: Wed, Mar 17 2010 1:49 am
From: Lubow

On Mar 17, 2:46 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> Your lack of emotional control, which results directly from your
> sexual and emotional repression, then attracts, as thewww.meankids.org
> attacks attracted, real loonies and thugs like Reid and Herbert
> Rosenau here, because these people like blood and glass.

Please avoid X-posting to misc.invest.stocks (MIS).

March is adopt-a-psycho month. Do a good dead. Do a mitzvah. Adopt
Reid as your own. Keep him away from MIS.

Thanks.

== 3 of 3 ==
Date: Wed, Mar 17 2010 3:12 am
From: spinoza1111

On Mar 17, 5:28 am, John Bode <jfbode1...@gmail.com> wrote:
> On Mar 16, 1:32 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> > On 2010-03-16, John Bode <jfbode1...@gmail.com> wrote:
>
> > > So now who's engaging in defamation?
>
> > Ahh, yeah.  That seems to be the thing everyone runs into.
>
> > Interestingly, I've pointed out a few times that I am, in fact,
> > a professional programmer, and that a big hunk of what I do is write
> > code (although not all of it is in C -- I do a lot of shell, and a fair
> > bit of Very Dark Magic in GNU make).  
>
> You know, I knew that, but was tacitly awarding the point to Nilges in
> my response.  Bad me, no cookie.  I should have known better, and
> apologize for being a dipshit.

It appears to me based on Seebs' performance in the %s replace and the
one line string length that most of his work is script kidding. He
believes that it's a good thing to do things fast, if incredibly
carelessly, and without writing documentation upfront and neatly as I
do in order to make sure you are clear on the requirements (writing
them down).

Responsible quality work can be done in certain languages designed
recently enough to incorporate good practice, where those languages
are interpreted script languages. Rexx and Visual Basic, for example.
But my experience with shells on unix and makefiles shows me that
EITHER Peter is misusing an inferior tool to do far too much, or is
restricted to trivial filter making.

>
> > So at this point, it's not just
> > that Nilges is continuing to make false and defamatory statements about
> > me, but that he's doing so despite correction.
>
> But that's *different*, you see.  Nilges isn't committing the
> unpardonable sin of pointing out where you made mistakes in a
> published work.  He's just accusing you of launching a smear campaign
> to make your bones with the developer community, which is nothing,
> really.

I have made very, very serious accusations against Seebach, this is
true. In fact, based on what I've learned, I believe that he got to
where he is by attacking good people and buying his way onto the C99
standard as resume enhancement.

However, I came to this conclusion based on facts he has affirmed in
this newsgroup and in CLCM, and his online performance in coding,
which has been very poor compared to others here. And, while I think
his code is poorly formatted according to my personal preference for a
literate style, I do not base my case against his performance
exclusively or largely on that, but on the bugs in his code, and his
attitude towards those bugs.

His response to the % bug? He told us about it, but gave no sign that
he was going to fix it until we persuaded him to. And, any fix was a
hack because the entire solution, in script kiddie fashion, started
off on the wrong foot: it did a character search and correcting it,
while leaving the initial approach alone, required a lookahead with
provision for looking one past the end of the string. A sensible
approach, of course, would have used strstr().

Peter has chosen to mock me and others based on taking "too much time"
to code, which is characteristic of the script kiddie mentality, in
which no time is taken, for better or worse, to plan the code...in my
case by predocumenting the code. This is because he's uneducated in
computer science, which stresses the programmer's responsibility to be
clear on what he's doing. Unfortunately, the script kiddie psychology
has spread to "real" programming because in a de-industrialized
America being raped by finance capital, any sort of unauthorised
planning in excess of a constantly declining minimum threatens the
dominance of the wealthy. For this reason, programmers have learned,
as Peter has learned, to brag about writing buggy code quickly...even
when, as in this case, they're comparing "apples and oranges": Peter
coding on his employers' time and my coding during my commute.

>
> It's like lying under oath about having an affair vs. lying under oath
> about outing a covert intelligence agent.  The former is a gross
> affront to the rule of law and an impeachable offense, but the latter
> isn't even worth a slap on the wrist, much less jail time.
>
> What, me, bitter?  Perish the thought.
>
> > But fundamentally, as long as he's a sufficiently blatant kook that no
> > one will ever take those criticisms seriously, I don't see any reason to
> > care.  It's actually sort of funny.  I am beginning to regret having
> > plonked him, if only because I could use his quotes in my next performance
> > review.  :)

I will be delighted, Peter, to give your manager a written assessment
of your performance, and if you think, in some perverted way, that
this will help you because I'm crazy (which I am not), let me know by
email. I would dearly love to see you hoist by your own petard as soon
as one of the intelligent people in your office realize how you're
wasting time.
>
> Sort of a like a Bill "Wrong Way" Kristol for programmers, huh?

==============================================================================
TOPIC: Shorter Rot13 Pure-C Implementation
http://groups.google.com/group/comp.lang.c/t/01d6c3202b93f929?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 12:22 am
From: Michael Foukarakis

On Mar 16, 3:59 pm, i...@localhost.claranet.nl (Ike Naar) wrote:
> In article <63726442-cf05-41e2-b7e1-9c2a99755...@q23g2000yqd.googlegroups.com>,
> Michael Foukarakis  <electricde...@gmail.com> wrote:
>
> >On Mar 10, 2:09 am, i...@localhost.claranet.nl (Ike Naar) wrote:
> >> Perhaps you are also missing a bigger picture: if you are allowed to
> >> change the requirements, where does it end? You've stretched the
> >> requirements very far, in that your program no longer implements ROT13
> >> for a large class of input files.
>
> >He did not alter or stretch the requirements. He introduced an
> >additional constraint.
>
> Introducing additional constraints is not changing the requirements?
>
> > Making your input files compatible is that much easy:
>
> >echo -ne "0x00" >> input
>
> >I don't see how this is so hard to comprehend.
>
> ROT13 has the nice property that when you apply it twice to
> any input text, it will produce the original input.
> Actually this is an essential property, because ROT13 is often used
> as a (very simple) text encrypter/decrypter.
>
> Let's see what true ROT13 does to the eight-byte text "foo\0bar\n",
> that is: 'f', 'o', 'o', '\0', 'b', 'a', 'r', '\n'
>
>                 "foo\0bar\n"
>   ---ROT13--->
>                 "sbb\0one\n"
>   ---ROT13--->
>                 "foo\0bar\n"
>
> Nice!  Michael Schroeder's solution (on which OP's code is based)
> behaves exactly like that.
>
> Now take OP's program (extended with your preprocessor):
>
>                 "foo\0bar\n"
>   ---preproces--->
>                 "foo\0bar\n\0"
>   ---OP--->
>                 "sbb"
>   ---preprocess--->
>                 "sbb\0"
>   ---OP--->
>                 "foo"
>
> Whoops, we lost five bytes. Not so nice.
>
> >> If you find that acceptable, then why not stretch it a bit further?
> >> "main(){}" implements ROT13 as well, as long as the input is short enough.
>
> >No, since it doesn't process input at all, it doesn't implement ROT13
> >for ANY input.
>
> "main(){}" works perfectly okay for zero-sized input.
> Imposing zero size is just an additional constraint ;-)

If you don't wish to understand my arguments, please refrain from
addressing me. I've only got so much time to waste.

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 17 2010 12:24 am
From: Jonathan Leffler

On 3/16/10 8:49 AM, Richard Bos wrote:
> jacob navia <jacob@spamsink.net> wrote:
>
>> Richard Delorme a =E9crit :
>>> Obviously the standard library could be improved, at least by removing=20
>>> dangerous function like gets() or stupid functions like strncpy and=20
>>> making all functions thread safe. It might also be made simpler by=20
>>> removing useless type like size_t.
>>> =20
>> This is already in the future standard. Most functions of the Microsoft
>> safe library proposal are accepted in the standard library.
>
> Oh, lord, I hope not. Replacing a mild gap with an inordinate crock is
> _not_ an improvement, no matter what Mickeysoft fans may say.

The proposed extra functions are currently in TR24731-1.

They are not all identical to the Microsoft functions of the same name.

In particular, Microsoft's vsnprintf_s() has a different signature from
the TR-24731 version. This, of course, means that there is no point in
trying to use the TR-24731 functions to provide portability between
non-Microsoft and Microsoft.

TR 24731-1 (http://www.open-std.org/JTC1/SC22/WG14/www/projects#24731-1)
says the interface to vsnprintf_s() is:

#define _ _STDC_WANT_LIB_EXT1_ _ 1
#include <stdarg.h>
#include <stdio.h>
int vsnprintf_s(char * restrict s, rsize_t n,
const char * restrict format, va_list arg);

Unfortunately, MSDN
(http://msdn.microsoft.com/en-us/library/d3xd30zz%28VS.80%29.aspx) says
the interface to vsnprintf_s() is:

int vsnprintf_s(
char *buffer,
size_t sizeOfBuffer,
size_t count,
const char *format,
va_list argptr
);

Parameters

* buffer - Storage location for output.
* sizeOfBuffer - The size of the buffer for output.
* count - Maximum number of characters to write (not including the
terminating null), or _TRUNCATE.
* format - Format specification.
* argptr - Pointer to list of arguments.

Note that this is not simply a matter of type mapping: the number of
fixed arguments is different, and therefore irreconcilable. It is also
unclear to me (and presumably to the standards committee too) what
benefit there is to having both 'sizeOfBuffer' and 'count'; it looks
like the same information twice (or, at least, code will commonly be
written with the same value for both parameters).

Sad!

Jonathan Leffler
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 2 of 2 ==
Date: Wed, Mar 17 2010 12:25 am
From: Nick <3-nospam@temporary-address.org.uk>

cri@tiac.net (Richard Harter) writes:

> On Tue, 16 Mar 2010 10:47:08 -0500 (CDT), Nick Keighley
> <nick_keighley_nospam@hotmail.com> wrote:
>
>>On 15 Mar, 23:44, Ian Collins <ian-n...@hotmail.com> wrote:
>>> On 03/16/10 12:24 PM, Richard Delorme wrote:
>>
>>> > Forward function declaration should be added to my list of things to
>>> > remove.
>>>
>>> Why?
>>
>>how?!
>>
>>How would mutual recursion work? Or separate compilation? What about
>>those weird people who put main() at the beginning of their
>>compilation units?
>
> Mutual recursion is simple unless you are fixated on one pass
> compilers. Forward function declarations (signatures) are needed
> for separate compilation.

So I think we are all agreed that removing the need for forward
declarations for static functions is very easy (just a second pass of
the source file). For separate compilation they are needed in the
header file, or some sort of compiler magic to generate a header file is
needed.

I'd quite like to see the first one, I don't think the second is worth
the effort.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

==============================================================================
TOPIC: help,about the regular expression
http://groups.google.com/group/comp.lang.c/t/ffcb7bf9a8149a2f?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 1:42 am
From: Nick Keighley

On 17 Mar, 05:02, "jk" <jiku...@gmail.com> wrote:

> Hello everyone,I want know what are the fellowing regular
> expressions,describing the tokens in the C language,  mean
> to ?
> L?'(\\.|[^\\'\n])+'
> and
> L?\"(\\.|[^\\"\n])*\"
> in which
> L [a-zA-Z_]

you perhaps need to take this somewhere that deals with regular
expressions. A Unix news group maybe?

==============================================================================
TOPIC: Find the top level domain name from subdomain
http://groups.google.com/group/comp.lang.c/t/6d0297d38b6cde6f?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 1:43 am
From: Nick Keighley

On 17 Mar, 04:48, susi <susmit...@gmail.com> wrote:

>     Are there any utility to find the top-level domain name from the
> subdomian url.
> Can any one help me?

this is off-topic to comp.lang.c, please try elsewhere

==============================================================================
TOPIC: Container library (continued)
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Mar 17 2010 1:45 am
From: jacob navia

Andrew Poelstra a écrit :
>
> The reason I don't like the first option is that is restricts extensibility.
> If I used your libraries, but decided I didn't like your hash table (IME
> hash tables have the most to gain by /not/ being generalized) I would be in
> the position of handing one allocator to my hash table, and one allocator
> to all N of your classes.
>

Mmm this is a good point. I did not think about that.

Obviously, the solution is (if we retain a single global object) that each class contains a pointer
to a specific allocator for the class. If that pointer is NULL (default situation), we use the
global object. If it is not NULL, it is assumed that it points to a similar table of functions
(malloc/free/realloc) that the user has set up for this class.

Within this schema, it is still easy to change the global behavior of all objects, but subclasssing
with a custom allocator is still easy and is NOT affected by any changes in the global behavior.

Thanks for your contribution.
jacob

== 2 of 5 ==
Date: Wed, Mar 17 2010 1:46 am
From: jacob navia

ng2010 a écrit :
> So sad to be dying and seeing youth tackling problems already solved in
> my own youth.
>
>
You misunderstand. I am not trying to invent a new way of doing those things. I am trying to invent
a generalized standard way of doing that in C. This has never been done before for C.

== 3 of 5 ==
Date: Wed, Mar 17 2010 1:58 am
From: Nick Keighley

On 17 Mar, 04:22, "ng2010" <ng2...@att.invalid> wrote:
> So sad to be dying and seeing youth tackling problems already solved in
> my own youth.

and the solution was? I'm not convinced there *is* a single right
answer for all situations.

== 4 of 5 ==
Date: Wed, Mar 17 2010 2:01 am
From: Nick Keighley

On 16 Mar, 23:07, jacob navia <ja...@spamsink.net> wrote:

> Data allocation strategies for containers can vary wildly, depending on
> the specific container and on the application. Environment
> considerations play also a major role: if there is enough RAM many
> things can be handled QUITE differently than when there isn't.
>
> It is impossible to find a strategy that can be always good in all
> situations, so naturally, we need an object with (roughly) 3 function
> pointers:
>
> (1) MALLOC
> (2) FREE
> (3) REALLOC
>
> This table of functions will be used by a container for
> allocating/releasing memory. It will default to the standard C
> functions, but can be changed so that a GC is used, for instance. In
> that case we would have
>
> MALLOC --> GC_malloc
> FREE   --> no operation
> REALLOC --> GC_realloc.
>
> Now, should this object be a global part of the library, i.e. a single
> allocation object for the whole library, or should each container class
> (hash tables, lists, dictionaries) have one, or should each individual
> container have one?
>
> If we have a single global object, changing the behavior of our
> containers is very easy, we have a single object to change and we are
> done. Obviously, this is VERY global and forces the user to have always
> the same allocation strategy for all containers.
>
> If we have a per class of container design, we have more flexibility, we
> could use the GC for hash tables but not for lists, etc. The price to
> pay is increased difficulty to change the behavior of all objects... To
> change from the default object to the GC, for instance, we would have to
> go through all container classes. True, the library could provide a
> function to do that, but if we add a container we would have to modify
> that function again and again.
>
> If we have an allocation object per individual container we have the
> maximum flexibility but changing the allocation  strategy becomes QUITE
> complicated.
>
> Personally, I think that is easier to understand the first option:
> having a single object that allocates/frees memory. It is rare that we
> would want to use a GC, say, and at the same time malloc/free at the
> same time.
>
> Obviously I am not sure, hence this message. What do you think?

both? That is a global allocation object that is the default allocator
that can be over-ridden on a per container basis.

If I have a number of small conatiners and a single gigantic container
maybe only gigantic container needs a special memory allocator. I
could imagine containers needing special memory (eg. for DMA).

Also the STL does it this way...

== 5 of 5 ==
Date: Wed, Mar 17 2010 2:11 am
From: Dr Malcolm McLean

> Now, should this object be a global part of the library, i.e. a single
> allocation object for the whole library, or should each container class
> (hash tables, lists, dictionaries) have one, or should each individual
> container have one?
>
Most of the time user won't really care abput the memory allocation
strategy wants. So the default should be to use some sensible scheme
(probably stdlib malloc) and to kep this away from the user.
However you can provide a function to set the defaults for all
containers. It should apply only to containers created after the call.
Then you can also provide special contructors that take memory
management function pointers as arguments. Most of the time these
won't be used, but they provide fine control to those who need it.

==============================================================================
TOPIC: Does GCC optimize variadic functions to death?
http://groups.google.com/group/comp.lang.c/t/00b2bccdde28fde4?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 2:19 am
From: Nick Keighley

On 16 Mar, 15:18, Seebs <usenet-nos...@seebs.net> wrote:

> <stdarg.h> is your friend, and has been available for roughly twenty
> years.

and before that there was varargs which i believe gave "semi-"
portability. I like the quote (from memory unfortunatly) from
Plauger's library book

"...in the early days everyone knew how Richie's compiler laid out the
arguments in memory so it was a simple excercise in pointer arithmatic
to walk the argument list"

>  The thing you were doing before was never portable or guaranteed,
> and there have been targets where it would never, ever, have worked -- that
> it worked at all was pure coincidence, and given how much it's confused
> you, I'd call it a pretty unfortunate coincidence.

==============================================================================
TOPIC: Is allocating large objects on the stack a good practice?
http://groups.google.com/group/comp.lang.c/t/ce22843b03b7665b?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 17 2010 2:37 am
From: Nick Keighley

On 16 Mar, 15:31, la...@ludens.elte.hu (Ersek, Laszlo) wrote:

> Additionally,
> res_construct() can participate in an even-higher level _init() routine.

isn't _init() in a reserved namespace? Or close to one anyway.

== 2 of 2 ==
Date: Wed, Mar 17 2010 2:38 am
From: Nick Keighley

On 16 Mar, 13:57, Michael Tsang <mikl...@gmail.com> wrote:

> [...] I know that, writing code that does not leak is
> VERY difficult in C. (In C++, the objects allocates memory only in the
> constructor and deallocates memory only in the destructor so the problem is
> not so serious).

whilst this is good practice C++ does not compel you to do this

==============================================================================
TOPIC: posting to comp.lang.c
http://groups.google.com/group/comp.lang.c/t/65d5493aa70b6031?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 2:41 am
From: "ptkrisada@gmail.com"

Hi all,

I'm new to google groups.
I received mails in digest mode.
How do I post to comp.lang.c using mail client.
I tried sending e-mails to comp.lang.c@googlegroups.com many times.
All failed.

Thanks,
Pete

==============================================================================
TOPIC: Cheap Wholesale Chanel Handbags Purses LV GUCCI free shipping (www.
vipchinatrade.com)
http://groups.google.com/group/comp.lang.c/t/85fabbeb94e2c1f8?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 2:52 am
From: NICEYOYO

AAA true leather Handbags
Cheap Wholesale Balenciaga Handbags <www.vipchinatrade.com paypal
payment>
Cheap Wholesale Balenciaga Purse
Cheap Wholesale Bally Purse <free shipping paypal payment>
Cheap Wholesale BOSS Purse <www.vipchinatrade.com paypal payment>
Cheap Wholesale Burberry Handbags
Cheap Wholesale Chanel Handbags <free shipping paypal payment>
Cheap Wholesale Chanel Purse
Cheap Wholesale Chloe Handbags
Cheap Wholesale Chloe Purse <free shipping paypal payment>
Cheap Wholesale Coach Handbags
Cheap Wholesale Coach Purse <www.vipchinatrade.com paypal payment>
Cheap Wholesale D&G Handbags
Cheap Wholesale D&G Purse
Cheap Wholesale Dior Handbags <free shipping paypal payment>
Cheap Wholesale Dunhill Purse
Cheap Wholesale Fendi Handbags <free shipping paypal payment>
Cheap Wholesale Gucci Handbags <www.vipchinatrade.com paypal
payment>
Cheap Wholesale Gucci Purse
Cheap Wholesale Hermes Handbags
Cheap Wholesale Hermes Purse <free shipping paypal payment>
Cheap Wholesale Jimmy Choo Handbags <free shipping paypal
payment>
Cheap Wholesale Jimmy Choo Purse <free shipping paypal payment>
Cheap Wholesale Juicy Handbags <www.vipchinatrade.com paypal
payment>
Cheap Wholesale Kooba Handbags
Cheap Wholesale Lancel Handbags
Cheap Wholesale Loewe Handbags <www.vipchinatrade.com paypal
payment>
Cheap Wholesale LV Handbags <free shipping paypal payment>
Cheap Wholesale LV Purse <free shipping paypal payment>
Cheap Wholesale Marc Jacobs Handbags <www.vipchinatrade.com paypal
payment>
Cheap Wholesale Miumiu Handbags
Cheap Wholesale Mulberry Handbags
Cheap Wholesale Prada Handbags <free shipping paypal payment>
Cheap Wholesale Prada Purse
Cheap Wholesale Thomaswlde Handbags <www.vipchinatrade.com paypal
payment>
Cheap Wholesale Valentnv Handbags
Cheap Wholesale Versace Handbags <www.vipchinatrade.com paypal
payment>

A+ Grade
Purse
Discount Wholesale Anna Purse <free shipping paypal payment>
Discount Wholesale Burbetty Purse
Discount Wholesale Chanel Purse <www.vipchinatrade.com >
Discount Wholesale Chloe Purse
Discount Wholesale Coach Purse <www.vipchinatrade.com >
Discount Wholesale D&G Purse
Discount Wholesale Dior Purse <www.vipchinatrade.com >
Discount Wholesale Dooney&Bourke Purse
Discount Wholesale ED Hardy Purse <www.vipchinatrade.com >
Discount Wholesale Fendi Purse
Discount Wholesale Ferragmo Purse
Discount Wholesale Gucci Purse <www.vipchinatrade.com >
Discount Wholesale Guess Purse
Discount Wholesale LV Purse <free shipping paypal payment>
Discount Wholesale Miumiu Purse
Discount Wholesale Prada Purse <www.vipchinatrade.com >
Discount Wholesale Tous Purse
Discount Wholesale Versace Purse <www.vipchinatrade.com > <free
shipping paypal payment>
Handbags
Discount Wholesale BOSS Handbag
Discount Wholesale Burberry Handbag <www.vipchinatrade.com >
Discount Wholesale CA Handbag
Discount Wholesale Chanel Handbag <free shipping paypal payment>
Discount Wholesale Chloe Handbag <www.vipchinatrade.com >
Discount Wholesale Coach Handbag
Discount Wholesale D&G Handbag <www.vipchinatrade.com >
Discount Wholesale Dooney&Bourke Handbag
Discount Wholesale ED Hardy Handbag <www.vipchinatrade.com >
Discount Wholesale Fendi Handbag
Discount Wholesale Gucci Handbag <www.vipchinatrade.com >
Discount Wholesale Hermes Handbag
Discount Wholesale Jimmy Choo Handbag <free shipping paypal
payment>
Discount Wholesale Juciy Handbag
Discount Wholesale LV Handbag <www.vipchinatrade.com >
Discount Wholesale Miumiu Handbag <www.vipchinatrade.com >
Discount Wholesale Prada Handbag
Discount Wholesale Tous Handbag <www.vipchinatrade.com >
Discount Wholesale Versace Handbags <free shipping paypal payment>

==============================================================================
TOPIC: Idiotic programming style edicts
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Mar 17 2010 2:52 am
From: Nick Keighley

On 16 Mar, 18:13, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> In article <IU.D20100316.T165150.P1185...@J.de.Boyne.Pollard.localhost>,
> Jonathan de Boyne Pollard  <J.deBoynePollard-newsgro...@NTLWorld.COM> wrote:

> >>> If an obscure technique is being employed, then a comment to that
> >>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments
> >>> along the following lines ...
>
> >>> x := X + 1  ; increment x
>
> A true CLC pedantic would point out that the above does not increment x
> (unless x and X have the same value).

it plainly isn't C. Perhaps in whatever-it-is-written-in cares about
case.

What *is* it written in?

> >>> ... which only serve to increase the noise floor.
>
> >> In our shop, those appeared when we got the idiotic edict that each
> >> line had to have a comment.
>
> >Such edicts make one want to write code in the form
>
> >     x  /* The variable x */
> >     =  /* is assigned */
> >     x  /* its value * /
> >     +  /* plus * /
> >     2  /* two */
> >     ;   /* . */
>
> Correction applied.  HTH.

#include "crlzyzz.h" /* obvious meaning */

if it's obvious, why did you comment it?

== 2 of 3 ==
Date: Wed, Mar 17 2010 5:03 am
From: jmfbahciv

Jonathan de Boyne Pollard wrote:
>>
>>>
>>> If an obscure technique is being employed, then a comment to that
>>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments
>>> along the following lines ...
>>>
>>> x := X + 1 ; increment x
>>>
>>> ... which only serve to increase the noise floor.
>>>
>> In our shop, those appeared when we got the idiotic edict that each
>> line had to have a comment.
>>
> Such edicts make one want to write code in the form
>
> x /* The variable x */
> = /* is assigned */
> x /* its value * /
> + /* plus * /
> 2 /* one */
> ; /* . */
>
And would make all tapes spill over to two magtapes.

Fortunately, your code would produce many detected errors.

/BAH

== 3 of 3 ==
Date: Wed, Mar 17 2010 5:05 am
From: jmfbahciv

ImpalerCore wrote:
> On Mar 16, 2:40 pm, Andrew Poelstra <apoels...@localhost.localdomain>
> wrote:
>> On 2010-03-16, ImpalerCore <jadil...@gmail.com> wrote:
>>
>>
>>
>>> On Mar 16, 12:51 pm, Jonathan de Boyne Pollard <J.deBoynePollard-
>>> newsgro...@NTLWorld.COM> wrote:
>>>>>> If an obscure technique is being employed, then a comment to that
>>>>>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments
>>>>>> along the following lines ...
>>>>>> x := X + 1 ; increment x
>>>>>> ... which only serve to increase the noise floor.
>>>>> In our shop, those appeared when we got the idiotic edict that each
>>>>> line had to have a comment.
>>>> Such edicts make one want to write code in the form
>>>> x /* The variable x */
>>>> = /* is assigned */
>>>> x /* its value * /
>>>> + /* plus * /
>>>> 2 /* one */
>>>> ; /* . */
>>> It also shows that maintaining these kinds of comment are more trouble
>>> than the comment is worth. The maintenance of these comments is way
>>> higher than the information they give, i.e. Who forgot to change the '/
>>> * one */' to '/* two */'?
>> x /* The pointer */
>> -> /* equals */
>> x /* itself */
>> = /* minus */
>> 2 /* five */
>> ; /* :( */
>
> Then you start questioning which is right, the comment or the code,
> which can end up leading to a lot more work to figure it out.
>
This code is unreadable. One of the reasons I don't like HLLs for
basic OS coding. It's very nice to be able to scan the listing
just like the CPU would do when executing.

/BAH

==============================================================================
TOPIC: Another style/readability question...
http://groups.google.com/group/comp.lang.c/t/aeb4dff89a1caa49?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 3:04 am
From: Nick Keighley

On 16 Mar, 14:46, "jackassp...@gmail.com" <jackassp...@gmail.com>
wrote:

> >If you have "lots" of variables, it may be that your
> >function is trying to do too much and would be better off
> >being split into multiple functions.  "May be," not "is."
>
> There is magic there. I haven't yet the experience to know when this
> is occurring. All in due time...

try writing a short discription of what the function does as viewed
from the outside. Give enough information so that a caller could use
your function only being able to see the prototype and your
description.

"loads cards and file information from the specified streams. Performs
validation and time-checking. Then parses the file data according to a
fixed regexp."

Everytime you start a new sentence or use a conjuction ("slurp file
data AND perform a twisty function AND resublimate the thiotoluene")
that implies your function is doing too much and should be broken up.

This is a rule-of-thumb and not an absolute rule. Also worry if you've
got more that 5 or 6 parameters or more than a couple of pages of code
or your 'if' nesting has made an 80 column layout unbearable.

K&R is full of small powerful functions. read it as a guide to good
design.

==============================================================================
TOPIC: VC 2005 died on template (part I)
http://groups.google.com/group/comp.lang.c/t/c134c7676e673a28?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 17 2010 3:22 am
From: Alex

template <int i> struct Factorial {
enum { N = i<=0? 1 : i*Factorial<i-1>::N };
};
template <> struct Factorial <-500> { enum { N = 1 }; };
const int factorial=Factorial<5>::N;

== 2 of 2 ==
Date: Wed, Mar 17 2010 4:34 am
From: jt@toerring.de (Jens Thoms Toerring)

Alex <alexey.d.zaitsev@gmail.com> wrote:
> template <int i> struct Factorial {
> enum { N = i<=0? 1 : i*Factorial<i-1>::N };
> };
> template <> struct Factorial <-500> { enum { N = 1 }; };
> const int factorial=Factorial<5>::N;

If you want to discuss C++ you should post to comp.lang.c++ and
not comp.lang.c (which is for C, a different language). And if
your compiler is broken then you probably best talk to whoever
produced it since then it's not a laguage issue but a quality
of implementation issue.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

==============================================================================
TOPIC: VS 2005 died on template (part II)
http://groups.google.com/group/comp.lang.c/t/6e0ed54a8d2e8f9f?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 17 2010 3:27 am
From: Alex

template <class T> void S(){ T t; }
struct A{ A(){} }; // died
//struct A{ ~A(){} }; // died
//struct A{void a(){}}; // not died
void kill(){
struct B{A a;};
S<B>();
}
void bill(){
struct B{A a;};
S<B>();
}

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

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