«

On Oct 1, 4:45*pm, "BartC" <b...@freeuk.com> wrote:
> "nroberts" <roberts.n...@gmail.com> wrote in message
>
> news:138d547d-36d2-44f2-b1c5-...
>
> > For example, we have a somewhat predictable in size but
> > constantly changing string the we have to construct. *I proposed that
> > we consider a buffer that grows with each call so that we pay minimal
> > cost in performance but yet never have to predict or worry about the
> > size of this string again. *He agreed we should discuss it but was
> > busy so I took a day and implemented it. *Had it under unit tests,
> > valgrind, etc...it worked. *I find though that he has no room for this
> > construct and would prefer to use a statically sized character array
> > and error out if we hit the end for some reason.
>
> But if you had a dynamically changing string, would you impose any upper
> bound on the size?
>
> If not, then some temporary glitch in the size would probably cause the
> machine to run out of memory and to bring everything down.
>
> And if there is a limit, then it's little different from the static
> solution!
>

That's an interesting point that neither of us had really considered.
I think that actually changes my mind.

On Oct 2, 9:12*pm, nroberts <roberts.n...@gmail.com> wrote:
> On Oct 2, 5:48*pm, Bill Reid <hormelf...@gmail.com> wrote:
>
> > On Oct 1, 2:49*pm, nroberts <roberts.n...@gmail.com> wrote:
> > For many if not most jobs, what you describe about yourself is
> > the classic description of a bad employee. *You are given a job to
> > do, and a set of existing tools and policies and procedures to
> > complete
> > the job,
>
> Actually...
>
> Also, perhaps you think otherwise but "team player" to me does not
> mean yes man.

Actually...

In almost all cases, a "team player" IS a "yes man", somebody
that will not challenge authority, PERIOD.

At least, that is how the term is used generally in business. If
you say you are a "team player", it is interpreted that you will not
contradict your boss in any way, shape, or fashion.

Now for ME, a TRUE "team player" is somebody who is very skilled
at their "position", and can be effectively coached and managed to
accomplish the larger goal. Of course, in order for this to happen,
it REALLY helps to have actual EFFECTIVE "coaches" and "managers"...

In any event, you are the new guy at Subway(TM), and you've
decided you don't think the sandwiches dictated by the corporate
office are very tasty, so you, as a "Sandwich Artiste", are
going to take it upon yourself to design your own sandwiches...

Which of course is fine, as long as you do it at home, and don't
rip off Subway(TM) for your salary in the process...

Look, as has been pointed out to you, the question doesn't
have a lot to do with the "C" programming language per se, except
that each and every programming language does tend to generate a
certain
type of pointless counter-productive behavior in its practitioners.
For that matter, the very act of declaring yourself a "professional
programmer" tends to generate a certain type of pointless
counter-productive behavior (like almost all "professions",
or ALL in the presence of actual unions), unless you consider
promoting full employment for "professional programmmers" to
be "productive" behavior.

"C" programmers tend to write a certain type of code which
is not very fast or very reliable or very maintainable, but
that's what they do. "C++" programmers write a different
type of code which is also not very fast or very reliable or
very maintainable, but that's what THEY do, and although
it's different from the terrible "C" code, it is written from
the same basic idea that what you're ostensibly trying to
accomplish is less important than what you can get away
with that seems "cool" in the language (sometimes called "elegance"
but is more correctly seen as a waste of human effort and
an inability to have a coherent practical logical thought,
the fundamental trait of a "professional programmer").

So you please go ahead and hassle your boss about
the array and string but be aware that some smart aleck
is going to trump you in the pointless debate by saying
the whole thing should be re-written in Java(TM) and
where will you be then, huh?

---
William Ernest Reid

On Oct 2, 11:09*pm, Bill Reid <hormelf...@gmail.com> wrote:
> On Oct 2, 9:12*pm, nroberts <roberts.n...@gmail.com> wrote:
>
> > On Oct 2, 5:48*pm, Bill Reid <hormelf...@gmail.com> wrote:
>
> > > On Oct 1, 2:49*pm, nroberts <roberts.n...@gmail.com> wrote:
> > > For many if not most jobs, what you describe about yourself is
> > > the classic description of a bad employee. *You are given a job to
> > > do, and a set of existing tools and policies and procedures to
> > > complete
> > > the job,
>
> > Actually...
>
> > Also, perhaps you think otherwise but "team player" to me does not
> > mean yes man.
>
> Actually...
>
> In almost all cases, a "team player" IS a "yes man", somebody
> that will not challenge authority, PERIOD.

Sigh..

> In any event, you are the new guy at Subway(TM), and you've
> decided you don't think the sandwiches dictated by the corporate
> office are very tasty, so you, as a "Sandwich Artiste", are
> going to take it upon yourself to design your own sandwiches...

Seriously broken metaphor. To bring it into line so you're comparing
apples to apples we should be talking about sandwich designers, not
waiters. I wasn't hired to slap out the same crap over and over
again. I was hired to write software, which very definitely includes
designing.

