How important is architecture to C developers?


N

nroberts

I'm a C++ developer and I am always sure to distinguish this from a C
developer any time there seems to be confusion. As a software
developer I can adapt to any language and API, and so I can adapt to
using C when I need to, but even though the two languages share much
in common I rarely use those aspects of C++ that are C.

I was recently hired into a new position. I knew there would be some
C development but I was lead to believe that this would be *legacy*
development and that I was being hired as a C++ developer. Turns out
that this was not at all the case and now I'm rather stuck.
Unfortunately I'm having a lot of trouble adapting to the situation
and I'm not sure if this is because I lack understanding of the C
"way", as I have not used it in 10 years, or if I'm just in a
generally troubling situation as it seems to me.

The lead architect of the project I'm on does not seem to have any
room for different ways of doing things. Unfortunately, he doesn't
seem to have a lot of eye toward architecture to begin with and so
when I come in and try to impose some we get into disagreements. For
example, we have a structure in the program that's got about 100 items
in it. It's kept in an array in global scope. Any function that uses
this structure takes an index to that array even if it doesn't do
anything but retrieve or manipulate a value within one instance of
that structure. I tried to factor this out so I could write some
functions that behaved differently and didn't depend on this global
array and I was in an argument for an hour attempting to justify this
action, apparently with little success.

From where I come from, I wouldn't expect to HAVE to justify such a
change. The function doesn't need or care about the array, so why
make it? Reduce dependencies, open the function for reuse, and
increase cohesion even if by a small amount. That I can make the
change easily, and I'm already messing with things in the area, means
I should do it.

There are also a lot of functions that seem to do a lot of things and
because everything seems to be a global variable, they end up touching
everything. This forces everyone that needs to work on the code into
the position of having to understand the entire thing in detail,
rather than some small area they are working on. It is a truism that
this happens to code, but this is early in the project's lifecycle and
the architect that created it doesn't seem to like me splitting
concerns, encapsulating data, etc... I'm trying to write C++ in C?

Again though, I made sure to make sure they knew that I was a C++
developer, not C. I can work with C when I need to interface with it,
but that's about it.

One thing that seems to guide this person is a desire to avoid heap
memory. 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. I suppose this could
be a philosophical difference perhaps with the C way vs. the C++ way
but I honestly do not understand the problem.

I do understand the fear of malloc. I hate memory leaks and without
RAII or a very clear ownership semantic it's very difficult, perhaps
impossible to avoid them. I do understand the argument that heap is
less predictable than the stack or global space in that malloc can
fail or fragment memory. On the other hand, we're targeting a very
powerful server with lots of memory and a buffer that grows as it
needs to and just sits around waiting is not likely to cause a lot of
fragmentation, which occurs more often when you repeatedly allocate
and deallocate objects.

Encapsulation of data seems to be a hard sell too. I wish to hide the
fact that this object is using a buffer, and in fact implemented the
buffer with a structure I don't want anyone other than itself to mess
with either. Yes, this is sort of object oriented, except for the
total lack of polymorphism and inheritence, but it seems to me like
just a good idea. If you want to keep code from mucking about in data
it shouldn't, encapsulate it. When I've tried to do this though I've
had to spend a lot of time trying to justify it as well because I'm
"complicating things". Unfortunately I see it as exactly the opposite
because I find strongly cohesive, encapsulated entities much easier to
work on than a conglomerate of functions that operate on a mishmash of
global variables.

We have totally different approaches to things. Mine is to face
change by trying to find a method to adapt the design of the program
to be compatible with the change and then extending it. His method
seems to be to hack at it until it seems to work. He is pretty smart
and so generally it appears he is successful, but I've never been a
big fan of this approach to software maintenance. I find it too
risky, prone to failing in bad ways that cost lots of money, and
shortens the lifetime of projects by making them fragile to
modification and difficult to learn.

