Archived

This topic is now archived and is closed to further replies.

Succinct

Design speed and reusability: c vs. c++

Recommended Posts

I work in a small c++ shop. The office is is purely a development site. There are only programmers there, and the closest form of middle or upper management is in New York (from Pittsburgh, PA). We have a small crew - 7 programmers, 5 testers, an engineer, and a technical writer, and the environment is very non-corporate and informal. Being that my office is very informal, we don't have official "design phases" and "design documents" (much to my dismay), unless we're working on a contract which requires them, such as miltary contracts, of which we have a few per year. Because of this, many of the projects we work on are done in a "from the seat of your pants" kind of way. The lead programmer sits down with whomever is going to be tasked to handle a particular project, gives the lesser programmer some ideas as to how he wants the functionality of the program to be, who works on what parts, a small amount of coding suggetions, and the rest of it is up to the lesser programmers. This is nice and all, that we basically get to do our own thing for each individual part, but it can really be hard sometimes, mainly because of the fact that some of the programmers are a little older and are stubbornly locked in their own coding styles and methodologies, even if it is not very intuitive for anyone else to look at and/or use. All of the programmers here use c++, but there are many different interpretations of just what "c++" is. Most of the guys at work, including the boss, are old-school c proponents. They look at c++ as being a small extension to c, and still use c style programming when they can, as often as they can. I'm a c++ aficionado, and look at c++ as being basically a different language from c. Now, here's my boggle. Because we all are given the room to design our programs ourselves, we all go about it the way we've found most successful - the other guys go about it in a fairly procedural-relational, c way, while I go about it in a fairly object oriented, c++ way. I try to write modular code, and make it reusable when I feel it will be reused eventually. They write poorly structured c code, lots of times using brute force (I saw a 10k line switch statement and a 5k line function) and code duplication, small, indescript variable names, variable names that have nothing to do with the program, such as girlfriend's names and what-not, and unnamed constants all over the place. Basically all of the things you might read about in "Code Complete", by Steve McConnell, that you're not supposed to do. The thing is, they get done a lot faster than me. A lot. Now, I feel that, in the long run, I'll be better off, because I'll have a code base of reuseable, modular objects. But until then, I feel like I'm behind in the game. Heh, another problem is that these guys don't like to interface with my objects, even when I make them as simple as possible. Much simpler than the schite they write. A perfect example is the difference between the OpenGL code I write and the code they write. The work we do is not very graphics intensive. We do some neat things with graphics, but it doesn't necessarily have to be real time, such as in a 3d game. Most of the objects are fairly static, only changing orientations and position. Because of this, I have my OpenGL client/server model classed out with a very small interface, only 5 main methods or so. To use OpenGL with my objects you only need to create a server object, attach it to a particular hwnd (via a single method call), create the object you want to render, and attach it to the server (again, a single method call). New objects are derived from a base object and override a single method that describes the object in OpenGL statements. New render objects generally consist of a single method, and that is all they need to be completely incorporated into the larger projects. When they're using OpenGL, the code is different every time, it jumps all around the application in various stages of initialization, execution, and shutdown, and is hell to trace through. They don't perform any clean-up or shutdown, and generally write a jumbled bunch of indecipherable junk that is so tightly coupled with every other part of the application that changing around any lines of code could render the entire project useless. And it's not just me who feels this way. Everyone feels the same about everyone else's code - they just can't figure it out without taking a long time to go though it themselves or having the original author go though it with them. This is except for my code, which everyone agrees is easy to read, but because it's more object oriented, they don't like to look at it. Should I conform to their method? Should I start writing sloppy code that, by way of brute force, is completed more quickly, or should I continue to take longer writing more modular, reusable code? If I ever want to get another job, I'd better keep writing modular code, but I'll probably take some heat here while I do it. I've already been "scolded" by the boss for my coding techniques, such as using "const", "new" instead of "malloc" and "calloc", and using "string" or "AnsiString" (a borland specifice string class) instead of "char*". My boss straight up told me he doesn't like me using const objects. He also doesn't like me using interfaces. He feels that I should just make all member data public so it can be directly accessed... WHAT THE HECK!? I AM IN CODING HELL! Any comments or suggestions? Please? Thank you for your bandwidth, -- Succinct Edited by - Succinct on November 2, 2001 12:15:20 PM

Share this post


Link to post
Share on other sites
quote:
Original post by Succinct
Because of this, many of the projects we work on are done in a "from the seat of your pants" kind of way.


Yay pants!
quote:

