C to C++ Learning Curve

0 Aufrufe
Direkt zur ersten ungelesenen Nachricht

TimW

ungelesen,
27.04.2000, 03:00:0027.04.00
an
I was just eating a sandwich and reading a thread in comp.object.corba and
there was a statement made that it usually takes a C programmer 12 to 18
months of everyday use to become useful in C++ programming. Then someone
else piped in and said "more like 3 years", then someone else said "I've
been C++ ing for 12 years and still don't have it down".

I didn't want to chime in to that thread, but these numbers seemed to
inflate the learning curve more than I would think is accurate, and it got
me thinking. For one thing, if it took 12 years to learn a programming
language, it would seem to defeat the usefulness of the language in
practical terms. That, by the time anyone was competant in the language it
would be a dead language. That, if it were that complex, it would be too
hard to be useful, and in particular, maintainable.

I dunno...perhaps it's because I've always enjoyed modularity and coded
using a lot of vectors to functions from the get go and perhaps I don't know
all the nuances of multiple inheritence and stuff and perhaps Bjarne
Stroustrup *is* the cure for insomnia, but I've always been able to at least
read C++ sources from the start, almost intuitively.

So...a question and a request for comments...

If a competant C programmer went off to C++ school...couldn't that
programmer be productive in more like a week or two instead of a year or
more ?

Thanks...

--
TimW

Stephen Howe [TeamSybase]

ungelesen,
27.04.2000, 03:00:0027.04.00
an

TimW <twa...@aspenres.com> wrote in message
news:au47$kHs$GA....@forums.sybase.com...

> I was just eating a sandwich and reading a thread in comp.object.corba and
> there was a statement made that it usually takes a C programmer 12 to 18
> months of everyday use to become useful in C++ programming. Then someone
> else piped in and said "more like 3 years", then someone else said "I've
> been C++ ing for 12 years and still don't have it down".

I think they are all correct. They are all answering the question, "How long
has to pass by before you know C++?". They are all drawing the line for
themselves in different places. The guy who said 12-18 months probably has
not used function try blocks but he can still use various features of C++
and be productive. The guy who said 12+ years is probably thinking of
various areas of C++ where he he has some doubts as to what language says in
that area and is thinking, "there are still things I don't know".
Nevertheless, he has written software in C++.

The fact is you don't have to know all of C++ to be productive in it. From
day 1 you can be productive. But it will be a long time before you approach
guruhood in C++ where you know every nook and cranny of the language. I
think, myself, it is of the order of 10 times more complex than C.

For myself, I feel I know C inside out, as per the ISO C 1990 & 1994
standard (not however the new C9X standard). I have been using it for 14
years. Mind you, I am probably fooling myself. There will still be areas
where someone might say something and I will say, "I didn't know that". I
think, I have approached pretty close to guruhood in C.

In contrast I have only been using C++ seriously for 3 years. There is
still basic learning to do and this will continue I think for many years. It
will be a long time before I am anywhere near the same standard as C.

But for yourself, you can start using C++.

You don't need to master classes, references, friends, virtual, new &
delete, templates, exceptions , operators, operator overloading, default
arguments, single inheritance, multiple inheritance to start using C++

Most of your knowledge of C can be used in C++. Mind you will find that
straight away that certain bad C habits have to be "unlearned" for C++. You
can use some of the C++ classes that Watcom provides, particularly string
classes.

After a while you might want to write your very first class. You can do
that.

After a bit more of a while you might want to use new/delete as C++
replacements for C's malloc()/free() particularly as they work with classes
better than malloc() and free() do.

Slowly bit by bit, you can use more and more of C++'s features as you get
more confident about using the language. For example, you can get by with
pointers for a long time and learn nothing about references. After a while
you might try references in certain situations, find them a bit of trouble
getting used to. After a little more time you might feel that in certain
circumstances, they are a lot more convienent to use than pointers.

Good books I recommend (ones that tell you under what circumstances you
would use a certain feature of C++ and when not to use it) are

I would pick up a copy of 2nd edition of Kline & Lomov's "C++ FAQ's". Have a
look at http://marshall-cline.home.att.net/cpp-faq-lite/ which is a 1/5th of
the size of the book above. Bookmark this and browse through it.
Also Scott Meyer's, "Effective C++" and "More Effective C++" are very good.

Hope that helps

--
Stephen Howe [TeamSybase] (In search of excellence)
London, UK