On the one hand I feel like I'm stuck under someone that has no
understanding of software design, a total apathy toward architecture
and good technique, and no toleration for different methods. On the
other hand, he's got decades of experience on me and is apparently
quite able to develop successful products. What I can't decide is how
much of this is due to being able to convince people he knows what
he's doing, and only working on small code bases.

The goal I have here is to find out if this is simply the C way that I
need to learn, and thus I should just STFU and be instructed, or are
the techniques I tend to use as universal as I perceive them to be and
my concerns are valid...meaning I still need to STFU and let things be
what they are but I might also be looking for ways out of the
situation.
 
Ad

Advertisements

R

Rich Webb

I'm a C++ developer and I am always sure to distinguish this from a C
developer any time there seems to be confusion. As a software
developer I can adapt to any language and API, and so I can adapt to
using C when I need to, but even though the two languages share much
in common I rarely use those aspects of C++ that are C.

I was recently hired into a new position. I knew there would be some
C development but I was lead to believe that this would be *legacy*
development and that I was being hired as a C++ developer. Turns out
that this was not at all the case and now I'm rather stuck.
Unfortunately I'm having a lot of trouble adapting to the situation
and I'm not sure if this is because I lack understanding of the C
"way", as I have not used it in 10 years, or if I'm just in a
generally troubling situation as it seems to me.

The lead architect of the project

[snippety snip]

Hosted or stand-alone? New C *tends* to show up more in non-hosted
environments, i.e. embedded processors, where how things are done are
strongly influenced by the environmental constraints. Is there anything
special about the project?
 
N

nroberts

I'm a C++ developer and I am always sure to distinguish this from a C
developer any time there seems to be confusion.  As a software
developer I can adapt to any language and API, and so I can adapt to
using C when I need to, but even though the two languages share much
in common I rarely use those aspects of C++ that are C.
I was recently hired into a new position.  I knew there would be some
C development but I was lead to believe that this would be *legacy*
development and that I was being hired as a C++ developer.  Turns out
that this was not at all the case and now I'm rather stuck.
Unfortunately I'm having a lot of trouble adapting to the situation
and I'm not sure if this is because I lack understanding of the C
"way", as I have not used it in 10 years, or if I'm just in a
generally troubling situation as it seems to me.
The lead architect of the project

[snippety snip]

Hosted or stand-alone? New C *tends* to show up more in non-hosted
environments, i.e. embedded processors, where how things are done are
strongly influenced by the environmental constraints. Is there anything
special about the project?

Hosted. It's got to be fast and up all the time is all that's special
about it.
 
J

James Kuyper

I'm a C++ developer and I am always sure to distinguish this from a C
developer any time there seems to be confusion. As a software
developer I can adapt to any language and API, and so I can adapt to
using C when I need to, but even though the two languages share much
in common I rarely use those aspects of C++ that are C.

Most of the aspects of C++ are C; it's pretty hard, probably impossible,
to use C++ without using the aspects it shares with C, such as using '+'
as the addition operator, or terminating expression statements with
semi-colons. I think you mean something more complicated than what you
actually said.
I was recently hired into a new position. I knew there would be some
C development but I was lead to believe that this would be *legacy*
development and that I was being hired as a C++ developer. Turns out
that this was not at all the case and now I'm rather stuck.
Unfortunately I'm having a lot of trouble adapting to the situation
and I'm not sure if this is because I lack understanding of the C
"way", as I have not used it in 10 years, or if I'm just in a
generally troubling situation as it seems to me.

The lead architect of the project I'm on does not seem to have any
room for different ways of doing things. Unfortunately, he doesn't
seem to have a lot of eye toward architecture to begin with and so
when I come in and try to impose some we get into disagreements. For
example, we have a structure in the program that's got about 100 items
in it. It's kept in an array in global scope. Any function that uses
this structure takes an index to that array even if it doesn't do
anything but retrieve or manipulate a value within one instance of
that structure. I tried to factor this out so I could write some
functions that behaved differently and didn't depend on this global
array and I was in an argument for an hour attempting to justify this
action, apparently with little success.

