twitter: comp.lang.c - 25 new messages in 8 topics

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

comp.lang.c@googlegroups.com

Today's topics:

* Fn Defn Style - 15 messages, 8 authors
http://groups.google.com/group/comp.lang.c/t/dfafc3c6b4eaaec1?hl=en
* Advanced data structures - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/2edd7d58412b2f69?hl=en
* pointers question - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/71f169a822944fea?hl=en
* http://www.find68.com cheaper nike shoes g-satr kidrobot hoodies ed hardy
star red monkey gino green global true religion ed-hardy kidrobot jeans
hoodies china supplier wholesaler exporters,manufacture - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/1e0e55c94d762551?hl=en
* ๑۩๑۩๑ cheap wholesale pants belts bikinis underwear at www.ecyaya.com - 2
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/857a6b47721392fb?hl=en
* Pointer to inside an array - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/227c21b5449d807c?hl=en
* Models Fashon Top Hot Sexy - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/f7c366b6328f960f?hl=en
* return x = 0; // under C99 for volatile x - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/5a1cee7ec0f064c1?hl=en

==============================================================================
TOPIC: Fn Defn Style
http://groups.google.com/group/comp.lang.c/t/dfafc3c6b4eaaec1?hl=en
==============================================================================

== 1 of 15 ==
Date: Tues, Dec 15 2009 6:55 am
From: Tom St Denis

On Dec 15, 9:12 am, Richard <rgrd...@gmail.com> wrote:
> Yet again your assumptions are totally wrong.
>
> And who said anything about ALL functions locked up in 2 files? Also,
> did you never bother to investigate more modern RCS which can handle
> hunks from within a file? A file is nothing more than a user view of
> data anyway in more advanced set ups....

I've worked with git, svn, cvs, and even clearcase. Collisions happen
all the time and they're nasty. That's why file locks exist. The
fewer resources you lock the better.

> > appreciate faster turn-around on build/rebuild cycles. You'd be an
> > idiot not to.
>
> Yes, but its another one of your straw men. My point is that your
> arbitrary 500 line limit is bullshit.

First, let me do my impression of you. "ZOMG TOM SAID SOMETHING THAT
I CAN DISAGREE WITH, *drool*, *wipe face*, I SIMPLY HAVE TO POST A
REPLY!!!!"

Then, I never said it was a hard written in stone limit. I have hand
written files that span into 6-7-8 hundred lines long. As a general
rule though if you're writing something [by hand] that gets over 500
lines, there is very likely [but not always] a chance to re-factor the
code to make it easier to work with [and/or a chance for code re-
use].

That's the difference between people like me [with experience] and
people like you [think they know everything]. We can say things like
"most files shouldn't be longer than 500 lines" and understand that it
means "most files shouldn't be super long because you'll probably be
able to factor the code better and achieve code reuse." Whereas you,
with little experience didn't know about that sort of development
strategy and just assumed that I meant "all files must be less than
500 lines because compilers can't handle 501 lines."

tl;dr, sometimes you just have to know when to shut up.

Tom

== 2 of 15 ==
Date: Tues, Dec 15 2009 8:04 am
From: Seebs

On 2009-12-15, Tom St Denis <tom@iahu.ca> wrote:
> Spoken like someone who either works alone or without a content/
> version control system. Suppose you have 20 people on a team and all
> of your source is locked in 2 files. What do the 18 other people
> do?

Advocate switching to git.

-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 3 of 15 ==
Date: Tues, Dec 15 2009 8:06 am
From: Tom St Denis

On Dec 15, 11:04 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-12-15, Tom St Denis <t...@iahu.ca> wrote:
>
> > Spoken like someone who either works alone or without a content/
> > version control system. Suppose you have 20 people on a team and all
> > of your source is locked in 2 files. What do the 18 other people
> > do?
>
> Advocate switching to git.

No matter the tool, if two people are working on the same bit of code
nothing good will result. If you have 50 functions in one file and
you're not all working on the same functions, sure collisions might
not happen...

Tom

== 4 of 15 ==
Date: Tues, Dec 15 2009 8:33 am
From: Squeamizh

On Dec 15, 6:55 am, Tom St Denis <t...@iahu.ca> wrote:
> On Dec 15, 9:12 am, Richard <rgrd...@gmail.com> wrote:
>
> > Yet again your assumptions are totally wrong.
>
> > And who said anything about ALL functions locked up in 2 files? Also,
> > did you never bother to investigate more modern RCS which can handle
> > hunks from within a file? A file is nothing more than a user view of
> > data anyway in more advanced set ups....
>
> I've worked with git, svn, cvs, and even clearcase. Collisions happen
> all the time and they're nasty. That's why file locks exist. The
> fewer resources you lock the better.
>
> > > appreciate faster turn-around on build/rebuild cycles. You'd be an
> > > idiot not to.
>
> > Yes, but its another one of your straw men. My point is that your
> > arbitrary 500 line limit is bullshit.
>
> First, let me do my impression of you. "ZOMG TOM SAID SOMETHING THAT
> I CAN DISAGREE WITH, *drool*, *wipe face*, I SIMPLY HAVE TO POST A
> REPLY!!!!"
>
> Then, I never said it was a hard written in stone limit. I have hand
> written files that span into 6-7-8 hundred lines long. As a general
> rule though if you're writing something [by hand] that gets over 500
> lines, there is very likely [but not always] a chance to re-factor the
> code to make it easier to work with [and/or a chance for code re-
> use].
>
> That's the difference between people like me [with experience] and
> people like you [think they know everything]. We can say things like
> "most files shouldn't be longer than 500 lines" and understand that it
> means "most files shouldn't be super long because you'll probably be
> able to factor the code better and achieve code reuse." Whereas you,
> with little experience didn't know about that sort of development
> strategy and just assumed that I meant "all files must be less than
> 500 lines because compilers can't handle 501 lines."
>
> tl;dr, sometimes you just have to know when to shut up.