General reminder (READ THIS, IT IS NOT FOR SHOW):
1. Make sure you specify the version number of the product
2. Make sure you specify the host operating system
3. Make sure you specify the type of target executable

Thank you

TimW

ungelesen,
27.04.2000, 03:00:0027.04.00
an
Stephen Howe [TeamSybase] wrote in message

[EXCELLENT, thoughtful reply (as normal) deleted]

>Hope that helps


Yes, most definately.

I've since posted in the .corba group my thoughts.

I'd wager to say that the learning curve can be excelerated by hard-ball
training. My theory is that it would be *extremely* cost-effective to send
the entire engineering team off to some serious C++ training. Perhaps plan
a 1 month (* man month) development down time, go to (4) 1 week seminars,
complete with hardball labs, etc.

Cover OO design, polymorphism, encapsulation, inheritence....do it frikken
right, the first time, and then send them loose on a *real* project. These
are bright people or they wouldn't have been hired, they'll get it, they'll
apply it and then you've built real technical assets. Companies should
plan on doing this yearly, set aside a week or two. Technology changes so
fast....think about how often engineers move, just to stay abreast of the
opportunities, then think about the cost of employee turnover and
corporate/application/industry knowledge, etc.

I think this would pay off handsomely for the company and for the
individuals involved and that you could have people up to speed (in more
than a superficial sense) relatively quickly.

My .02 and advide that I think I would recommend to any SW manager in this
day and age.

Thanks again Stephen.

--
TimW


Tony Cook

ungelesen,
28.04.2000, 03:00:0028.04.00
an
"Stephen Howe [TeamSybase]" wrote:
> You don't need to master classes, references, friends, virtual, new &
> delete, templates, exceptions , operators, operator overloading, default
> arguments, single inheritance, multiple inheritance to start using C++

I think you need to understand classes, virtual member functions, new &
delete and single inheritence to be _useful_ as a C++ programmer.

Understanding how to use template classes and exceptions is pretty
essential too, though this is mostly realizing that 'typedef vector<foo>
bar;' is going to simplify your code a great deal ;). The main
difficultly with this level of knowledge would be that the current crop
of C++ compilers produce very opaque compilation messages when something
goes wrong when you are using templates.

Having a handle on the C++ standard library would help too - though this
obviously won't help with Watcom C++.

Just IMNSHO, of course.

Kon Tantos

ungelesen,
28.04.2000, 03:00:0028.04.00
an

TimW wrote:
>
> Stephen Howe [TeamSybase] wrote in message
>
> [EXCELLENT, thoughtful reply (as normal) deleted]
>
> >Hope that helps
>
> Yes, most definately.
>
> I've since posted in the .corba group my thoughts.
>
> I'd wager to say that the learning curve can be excelerated by hard-ball
> training. My theory is that it would be *extremely* cost-effective to send
> the entire engineering team off to some serious C++ training. Perhaps plan
> a 1 month (* man month) development down time, go to (4) 1 week seminars,
> complete with hardball labs, etc.
>

Most people don't get good value out of intensive 3day-1week courses.
The problem is that most people need time for new concepts to sink in
before they can really grapple with them. This is more applicable when
people have a lot invested in the 'old' concepts. Going from C using
modular (structured...) programming to C++ using OO programming is quite
a change in direction.

As Stephen said, the good part is that you can ease yourself into C++
from C, but you will not get real any benefits (ie more reliable,
manageable code etc) until you are weel over to oo programming, in fact
most (if not all) of you early C++ code will take longer to write, be
larger and slower than your equivalent C code. If you want to use the
code commercially, this can be quite an issue.