From where I come from, I wouldn't expect to HAVE to justify such a
change. The function doesn't need or care about the array, so why
make it? Reduce dependencies, open the function for reuse, and
increase cohesion even if by a small amount. That I can make the
change easily, and I'm already messing with things in the area, means
I should do it.

There are also a lot of functions that seem to do a lot of things and
because everything seems to be a global variable, they end up touching
everything. This forces everyone that needs to work on the code into
the position of having to understand the entire thing in detail,
rather than some small area they are working on. It is a truism that
this happens to code, but this is early in the project's lifecycle and
the architect that created it doesn't seem to like me splitting
concerns, encapsulating data, etc... I'm trying to write C++ in C?

Most of what you're talking about is bad design in C, as well as C++. C
has fewer tools for encapsulation than C++ does, but good C designers
use those tools where appropriate. Bad designers (in either language)
come up with messes like the ones you describe.
One thing that seems to guide this person is a desire to avoid heap
memory. ...

Whether or not that's a legitimate concern depends upon the environment.
In my current environment, it isn't, but I've worked in ones where it
was. Do you know for certain that his concern about heap usage is
excessive, given the target platforms for this software?

....
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. I suppose this could
be a philosophical difference perhaps with the C way vs. the C++ way
but I honestly do not understand the problem. ...

If it's a legitimate problem on that platform, there's a good chance
that it's a legitimate concern in both languages - it isn't C-specific.
On the one hand I feel like I'm stuck under someone that has no
understanding of software design, a total apathy toward architecture
and good technique, and no toleration for different methods.

I've reached a point in my career where no one cares to exert authority
over me on issues of how my programs are designed; I've got complete
freedom to use whichever architecture I think is best. That's because
I'm clearly far more competent to decide such issues than my bosses are;
they're more competent than me on management skills (mine are awful).
But I didn't reach that point till I was 40 (someone whose career
involved fewer side-tracks than mine might have gotten there earlier).
Until you get there, you'll have to learn to deal with bosses whose
judgment differs from yours, and may even be inferior to yours.
The goal I have here is to find out if this is simply the C way that I
need to learn, and thus I should just STFU and be instructed, or are
the techniques I tend to use as universal as I perceive them to be and
my concerns are valid...meaning I still need to STFU and let things be
what they are but I might also be looking for ways out of the
situation.

Nothing you've described is C specific.
 
B

BartC

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!

So possibly both kinds of approaches to this project have their points; and
who has ultimate responsibility for the software working reliably?