There is a cost associated with what you're advocating. Shorter files
implies more files, which adds complexity. At the very least, you'll
need more "glue" in the form of extern declarations and prototypes,
which makes code harder for your coworkers to follow and maintain.
Maybe my experience is unique, but I have found that "judicious
refactoring" of code that a large teams works on causes more problems
than it solves, as it forces everyone to become reacquainted with the
design du jour. Obviously, code reuse is good, but it is only
achieved if the other members of your team know where the code is and
what the functions are called. Getting (re)acquainted with code takes
time and effort.

When I'm writing something alone, I do find that the benefits of heavy
refactoring outweigh the added complexity.

What does "tl;dr" mean?

== 5 of 15 ==
Date: Tues, Dec 15 2009 8:52 am
From: Tom St Denis

On Dec 15, 11:33 am, Squeamizh <sque...@hotmail.com> wrote:
> On Dec 15, 6:55 am, Tom St Denis <t...@iahu.ca> wrote:
>
>
>
> > On Dec 15, 9:12 am, Richard <rgrd...@gmail.com> wrote:
>
> > > Yet again your assumptions are totally wrong.
>
> > > And who said anything about ALL functions locked up in 2 files? Also,
> > > did you never bother to investigate more modern RCS which can handle
> > > hunks from within a file? A file is nothing more than a user view of
> > > data anyway in more advanced set ups....
>
> > I've worked with git, svn, cvs, and even clearcase. Collisions happen
> > all the time and they're nasty. That's why file locks exist. The
> > fewer resources you lock the better.
>
> > > > appreciate faster turn-around on build/rebuild cycles. You'd be an
> > > > idiot not to.
>
> > > Yes, but its another one of your straw men. My point is that your
> > > arbitrary 500 line limit is bullshit.
>
> > First, let me do my impression of you. "ZOMG TOM SAID SOMETHING THAT
> > I CAN DISAGREE WITH, *drool*, *wipe face*, I SIMPLY HAVE TO POST A
> > REPLY!!!!"
>
> > Then, I never said it was a hard written in stone limit. I have hand
> > written files that span into 6-7-8 hundred lines long. As a general
> > rule though if you're writing something [by hand] that gets over 500
> > lines, there is very likely [but not always] a chance to re-factor the
> > code to make it easier to work with [and/or a chance for code re-
> > use].
>
> > That's the difference between people like me [with experience] and
> > people like you [think they know everything]. We can say things like
> > "most files shouldn't be longer than 500 lines" and understand that it
> > means "most files shouldn't be super long because you'll probably be
> > able to factor the code better and achieve code reuse." Whereas you,
> > with little experience didn't know about that sort of development
> > strategy and just assumed that I meant "all files must be less than
> > 500 lines because compilers can't handle 501 lines."
>
> > tl;dr, sometimes you just have to know when to shut up.
>
> There is a cost associated with what you're advocating. Shorter files
> implies more files, which adds complexity. At the very least, you'll
> need more "glue" in the form of extern declarations and prototypes,
> which makes code harder for your coworkers to follow and maintain.
> Maybe my experience is unique, but I have found that "judicious
> refactoring" of code that a large teams works on causes more problems
> than it solves, as it forces everyone to become reacquainted with the
> design du jour. Obviously, code reuse is good, but it is only
> achieved if the other members of your team know where the code is and
> what the functions are called. Getting (re)acquainted with code takes
> time and effort.
>
> When I'm writing something alone, I do find that the benefits of heavy
> refactoring outweigh the added complexity.

Well presumably your exported functions will have corresponding
entries in header files anyways. So yeah there are more entries in
your makefile but that's more than made up for in the quicker builds
and easier content management.

I actually find it easier to have separate functions in separate files
because I tend to think of files as ideas or algorithms. One file may
perform elliptic curve point addition, while another does doubling.
That way if I'm in the mood to review the point addition code I just
look at that. As opposed to opening a 3000 line file and finding the
function I need and having to see the other code in the process...

Even when writing applications [I tend to work on libraries more] I
separate out the re-usable code into libraries inside the source tree
for the application. So in essence the application is merely a user
interface or driver for the functionality provided by the libraries.
Like we recently wrote an app with crypto and DB functionality. So we
had a libcert.a for crypto and libdb.a for our DB retrieve/store
functions. The actual app customers used was a relatively short piece
of code that parses command line options and makes use of the two
libraries. In this case we re-used the crypto lib for another part of
the project.

The trick is to have a solid design to start with, then document as
you go. In our group, we're all expected to contribute and READ the
SDK user guides. So "keeping up" with development is just part of the
job. Of course if you don't document anything I can see how your
coworkers can get lost...

> What does "tl;dr" mean?

"too long, didn't read." It's used for when you ramble on and want to
sum it up for the impatient.