I have found that programmers are more likely to respond to 'drawn out'
learning sessions (eg 18 x 3hr sessions, with each session run once per
week. This allows more 'sink in' time & doesn't force you to be released
from earning income.

> Cover OO design, polymorphism, encapsulation, inheritence....do it frikken
> right, the first time, and then send them loose on a *real* project. These
> are bright people or they wouldn't have been hired, they'll get it, they'll
> apply it and then you've built real technical assets. Companies should
> plan on doing this yearly, set aside a week or two. Technology changes so
> fast....think about how often engineers move, just to stay abreast of the
> opportunities, then think about the cost of employee turnover and
> corporate/application/industry knowledge, etc.
>
> I think this would pay off handsomely for the company and for the
> individuals involved and that you could have people up to speed (in more
> than a superficial sense) relatively quickly.
>
> My .02 and advide that I think I would recommend to any SW manager in this
> day and age.
>
> Thanks again Stephen.
>
> --
> TimW

--
Regards
Kon Tantos
kso...@attglobal.net or kon.t...@tafe.nsw.edu.au

Markus Neifer

ungelesen,
28.04.2000, 03:00:0028.04.00
an
TimW wrote:
[learning C++]

Bjarne Stroustrup [1] said that C++ was designed
for a step-by-step migration from C to C++. But it
needs it's time.
I agree with Kon Tantos that you have to learn oop
too or you'll be a poor C++ programmer. In-deep
knowledge of C++ specials is not necessary.
On the other hand if you're already very familar
with structured programming:

'In fact IBM Consulting studies show that there is
approximately a 10% chance of successfully retrain-ing
a COBOL programmer in C++, although the transition to
Smalltalk is more successful.'[2]

[1] The C++ programming language. 3rd. §1.2
[2] IBM. Les Bell. Introduction to SOM
--
MN Watcom Page and MN Java Page at
> http://home.t-online.de/home/howlingmad <


Stephen Howe [TeamSybase]

ungelesen,
28.04.2000, 03:00:0028.04.00
an

Tony Cook <tony...@teamsybase.com> wrote in message
news:3908F254...@teamsybase.com...

> "Stephen Howe [TeamSybase]" wrote:
> > You don't need to master classes, references, friends, virtual, new &
> > delete, templates, exceptions , operators, operator overloading,
default
> > arguments, single inheritance, multiple inheritance to start using C++
>
> I think you need to understand classes, virtual member functions, new &
> delete and single inheritence to be _useful_ as a C++ programmer.

On a strict level, I totally agree with you. If all you ever did was shift
from WCC386 to WPP386 to compile code and nothing else, then you are using
WPP386 as a psuedo-lint (pseudo because WPP386 is not a C compiler). Your
not making the OO jump.

My point was that you can do these things on a gradual basis. Some of these
would have to be done at once. The moment you want pointers to classes
straight away you need to use new and delete rather tham malloc/free if you
want them properly constructed :)

Virtual member functions? Only if you have inheritance going on. Surely
there is no need without inheritance?

Single Inheritance? Only if your model of the domain your program covers has
situations where one object can be substituted for another. But on this I
concur with you. Most programs that model some real-life problem have
exactly this. It would have to be either a very simplistic program to have
no inheritance or just an academic program that is not solving some
real-life problem.

> Understanding how to use template classes and exceptions is pretty
> essential too, though this is mostly realizing that 'typedef vector<foo>
> bar;' is going to simplify your code a great deal ;).

Yes.

>The main difficultly with this level of knowledge would be that the current
crop
> of C++ compilers produce very opaque compilation messages when something
> goes wrong when you are using templates.

Groan, indeed yes. I am very familar with this. Seems hard for them to
diagnose if you have something wrong.

> Just IMNSHO, of course.

Thnaks

Al Balmer [TeamSybase]

ungelesen,
28.04.2000, 03:00:0028.04.00
an
On Thu, 27 Apr 2000 12:47:53 -0600,
in powersoft.public.watcom_c_c++.general

TimW <twa...@aspenres.com> wrote:
>
>If a competant C programmer went off to C++ school...couldn't that
>programmer be productive in more like a week or two instead of a year or
>more ?
>
All a matter of definition. The C programmer could be writing C-like code using
some of the features of C++ as a "better C" in a few days, and gain significant
benefits from doing so.

OTOH, C++ is really all about object-oriented programming, and requires that the
programmer develop a different mind-set. For some programmers, that "Aha! I get
it!" moment may come immediately, for others it may never happen. I have a
theory that it's easier for people who've been exposed to things like SNOBOL and
Lisp in addition to the "traditional" procedural languages.

Once that hurdle is passed, C++ has lots of arcane nooks and crannies, with some
pretty subtle gotcha's. If you don't want to become a real language guru, you
can easily avoid most of these and be highly productive.

Al Balmer - Team Sybase
Balmer Consulting

Please reply in Newsgroup, not email.

Stephen Howe [TeamSybase]

ungelesen,
28.04.2000, 03:00:0028.04.00
an

TimW <twa...@aspenres.com> wrote in message
news:vTuxknJs$GA....@forums.sybase.com...

> Stephen Howe [TeamSybase] wrote in message