(I've mostly worked by myself but remember having a supervisor who didn't
quite see the point of these new-fangled 'subroutines' I was sprinkling
through my code! Then he saw how easy some mods became, and started seeing
the point.

Maybe you need to find a similar example to help 'sell' your approach, but
that'll be much harder in your case, with an existing project.)
 
I

Ian Collins

I'm a C++ developer and I am always sure to distinguish this from a C
developer any time there seems to be confusion. As a software
developer I can adapt to any language and API, and so I can adapt to
using C when I need to, but even though the two languages share much
in common I rarely use those aspects of C++ that are C.

I was recently hired into a new position. I knew there would be some
C development but I was lead to believe that this would be *legacy*
development and that I was being hired as a C++ developer. Turns out
that this was not at all the case and now I'm rather stuck.
Unfortunately I'm having a lot of trouble adapting to the situation
and I'm not sure if this is because I lack understanding of the C
"way", as I have not used it in 10 years, or if I'm just in a
generally troubling situation as it seems to me.

I think the best advise is to brush up your CV and start digging a
tunnel. Being a round peg in a square hole invariably leads to tears.
The lead architect of the project I'm on does not seem to have any
room for different ways of doing things. Unfortunately, he doesn't
seem to have a lot of eye toward architecture to begin with and so
when I come in and try to impose some we get into disagreements. For
example, we have a structure in the program that's got about 100 items
in it. It's kept in an array in global scope. Any function that uses
this structure takes an index to that array even if it doesn't do
anything but retrieve or manipulate a value within one instance of
that structure. I tried to factor this out so I could write some
functions that behaved differently and didn't depend on this global
array and I was in an argument for an hour attempting to justify this
action, apparently with little success.

As other responders have noted, this is bad design, regardless of
language. C lacking the higher level features of C++ is no excuse for a
bad design.

The goal I have here is to find out if this is simply the C way that I
need to learn, and thus I should just STFU and be instructed, or are
the techniques I tend to use as universal as I perceive them to be and
my concerns are valid...meaning I still need to STFU and let things be
what they are but I might also be looking for ways out of the
situation.

What you are experiencing is a personality clash, not a language culture
one.
 
Ad

Advertisements

S

Stephen Sprunk

I'm a C++ developer and I am always sure to distinguish this from a C
developer any time there seems to be confusion. As a software
developer I can adapt to any language and API, and so I can adapt to
using C when I need to, but even though the two languages share much
in common I rarely use those aspects of C++ that are C.

C++ isn't that different from C. C++ has some nifty syntactic sugar
that make doing many things the "right way" a bit easier, but good
design is the same in _any_ language, particularly two as closely
related as C and C++.
The lead architect of the project I'm on does not seem to have any
room for different ways of doing things.

Regardless of the specifics, this is a bad sign. A good architect will
always be open to new ideas and, if they're better than his, will adopt
them. A closed mind is a big problem in any language--indeed, in any field.
For example, we have a structure in the program that's got about 100
items in it.

I've seen a handful of cases where that's appropriate, but they're
pretty rare.
It's kept in an array in global scope.

There are many folks against having _any_ global variables; I tend to
avoid such absolutism, but they probably got that way from dealing with
projects like yours...
On the one hand I feel like I'm stuck under someone that has no
understanding of software design, a total apathy toward architecture
and good technique, and no toleration for different methods. On the
other hand, he's got decades of experience on me and is apparently
quite able to develop successful products. What I can't decide is how
much of this is due to being able to convince people he knows what
he's doing, and only working on small code bases.

I suspect his "success" is due to being able to maintain absolute
control over projects small enough (and with few enough developers) that
he can keep the entire thing in his head at the same time.
The goal I have here is to find out if this is simply the C way that I
need to learn, and thus I should just STFU and be instructed, or are
the techniques I tend to use as universal as I perceive them to be and
my concerns are valid...meaning I still need to STFU and let things be
what they are but I might also be looking for ways out of the
situation.

Your concerns appear to be valid. The problem is not the language,
though, as what you want to do is IMHO the "right" way to do things in C
as well as C++. Only the syntax differs.

It sounds like a "way out of the situation" is probably your best
option, but in the meantime you'd probably best be served by adapting to
your environment. Just, for the sake of your career, don't stick around
any longer than necessary, lest you internalize some of his poor design
(and management/teamwork) practices and take them with you when you leave.

S
 
B

BGB

I think the best advise is to brush up your CV and start digging a
tunnel. Being a round peg in a square hole invariably leads to tears.


As other responders have noted, this is bad design, regardless of
language. C lacking the higher level features of C++ is no excuse for a
bad design.

yep.


global variables and arrays are ugly IMO, and better off avoided (I
personally prefer to avoid global variables wherever possible, and
generally create and pass around "context structs" which contain most data).

FWIW, I typically use contexts (in C) similarly to how many people use
classes in OO languages, but with the obvious difference that there is
no built-in support for inheritance (most commonly, cases which would
normally be done via inheritance are handled instead by having pointers
to the data for the "sub-classes", and by making use either of explicit
vtables or function pointers).


also, by convention, I tend to manually use explicit constructors and
destructors (via function calls to create and destroy objects) rather
than have client code allocate/free the memory directly.

also, fairly often an analogue of getters/setters is used.

scope issues are generally avoided through explicit naming conventions
(name clashes are not some unavoidable fault of the language, rather
they are more often an issue with poor naming conventions or ones'
failure to adhere to them).

What you are experiencing is a personality clash, not a language culture
one.

yeah...

C and C++ need not really be all that much different.

mostly it is a difference of language syntax.


many arguments IME are more often about philosophical views and coding
practices than about real technical matters.

for example, recent arguments about coding practices because, for
example, I don't believe copy-paste is necessarily a bad thing, and that
there may be worse issues at play (making copy/paste a lesser of the
evils). not that it is always a good thing either (if one is just
endlessly copy-pasting a sequence of code which could just as easily
have been put in a function, yes, this is a bad thing...).

another recent argument was partly because I tend to believe that
computers (and reality as a whole) are made out of "stuff" (software,
hardware, matter, ...) rather than being made out of math or similar
(for whatever bizarre reason, some people seem to believe everything is
made out of math...). I instead tend to see math as a system of
abstractions and formalisms, which exist largely independently from the
things they describe. (like "existence precedes essence" and similar).

so, yes, there are potential conflicts everywhere...



in the cases where I write C++, admittedly it often looks a little more
C like (I rarely make much use of STL/Boost/...), and often it tends to
be reasonably conservative (C++ features used sparingly) as often the
border back to C land is not too far away.


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.

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).

