How important is architecture to C developers?

Discussion in 'C Programming' started by nroberts, Oct 1, 2011.

  1. nroberts

    nroberts Guest

    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.
     
    nroberts, Oct 1, 2011
    #1
    1. Advertising

  2. nroberts

    Rich Webb Guest

    On Sat, 1 Oct 2011 14:49:48 -0700 (PDT), nroberts
    <> wrote:

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

    --
    Rich Webb Norfolk, VA
     
    Rich Webb, Oct 1, 2011
    #2
    1. Advertising

  3. nroberts

    nroberts Guest

    On Oct 1, 3:14 pm, Rich Webb <> wrote:
    > On Sat, 1 Oct 2011 14:49:48 -0700 (PDT), nroberts
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > <> wrote:
    > >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.
     
    nroberts, Oct 1, 2011
    #3
  4. nroberts

    James Kuyper Guest

    On 10/01/2011 05:49 PM, nroberts wrote:
    > 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.
    --
    James Kuyper
     
    James Kuyper, Oct 1, 2011
    #4
  5. nroberts

    BartC Guest

    "nroberts" <> wrote in message
    news:...

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

    --
    Bartc
     
    BartC, Oct 2, 2011
    #5
  6. nroberts

    Ian Collins Guest

    On 10/ 2/11 10:49 AM, nroberts wrote:
    > 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.

    <snip>

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

    --
    Ian Collins
     
    Ian Collins, Oct 2, 2011
    #6
  7. On 01-Oct-11 16:49, nroberts wrote:
    > 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

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
     
    Stephen Sprunk, Oct 2, 2011
    #7
  8. nroberts

    BGB Guest

    On 10/1/2011 4:55 PM, Ian Collins wrote:
    > On 10/ 2/11 10:49 AM, nroberts wrote:
    >> 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.
    >


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


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


    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...
     
    BGB, Oct 2, 2011
    #8
  9. nroberts

    Bill Reid Guest

    On Oct 1, 2:49 pm, nroberts <> wrote:
    > 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...

    ---
    William Ernest Reid
     
    Bill Reid, Oct 3, 2011
    #9
  10. nroberts

    nroberts Guest

    On Oct 2, 5:48 pm, Bill Reid <> wrote:
    > On Oct 1, 2:49 pm, nroberts <> 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.
     
    nroberts, Oct 3, 2011
    #10
  11. nroberts

    nroberts Guest

    On Oct 1, 4:45 pm, "BartC" <> wrote:
    > "nroberts" <> wrote in message
    >
    > news:...
    >
    > > 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.
     
    nroberts, Oct 3, 2011
    #11
  12. nroberts

    Bill Reid Guest

    On Oct 2, 9:12 pm, nroberts <> wrote:
    > On Oct 2, 5:48 pm, Bill Reid <> wrote:
    >
    > > On Oct 1, 2:49 pm, nroberts <> 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
     
    Bill Reid, Oct 3, 2011
    #12
  13. nroberts

    nroberts Guest

    On Oct 2, 11:09 pm, Bill Reid <> wrote:
    > On Oct 2, 9:12 pm, nroberts <> wrote:
    >
    > > On Oct 2, 5:48 pm, Bill Reid <> wrote:

    >
    > > > On Oct 1, 2:49 pm, nroberts <> 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.
     
    nroberts, Oct 3, 2011
    #13
  14. nroberts

    Ian Collins Guest

    On 10/ 3/11 07:29 PM, nroberts wrote:
    > On Oct 2, 11:09 pm, Bill Reid<> 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
     
    Ian Collins, Oct 3, 2011
    #14
  15. On Oct 3, 5:19 am, nroberts <> wrote:
    > On Oct 1, 4:45 pm, "BartC" <> wrote:
    > > "nroberts" <> wrote in message
    > >news:...


    > > > 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.
     
    Nick Keighley, Oct 3, 2011
    #15
  16. nroberts

    Ian Collins Guest

    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
     
    Ian Collins, Oct 3, 2011
    #16
  17. On Oct 3, 7:09 am, Bill Reid <> wrote:
    > On Oct 2, 9:12 pm, nroberts <> wrote:
    > > On Oct 2, 5:48 pm, Bill Reid <> wrote:
    > > > On Oct 1, 2:49 pm, nroberts <> 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>
     
    Nick Keighley, Oct 3, 2011
    #17
  18. nroberts

    James Kuyper Guest

    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
     
    James Kuyper, Oct 3, 2011
    #18
  19. nroberts

    James Kuyper Guest

    On 10/03/2011 03:40 AM, Nick Keighley wrote:
    > On Oct 3, 7:09�am, Bill Reid <> wrote:
    >> On Oct 2, 9:12�pm, nroberts <> wrote:
    >>> On Oct 2, 5:48�pm, Bill Reid <> wrote:
    >>>> On Oct 1, 2:49�pm, nroberts <> 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
     
    James Kuyper, Oct 3, 2011
    #19
  20. nroberts

    BGB Guest

    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.
     
    BGB, Oct 3, 2011
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Muhammad Khan
    Replies:
    4
    Views:
    1,258
    Mike Treseler
    Jul 10, 2003
  2. Replies:
    3
    Views:
    530
    Malcolm
    Sep 29, 2005
  3. rashmi
    Replies:
    2
    Views:
    489
    Grumble
    Jul 5, 2005
  4. Replies:
    3
    Views:
    442
    Malcolm
    Sep 29, 2005
  5. Replies:
    4
    Views:
    687
    Malcolm
    Sep 29, 2005
Loading...

Share This Page