> I'd wager to say that the learning curve can be excelerated by hard-ball


> training. My theory is that it would be *extremely* cost-effective to
send
> the entire engineering team off to some serious C++ training. Perhaps
plan
> a 1 month (* man month) development down time, go to (4) 1 week seminars,
> complete with hardball labs, etc.

Well, maybe. I am not a great fan of training. I have been on some courses
that cost a lot and forgotten what I have learn't in 2 weeks time. Maybe you
need a more hands-on approach.

I go along with what Kon says. Must of my knowledge is "hard won" where I am
trying to get something to work and it does not. In terms of learning things
I tend to

(i) read books, magazines (so Stroustrup's 3rd edition is mandatory really).
Those books I mentioned.
(ii) Try example code out and try developing my own stuff.
(iii) browse comp.lang.c++ and post things here when I am stuck. But
WARNING!!! This newsgroup is only tolerant of posts to do with standard
++ - that covers ARM C++ and ISO C++. If you post questions on "NT",
"Unix", "Linux", OS/2" or "reading from keyboards", "clearing the screen",
"interrupts" or "Visual C++", "Watcom", "Borland" then you will get a rude
reply that your post is off-topic and could you post your question to a
newsgroup _specific_ to your OS or a newsgroup _specific_ to your
hardware or to a newsgroup _specific_ to your compiler.
It is all right to ask, "Is Watcom C++ compliant to the ANSI/ISO C++
standard in this area"? That is on-topic.
It is not all right to ask, "How do I get Watcom C++ to produce a map file"?
comp.lang.c++ neither knows nor cares. That is what this newsgroup is for,
to ask stuff specific to Watcom.

My knowledge come from trying things out myself, reading article, magazines,
manuals a lot, asking Tony Cook <g>, posting to comp.std.c++, comp.lang.c++
when stuck or I need information, reading other peoples code that is better
than mine and understanding it.
That is how I learn.

If you know how to "work the newsgroups", they can be of great use to you. I
work them for myself when I am stuck.

Where training I think is of some benefit is where your team has tied to
master the basics, succeeded on some things, failed on others. If the
training allows some interaction with the instructor, you can present your
questions and learn very fast.

Alan Balmer

ungelesen,
28.04.2000, 03:00:0028.04.00
an
On Fri, 28 Apr 2000 18:55:11 +0100, "Stephen Howe [TeamSybase]"
<SPAMGUARDs...@teamsybase.com> wrote:

>Where training I think is of some benefit is where your team has tied to
>master the basics, succeeded on some things, failed on others. If the
>training allows some interaction with the instructor, you can present your
>questions and learn very fast.

Sometimes, when you've learned a subject by having to do it, training
can help to tie your knowledge together into a coherent whole.

--
Al Balmer [TeamSybase] Balmer Consulting
mailto:alan....@teamsybase.com

Please reply in newsgroup, not e-mail.

Stephen Howe [TeamSybase]

ungelesen,
29.04.2000, 03:00:0029.04.00
an
On Fri, 28 Apr 2000 19:31:58 -0700, Alan Balmer <alba...@worldnet.att.net>
wrote:

>Sometimes, when you've learned a subject by having to do it, training
>can help to tie your knowledge together into a coherent whole.

Exactly :)

Tony Cook

ungelesen,
30.04.2000, 03:00:0030.04.00
an
On Fri, 28 Apr 2000 17:50:12 +0100, "Stephen Howe [TeamSybase]"
<SPAMGUARDs...@teamsybase.com> wrote:

>Virtual member functions? Only if you have inheritance going on. Surely
>there is no need without inheritance?
>
>Single Inheritance? Only if your model of the domain your program covers has
>situations where one object can be substituted for another. But on this I
>concur with you. Most programs that model some real-life problem have
>exactly this. It would have to be either a very simplistic program to have
>no inheritance or just an academic program that is not solving some
>real-life problem.

There's another good reason for using single inheritance - better
separation between interface and implementation, eg:

class FooIf
{
public:
static FooIf *make();
virtual int method1() = 0;
};

// in an implementation file somewhere
class FooImp : public FooIf
{
// implementation of FooImp;
};

FooIf *FooIf::make() {
return new FooImp;
}

This lets you limit included files to those required by the interface of
the class (reducing compilation time and in many cases namespace noise.)

Of course, this doesn't necessarily apply to the beginning programmer
(though she/he might need to maintain code using this construct.)
--
Tony Cook [TeamSybase]
moderator powersoft.public.watcom_c_c++.general
(Please repond in news: I ignore uninvited email responses)

