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