Tom

== 6 of 15 ==
Date: Tues, Dec 15 2009 8:57 am
From: cri@tiac.net (Richard Harter)

On Tue, 15 Dec 2009 04:33:49 -0800 (PST), Tom St Denis
<tom@iahu.ca> wrote:

>On Dec 15, 6:55=A0am, Richard <rgrd...@gmail.com> wrote:
>> "bartc" <ba...@freeuk.com> writes:
>> > Tom St Denis wrote:
>> >> On Dec 12, 3:31 pm, Nick <3-nos...@temporary-address.org.uk> wrote:
>>
>> >> Why not just re-factor your code so there are fewer functions per
>> >> file. =A0Limiting yourself to one exported function per file is handy =
>to
>> >> help there. =A0Of course there are static functions, but in reality,
>> >> most source files should be less than 500 lines at most anyways
>>
>> > Why? Isn't having up to ten times as many source files lying around (ev=
>en
>> > forgetting the problems with private functions, variables and namespace=
>s),
>> > going to be more hassle than longer source files (and half the time you=
>'re
>> > hardly aware of the size of the file).
>>
>> Tom appears to be stuck in the ark with regard to his toolsets. The size
>> of a file should not be consideration within normal limits related to
>> todays HW unless it severely impacts compilation for example. When
>> navigating around code I rarely bother noticing which file its in for
>> example.
>
>Spoken like someone who either works alone or without a content/
>version control system. Suppose you have 20 people on a team and all
>of your source is locked in 2 files. What do the 18 other people
>do?

That would be a very peculiar project. The code base for a 20
person team would be on the order of 100,000 lines of code. Few
projects keep their code in two 50,000 line files.

More to the point, many small files, few larger files is a
natural consequence of orthogonality of file purpose. That is,
in good software practice (IMNSHO) each file implements a well
defined functionality and each such functionality goes in its own
file.

Decent version control systems let you generate reports that tell
you how often each file is altered. The results are fairly
consistent across a wide variety of projects - most of the change
action is in a small minority of files. Sometimes, of course, a
file may be revised many times because it is badly written.
However, most projects seem to have hot spot functionality, i.e.,
places that are strongly impacted as the project grows and
changes shape.

What it comes down to is that maxims like "most source files
should be less than 500 lines" have it the wrong way around,
rather like trying to steer a donkey by grabbing its tail. Take
care of your software structure and your file sizes will take
care of themselves.

>
>Also, I work on a quad-core AMD box with 4GB of ram. I still
>appreciate faster turn-around on build/rebuild cycles. You'd be an
>idiot not to.
>
>Tom

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Infinity is one of those things that keep philosophers busy when they
could be more profitably spending their time weeding their garden.

== 7 of 15 ==
Date: Tues, Dec 15 2009 9:04 am
From: "bartc"