Will Honea

ungelesen,
30.04.2000, 03:00:0030.04.00
an
On Thu, 27 Apr 2000 18:47:53 "TimW" <twa...@aspenres.com> wrote:

> I was just eating a sandwich and reading a thread in comp.object.corba and
> there was a statement made that it usually takes a C programmer 12 to 18
> months of everyday use to become useful in C++ programming. Then someone
> else piped in and said "more like 3 years", then someone else said "I've
> been C++ ing for 12 years and still don't have it down".

Fascinating topic, but 35+ years in this game allows a bit different
perspective than most of the comments have displayed. Most of the responses
have emphasized technique and style - the tools of the language. When I look at
myself and the programmers around me it appears to me that the single essential
concept that escapes most of us is not the implementation of the language but
rather the underlying concept of OOP. I see far fewer instances of programmers
unable to use C++ to implement a design than I do of programmers unable to
properly conceptualize the design in the first place - myself included. Single
inheritance, multiple inheritance, virtualization, templates - these are all
tools to be used (or misused) to implement the program as designed. Unless the
design is appropriate none of them are magic bullets that produce good programs.
Learning to think in terms of objects instead of procedural processes requires
a much more profound change in thinking than simply learning how to use a
different tool to implement the code. I sometimes think it's in the same
category as spatial perception where some people grasp it without even being
aware of it, others have to struggle to attain it, and some never will.

--
Will Honea <who...@codenet.net>

Trevor L. Jackson, III

ungelesen,
30.04.2000, 03:00:0030.04.00
an
Tony Cook wrote:

> On Fri, 28 Apr 2000 17:50:12 +0100, "Stephen Howe [TeamSybase]"
> <SPAMGUARDs...@teamsybase.com> wrote:
>
> >Virtual member functions? Only if you have inheritance going on. Surely
> >there is no need without inheritance?
> >
> >Single Inheritance? Only if your model of the domain your program covers has
> >situations where one object can be substituted for another. But on this I
> >concur with you. Most programs that model some real-life problem have
> >exactly this. It would have to be either a very simplistic program to have
> >no inheritance or just an academic program that is not solving some
> >real-life problem.
>
> There's another good reason for using single inheritance - better
> separation between interface and implementation, eg:
>
> class FooIf
> {
> public:
> static FooIf *make();
> virtual int method1() = 0;
> };
>
> // in an implementation file somewhere
> class FooImp : public FooIf
> {
> // implementation of FooImp;
> };
>
> FooIf *FooIf::make() {
> return new FooImp;
> }
>
> This lets you limit included files to those required by the interface of
> the class (reducing compilation time and in many cases namespace noise.)

A couple of questions...

1) Do you believe the hidden derived implementation is superior to the
pointer-to-implementation (pimpl) approach?

2) Is there a variant of this method that works without covariant returns
(notoriously Microsoft(tm) C++)?


Trevor L. Jackson, III

ungelesen,
30.04.2000, 03:00:0030.04.00
an
Will Honea wrote:

I agree. many of the fundamental conceptual benefits of OOP were available prior to
the widespread use of OO languages. In that sense the OO languages simply enforce
the best practices of OO design in non-OO languages. One critical concept is
encapsulation. C++ enforces this fairly well, although there are escapes that can
be abused. But a reasonably competent programmer is going to encapsulate
functionality in a lump containing data and code (c.f., "Data Structures +
Algorithms = Programs" ) whether the language enforces it or not.

All of the concepts you mentioned, including virtualization and templates, and some
you did not such as robust exception handling, existed and were used where
appropriate prior to the formulation offered by OO languages. Even the arcana such
as RAII and Do/Undo paradigms is not new, and was used by good software engineers.

Unfortunately, the widespread adoption of OO tools does not guarantee the widespread
adoption of the fundamental underlying abstractions. If a worker only know how to
use a hammer and you give him a micrometer, everything he sees still looks like a
nail. Many times the micrometer (OOL) is not as effective on nails as the hammer
(procedural languages).

I believe that widespread adoption of OO methods will require the abandonment of the
BASIC/FORTAN --> C/Pascal --> C++/Java learning path, replacing it with training
that starts with OO concepts. I expect this would make a great book, but I'll be
dammed if I an find an OO improvement to "Hello, world!" ;-)