The lead programmer sits down with whomever is going to be tasked to handle a particular project, gives the lesser programmer some ideas as to how he wants the functionality of the program to be, who works on what parts, a small amount of coding suggetions, and the rest of it is up to the lesser programmers.


Excellent. Are there are any vacancies?
quote:

some of the programmers are a little older and are stubbornly locked in their own coding styles and methodologies, even if it is not very intuitive for anyone else to look at and/or use.


They''re wrong.
quote:

I try to write modular code, and make it reusable when I feel it will be reused eventually.


Very good. Shouldn''t you be making it reusable whether or not you imagine it''ll be reused? You can''t always be sure what the next project will entail.
quote:

They write poorly structured c code, lots of times using brute force (I saw a 10k line switch statement and a 5k line function) and code duplication, small, indescript variable names, variable names that have nothing to do with the program, such as girlfriend''s names and what-not, and unnamed constants all over the place.


Do you mean that their data is poorly structured, or their actual code? If it''s really their code, then they ought to be willing to listen to what''s wrong.

Don''t they know you''re meant to call them ''foobar'', ''wombat'', and ''magic''?

By indescript, do you mean using ''i'' for a loop counter, or using ''i'' for a global variable? If it''s for the global variable, give them a beating.
quote:

Basically all of the things you might read about in "Code Complete", by Steve McConnell, that you''re not supposed to do.


Nice plug.
quote:


The thing is, they get done a lot faster than me. A lot. Now, I feel that, in the long run, I''ll be better off, because I''ll have a code base of reuseable, modular objects. But until then, I feel like I''m behind in the game.


You said they were older than you. That most likely means they''ve been programming for longer than you, so it shouldn''t be surprising that they can do it faster.
quote:

Heh, another problem is that these guys don''t like to interface with my objects, even when I make them as simple as possible. Much simpler than the schite they write.


Judging from your description of them, it''s not your objects they don''t like to interface with, it''s objects in general.
quote:

Should I conform to their method?


Yes.
quote:

Should I start writing sloppy code that,


No.
quote:

I''ve already been "scolded" by the boss for my coding techniques, such as using "const", "new" instead of "malloc" and "calloc", and using "string" or "AnsiString" (a borland specifice string class) instead of "char*". My boss straight up told me he doesn''t like me using const objects. He also doesn''t like me using interfaces.


I don''t like interfaces, myself. I just use classes with virtual members if I want something that''s like an interface.
quote:

He feels that I should just make all member data public so it can be directly accessed...


I love OOP, and I agree with your boss on this one. Variables should be public. It is a deficiency in the C++ language that means everyone tells you to make them private: C++ doesn''t allow a class to know when you assign a value to one of its fields. Having said that, if you''re programming in C++, variables should be private, because of the deficiency.
quote:


Any comments or suggestions? Please?



When you are employed by a company, they will generally have rules about the coding and design style that is acceptable by that company. They don''t impose that style because they are fascist (well, sometimes they do), but because it is important to have a style that everyone uses, elsewise no one can work together.

Judging from your description, it appears that your office doesn''t have a style-guide. It is important to have one. The fact that OOP is technically correct doesn''t mean it must be used: in the end what matters is that the programmers use a paradigm with which the majority of them are familiar. Your office needs a style-guide that is compatible with the programming practices of everyone who works there.

All your bases belong to us

Share this post


Link to post
Share on other sites
quote:
Original post by Mayrel
I love OOP, and I agree with your boss on this one. Variables should be public. It is a deficiency in the C++ language that means everyone tells you to make them private: C++ doesn''t allow a class to know when you assign a value to one of its fields. Having said that, if you''re programming in C++, variables should be private, because of the deficiency.



I agree. This is the only reason I use interfaces. Borland C++ actually has circumvented the c++ problem by making properties, pseudo-variables that, when accessed, in the same manner that any other public member variables are accessed, actually call a method in response to the access. Now THAT''S beautiful! I use properties when I can (when I''m sure the code I''m writing will say in Borland), but becuase I also use MSVC from time to time I have to use interfaces.

You seem to be a very informed individual, Mayrel. Nice to see your reply

-- Succinct

Share this post


Link to post
Share on other sites
Examples of global and member data variable names:
g,gx,ggx,gxx,x,zed,zax (zed and zax are always filenames, I''ve recently found out),

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Mayrel
Excellent. Are there are any vacancies?


I''ll keep you posted. My head may explode soon though, and though this will generate a vacancy, I won''t be able to tell you.
quote:

They''re wrong.


Ouch!
quote:

Very good. Shouldn''t you be making it reusable whether or not you imagine it''ll be reused? You can''t always be sure what the next project will entail.