Tom St Denis wrote:
> On Dec 15, 6:55 am, Richard <rgrd...@gmail.com> wrote:
>> "bartc" <ba...@freeuk.com> writes:
>>> Tom St Denis wrote:
>>>> On Dec 12, 3:31 pm, Nick <3-nos...@temporary-address.org.uk> wrote:
>>
>>>> Why not just re-factor your code so there are fewer functions per
>>>> file. Limiting yourself to one exported function per file is handy
>>>> to help there. Of course there are static functions, but in
>>>> reality, most source files should be less than 500 lines at most
>>>> anyways
>>
>>> Why? Isn't having up to ten times as many source files lying around
>>> (even forgetting the problems with private functions, variables and
>>> namespaces), going to be more hassle than longer source files (and
>>> half the time you're hardly aware of the size of the file).
>>
>> Tom appears to be stuck in the ark with regard to his toolsets. The
>> size of a file should not be consideration within normal limits
>> related to todays HW unless it severely impacts compilation for
>> example. When navigating around code I rarely bother noticing which
>> file its in for example.
>
> Spoken like someone who either works alone or without a content/
> version control system. Suppose you have 20 people on a team and all
> of your source is locked in 2 files. What do the 18 other people
> do?
>
> Also, I work on a quad-core AMD box with 4GB of ram. I still
> appreciate faster turn-around on build/rebuild cycles. You'd be an
> idiot not to.

Does it really take that much longer to compile 5000 lines instead of 500?
(My files are typically 5000 lines and take a fraction of a second to
compile.)

And how does it affect building other than making it take longer because of
having to deal with hundreds of files instead of dozens?

(I don't know how these things work in teams; maybe only one member has
build/run privileges? Or can anyone build and test a project that includes
half-finished modules from other team members? Or does each person just
test, independently, a small portion of the project in a test setup. That
still doesn't explain this arbitrary file line-limit.)

--
Bartc

== 8 of 15 ==
Date: Tues, Dec 15 2009 9:20 am
From: Keith Thompson

Tom St Denis <tom@iahu.ca> writes:
> On Dec 15, 6:33 am, "bartc" <ba...@freeuk.com> wrote:
>> Tom St Denis wrote:
>> > On Dec 12, 3:31 pm, Nick <3-nos...@temporary-address.org.uk> wrote:
>> > Why not just re-factor your code so there are fewer functions per
>> > file. Limiting yourself to one exported function per file is handy to
>> > help there. Of course there are static functions, but in reality,
>> > most source files should be less than 500 lines at most anyways
>>
>> Why? Isn't having up to ten times as many source files lying around (even
>> forgetting the problems with private functions, variables and namespaces),
>> going to be more hassle than longer source files (and half the time you're
>> hardly aware of the size of the file).
>
> Generally you want fewer functions per file for numerous reasons
>
> 1. Makes it easier to work with others in a version control system,
> as you lock a smaller percentage of the code at any given time.

Most modern version control systems don't lock files; they allow
two different people to work on the same file at the same time.
But typically the last person to check in the file has to merge
the changes. If the changes are isolated from each other, this is
straightforward; if not, you'd have the same merging problem with
one function per file.

> 2. It speeds up build/rebuild times while testing new code
> 3. It makes it easier to "smart" link code as not all linker can do
> per function linking, they're usually per object file.
> 4. I find it generally easier to work on smaller files, specially
> when what I'm looking for isn't hidden in the middle of a 3,000 line
> file... but that's just MHO.

Some text editors (Emacs in particular) have a mode in which you
can temporarily narrow the visible portion of a file, working on
a subset as if it were an entire file. (And I just learned
that there's a vim plugin that does the same thing.)

> Usually, the smart thing to do is sort your source tree with these
> things called directories. So finding files should be easy.

Unless you've got thousands of them.

--
Keith Thompson (The_Other_Keith) kst-u@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"

== 9 of 15 ==
Date: Tues, Dec 15 2009 9:34 am
From: Richard

Tom St Denis <tom@iahu.ca> writes:

> On Dec 15, 11:04 am, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2009-12-15, Tom St Denis <t...@iahu.ca> wrote:
>>
>> > Spoken like someone who either works alone or without a content/
>> > version control system. Suppose you have 20 people on a team and all
>> > of your source is locked in 2 files. What do the 18 other people
>> > do?
>>
>> Advocate switching to git.
>
> No matter the tool, if two people are working on the same bit of code
> nothing good will result. If you have 50 functions in one file and
> you're not all working on the same functions, sure collisions might
> not happen...
>
> Tom

A little like your views on Macros your views seem based on nothing
more than your own gut feeling which in turn are based on your own
limited experiences.

I have worked on huge projects where certain key files might be
branched 4 or 5 times.

Please, learn about the tools before commenting.

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

== 10 of 15 ==
Date: Tues, Dec 15 2009 9:40 am
From: Richard

Tom St Denis <tom@iahu.ca> writes:

> On Dec 15, 9:12 am, Richard <rgrd...@gmail.com> wrote:
>> Yet again your assumptions are totally wrong.
>>
>> And who said anything about ALL functions locked up in 2 files? Also,
>> did you never bother to investigate more modern RCS which can handle
>> hunks from within a file? A file is nothing more than a user view of
>> data anyway in more advanced set ups....
>
> I've worked with git, svn, cvs, and even clearcase. Collisions happen
> all the time and they're nasty. That's why file locks exist. The
> fewer resources you lock the better.

Yet you dont seem to know how they work. It is quite usual for many
people to work on the same files. Its why these systems exist.

>
>> > appreciate faster turn-around on build/rebuild cycles. You'd be an
>> > idiot not to.
>>
>> Yes, but its another one of your straw men. My point is that your
>> arbitrary 500 line limit is bullshit.
>
> First, let me do my impression of you. "ZOMG TOM SAID SOMETHING THAT
> I CAN DISAGREE WITH, *drool*, *wipe face*, I SIMPLY HAVE TO POST A
> REPLY!!!!"

Well, it's a poor impression. Yes, I disagree with you. Because you're
wrong.

>
> Then, I never said it was a hard written in stone limit. I have hand

But you still came out with it.

> written files that span into 6-7-8 hundred lines long. As a general

That's nice.

> rule though if you're writing something [by hand] that gets over 500
> lines, there is very likely [but not always] a chance to re-factor the
> code to make it easier to work with [and/or a chance for code re-
> use].

Extra files can also introduce extra complexity.

>
> That's the difference between people like me [with experience] and
> people like you [think they know everything]. We can say things like

It wasn't me making all sorts of rules : it was you. I'm a programmer
for a long time and have worked on a lot of systems. But it's you
showing off about your experience and you making the rules I see. First
we have you condemning inline functions, and now large files. Yeah, I am
playing devils advocate a bit - but primarily because I find your
arguments weak and similar to those small minded people who insits only
their coding style will suffice.

> "most files shouldn't be longer than 500 lines" and understand that it
> means "most files shouldn't be super long because you'll probably be
> able to factor the code better and achieve code reuse." Whereas you,
> with little experience didn't know about that sort of development

You dont know anything about my experience. It is, needless to say,
considerably more than you assume.

> strategy and just assumed that I meant "all files must be less than
> 500 lines because compilers can't handle 501 lines."

I never said compilers couldnt handle 501. You produce yet another straw
man.

Files can be split based on functional partitioning. To split BECAUSE
its more than 500 lines is ridiculous with modern RCS and navigation
tools.

>
> tl;dr, sometimes you just have to know when to shut up.

I suspect you should take your own advice as you are clearly starting to
shout and yell and stomp your oh so experienced little feet.

>
> Tom

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

== 11 of 15 ==
Date: Tues, Dec 15 2009 9:42 am
From: Richard

Tom St Denis <tom@iahu.ca> writes:

> On Dec 15, 11:33 am, Squeamizh <sque...@hotmail.com> wrote:
>> On Dec 15, 6:55 am, Tom St Denis <t...@iahu.ca> wrote:
>>
>>
>>
>> > On Dec 15, 9:12 am, Richard <rgrd...@gmail.com> wrote:
>>
>> > > Yet again your assumptions are totally wrong.
>>
>> > > And who said anything about ALL functions locked up in 2 files? Also,
>> > > did you never bother to investigate more modern RCS which can handle
>> > > hunks from within a file? A file is nothing more than a user view of
>> > > data anyway in more advanced set ups....
>>
>> > I've worked with git, svn, cvs, and even clearcase. Collisions happen
>> > all the time and they're nasty. That's why file locks exist. The
>> > fewer resources you lock the better.
>>
>> > > > appreciate faster turn-around on build/rebuild cycles. You'd be an
>> > > > idiot not to.
>>
>> > > Yes, but its another one of your straw men. My point is that your
>> > > arbitrary 500 line limit is bullshit.
>>
>> > First, let me do my impression of you. "ZOMG TOM SAID SOMETHING THAT
>> > I CAN DISAGREE WITH, *drool*, *wipe face*, I SIMPLY HAVE TO POST A
>> > REPLY!!!!"
>>
>> > Then, I never said it was a hard written in stone limit. I have hand
>> > written files that span into 6-7-8 hundred lines long. As a general
>> > rule though if you're writing something [by hand] that gets over 500
>> > lines, there is very likely [but not always] a chance to re-factor the
>> > code to make it easier to work with [and/or a chance for code re-
>> > use].
>>
>> > That's the difference between people like me [with experience] and
>> > people like you [think they know everything]. We can say things like
>> > "most files shouldn't be longer than 500 lines" and understand that it
>> > means "most files shouldn't be super long because you'll probably be
>> > able to factor the code better and achieve code reuse." Whereas you,
>> > with little experience didn't know about that sort of development
>> > strategy and just assumed that I meant "all files must be less than
>> > 500 lines because compilers can't handle 501 lines."
>>
>> > tl;dr, sometimes you just have to know when to shut up.
>>
>> There is a cost associated with what you're advocating. Shorter files
>> implies more files, which adds complexity. At the very least, you'll
>> need more "glue" in the form of extern declarations and prototypes,
>> which makes code harder for your coworkers to follow and maintain.
>> Maybe my experience is unique, but I have found that "judicious
>> refactoring" of code that a large teams works on causes more problems
>> than it solves, as it forces everyone to become reacquainted with the
>> design du jour. Obviously, code reuse is good, but it is only
>> achieved if the other members of your team know where the code is and
>> what the functions are called. Getting (re)acquainted with code takes
>> time and effort.
>>
>> When I'm writing something alone, I do find that the benefits of heavy
>> refactoring outweigh the added complexity.
>
> Well presumably your exported functions will have corresponding
> entries in header files anyways. So yeah there are more entries in
> your makefile but that's more than made up for in the quicker builds
> and easier content management.
>
> I actually find it easier to have separate functions in separate files
> because I tend to think of files as ideas or algorithms.

I knew this would be your base reason. And its ridiculous. A function
name is more than enough partitioning. How you think of functions is
silly. I suspect it comes from some antiquated notion of how RCS should
work.

What next? C++ member functions in separate files in subdirs
representing their class.

== 12 of 15 ==
Date: Tues, Dec 15 2009 9:46 am
From: Richard

cri@tiac.net (Richard Harter) writes:

> On Tue, 15 Dec 2009 04:33:49 -0800 (PST), Tom St Denis
> <tom@iahu.ca> wrote:
>
>>On Dec 15, 6:55=A0am, Richard <rgrd...@gmail.com> wrote:
>>> "bartc" <ba...@freeuk.com> writes:
>>> > Tom St Denis wrote:
>>> >> On Dec 12, 3:31 pm, Nick <3-nos...@temporary-address.org.uk> wrote:
>>>
>>> >> Why not just re-factor your code so there are fewer functions per
>>> >> file. =A0Limiting yourself to one exported function per file is handy =
>>to
>>> >> help there. =A0Of course there are static functions, but in reality,
>>> >> most source files should be less than 500 lines at most anyways
>>>
>>> > Why? Isn't having up to ten times as many source files lying around (ev=
>>en
>>> > forgetting the problems with private functions, variables and namespace=
>>s),
>>> > going to be more hassle than longer source files (and half the time you=
>>'re
>>> > hardly aware of the size of the file).
>>>
>>> Tom appears to be stuck in the ark with regard to his toolsets. The size
>>> of a file should not be consideration within normal limits related to
>>> todays HW unless it severely impacts compilation for example. When
>>> navigating around code I rarely bother noticing which file its in for
>>> example.
>>
>>Spoken like someone who either works alone or without a content/
>>version control system. Suppose you have 20 people on a team and all
>>of your source is locked in 2 files. What do the 18 other people
>>do?
>
> That would be a very peculiar project. The code base for a 20
> person team would be on the order of 100,000 lines of code. Few
> projects keep their code in two 50,000 line files.

Like most of Tom's arguments it is based on shouting loudly and
exaggeration.

>
> More to the point, many small files, few larger files is a
> natural consequence of orthogonality of file purpose. That is,
> in good software practice (IMNSHO) each file implements a well
> defined functionality and each such functionality goes in its own
> file.
>
> Decent version control systems let you generate reports that tell
> you how often each file is altered. The results are fairly
> consistent across a wide variety of projects - most of the change
> action is in a small minority of files. Sometimes, of course, a
> file may be revised many times because it is badly written.
> However, most projects seem to have hot spot functionality, i.e.,
> places that are strongly impacted as the project grows and
> changes shape.
>
> What it comes down to is that maxims like "most source files
> should be less than 500 lines" have it the wrong way around,
> rather like trying to steer a donkey by grabbing its tail. Take
> care of your software structure and your file sizes will take
> care of themselves.

Exactly. Noe that I am not suggesting all files should be larger than
500 lines ... that is yet another straw man from Tom to defend his
rather antiquated stance.

>
>>
>>Also, I work on a quad-core AMD box with 4GB of ram. I still
>>appreciate faster turn-around on build/rebuild cycles. You'd be an
>>idiot not to.
>>
>>Tom
>
> Richard Harter, cri@tiac.net
> http://home.tiac.net/~cri, http://www.varinoma.com
> Infinity is one of those things that keep philosophers busy when they
> could be more profitably spending their time weeding their garden.

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

== 13 of 15 ==
Date: Tues, Dec 15 2009 9:50 am
From: Ben Pfaff

Tom St Denis <tom@iahu.ca> writes:

> Spoken like someone who either works alone or without a content/
> version control system. Suppose you have 20 people on a team and all
> of your source is locked in 2 files. What do the 18 other people
> do?

The other 18 people have plenty of time to learn how to break up
a program into modules and to use and maintain a version control
system.
--
Ben Pfaff
http://benpfaff.org

== 14 of 15 ==
Date: Tues, Dec 15 2009 10:07 am
From: Tom St Denis

On Dec 15, 12:40 pm, Richard <rgrd...@gmail.com> wrote:
> Yet you dont seem to know how they work. It is quite usual for many
> people to work on the same files. Its why these systems exist.

Provided they don't touch overlapping sections of code. Yeah I agree
there won't be problems. But if people are doing a code review and
touching up things here and there it's easy to collide. That's why
locking a file is easier, it prevents this problem. Now if you lock a
file with huge segments of your project your boned.

Not to forget to mention the build time speedups, which is usually
fairly invaluable.

> > Then, I never said it was a hard written in stone limit. I have hand
>
> But you still came out with it.

It's HOW you reacted to it that is important. You threw away any
possible reasonable interpretation and went directly for "he must mean
the compiler can't handle large files." And you didn't do that
because you're being difficult, you did that because you don't know
better.

> Extra files can also introduce extra complexity.

Not really. It takes me all of 5 seconds to add a source file to a
makefile. Takes another 2 seconds to import it to CVS. Adding files
to a well maintained source tree is really easy.

> It wasn't me making all sorts of rules : it was you. I'm a programmer
> for a long time and have worked on a lot of systems. But it's you
> showing off about your experience and you making the rules I see. First
> we have you condemning inline functions, and now large files. Yeah, I am
> playing devils advocate a bit - but primarily because I find your
> arguments weak and similar to those small minded people who insits only
> their coding style will suffice.

Well I'm not a "programmer." I'm a developer. So it's my job to not
only write software but produce maintainable and manageable source
trees that stand the test of time. That includes proper tree layout,
documentation, API design rules, etc. I don't just sit and write for
loops all day long like your typical code monkey.

> > strategy and just assumed that I meant "all files must be less than
> > 500 lines because compilers can't handle 501 lines."
>
> I never said compilers couldnt handle 501. You produce yet another straw
> man.
>
> Files can be split based on functional partitioning. To split BECAUSE
> its more than 500 lines is ridiculous with modern RCS and navigation
> tools.

It's a rule of thumb. Stop being so obtuse. I said that chances are
if you're writing a SINGLE function that approaches 500 lines that
chances are good you can factor functionality out of it. That doesn't
mean there aren't exceptions. But it's a very common rookie mistake
to put all your code in one basket. 500 was just a number I pulled
out of thin air too. You can obviously factor smaller functions.

But you're being obtuse for argumentative sake...

Tom

== 15 of 15 ==
Date: Tues, Dec 15 2009 10:10 am
From: Tom St Denis

On Dec 15, 12:42 pm, Richard <rgrd...@gmail.com> wrote:
> I knew this would be your base reason. And its ridiculous. A function
> name is more than enough partitioning. How you think of functions is
> silly. I suspect it comes from some antiquated notion of how RCS should
> work.
>
> What next? C++ member functions in separate files in subdirs
> representing their class.

Depends on the length and complexity. You seem to be of the school
where longer compilation times == greater success. That sort of
thinking leads to people bragging about "2 million lines of code" and
"8 hour build times" ...

I consider it a design flaw if changing a single line of code results
in a turn around time [after an initial build] of longer than 5
seconds [+/- a few for network traffic].

I also don't code in C++ because I've never found a use for it. But
that's another topic for another usenet group for another day.

Tom

==============================================================================
TOPIC: Advanced data structures
http://groups.google.com/group/comp.lang.c/t/2edd7d58412b2f69?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Dec 15 2009 7:30 am
From: cri@tiac.net (Richard Harter)

On Sat, 12 Dec 2009 10:44:53 GMT, Bruce Cook
<bruce-usenet@noreplybicycle.synonet.comnoreply> wrote:

>bartc wrote:
>
>>
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>[...]
>> There might be more apt languages than C (not everyone is comfortable with
>> zero-based indexing for example), but if it's a choice between 'MIX' and
>> C, then C wins.
>
>I'm interested in why you'd pick zero-based indexing as something people
>would specifically have problems with in C.
>
>I personally find zero-based indexing fairly natural, other languages which
>1 based indexing such as Fortran and Cobol used to bug me, especially after
>I had started programming in C and "knew there was a better way" :)
>
>zero based indexing certainly makes more sense mathematically.