Alan Balmer

ungelesen,
30.04.2000, 03:00:0030.04.00
an
On Sun, 30 Apr 2000 10:25:37 -0400, "Trevor L. Jackson, III"
<full...@aspi.net> wrote:

>
>I believe that widespread adoption of OO methods will require the abandonment of the
>BASIC/FORTAN --> C/Pascal --> C++/Java learning path, replacing it with training
>that starts with OO concepts.

OO proponents have been advocating that training start with a pure OO
language for a long time. It used to be that the usual suggestion for
a first language was Smalltalk, but now there are several suitable
languages.

Dr. Gerald N. Johnson

ungelesen,
30.04.2000, 03:00:0030.04.00
an
Isn't it fundamental to OOP that the compiler and OS is presumed better
at details than the applications programmer? For those of us that
learned C by starting with fractured basics, FORTRAN and PL/1 that gave
wrong answers because the compiler and OS were NOT better at details and
so went to assembler and C, letting the compiler handle the details
gives us the feeling of giving away too much control.

I can see the use of class structures forcing uniformity of programming
style in the large group program creation process, but in my solo shop,
I think I produce smaller and faster executables in C than I'd produce
in C++. My productivity might not be as great as it would be if I was
competent in C++, but in C I have more control of the details that I
consider crucial to creating programs that produce correct answers in
the shortest execution time.

I admit that sometimes my C looks like verbose assembler, and that my
attempts at C++ and Java look more like my C.

Gerald J.

Will Honea

ungelesen,
30.04.2000, 03:00:0030.04.00
an

A man after my own heart! Let's face it, a craftsman who is not skilled enough
to use the best available tool for a task is a poor hacker, at best. Since my
primary training leaned very heavily toward the hardware end of the
software->firmware->hardware continuim I tend to be, as you point out, quite
pragmatic about the tools I use. When bringing a new instrument on line I
frequently resort to a well-traveled FORTH kernel for initial trials and
characterizations. For 'get-it-done-NOW' control applications on hardware
constrained platforms a mixture of C and Assembler is frequently the more
appropriate environment. This does not really address the topic at hand where,
I believe, one of the basic assumptions is that the target environment is in
fact adequate for the deployment of C++ code.

I contend that there is a fundamental flaw in the concept of teaching 'pure' OO
design. A perfect example can be found in a program segment written by one of
our hotshot C++ types. As an OO design, the program was a marvel - beautifully
crafted, maximum use of encapsulation, absolutely wonderful. That is, until a
new programmer had to take over maintainence. The program was so completely
oriented toward the objects that it was extremely difficult for anyone to
determine how it was supposed to accomplish it's mission. After a couple of
weeks of study the maintainer was finally able to begin to debug the process to
find a fatal implementation error. It was a communications task and finding the
single inappropriate (not wrong, just needed tweeking) took an inordinate amount
of time. In my opinion, the effort needed to debug this monstrosity could not
be justified. Had the code been re-organized to more clearly show the
procedural process the debug and change would have been much simpler.

When designing courses and (long out of use) texts, I stressed a precursor to
the current OO environment: Top down design, bottom up implementation. Even
that can needlessly obscure the functional logic of a program, especially to
someone other than the original coder. I would propose that the better approach
is to teach the design of programs using the simplest available implementation
available with penalties for any embellishment that cannot be specifically
justified. In that context, C++ has a definite place and justifies the learning
curve for most individuals but it is simply one more tool in the box. Too
frequently I see the gung-ho recent CS graduates who treat it as a religion and
an end in itself rather than just that, another tool.

--
Will Honea <who...@codenet.net>

Alan Balmer

ungelesen,
30.04.2000, 03:00:0030.04.00
an
On Sun, 30 Apr 2000 11:39:00 -0500, "Dr. Gerald N. Johnson"
<ger...@ames.net> wrote:

>Isn't it fundamental to OOP that the compiler and OS is presumed better
>at details than the applications programmer?

Hmm... I don't think I'd put it quite that way. The compiler is
presumed better/more efficient at generating large quantities of
detail. In fact, they've gotten good enough to generate (on the
average) better code than many assembler programmers, and even give
the top-notch programmer a surprise now and then. Sometimes the
compiler can apply special knowledge or do resource analysis in a
comprehensive way that no programmer with finite time can manage.