I generally go instead by the convention of liking around 500-1000 lines
per file (too much smaller means excess jumping between files, and too
much larger makes scrolling/navigation tedious).


or such...
 
B

Bill Reid

I'm a C++ developer and I am always sure to distinguish this from a C
developer any time there seems to be confusion.  As a software
developer I can adapt to any language and API, and so I can adapt to
using C when I need to, but even though the two languages share much
in common I rarely use those aspects of C++ that are C.

I was recently hired into a new position.  I knew there would be some
C development but I was lead to believe that this would be *legacy*
development and that I was being hired as a C++ developer.  Turns out
that this was not at all the case and now I'm rather stuck.
Unfortunately I'm having a lot of trouble adapting to the situation
and I'm not sure if this is because I lack understanding of the C
"way", as I have not used it in 10 years, or if I'm just in a
generally troubling situation as it seems to me.

The lead architect of the project I'm on does not seem to have any
room for different ways of doing things.  Unfortunately, he doesn't
seem to have a lot of eye toward architecture to begin with and so
when I come in and try to impose some we get into disagreements.  For
example, we have a structure in the program that's got about 100 items
in it.  It's kept in an array in global scope.  Any function that uses
this structure takes an index to that array even if it doesn't do
anything but retrieve or manipulate a value within one instance of
that structure.  I tried to factor this out so I could write some
functions that behaved differently and didn't depend on this global
array and I was in an argument for an hour attempting to justify this
action, apparently with little success.

From where I come from, I wouldn't expect to HAVE to justify such a
change.  The function doesn't need or care about the array, so why
make it?  Reduce dependencies, open the function for reuse, and
increase cohesion even if by a small amount.  That I can make the
change easily, and I'm already messing with things in the area, means
I should do it.

There are also a lot of functions that seem to do a lot of things and
because everything seems to be a global variable, they end up touching
everything.  This forces everyone that needs to work on the code into
the position of having to understand the entire thing in detail,
rather than some small area they are working on.  It is a truism that
this happens to code, but this is early in the project's lifecycle and
the architect that created it doesn't seem to like me splitting
concerns, encapsulating data, etc...  I'm trying to write C++ in C?

Again though, I made sure to make sure they knew that I was a C++
developer, not C.  I can work with C when I need to interface with it,
but that's about it.

One thing that seems to guide this person is a desire to avoid heap
memory.  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.  I suppose this could
be a philosophical difference perhaps with the C way vs. the C++ way
but I honestly do not understand the problem.

I do understand the fear of malloc.  I hate memory leaks and without
RAII or a very clear ownership semantic it's very difficult, perhaps
impossible to avoid them.  I do understand the argument that heap is
less predictable than the stack or global space in that malloc can
fail or fragment memory.  On the other hand, we're targeting a very
powerful server with lots of memory and a buffer that grows as it
needs to and just sits around waiting is not likely to cause a lot of
fragmentation, which occurs more often when you repeatedly allocate
and deallocate objects.

