P
Phlip
Gavin said:
The distinction is simply which features newbies should use. They should use
std::string first, long long before ever using char *.
The distinction is simply which features newbies should use. They should use
std::string first, long long before ever using char *.
P
Phlip
Branimir said:
Uh, no. Use Ruby for high developer performance. The kind you need on 80% of
your code. ;-)
C++ is much better and easier for that task, but I really miss
run time parametric polymorphism
Yep. You will be so far beyond that in so few statements...
B
blangela
At the college where I teach C++ (part-time, in the evenings), I used
to teach only "C++ for C Progammers" courses. Now my C++ courses no
longer require students to know C programming. In fact, I teach an
intermediate C programming course, that has as it's prerequsite my
introductory C++ programming course! I still teach one "C++ for C
Programmers course" a year -- people enrolling seem to be mostly old
time embedded C programmers wanting to evolve to C++ programming.
It seems that the C++ community (at least the C++ community that posts
on this site) is pretty unanimous in recommending the "Accelerated C+
+" text for learning C++. If you take a peek at this book, you will
discover that it definitely does not teach C programming first, and
then go on to teach the OOP features of the C++ language. I think
this answers your question.
I am currently using the Deitel and Deitel "C++ How To Program" 5th
edition as my text in my C++ courses (if I ever find my self
unemployed and with 1000 hours of free time on my hands, I will take
those 1000 hours to convert my courses to the text discussed above).
This text covers the introduction of classes in Chapter 3 and does not
cover the introduction of pointers (a C programming staple) until
Chapter 8. I believe that this text is the most widely used C++
college text in the world! Again, I think this demonstrates that it i
definitely not necessary (or recommended) to learn C programming
before learning to program C++.
Cheers,
Bob
R
Roland Pibinger
Without char* (or wchar_t*) you cannot even open a file in C++. The
newbie then asks you why C++ has two different string types and why he
gets those 'std::basic_string<_Elem,_Traits, _Ax>' in the compiler
error messages.
R
Roland Pibinger
I have no own definition of OOP. I merely use the common definiton.
OOP is usually characterized by encapsulation, inheritance and
polymorphism. The latter, polymorphism, is the most important because
genuine OO attribute. STL uses no polymorphism, i.e. no interfaces, no
virtual functions and no inheritance (except for some negligible
implementation inheritance). Moreover, STL containers, iterators and
algorithms are designed only for values, not for objects. In sum, STL
is not object oriented.
G
Gianni Mariani
That's a very constrained definition. The basis of OOP is
encapsulation which then allows for many other things which includes
polymorphism as another. There is no prerequisite to use polymorphism
to be designing using OOP.
I
Ian Collins
Either way (public data members or accessors) in a class is a smell.Juha said:
G
Gianni Mariani
Hey, I resemble that remark.
Being a C guy pre C++, I still make everything public and then fix the
code later ... Having said that, I do think that it's not a clear cut
rule that all member variables need to be private in every class. For
example, returning a value that contains a number of different
elements. A "message" in a protocol. There is an Austria C++ class
to parse and combine URL's. I'd probably do it differently today but
the class itself is the result. Making accessors for all the
different components is neither useful nor necessary.
Yes, I know, I'm the one who raised this criticism so why am I
defending myself from my own criticism. Go figure,
O
Old Wolf
Either that, or you have to know C!
I have no idea how memory is laid out in x86. I heard there is
a 'data segment' and a 'code segment' but I'd have no idea
where to find them; nor if there are any stacks in there -- but
my programs work just fine and do not have any undefined
behaviour. Sometimes they have implementation-defined
behaviour but I'm aware of those cases and approve of them.
What's required to avoid undefined behaviour, is the ability
to read the C standard, or appropriate paraphrasing such
as the c.l.c FAQ.
Why bother posting then?
The 1990s called, they want their one eye back.
O
Old Wolf
I find that the more C I write, the *fewer* kludges I use, because I
learn how to write portable code in the first place. In fact the only
time I use kludges now is to work around compiler bugs, or to
access memory in some third-party library where they didn't
specify their interface properly -- neither of which should be
considered a problem with C, or something that is fixed with C++!
Now that is true, although of course you could replace 'C' with
'anything' and 'C++' with 'anything else' and still get a true
statement.
For example, people who mostly develop in C++ often have
a low opinion of C.
B
Branimir Maksimovic
Of course, C is portable, you can;t access segment registers
without extensions.But stack can be problem.
I have written some medical application in C back in 92. on AT&T unix
(non pc hardware).
Os provided very small stack (4-8kb if I remember correctly).
Without knowing about stack, I would perhaps use automatic
arrays instead of using malloc, and application could crash.
But as long as you are writing,
high level applications you don;t have to know
how particular platform works. If you are writing operating
system kernel or device driver, things are different.
To express opinion?
Greetings, Branimir.
R
Roland Pibinger
Encapsulation is a general design principle independant of the
programming paradigm. Polymorphism is a fundamental and distinctive
OOP concept, see e.g.
http://en.wikipedia.org/wiki/Object-oriented_programming
J
James Kanze
It probably depends on where you learned C. I was a
"self-taught" C programmer, but the usual way I've always seen C
written (even 20 years ago) was to define a struct and a set of
functions to manipulate it, and then to cross your fingers that
no one accessed any of the struct except for your functions. I
adopted C++ originally solely for private---I hadn't the
slightest idea what OO was, and there weren't templates at the
time. Even today, the rest is just icing on the cake.
Encapsulation is essential, regardless of the paradigm.
Otherwise, the code rapidly becomes unmaintainable. That was
true already back before C++ came along.
P
Phlip
Gianni said:
Me too.
Correct; a program could wildly abuse semantic encapsulation, and still have
private data. The most important rule here is to avoid "long distance access
to low-level things". The farther apart two things are, the more formal
their communication should be. The other ways to say that are generally
"encapsulation is hierarchical", and "avoid inappropriate intimacy".
Correct - that's just one big data object. If it's not an object with public
behavior and private state, then there's no behavior to defend from
unexpected changes to that state.
J
Juha Nieminen
Gianni said:
And I suppose "fixing the code later" often doesn't get done at
all?
Well, I think a return value is a bit of an exception.
Functions return things by value all the time, and it's completely
normal. For example, a function may return an integer.
Of course in some cases you might need to, for example, return
*two* integers instead of one. Thus it makes sense to return them
in a struct.
In a way one could think that return values are not internal
implementation.
But anyways, as someone already insinuated, if you find yourself
having to write tons of accessor methods (or alternatively, if you
are lazy, having to put tons of variables in the public part of the
class), then there's probably a flaw in your OO design. It means that
there's way too much dependency between two or more classes. When a
program is well designed then you usually don't need tons of accessors.
Sometimes a module just has some values which are accessed constantly.
For example, you might have an object which has screen coordinates, and
these coordinates are used all the time everywhere. One would be tempted
to put these coordinates in the public part of the class instead of
having some stupid getX(), getY() and setCoords() functions.
However, abstracting those coordinates away is still a good thing.
It may be that at some point you might want to make some optimizations
to that class. For example, you might want to create a piece of code
which searches for the closest object to a given point. In that case
it would be handy if the objects were arranged in a Kd-tree or such.
Of course if you didn't abstract the coordinates of the object, but
everything accesses these coordinates directly, you can't optimize
the objects in such way that they are stored in the Kd-tree (and
moved inside it when the setCoords() function is called).
J
Juha Nieminen
Old said:
But I think that opinion is not completely baseless. The problem
with C is that it simply doesn't offer the tools for making safe code
(unless you use some kind of garbage collection extension for C, and
even that only helps with memory allocation but nothing else).
P
Phlip
Juha said:And I suppose "fixing the code later" often doesn't get done at
all?
Winki noted. But...
One of the most important concepts in software engineering is that nothing
is ever finished, and that "premature complexity" is just as bad as
"premature optimization".
When you type a new function, you know you are making many compromises. The
most important thing is to get the function to pass its test. If you think
of improvements that would interrupt your flow, write them with // TODO on
them.
Then, when you have slack time between features, search for the TODOs and
fix them, easiest ones first.
Note that strategy depends on two further assets:
- wall-to-wall unit tests
- slack time between
If you don't have those, you have more problems than just the occassional
public method!
He means the design difference between an object with members and a
structure, used as a data bucket. The bucket should be private to its
module.
B
Branimir Maksimovic
Couldn't you just use forward declaration of
struct, while hiding definition in implementation file,
if data members are not meant for public access?
Greetings, Branimir.
G
Gianni Mariani
Read that URL more carefully.
P
Phlip
What's wrong with it?
Last year, the first few paragraphs on that WikiPedia page repeated the
fallacy that "OO is better because it lets you match program objects to
real-world objects". Paraphrased.
That verbiage appears at the top of many introductions to OO, and it's
wrong. If two people want to debate two designs, one can't say "mine is
better because my objects more closely match real-world objects." That
brings nothing to the debate.
So it's awesome to see someone has completely tuned up the page and put in a
much better summary, with the voodoo stuff moved down to one probationary
segment.