I try to, but like I said, I feel like I''m always behind, so I don''t always, though I''d like to.
quote:

Do you mean that their data is poorly structured, or their actual code? If it''s really their code, then they ought to be willing to listen to what''s wrong.


Both. You should see some of the structures used, and the code that uses them. You should see some of the code in general... ACK! I mean, the actual code is usually good. But the structure of it usually starts off like how an optimized section of code might end up looking when finished. Just hell to work with.
quote:

Don''t they know you''re meant to call them ''foobar'', ''wombat'', and ''magic''?


Heh, I''ve seen ''foo'', ''bar'', and ''foobar'' in a few places. "Just like the examples!" - arrgh...
quote:

By indescript, do you mean using ''i'' for a loop counter, or using ''i'' for a global variable? If it''s for the global variable, give them a beating.


Examples of global and member data variable names:
  
int a,b,c;
int ww,hh,xx,xa;
FILE *zax; // zax is always a file pointer

FILE *zed; // as is zed

int a,b;
bool da;
int x,xx,y,yy;
int scaleval,smod,iran,ggx;
BYTE *smode, *mode;
int orin,olorin;
DWORD tic;
BYTE *dev;
float *fcrot;
int icrot;
int a,b,x,y,i,j,k;
DWORD tic1;
int ggx,ggy, nggx, nggy, uggx, uggy, vggx, vggy, cenx, ceny, ncenx, nceny, ucenx, uceny, vcenx, vceny;
float goff, noff, uoff, voff;
int crossx, crossy, downx, downy;

And one of my favorites:
  
void __fastcall TDDepth::DrawButtonG(int w)
{
int a,x,y,xx,yy,i,j,xa,ya,xb;
x=butts[w].x;
y=butts[w].y;
xx=butts[w].w;
yy=butts[w].h;
...
}

So, yes, it is normal variable names, not unimportant ones such as loop counters.

I''m sure they make sense to whomever wrote them, and they may in context, but I''m used to code you can understand by glancing at it. I''d say that makes development times a little quicker... Maybe it''s just me.
quote:

Nice plug.


Thanks I''ve always liked that book, and I recommend it every time I get the chance to.
quote:

You said they were older than you. That most likely means they''ve been programming for longer than you, so it shouldn''t be surprising that they can do it faster.


Yes, but I''ve been programming for a few years now, myself. They''ve only got a few years on me. Not too long. The extra programming time they have doesn''t seem proportional, I think. Granted, I''ve only been doing it professionally for a short time, now, but I''ve been -cough- unemployed -cough cough- for awhile before hand, a time during which I spent most of my time programming and sending out resumes
quote:

Judging from your description of them, it''s not your objects they don''t like to interface with, it''s objects in general.


Very true. That makes me feel good. Does wonders for my ego
quote:

Yes.


Darn. I''ve gotten similar sentiments from friends via e-mail.
quote:

No.


Good!
quote:

I don''t like interfaces, myself. I just use classes with virtual members if I want something that''s like an interface.


I usually start off that way, but a complex object can have multiple interfaces (like COM objects). I don''t necessarily multiply inherit a bunch of virtual interfaces, but I do generally seperate sections of a class''s definition into groups of interfaces, which are a set of interface methods all used in the same general context, and internal methods.
quote:

I love OOP, and I agree with your boss on this one. Variables should be public. It is a deficiency in the C++ language that means everyone tells you to make them private: C++ doesn''t allow a class to know when you assign a value to one of its fields. Having said that, if you''re programming in C++, variables should be private, because of the deficiency.


I agree. Other, higher level(?) languages do notify objects when their members change. If c++ did this, I wouldn''t like interfaces, either. This is the main reason I use interfaces - to notify the object that it''s changing. Thank goodness for Borland C++ Builder and it''s ANSI extensions!
quote:

When you are employed by a company, they will generally have rules about the coding and design style that is acceptable by that company. They don''t impose that style because they are fascist (well, sometimes they do), but because it is important to have a style that everyone uses, elsewise no one can work together.


I agree. I would love this, actually, even if it was saying that everyone had to use commented assembly language, exclusively. Just so everyone knows how to write their code, what they''re looking at, and doesn''t have to figure out exactly some other programmer is trying to express.

Programming is like speaking another language, and writing a program is exactly like trying to write a story in a second language. The quality of the program will -usually- be based on the author''s command of the language, and his ability to express himself in terms of it. If someone is writing a paper in German, and another German speaker has to read it, it would benefit the reader if the author didn''t use a German form of Pig-latin to write the paper, which is the equivalent of what I see here in my shop sometimes.