OTOH, this might be considered fundamental in the sense that the
compiler (and the OS with its API's) relieves us of the detail work,
allowing the practical use of ever-higher levels of abstraction (as in
OO.) OK, so I've talked myself into it - you're right. <G>

>For those of us that
>learned C by starting with fractured basics, FORTRAN and PL/1 that gave
>wrong answers because the compiler and OS were NOT better at details and
>so went to assembler and C, letting the compiler handle the details
>gives us the feeling of giving away too much control.

This feeling is still prevalent, at least among old hands. However, I
persuaded myself years ago that clarity of programming was more
important than "helping" the compiler produce good code, and (for the
most part) I've managed to follow that philosophy, and the compilers
(for the most part) have justified my faith.

>I can see the use of class structures forcing uniformity of programming
>style in the large group program creation process,

Only if the shop uses a particular framework or to the extent that the
shop extensively uses well-developed class libraries. Even then, there
can be a great variation in style and readability. Successful style
guidelines have been produced for C and even assembler.

> but in my solo shop,
>I think I produce smaller and faster executables in C than I'd produce
>in C++.

Quite likely.

>My productivity might not be as great as it would be if I was
>competent in C++, but in C I have more control of the details that I
>consider crucial to creating programs that produce correct answers in
>the shortest execution time.

Actually, your productivity may be greater than with OO, depending on
the type of work you do and it's variability. Productivity gains with
OO are (imo) primarily gained through reusability and the management
of large (multi-person) projects. If you can't apply reusability, OO
may slow you down. OTOH, if you consider C++ as simply a "better C",
you may find some neat features that enhance productivity or decrease
maintenance efforts.


>
>I admit that sometimes my C looks like verbose assembler, and that my
>attempts at C++ and Java look more like my C.
>

>Gerald J.

Kon Tantos

ungelesen,
01.05.2000, 03:00:0001.05.00
an

Tony Cook wrote:
>
[snip...]


>
> There's another good reason for using single inheritance - better
> separation between interface and implementation, eg:
>
> class FooIf
> {
> public:
> static FooIf *make();
> virtual int method1() = 0;
> };
>
> // in an implementation file somewhere
> class FooImp : public FooIf
> {
> // implementation of FooImp;
> };
>
> FooIf *FooIf::make() {
> return new FooImp;
> }
>
> This lets you limit included files to those required by the interface of
> the class (reducing compilation time and in many cases namespace noise.)
>

> Of course, this doesn't necessarily apply to the beginning programmer
> (though she/he might need to maintain code using this construct.)

Multiple inheritance generally provides a better technique for
interface/implementation seperation. Typically an abstract class is used
as the interface and an engine class is used for the implementation. An
(oversimplified) example is:

class ArrayException {};

template < class T >
class Array<T> // an engine class
{
public:
Array( int sze_ );
...
T& operator [] ( int off_) throw( ArrayException );
...
private:
T* store;
};

class LinkedListException {};

template < class T >
class LinkedList<T> // an engine class
{
...
};

class StackException {};

template < class T >
class Stack<T>
{
public:
virtual T Pop() = 0;
virtual void Push( t const & el_ ) throw( StackException ) = 0;
...
};

template < class T >
class BoundedStack : public Stack<T>, private Array<T>
{
// implements a stack of fixed size
// provide overrides for Stack pure virtual methods
};

template < class T >
class UnBoundedStack : public Stack<T>, private LinkedList<T>
{
};

Tony Cook

ungelesen,
02.05.2000, 03:00:0002.05.00
an
On Sun, 30 Apr 2000 10:07:19 -0400, "Trevor L. Jackson, III"
<full...@aspi.net> wrote:

>1) Do you believe the hidden derived implementation is superior to the
>pointer-to-implementation (pimpl) approach?

I've seen a detailed discussion of a pimpl approach somewhere - but I
couldn't find the details (I checked the indices of 7 books). I'll assume
you mean the method described at the bottom of page 113 in the original
edition of Effective C++ (Meyers calls this a Handle or Cheshire Cat
class.)

I would say it depends on your requirements.

I typically use the hidden derived implementation in association with an
auto_ptr type class - so that I don't need to write a wrapper class to
manage the lifetime of the objects.

Objects of these classes typically have identity too - rather than being a
value oriented class (like a string class).

>2) Is there a variant of this method that works without covariant returns
>(notoriously Microsoft(tm) C++)?

The method I described doesn't use co-variant returns.

Allen antworten
Dem Autor antworten
Weiterleiten
0 neue Nachrichten