Software development is a skilled, technical occupation. Comparing it
to unskilled "labor" is a bit nutty.

> Which of course is fine, as long as you do it at home, and don't
> rip off Subway(TM) for your salary in the process...

Nope. Being hired to design sandwiches means I should be doing so
instead of just waiting for someone to tell me exactly what cookie to
cut and in what shape.

> So you please go ahead and hassle your boss about
> the array and string but be aware that some smart aleck
> is going to trump you in the pointless debate by saying
> the whole thing should be re-written in Java(TM) and
> where will you be then, huh?

You seriously have a lot of chips on your shoulder. You're also
coming off as a bit of a loon. It's really hard to take you seriously
when you're flailing about like that.

On 10/ 3/11 07:29 PM, nroberts wrote:
> On Oct 2, 11:09 pm, Bill Reid<hormelf...@gmail.com> wrote:

<nonsense>

> You seriously have a lot of chips on your shoulder. You're also
> coming off as a bit of a loon. It's really hard to take you seriously
> when you're flailing about like that.

That's What he does!

--
Ian Collins

On Oct 3, 5:19*am, nroberts <roberts.n...@gmail.com> wrote:
> On Oct 1, 4:45*pm, "BartC" <b...@freeuk.com> wrote:
> > "nroberts" <roberts.n...@gmail.com> wrote in message
> >news:138d547d-36d2-44f2-b1c5-...

> > > For example, we have a somewhat predictable in size but
> > > constantly changing string the we have to construct. *I proposed that
> > > we consider a buffer that grows with each call so that we pay minimal
> > > cost in performance but yet never have to predict or worry about the
> > > size of this string again. *He agreed we should discuss it but was
> > > busy so I took a day and implemented it. *Had it under unit tests,
> > > valgrind, etc...it worked. *I find though that he has no room for this
> > > construct and would prefer to use a statically sized character array
> > > and error out if we hit the end for some reason.
>
> > But if you had a dynamically changing string, would you impose any upper
> > bound on the size?
>
> > If not, then some temporary glitch in the size would probably cause the
> > machine to run out of memory and to bring everything down.
>
> > And if there is a limit, then it's little different from the static
> > solution!

not if you have many such dynamic objects. The sum of all those static
allocatiosn may exceed the memory used by dynamic allocations. And if
the system is ported to a system with more memory you have to
recalculate all the staic sizes. If the usage pattern changes you have
to...

> That's an interesting point that neither of us had really considered.
> I think that actually changes my mind.

On 10/ 3/11 08:33 AM, BGB wrote:
>
> granted, there is apparently a faction off in C++ land who often writes
> code which looks like it escaped from Java or something.
>
> typically a big tree of C++ files, each containing a single class, and
> typically all #include'ed by a big root C++ file:
> #include "foo/A.cpp"
> #include "foo/B.cpp"
> #include "foo/C.cpp"
> #include "bar/A.cpp"
> ....
>
> sometimes, one sees #import here instead.

Not in C++ or C you won't.

> however, I don't suspect this is the "standard" practice (I haven't seen
> all that many projects which do this, although single-class-per-file
> does seem to be fairly common in many projects).

Single class per file is no different from modularised C.

--
Ian Collins

On Oct 3, 7:09*am, Bill Reid <hormelf...@gmail.com> wrote:
> On Oct 2, 9:12*pm, nroberts <roberts.n...@gmail.com> wrote:
> > On Oct 2, 5:48*pm, Bill Reid <hormelf...@gmail.com> wrote:
> > > On Oct 1, 2:49*pm, nroberts <roberts.n...@gmail.com> wrote:

> > > For many if not most jobs, what you describe about yourself is
> > > the classic description of a bad employee. *You are given a job to
> > > do, and a set of existing tools and policies and procedures to
> > > complete the job,

and no suggestions for improvement are acceptable? Can we jangle our
chains?

> > Actually...
>
> > Also, perhaps you think otherwise but "team player" to me does not
> > mean yes man.
>
> Actually...
>
> In almost all cases, a "team player" IS a "yes man", somebody
> that will not challenge authority, PERIOD.

no. If I think my boss or team mate is wrong I'll tell him so. If my
boss says "tough that's the way its going to be" then I get on with
it. All improvements in quality ultimately come from someone's
dissatisfaction with teh way thinsg are.

> At least, that is how the term is used generally in business. *If
> you say you are a "team player", it is interpreted that you will not
> contradict your boss in any way, shape, or fashion.

good grief. Where do you work?! North Korea?

<snip>

On 10/03/2011 03:36 AM, Ian Collins wrote:
> On 10/ 3/11 08:33 AM, BGB wrote:
....
>> sometimes, one sees #import here instead.
>
> Not in C++ or C you won't.