Everyone here has their own very subjective style, and no one is willing to change it for the sake of uniformity and professionalism.

Hungarian notation was easier to understand the first time I''d ever seen it than a lot of the code here.
quote:

Judging from your description, it appears that your office doesn''t have a style-guide. It is important to have one. The fact that OOP is technically correct doesn''t mean it must be used: in the end what matters is that the programmers use a paradigm with which the majority of them are familiar. Your office needs a style-guide that is compatible with the programming practices of everyone who works there.



Again, I agree. I am the only person, I think, with a few reservations, who''s heard of a style-guide, let alone read anything about them (again, "Code Complete" comes to mind, as does "Writing Solid Code" by Steve Maguire). I still use funtional based paradigms where it is more applicable, such as simple file I/O, image data, and array manipulation, among other things, but I tend not to mingle the two too much. Sometimes here, though, everything is a hybrid.

But, as far as OOP comprehension, some of the guys here are just too stuck in c. A couple of the programmers started out in c++, and hate what goes on here every bit as much as I do, but it''s up to the boss, and he just doesn''t feel like doing it.

/sigh

Oh well. I don''t really mind, though. They could tell me to write japanese code in assembly language, on paper, in a closet, and in the dark, and I''d still be happy to be putting food on my table with it. I just like programming, but, hey, we can all vent, can''t we?

At least it''s not just me, though. It''s not just me.
*Keeps telling himself this.*

Again, thank you for your bandwidth.

Share this post


Link to post
Share on other sites
MSVC6 has property extentions. I hate them. Side-effects are evil. If a property is public, it damn well better be an object.

From the Connection15 interface of the ADO typelibrary:
#import "C:\Program Files\Common Files\System\ADO\msado15.dll"
  
__declspec(property(get=GetConnectionString,put=PutConnectionString))
_bstr_t ConnectionString;



quote:

...such as using "const", "new" instead of "malloc" and "calloc", and using "string" or "AnsiString" (a borland specifice string class) instead of "char*". My boss straight up told me he doesn''t like me using const objects. He also doesn''t like me using interfaces. He feels that I should just make all member data public so it can be directly accessed...


balls - Maybe you should just drop C++ for a while and buff up on C. Or buy your boss a copy of "Effective C++" You you ever use the STL? I bet they love that

They apparently don''t like structures either... I was working with a guy on a LabView project, and the concept of a "typedef" was alien to him.

Magmai Kai Holmlor
- Not For Rent

Share this post


Link to post
Share on other sites
The properties that BCB uses are seemingly much easier to work with -
  
int m_Value;
void SetValue( const int );
int GetValue( void ) const;

__property Value = { read = GetValue,write = SetValue };

- makes perfect sense to me, and there''s no imports or active x needed!

Mag - didn''t bcb''s properties format come from delphi? A lot of BCB came from delphi, heck, even their win32 code base is in object pascal. I know you''ve used delphi before, which is why I ask.

But, yes, when I use the STL I basically get a "never let me see that section of code again" look. They would rather hard code a linked list traversing it manually every time they use it. I mean they won''t even use access functions! PHEW!

Null and void - I agree. Though I like c++ better, and would rather use it due to how I feel about it''s reuseablility vs c''s reuseability, I am definitely a better c programmer. I also get projects done faster when I use just plain c. That''s when I''m starting a project from scratch, though, with no reused code. Reusing my OpenGL object code will save me a few weeks worth of work on future projects, though!

Share this post


Link to post
Share on other sites
NO! The import nor ActiveX is needed (and ATL is the Active Template Library, though you can implement ActiveX controls with it, your not forced to :p)

That''s just what I was working with when I discovered that MSVC6 in fact did support property get/set tuples.

  
DWORD GetBadIdea() {return BadIdea;}
void PutBadIdea(DWORD BadIdea_) {BadIdea=BadIdea_;}
__declspec(property
(get=GetBadIdea,put=PutBadIdea)) DWORD BadIdea;

The syntax is almost the same...

And I''d bet money that the BCB''s property extension was required due to it''s Delphi roots.

What drives me absolutely nucking-futz at work, is that they used Delphi to build a very flexible program architecture - that Delphi has no-way what-so-ever of gracefully coping with. They did (and continue) to do veritable circus tricks to compile their code with Delphi. Delphi doesn’t handle dynamic arrays all that well – so they create a type array[1..10000000] as int and another type as a pointer to that type. Then declare an array pointer, and use reallocmem with a small chain of cast to allocate as much ram as they actually need. Now that’s not entirely different from the way you’d do it in C or C++, but they type definitions are kinda silly - it does bounds checking when you access the array – but with invalid bounds (1..10000000)! Maximum overhead for no benefit!
Let that be a lesson to you to mention Delphi around me :p
[end rant]