Encapsulation of data seems to be a hard sell too.  I wish to hide the
fact that this object is using a buffer, and in fact implemented the
buffer with a structure I don't want anyone other than itself to mess
with either.  Yes, this is sort of object oriented, except for the
total lack of polymorphism and inheritence, but it seems to me like
just a good idea.  If you want to keep code from mucking about in data
it shouldn't, encapsulate it.  When I've tried to do this though I've
had to spend a lot of time trying to justify it as well because I'm
"complicating things".  Unfortunately I see it as exactly the opposite
because I find strongly cohesive, encapsulated entities much easier to
work on than a conglomerate of functions that operate on a mishmash of
global variables.

We have totally different approaches to things.  Mine is to face
change by trying to find a method to adapt the design of the program
to be compatible with the change and then extending it.  His method
seems to be to hack at it until it seems to work.  He is pretty smart
and so generally it appears he is successful, but I've never been a
big fan of this approach to software maintenance.  I find it too
risky, prone to failing in bad ways that cost lots of money, and
shortens the lifetime of projects by making them fragile to
modification and difficult to learn.

On the one hand I feel like I'm stuck under someone that has no
understanding of software design, a total apathy toward architecture
and good technique, and no toleration for different methods.  On the
other hand, he's got decades of experience on me and is apparently
quite able to develop successful products.  What I can't decide is how
much of this is due to being able to convince people he knows what
he's doing, and only working on small code bases.

The goal I have here is to find out if this is simply the C way that I
need to learn, and thus I should just STFU and be instructed, or are
the techniques I tend to use as universal as I perceive them to be and
my concerns are valid...meaning I still need to STFU and let things be
what they are but I might also be looking for ways out of the
situation.

Or the situation might be looking to get you out of it...

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, but instead of doing the job you proceed to complain
about the tools and policies and procedures, and even take it
upon yourself WITHOUT AUTHORIZATION to create your own policies
and procedures, BUT I HAVEN'T HEARD ONE WORD FROM YOU ABOUT
ACTUALLY DOING THE JOB YOU WERE HIRED TO DO.

Of course, this type of behavior is not atypical in programming,
but that still doesn't make it acceptable. I remember one time,
a FORMER programmer in another group, who was quite mystified
as to why he couldn't find work, regaled the group with a story
about how he unilaterally decided the debugger that he was
provided with wasn't good enough, so he set upon a year-long
task to write his own. I did try to inform him that if he
was working for me, assigning yourself an open-ended task of
writing a debugger rather than doing the job you were hired
to do would be your last act as an employee, and if I found
out in the hiring process you were prone to that type of
behavior, I would not hire you.

Fortunately for you and him, I don't work as an engineering
manager, and based on my experience with a lot of engineering
managers, that may be because I'm over-qualified, at least
in the common sense department, if not tediously technically
well-versed...

So, in any event, that's just MY opinion, but it's also
my opinion that possibly what you describe IS bad "architecture",
because it generally doesn't sound too good, but then I also
don't know enough about software requirements and development
history to make a canonical determination...what you describe may
also be a REASONABLE solution to the requirements over time, and at
least one other respondant to this thread has noted that on one issue
you may not be thinking 100% clearly...

Would it be so difficult to give your BOSS the benefit of
the doubt, and try to be a "team player"? Especially considering
doing otherwise might get VERY difficult for you...
 
N

nroberts

On Oct 1, 2:49 pm, nroberts <[email protected]> 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.
 
N

nroberts

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.
 
Ad

Advertisements

B

Bill Reid

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?
 
N

nroberts

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.
 
N

Nick Keighley

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...
 
I

Ian Collins

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.
 
Ad

Advertisements

N

Nick Keighley

and no suggestions for improvement are acceptable? Can we jangle our
chains?
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>
 
J

James Kuyper

On 10/ 3/11 08:33 AM, BGB wrote: ....

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.
 
J

James Kuyper

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.
 
Ad

Advertisements

B

BGB

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).

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top