A fully conforming implementation of either C or C++ is required to
parse #import as a "non-directive"; both standards explicitly say that
"Despite the name, a non-directive is a preprocessing directive." That
comment happens to be footnote 150 in both n1256.pdf and and n3035.pdf,
the most recent drafts I have for the two standards. Footnotes are
non-normative, but these footnotes merely point out something that you
can derive from a careful examination of section 6.1p1 and p2 of the
n1256.pdf, and section 16.1p1 and p2 of n3035.pdf. The behavior of such
a directive, if it survives conditional compilation, appears to be
undefined by reason of a lack of definition; at least I couldn't locate
any applicable definition in either standard. A non-detective would
therefore be a perfectly appropriate mechanism for a fully conforming
implementation to introduce extensions to the language; but it should
never appear in code intended to be portable.
--
James Kuyper

On 10/03/2011 03:40 AM, Nick Keighley wrote:
> On Oct 3, 7:09�am, Bill Reid <hormelf...@gmail.com> wrote:
>> On Oct 2, 9:12�pm, nroberts <roberts.n...@gmail.com> wrote:
>>> On Oct 2, 5:48�pm, Bill Reid <hormelf...@gmail.com> wrote:
>>>> On Oct 1, 2:49�pm, nroberts <roberts.n...@gmail.com> wrote:
>
>>>> For many if not most jobs, what you describe about yourself is
>>>> the classic description of a bad employee. �You are given a job to
>>>> do, and a set of existing tools and policies and procedures to
>>>> complete the job,
....
>>> Actually...
>>
>>> Also, perhaps you think otherwise but "team player" to me does not
>>> mean yes man.
>>
>> Actually...
>>
>> In almost all cases, a "team player" IS a "yes man", somebody
>> that will not challenge authority, PERIOD.

That could be the way that many people use the term; but being a "team
player" in that sense is not something I aspire to, nor is it something
I value in my subordinates.

> no. If I think my boss or team mate is wrong I'll tell him so. If my
> boss says "tough that's the way its going to be" then I get on with
> it. All improvements in quality ultimately come from someone's
> dissatisfaction with teh way thinsg are.

I will not accept any orders that call for me to do something which is
(in order of decreasing importance) immoral, illegal, against company
policy, or outside the domain of authority of the person giving the
order. However, if given an order that violates none of those
restrictions, I will obey that order. If I don't like doing the things
I'm being ordered to do, I'll let my boss know, and if he's not inclined
to change the situation, I'll quit (preferably not until after locating
a new job). However, I won't refuse to obey legitimate orders until
after I've quit, when they cease to be binding on me.

If given an order that violates none of those constraints, but is, in my
best judgment, a bad idea, I will not obey it until after informing my
boss of the reasons why I think it's a bad idea. I'm a technical
employee being paid for my expertise; I'm not earning my pay if I fail
to use that expertise to evaluate the reasonableness of the orders I'm
given.

If my boss insists on going ahead with the bad idea, I try to make sure
I've got the orders in writing, if possible, to document the fact that
the bad idea was not my decision. Of course, asking one's boss to
provide an order in writing can be politically difficult. However, I've
found that asking questions about an order by e-mail can sometimes
elicit usable documentation of the fact that it was his decision,
without having to explicitly ask for such documentation.

I want my subordinates to act in precisely that same fashion towards me,
and most of them have done so.
--
James Kuyper

On 10/3/2011 12:36 AM, Ian Collins wrote:
> On 10/ 3/11 08:33 AM, BGB wrote:
>>
>> granted, there is apparently a faction off in C++ land who often writes
>> code which looks like it escaped from Java or something.
>>
>> typically a big tree of C++ files, each containing a single class, and
>> typically all #include'ed by a big root C++ file:
>> #include "foo/A.cpp"
>> #include "foo/B.cpp"
>> #include "foo/C.cpp"
>> #include "bar/A.cpp"
>> ....
>>
>> sometimes, one sees #import here instead.
>
> Not in C++ or C you won't.
>

not in portable code, but in a certain commonly-used compiler, it
functions as a one-off include.

apparently, not sufficiently verified, another commonly-used compiler
may contain an "#include_once" directive (references found to it
existing, not listed in documentation though, although a related
"#include_next" is mentioned, but whatever...).


granted, it is more preferable IMO to use the usual guard-directives and
a standard #include.

as in:
#ifndef FOO_A_CPP
#define FOO_A_CPP
....
#endif


a lot of code structured in the way mentioned before does so without any
guard directives though (it is probably fairly dependent on
include-order or similar).


>> however, I don't suspect this is the "standard" practice (I haven't seen
>> all that many projects which do this, although single-class-per-file
>> does seem to be fairly common in many projects).
>
> Single class per file is no different from modularised C.
>

granted, but I often tend to put things in the same file if they will
all be small. for example, if the class would only result in around less
than 50 lines or so, then it makes little sense to give it dedicated
files (vs lumping).

similarly, a large class could have it contents be reasonably split
across multiple files.


I suspect my "basic unit of aggregation" tends to be a bit larger though.