Magmai Kai Holmlor
- Not For Rent

Share this post


Link to post
Share on other sites
HAHA viva the world of lost dum f*cks! Where I work the managers are extremley nice ppl, except for the fact that they are managers in the wrong industry such as, no previous software development experience, as in never written code before... So.... they outsource some code because the team is "busy". Now suposedley, they outsourced the code to some dood who aparently has "15 years" experience... Now every time we code something, we get asked the question: "Did you guys REUSE such and suchs code?" My response to that: "No his code is crap!" Manager: "Why? He has 15 years experience" Me: "It works, doesn''t mean it is done right!" So bassically what we do, is we create custom server applications that connect to several banks around the world... All applications as a requirment must be NT services... Now the XYZ doods code is all mixed up and intertwined... Meaning he mixes C and C++, uses sometimes printfs with couts... This is do to the fact that he writes alot of code that he probably ruses, bu cutting and pasting into new applications... Also the fact that he mixed up the banking logic with the actual NT service code... etc... So my solution to his mess is rewrite a framework for services where you can subclass and overide the main NT service functions... So now my code is under review by our suposed dev lead, which is no better then me only fact that he puts up with the bullshit and am the rebelious one... bla bla bla

Share this post


Link to post
Share on other sites
quote:

I love OOP, and I agree with your boss on this one. Variables should be public. It is a deficiency in the C++ language that means everyone tells you to make them private: C++ doesn''t allow a class to know when you assign a value to one of its fields. Having said that, if you''re programming in C++, variables should be private, because of the deficiency.



Bleh, unless your using a very old compiler this argument will not hold

if you want to give the users access to an array inside,
you do it like this

class foo
{
public:
...
vector< int >& getArray();
private:
vector< int > array;
}

inline
vector< int >& getArray()
{
return array;
}


This will give access to the array without _ANY_ overhead.

And your definately wrong on your OO perspective, its very not OO to make all your members public.

Its all about making an interface which the users of your class can use.
If you need to give them access to all the internal data, then its because you have failed to create a proper interface.

... so Succint, I would still say you have the long end, I''d suggest you buy your boss a copy of design patterns or something like that.

Share this post


Link to post
Share on other sites

...such as using "const", "new" instead of "malloc" and "calloc", and using "string" or "AnsiString" (a borland specifice string class) instead of "char*". My boss straight up told me he doesn''t like me using const objects. He also doesn''t like me using interfaces. He feels that I should just make all member data public so it can be directly accessed...


Seriously, const and interfaces are part of C++. They been around for years. So bassicaly your boss is saying that BJiorn Strousup doesn''t know what he is doing

Share this post


Link to post
Share on other sites
Heh, he doesn''t even know WHO Bjarne Strostrup is! I''ve even told him a few times, and he always forgets.

I found out the Code Complete is only $20 on Amazon. I think I know what I''m getting a few people for Christmas.

These guys just don''t understand exactly what C++ is. They''re stuck in c. Heh, I bet they look at c++ in the same way I did when I was 13 .

Share this post


Link to post
Share on other sites
Geez, I couldn't work with people who made their global variables that abstract ;-)

I really don't like these ones:
    
int a,b,c;
int ww,hh,xx,xa;
FILE *zax; // zax is always a file pointer

FILE *zed; // as is zed

int a,b; bool da;
int x,xx,y,yy;
int scaleval,smod,iran,ggx;
BYTE *smode, *mode;
int orin,olorin;
DWORD tic;
BYTE *dev;
float *fcrot;
int icrot;
int a,b,x,y,i,j,k;
DWORD tic1;
int ggx,ggy, nggx, nggy,
uggx, uggy, vggx, vggy,
cenx, ceny, ncenx, nceny,
ucenx, uceny, vcenx, vceny;
float goff, noff, uoff, voff;
int crossx, crossy, downx, downy;


I try to avoid global variables; then again, there are times when they are very useful.

Edited by - Viscous-Flow on November 5, 2001 7:17:40 PM

Share this post


Link to post
Share on other sites
I'm inspired to post more .

quote:
Original post by Succinct
They're stuck in c.


They're stuck in crappy C. The "const" keyword is part of the C standard as well, it has been for at least 2 years (at least 5 probably, but I don't have the older copies of the standards). Even in my C programs I use ONE linked list (I use macros and casting to fake templates, heh), I don't make one for each type. Global variables are to be avoided in general. When you can't avoid them, don't put them in a global namespace (yeah, I know namespaces are a C++ thing, but it still is an applicable term to C even though it isn't a keyword ), use a header that is shared with only the select few files that need to know about them. Globals always deserve the most specific function names, not things like "gxfd" .