From a mathematical viewpoint, 1 based is appropriate for
counting elements and 0 based for counting/measuring intervals.

== 2 of 3 ==
Date: Tues, Dec 15 2009 8:09 am
From: Keith Thompson

jacob navia <jacob@nospam.org> writes:
> Nick Keighley a écrit :
>>
>> I'd have thought the cost would be at compile time. Just add one (or
>> whatever) to the base address.
>>
>> [Incidently I don't expect to win a "zero-indexing is bad" argument in
>> clc but it's fun trying]
>
> The programming language APL had a system variable QuadIO, for Index
> Origin that would be either 1 or 0. It was systematically added to
> all array indices, and allowed you to start arrays indices either
> with 1 or zero, as you wish.

Perl also has (had) a system variable, set to 0 by default,
that determines the index of the first element in an array.
It's hardly ever used, and its use is strongly discouraged.
(Perl-arrays are 0-based.)

This isn't an argument for or against 0-based or 1-based indexing;
controlling it via a language-defined global variable was a bad idea.

== 3 of 3 ==
Date: Tues, Dec 15 2009 9:25 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

jacob navia <jacob@spamsink.net> writes:
>"Advanced data structures" from Peter Brass.

From a technical point of view, there is no means to tell,
how "advanced" a data structure is, it depends on the
reader, whether he

- deems a data structure to be "advanced",

- deems this data structure not to be "advanced" or

- is unable or unwilling to assess wether a
given data struture is "advanced".

A more technical and objective title might be
�graph processing in C�, since the books seems to deal with
lists and trees (IIRC), which are special kinds of graphs.

==============================================================================
TOPIC: pointers question
http://groups.google.com/group/comp.lang.c/t/71f169a822944fea?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 15 2009 8:05 am
From: Seebs

On 2009-12-15, annalissa <aarklon@gmail.com> wrote:
> On Dec 14, 6:23 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> No. For one thing ++*p++ is parsed as if it were ++(*(p++)). Postfix
>> operators bind more tightly than prefix ones.

> nope i don't think so , what about maximal munch rule ? , why it can't
> be applied here ?

It can, but all that applies to is tokens. Maximal munch is why that's
++ * p ++
not, say,
+ + * p + +

It has nothing to do with precedence.

==============================================================================
TOPIC: http://www.find68.com cheaper nike shoes g-satr kidrobot hoodies ed
hardy star red monkey gino green global true religion ed-hardy kidrobot jeans
hoodies china supplier wholesaler exporters,manufacture
http://groups.google.com/group/comp.lang.c/t/1e0e55c94d762551?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 15 2009 8:34 am
From: zengqunhai

www.find68.com
Christmas sale, free shipping discounts are beautifully gift

Christmas is approaching, your Christmas gifts ready? wownicesales
mall for you, which involves a number of well-known brands from the
Asia-Pacific region the trend of merchandise. Promotional discounts
should be, come SHOPPING bar!

In order to meet the arrival of Christmas. Our company has been in
order to return the old customers of the Company for their support.

Overall direct sales business. Wholesale price of a rare opportunity.
You are still hesitant about. Chance only once.
Not to be missed.

(I)Our Company is Online store, and we vogu emalls offer top quality
sport shoes, famous brand shoes and sportswear at good price.

(II) I n the past 6 years, we have sent great many products to the
customers in USA, Europe, ASIA and other area, also we have lots of
experience in dealing with online business oversea

(III) Generally, Goods are delivered in fast and safety way Of
course, shoes and clothing will be packaged in original box with tags

www.find68.com

New to Hong Kong : Winter Dress

---**** NHL Jersey Woman $ 40 ---**** NFL Jersey $ 35
---**** NBA Jersey $ 34 ---**** MLB Jersey $ 35
---**** Jordan Six Ring_m $36 ---**** Air Yeezy_m $ 45
---**** T-Shirt_m $ 25 ---**** Jacket_m $ 36
---**** Hoody_m $ 50 ---**** Manicure Set $ 20 ... ...

HOT SELL Product Brand is below:
Nike Air Jordan(1-25)/Jordan Six Ring/Jordan Fusion/Nike Shox/
Air Max/AF1/Dunk: $32
airmax 90, 95 etc $35-42 free shiping.
boots: UGG etc $60 free shiping.
Jeans : polo etc $35-49 free shipping
T-shirts : A&f etc $12-18 free shipping.
hoodies: 5ive etc $28-40 free shipping
handbags: Ed hardy etc $35-68 free shipping
Sunglasses: LV etc $17 free shipping
Belts: BOSS etc $15 free shipping
Caps: red bull etc $12-15 free shipping
Watches:rolex etc $80 free shipping

Wel come to S hopping www.find68.com

==============================================================================
TOPIC: ๑۩๑۩๑ cheap wholesale pants belts bikinis underwear at www.ecyaya.com
http://groups.google.com/group/comp.lang.c/t/857a6b47721392fb?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Dec 15 2009 8:57 am
From: hero

๑۩๑۩๑ cheap wholesale pants belts bikinis underwear at www.ecyaya.com

fahionable pants
cheap wholesale A&F Pants with high quality and low price on www.ecyaya.com
cheap wholesale Affliction Pants with high quality and low price on
www.ecyaya.com
cheap wholesale Artful Dodger Pants with high quality and low price on
www.ecyaya.com
cheap wholesale Bape Pants with high quality and low price on www.ecyaya.com
cheap wholesale BBC Pants with high quality and low price on www.ecyaya.com
cheap wholesale Christian Audigier Pants with high quality and low
price on www.ecyaya.com
cheap wholesale Coogi Pants with high quality and low price on www.ecyaya.com
cheap wholesale ED Hardy Pants with high quality and low price on
www.ecyaya.com
cheap wholesale Evisu Pants with high quality and low price on www.ecyaya.com
cheap wholesale RMC Pants with high quality and low price on www.ecyaya.com

cool belts
the hottest Afflirtion Belt with high quality and low price on www.ecyaya.com
the hottest Armani Belt with high quality and low price on www.ecyaya.com
the hottest Bape Belt with high quality and low price on www.ecyaya.com
the hottest Boss Belt with high quality and low price on www.ecyaya.com
the hottest Burberry Belt with high quality and low price on www.ecyaya.com
the hottest C.D Belt with high quality and low price on www.ecyaya.com
the hottest Chanel Belt with high quality and low price on www.ecyaya.com
the hottest CK Belt with high quality and low price on www.ecyaya.com
the hottest D&G Belt with high quality and low price on www.ecyaya.com
the hottest Diesel Belt with high quality and low price on www.ecyaya.com
the hottest DSQ Belt with high quality and low price on www.ecyaya.com
the hottest ED Belt with high quality and low price on www.ecyaya.com
the hottest Gucci Belt with high quality and low price on www.ecyaya.com
the hottest Hermes Belt with high quality and low price on www.ecyaya.com
the hottest Levfs Belt with high quality and low price on www.ecyaya.com
the hottest LV Belt with high quality and low price on www.ecyaya.com
the hottest Polo Belt with high quality and low price on www.ecyaya.com
the hottest Prada Belt with high quality and low price on www.ecyaya.com
the hottest Versace Belt with high quality and low price on www.ecyaya.com

beautiful bikinis
cheap wholesale Bureriy Swimming with high quality and low price on
www.ecyaya.com
cheap wholesale Chanel Swimming with high quality and low price on
www.ecyaya.com
cheap wholesale Ed Hardy Swimming with high quality and low price on
www.ecyaya.com
cheap wholesale Gucci Swimming with high quality and low price on
www.ecyaya.com
cheap wholesale LV Swimming with high quality and low price on www.ecyaya.com
cheap wholesale Touse Swimming with high quality and low price on
www.ecyaya.com

well-selling underwear
cheap wholesale A&F Underwear with high quality and low price on
www.ecyaya.com
cheap wholesale Armani Underwear with high quality and low price on
www.ecyaya.com
cheap wholesale BOSS Underwear with high quality and low price on
www.ecyaya.com
cheap wholesale CK Underwear with high quality and low price on www.ecyaya.com
cheap wholesale Ed Hardy Underwear with high quality and low price on
www.ecyaya.com
cheap wholesale LV Underwear with high quality and low price on www.ecyaya.com

== 2 of 2 ==
Date: Tues, Dec 15 2009 8:57 am
From: hero

๑۩๑۩๑ cheap wholesale pants belts bikinis underwear at www.ecyaya.com

==============================================================================
TOPIC: Pointer to inside an array
http://groups.google.com/group/comp.lang.c/t/227c21b5449d807c?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 15 2009 9:24 am
From: mohangupta13

On Dec 15, 4:03 pm, Alok Singhal <gandalf...@gmail.com> wrote:
> Hi,
>
> Let's say I have:
>
> int a[20] = {0};
>
> Is the declaration below legal according to C89?
>
> int (*p)[5] = (int (*)[5])(a+6);
As far as i think (i am not 100% certain though) its legal. But in
this case only (p+2)[3] can be safely addressed for storing values.

Mohan

==============================================================================
TOPIC: Models Fashon Top Hot Sexy
http://groups.google.com/group/comp.lang.c/t/f7c366b6328f960f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 15 2009 9:39 am
From: nazmul hossain

hello how are you, please go my site & enjoy _Models Fashon Top Hot
Sexy_
news and Award information,Go Now....
http://allmedia24h.blogspot.com/

==============================================================================
TOPIC: return x = 0; // under C99 for volatile x
http://groups.google.com/group/comp.lang.c/t/5a1cee7ec0f064c1?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Dec 15 2009 9:49 am
From: Francois Grieu

Hi, consider:

volatile unsigned char x;
unsigned char foo(void) { return x = 0; }

Assuming conformant C99, when foo is executed, is the value returned
a) allways 0
b) what was read from x after x has been written with 0
c) unspecified.

TIA,
François Grieu

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

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

twitter

Tuesday, December 15, 2009

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

0 Comments:

Post a Comment

About Me

Previous Posts