|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 09 July 2002 15H:21, Fred K Ollinger wrote:
> > My opinion is that C++ evolved from C just like ObjectPascal evolved from
> > Pascal. I wouldn't call either of them temporary solutions. Both have
> > evolved, and both seem to continue to do so.
>
> Although, it may appear that C++ "evolved" from C b/c C++ compilers are
> backwards compatable, I think that this does allow for really bad
> programming practices.
>
> Larry Wall is cool, but I strong disagree w/ his TIMTOWTDI idea when it
> comes to programming b/c consistency is very important.
I disagree with the focus here. I think READABILITY is more important than
consistency. Consistency sometimes, but not always, results in readability.
If everybody in a group writes similar unreadable code, you still have a
problem. How about if we try to get everybody to consistently write readable
code? How does that sound? And, I'm not saying anything about the readability
of any pearl code I've read or worked on...
Another example is boiler plate comment blocks. If the comments in the comment
blocks are worthless, then the comment blocks themselves are worthless.
Consistency bought you nothing but extra comment lines you have to weed
through to find that you have worthless comments. If the comments themselves
were improved, then you'd have something.
>
> Usually mixing c and c++ has worked for me, but it does make for messy
> code. My experience comes from using the c++ strings and char arrays
> together.
>
Yes, you should generally pick one approach within a module. I would
definitely recommend avoiding the mixture of these two string approaches
within a given application. BTW, If you wanted to trash the lack of good
string support in the C++ language, I would NOT disagree there.
> c++ is so popular today b/c it mixes w/ c, but that doesn't mean that
> mixing the two is a good idea. If the ideas in c++ are so good, then their
> methods should be used and c methods not used. If the ideas in c++ are not
> so good then there's no point in having them.
This is like saying that if C is was so good, why would anybody still program
in assembly. For some people/projects assembly language is still the
simplest/most efficient way to do things. That doesn't mean everyone should
program in assembly, or that you should always mix C/assembly. For most
people, C++ should allow people to write better, easier to read, and
sometimes even faster code with fewer lines of code. That doesn't mean "why
would anybody still program in straight C". And, just because you can write
better code in C++ doesn't mean you automatically will.
>
> This is coming from a half-assed c++ programmer who badly wants to master
> c.
A little attempt at humor: So, if I'm half-assed and you're half-assed, does
that make us one complete ass?!
>
> > I'm sure there are have been many purists that would say (and did say)
> > that any OO language that's not designed from scratch is only a temporary
> > solution. However, I don't believe that any of these people were closely
> > involved with the design and evolution of C++.
>
> I don't think that's what Noah meant.
>
> If c++ gave methods that did _different_ things than c then it could be
> said to have evolved. An example is bash evolving from sh (and ksh).
>
> However, c++ seeks to replace c's methods with it's own. It retains c
> compiling capability, IMHO, in order to get c programmers to learn c++.
> "Look, you can still do c, but if the fancy strikes you, use these better
> methods, too."
You seem to be contradicting in these two paragraphs. You think that c++
DOESN'T give you different methods that do "_different_ things", then you say
that c++ "seeks to replace c's methods". Isn't that methods that do
"_different_ things"? "Methods" and "things" is a little vague here.
I'll give an example of C++ evolution: the addition of exceptions and
templates. Is this not evolution in your book? Again, IMHO, C++ has been
evolving and is still evolving. Very few c++ compilers have caught up with a
substantial percentage (> 90%) of the features of the language.
And, C++ does not strictly retain "c compiling capability". There is some C
syntax that is definitely not valid C++. The BASIS for C++ syntax, however,
is clearly C.
>
> I _like_ mixing c and c++, but that doesn't mean that it's good for me. I
> like perl, and I like being sloppy, but that could make more work in the
> end. I think that the structure in pascal tries to force people out of
> these bad habits.
I'm NOT recommending SLOPPY coding. I'm definitely not recommending putting
"C" funtion definitions in the middle of a module with a bunch of member
function definitions. I'm saying that you can CALL a "C" function from the
middle of a member function definition. In fact, many times you HAVE TO for
system calls. Unless you want to rewrite your entire system library in an OO
paradigm. And, I don't recommend that.
No matter how much you abstract it and wrap it, the actual system call is
usually burried in there somewhere. And that's OK.
Now, imagine that you have an existing API that your company has been using
for 20 years. If you can come up with a nice OO approach, great! If not,
don't force a bunch of objects down everyones throats just to say "we're
doing everything 100% OO".
The point is, don't assume that you have to throw out ALL of the world of
procedural programming to adopt an OO approach. This does NOT mean that you
should just switch back and forth for no reason. The point is, you should
incorporate new ideas for a reason. And, incorporating new ideas should not
always require starting over from scratch. Use what you've already learned
(procedural programming), then add the new concepts (OO).
To me, OO does not mean "don't create procedures anywhere". IMHO, it does mean
simplify and group functions with relevant data. If you don't have a set of
related functions and have no related data that you need to keep with that
function (different data every time you call the function), then you probably
don't have a new type of object.
>
> > Also, it would seem to be completely counter-productive to work on the
> > design of a language that you intended for obsolescence (sp?). Not that
> > it couldn't have happened that way. But, I'd be very surprised if that
> > was actually the way that Bjarne Stroustrup intended.
>
> Did he take ideas from other OO langs and bolt them onto a c compiler?
> That's how it's looked to me.
No, the C++ language would have been created in a much shorter timespan if
that was the only goal. As it was, it took about 10-15 years to EVOLVE most
of what the C++ standard is today.
>
> I've heard so many people talk about these really cool oo langs (small
> talk) that can't be used for compatability reasons.
>
> > BTW: I believe that Eiffel was a from-scratch OO language, and I haven't
> > seen any new development with that language in quite some time. I don't
> > doubt that someone is working on it somewhere in the world, though.
>
> I have read a lot of mind-numbing Eiffel advocacy, among it suggests that
> the mess w/ deps in linux seems to be some brokenness in c/c++ itself. I
> doubt this may be all the story b/c the book goes on to praise java for
> dealing w/ lib problems, but I have had lots of puke on my screen when I
> don't have all my paths set up right. I do wish there was a magic way out
> of dynamic library hell. I don't think that static linking everything is
> the answer, and I do think that apt-get is a step in the right direction,
> but I still have messes w/ libs getting mucked up all the time. Mostly
> this is my own fault, tinkering, but still.
>
> > There's nothing stopping you from using printf in a C++ program. It's a
> > function call and is perfectly valid. IMHO, the intent of C++ was exactly
> > not to throw away C, but to add OO concepts. Also, the words are "support
> > object-oriented programming", not REQUIRE it. When you write C++ code,
> > you often can and do need to call functions with C-style syntax. This is
> > perfectly valid, acceptable, and common practice in many of the most OO
> > development groups. C-style functions are NOT BAD. They just might not be
> > AS GOOD, or as readable in a true OO app.
>
> But I'd rather keep using all C-style functions only and only use c++ for
> improving things that weren't in c all ready. My point is I don't want to
> have printf and cout b/c I think it's a mess. I guess the answer to this
> is not to use C-style functions at all.
If you aren't going to make any C-style function calls, then what system
library do you plan on using?
Or, if you mean not to create any NEW C-style functions, what if it's just a
couple of lines of code that would often repeat and totally unrelated to any
other code? The repeated object instantiation and method call alone might end
up giving you more lines of code and might actually make your code more
difficult to read than a simple function call. Plus, you should not create a
class that makes no sense.
If someone were to tell you to always create classes, even if they make no
sense, I would recommend finding someone else to give you OO programming
advice.
Again, I'm NOT saying don't create classes. I'm saying HAVE A REASON for the
class. If you can't find a reason (and you've thought about it first), then
maybe you just need a simple function.
As a result of creating 1 C-style function in its own module (function.h and
function.cpp), have I introduced sloppy programming? I don't think so.
Have I negated all of the benefits of OO? No, I don't think so. In fact, I
reserve the right to create a class later and move that function to the new
class if a compelling reason shows up (when the requirements change, and they
will).
Am I saying, "Always start with C-style functions"? No, definitely not. If I'm
using an OO approach, I am generally looking for classes to group related
functionality and data.
Again, what I am saying is: Don't create a class just to create a class. If it
makes the code LESS readable and there's no compelling reason to do so, don't
do it!
Simpler is usually better and almost always easier to read.
>
> > Here's an example: If you have a "C" function that does exactly what you
> > need, you don't need to create an object that simply calls that function.
> > However, if creating an object, or moving the function call to an already
> > existing object, simplifies much of the rest of your code, then do it.
> > IMHO, the biggest gains still to be realized from OOP is code
> > readability.
>
> Here, here. Although, it takes a while to get used to oo. I gave myself
> ulcers when I made way too many classes, at first, and I spent time trying
> to pass variables from class to class. I still don't think I have that
> right. I'm not saying personal incompetence makes for a bad language, but
> I'm saying all things in moderation.
>
> In many small programs, I don't see the point in oo at all, in even mediam
> size ones, I'm in hell if I don't do at least a little modularization.
OO is very much about encapsulation. If you only have a couple of lines of
code in your app, guess what? It's already encapsulated. Dear lord, please do
NOT create objects just to create objects. They really ought to have a reason
for being created!
>
> > I completely (but respectfully) disagree with this description. I believe
> > that it is fairly common knowledge that Java is a direct descendant of
> > C++. I believe that this is spelled out in pretty much every Java book
> > I've ever read.
>
> I like java for this reason. It has all the good stuff from c++, but none
> of the rough edges. I'd probably use it more often if it had a free
> compiler to create binaries using swing libs. I all ready learned qt so I
> don't need this so much anymore.
>
QT is generally a good OO GUI library. And, you can avoid dealing with many of
the "C" style system library calls. But guess what? Those system library
calls are inside the QT library. They don't just go away. Sometimes its more
efficient and less code to just call the system library directly. And, that's
OK! Most of the time, though, you should stick with what's provided by QT and
not worry about what's underneath.
> > In addition, one of the ways that the Java certification exam tries to
> > trip you up on is on some of the subtle differences between C++ and Java.
> >
> > Well, I hope you didn't take any of my message as an insult. I did,
> > however, take objection to statements like "C++ is broken" and merely
> > "intended as a temporary solution".
>
> This was news to me, too. I did see the point, though.
Well, it would be news if it was true. Which, I'm fairly certain that it
isn't.
I've put some very successful projects into production for a number of
companies in very short timeframes using OO concepts with C++. If the
language was broken, then that wasn't possible, yet somehow it happened
anyway. And, if Mr. Stroustrup intended something to replace C++, what
exactly was that? When will he start working on that?
>
> > And, you seem to be trying to indicate that Java stems very closely from
> > ObjectPascal and is simply similar to C++ in some elements. I believe
> > that you have that entirely backwards.
>
> Well if you are going to copy an older oo language, there's only so many
> ways you are going to want to change around the syntax.
>
I'm not strictly talking about basic syntax. Noah mentioned the design or
intent of the designers. I'm simply quoting the designers and giving my
interpretation of what I see there. I'm still unsure if either of you
disagree with my interpretation of the quotes I gave you.
> I think that this is like saying BB King sounds a lot like the Rolling
> Stones. Hmm.
>
> Fred
>
IMHO, we are fortunate to have these language choices. I'm glad to see
ObjectPascal available, even from more than one source.
However, I don't want to read inaccurate statements about the design of a
language that I do use quite frequently.
We're starting to get into good OO design principles a bit. There's definitely
a lot of room for debate there. And, that goes for no matter what language
you are using.
Cheers,
Jason Nocks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAj0rV64ACgkQ3CryLfCgqRlXZwCfVeUAZdYVzu+7ii3Yo2nha/p3
88wAn3qr4CFyrRrN2LF01eTMzQo17WuY
=boTy
-----END PGP SIGNATURE-----
______________________________________________________________________
Philadelphia Linux Users Group - http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion - http://lists.phillylinux.org/mail/listinfo/plug
|
|