However, I agree with them about a couple things. You shouldn't use ANY compiler specific extensions like "AnsiString." If they are already using char pointers instead of STL strings, you shouldn't mix string styles either. If they're already using a modular or procedural approach, you should use what they are instead of writing your own OO interface based designs. Although, it doesn't sound like they're being very consistent on their design style on their own, so screw 'em (just don't get yourself in trouble, heh). If they're doing C, you shouldn't be using new or delete, you should be using malloc and free.

I may write more (both agreeing and disagreeing with you) later, so I'm not saying I'm done . For the most part I think your fault is not merging with the code base correctly, and I think their fault is being ignorant of coding style, standards, and technique.

[Resist Windows XP's Invasive Production Activation Technology!]

Edited by - Null and Void on November 5, 2001 7:19:09 PM

Share this post


Link to post
Share on other sites
I would say you need a differant approach. You need a less advesarial approach. Rather than speaking you need to listen. Ye ole infamous people skills. You are not dealing with computer, you are dealing with people. You do not keep pounding away at the same routine trying small variations until it works. You need to take a step back and say what is going wrong here. Having been there and done that I can pretty well guess what is going wrong. It is not how do you get them to see that you are right. It is not how do you get them to make a huge leap of faith. That is not how people work. Rather it is how do you convince them that you are both right and there is no conflict in that. How do you get them to take a little babystep in the right direction. How do you make you accomplishing your goal their success.

Share this post


Link to post
Share on other sites
quote:
Original post by LilBudyWizer
I would say you need a differant approach. You need a less advesarial approach. Rather than speaking you need to listen. Ye ole infamous people skills. You are not dealing with computer, you are dealing with people. You do not keep pounding away at the same routine trying small variations until it works. You need to take a step back and say what is going wrong here. Having been there and done that I can pretty well guess what is going wrong. It is not how do you get them to see that you are right. It is not how do you get them to make a huge leap of faith. That is not how people work. Rather it is how do you convince them that you are both right and there is no conflict in that. How do you get them to take a little babystep in the right direction. How do you make you accomplishing your goal their success.


*scratch scratch*

Err.... was there anything there there?

oh.... ok. "Compromise".

Share this post


Link to post
Share on other sites
I''m sorry Null and Void. I realize that I sound like I''m bashing c here and there, but I really don''t mean to. I really like c. I still use c for various things, especially when I''m doing examples for other people, and when I''m throwing something together really fast - c++ just takes longer when you''re not reusing objects, IMHO. Also, we do some embedded system programming, and there is only a c compiler for our hardware. C is a much better language for certain things. The only reason I''m advocating c++ here is because it fits the software we''re working on better. These guys don''t understand the seperation between c programming paradigms and using c++. All of our code is a hybrid. Heh, there are 2365 compiler warnings on a full build - mostly "member function xxx hides virtual member function xx in parent class" types of warnings. I changed 3 lines of code and pulled out 700 warnings - they were defining a variable in a header file that is included everywhere, and I just externed it to the .cpp. It''s not that they''re using c, it''s that they''re using c badly, giving it a dash of c++, and calling it OOP programming...

I try and use as little global data as possible. In fact, most of the global data used in windows programming, to my knowledge, is the win32 specific data - the HWND, HDC, etc. With c++ you can completely avoid using the global data by using window user data or window properties and storing the c++ "window" object''s pointer there. There is no reason to store graphical coordinates as global variables if they''re relative to a single window. Same thing with file pointers and anything else that is relative to a specific task. I feel you should only use global variables for -cough- global data -cough- which, sadly, usually isn''t the case here.

LilBudyWizer - I wouldn''t say I''m necessarily being advesarial. My office is very non-corporate and informal. Everyone jokes here and there about such-and-such''s filthy coding style and what not. It''s not like I''m trying to convince the evil manager that the code being written is wrong, because we''re all pretty much friends, and I don''t particularly want to convice them that they''re wrong and I''m right. I''m more looking to meet on middle ground and to have them acknowledge the differences, think about progressing as modern programmers, and allowing me to use my OOP instead of a P/R - OOP hodgepodge.

Heh, on an interesting side note, try malloc()ing an object with an important constructor. PHEW, I''ve never done it, but I imagine that it would send your program down in a fast and fiery crash!

But, to reiterate and clear up any confusion - I do like c, when it''s c you mean to be using, and I''m not looking to start a huge finger pointing battle with the folks at work. I just want them to stop telling me that my coding style is wrong because I actually use OOP and good coding style . I don''t think this is possible, due to human nature and human stubborness, so I''m probably just going to stick it out until they let the issue go. I''m will NOT begin to program using hodgepodge techniques, unless that is the best option at the time (which I can''t really see happening). I''m not bothered because they think I should program in c - I would have no problem with that - it''s more that they feel I should program sloppily like them

Thank you all for your bandwidth so far,
-- Succinct

Share this post


Link to post
Share on other sites
Succinct,
I''ve been following this post for some time, resisting the urge to speak up in horror about what I''ve read. There are all these people making posts about how you have to change your style to conform to what you perceive as shit, and how you have the wrong ideas, and well frankly, it pisses me off. I agree with you and your coding style 100%. I think procedural programming has its place, but is for the most part a thing of the past have been built upon to produce more modern, mature design methodologies.

In my old job I was a project technical lead on a medium sized software project. We had a particular programmer who was surprisingly good at user interface programming. His code though made a mockery of OOP. He insisted on global data, public class data members only, no getters or setters, no interfaces, and no formal state machines, only loosly managed state variables.

I considered him a glorified procedural programmer who pretended to understand OOP. He didn''t know anything about OOP. I was his team lead, but I wasn''t the project manager so I wasn''t able to dictate his design. I often wondered why he didn''t just use structs all the time instead of classes. In fact, he didn''t need c++ for the garbage he was writing, just c.

I was also the main designer of the data processing engine that ran underneath the user interface and I was determined to not let his filthy octopus of procedural code extend its tentacles into the beautifully OOP conformant data processing engine where it might corrupt the beautiful piece of work that the rest of my team had worked on so diligently. We created a beautiful work of art, a sculpture out of marble if you will, and if given the chance he''d have coursely nailed two-by-fours into it to extend his design.

I might add that there was not a BIT of global data in the entire dtat processing engine. So the design I basically came up with was a pyramid scheme where he, as the UI programmer, only had one single entrance point to the entire engine, and this was through an interface class that wrapped a more fully featured class that contained the engines various modules. This interface class didn''t have ANY public data. It was all data request methods. To make sure that he couldn''t modify this interface to follow his own programming style I made it so that he didn''t have write privileges on this file in our source repository. I couldn''t dictate how he had to program, but I was the owner of the source tree.

If he wanted data, he asked us for it. If he needed some data we weren''t providing, he''d have to ask us to expose it. It was frustrating for him at first because he couldn''t just take what he wanted without worrying about the consequences, but program maintenance times due to this action were amazingly low. It was amazingly effective.

Ever so slowly what we did was remove spaghetti/procedural code from his component and turn it into proper OOP code/design and throw it behind the interface class. He had to conform. Near the end of the project he started seeing that it is amazingly comforting to use interface classes because if you find a problem it always traces back to that one place.

Now I work as an operating systems programmer and I know that the OS I work on wouldn''t be nearly as amazing as it is if it weren''t for OOP. Of course some of the people I work with are amazing procedural programmers using an OO language, but there are many good OO people here as well and in fact they make up most of the senior design team. We have several hundred employees working on this one operating system.

What I noticed about my old UI programmer''s methodology versus the rest of the teams was that when it came to continual maintenance and feature additions, our engine scaled amazingly well. His user interface was re-written nearly 5 times in the course of 10 months due to changing requirements.

It should be noted that for every user interface requirement change there was generally a change required in the engine as well. I''d also like to note that we didn''t once have to re-write the engine. Only once did we have to undertake a semi-significant engine design change, and since all of our classes worked off of data accessor methods and interfaces the changes to certain fundamental classes didn''t affect at all the majority of the classes that were already written.

What I find is that procedural programmers don''t worry about consequences of their design approach until a problem occurs, but OOP programmers try to eliminate as many future problems right away as possible.

Well, this rant is long enough. I just want to say that I support your struggle to support OOP and move programming in a forward direction and I''m proud and relieved that there are other people like myself who don''t like to settle for mediocrity.

I, like yourself, believe that procedural programming HAD its glory days in the past but there are newer methods of software design that are way more mature and effective under todays software requirements. It is also my belief that procedural programming is OK when it comes to individuals working on a one man project, but on large projects if encapsulation is not adhered to the result is devastating (project cancellation, been there.)

I''d recommend that you continue to do what you were doing and make your interfaces rock solid. What you need to do is ensure your bosses that by providing them with a black box interface to your code you are eliminating possiblity for errors by providing them with a common trace point for all bugs involved in your module. They can then always trace bugs directly back to your single code entrance point and then hand the bug over to you.

Also point out that a lot of OO design is concerned with states and state machines and you can not manage a proper state machine when your class member data is public. It is the duty of the class to manage all data and to return the data in whatever manner it chooses through access to its interfaces. By providing public member data you eliminate a class''s ability to protect and manage its internal representation of its data.

For all the rest of you who are too lazy to truely try to understand OOP and criticize this person for his wonderful approach toward software design, shame on you. Maybe you should re-evaluate OOP and do a little research. Now don''t take me for an OOP zealot. I believe that procedural programing still has its place in things such as function libraries, but leave mature software development to mature software design methodologies.

Bravo Succinct,

RandomTask

By the way, using malloc in c++ is just plain silly.

Share this post


Link to post
Share on other sites
Succinct, welcome to the real world.

My company is even better. My manager tells ppl that this app and that app are extended from our 3dengine.

What "extended" means is they come from the same code base. Bascially, a "copy,paste,hack" job.

One of these days, there is gonna be a hard to track bug and nobody is gonna know which module it comes from. (and it''s probably your coworkers). If there is a dateline closing, prepare lots of coffee.

A lead programmer should dictate what sort of interfaces each module expects, how the modules interact. (i.e. doing software architectureal design)

And lesser programmers do the specific implementation.

Without that, integration between modules is gonna be hell. (More coffee again)

My advice is to start preparing your resume.

Share this post


Link to post
Share on other sites
The difference between your position, RandomTask, and Succinct''s, is that you''re the boss. Succinct says his boss told him not to do certain things. People tend to get fired where I work when they continue to do things the boss tells them not to...


...
quote:

Heh, on an interesting side note, try malloc()ing an object with an important constructor. PHEW, I''ve never done it, but I imagine that it would send your program down in a fast and fiery crash!



You can safely do that:
  
#include <new>

class CCheckThisOut
{
public:
CCheckThisOut() : m_pArray(0)
{
}
private:
int* m_pArray;
};

//...

//CCheckThisOut constructed in the memory returned by malloc.

void* pv = malloc(sizeof(CCheckThisOut);
CCheckThisOut* pCTO = new(pv) CCheckThisOut;
//this new does not allocate any memory, it uses the memory pointed at by pv and calls CCheckThisOut''s constructor on it


It''s called placement new, I learned about it a week ago. Don''t ask me how to delete it, I don''t know yet ... maybe it''s:
  
delete(pv) pCTO;
free(pv);


...
P.S. I should mention that Delphi 4, 5, & 6 have support for dynamic arrays, but our Delphi codebase comes from before that.

Magmai Kai Holmlor
- Not For Rent

Share this post


Link to post
Share on other sites
At the risk of drifting slightly offtopic ... I believe deletion has to be done like so:
  
pCTO->~CCheckThisOut();
free(pv);

Share this post


Link to post
Share on other sites
Thanks for sharing your sentiments, everyone. I must say, though, RandomTask has given me a large glimmer of hope. I think my best bet is to keep writing my code like I always have, and only expose to them the parts they will need via encapsulation and interfaces. I''ll take some heat for it, but I think, in the long run, it''s the smartest way to go, for my own sanity, for the good of the project''s scaleability and reusability, bug tracking, and, besides, it''s just plain more aestheticly pleasing.

I am NOT planning on changing my style to fit theirs. Sure, if it was just a different coding style, that''s fine. While I was learning windows, I was speaking and writing in hungarian notation like it was a second language, but it''s not my style. Besides, there''s not a particular coding style to fit! Everyone here has their own different style, mine just "looks too much like book code", they say.

They say I''m too bound in Computer Science theory, and that stuff, like interfaces and encapsulation, do not really work in the real world when you''re on a deadline. They claim that some of the code looks the way it does because of deadlines.

Well, I may be drinking a lot of coffee for my next few deadlines, but after that, I''ll have myself a good code base of components we generally use in our products, and I''ll be able to reuse them with little or no modification, and I''ll only have to include a header file - much better than cutting and pasting, IMHO.

Any other suggestions will still be greatly appreciated.

Thanks again, everyone,
-- Succinct

Share this post


Link to post
Share on other sites
Succinct, I haven''t really been following this thread, so please excuse me if this question has already been asked, but why are you still working there? That working environment is the worst I''ve ever heard of! Why not find a better job where you are encouraged, and even expected, to develop your skills as a programmer?

It sounds like you aren''t learning a thing from your current job (except what not to do ), so why not move on to a place where you can learn?


- Houdini

Share this post


Link to post
Share on other sites