f



C or C++

Hi All,

I am starting to learn C and am wondering if C++ may be a better 
choice? The purpose is to do free software development and eventually 
contribute to existing projects.

I believe that a lot of gnome stuff is c and kde stuff tends to be c++ 
is that correct?

what would other people out their recommend. I realize there are lots 
of different opinions on this but I was just interest to see third 
party thoughts.

Thanks

Anthony
0
Anthony
2/21/2007 6:44:21 AM
comp.os.linux.development.apps 5216 articles. 1 followers. Post Follow

142 Replies
1154 Views

Similar Articles

[PageSpeed] 31

Anthony Irwin <nospam@noemailhere.nowhere> wrote:
> Hi All,
> 
> I am starting to learn C and am wondering if C++ may be a better 
> choice? The purpose is to do free software development and eventually 
> contribute to existing projects.

I prefer C to C++. I suggest you first learn C. You can still learn C++ 
afterwards.

Regards,

Mark.

-- 
Mark Hobley
393 Quinton Road West
QUINTON
Birmingham
B32 1QE

Telephone: (0121) 247 1596
International: 0044 121 247 1596

Email: markhobley at hotpop dot donottypethisbit com

http://markhobley.yi.org/

0
markhobley
2/21/2007 8:03:56 AM
Mark Hobley wrote:
> Anthony Irwin <nospam@noemailhere.nowhere> wrote:
>=20
>>Hi All,
>>
>>I am starting to learn C and am wondering if C++ may be a better=20
>>choice? The purpose is to do free software development and eventually=20
>>contribute to existing projects.
>=20
>=20
> I prefer C to C++. I suggest you first learn C. You can still learn C++=
=20
> afterwards.

Bear in mind that C -> C++ is more than just "learning a new language".=20
To do it properly, IMHO, requires a complete new approach: object=20
orientedness. I've never managed to switch my brains over to that.

--=20
Josef M=F6llers (Pinguinpfleger bei FSC)
	If failure had no penalty success would not be a prize
						-- T.  Pratchett

0
Josef
2/21/2007 8:07:02 AM
Josef Moellers wrote:
> Bear in mind that C -> C++ is more than just "learning a new language". 
> To do it properly, IMHO, requires a complete new approach: object 
> orientedness. I've never managed to switch my brains over to that.

Exactly. You can learn C++ syntax very fast, but it took me about 1.5 
years to start thinking in OO terms. I also found out that once you do 
that, it's hard to do do any C programming.

-- 
Milan Babuskov
http://abrick.sourceforge.net
0
Milan
2/21/2007 8:49:47 AM
Josef Moellers wrote:
> 
> Bear in mind that C -> C++ is more than just "learning a new language".
> To do it properly, IMHO, requires a complete new approach: object
> orientedness. I've never managed to switch my brains over to that.

I totally agree with your point !!!

I really desperate each time I hear: "Learn C then C++, because it's
logic" (or vice-versa). Everybody should understand that despite a very
similar syntax both languages cover very different (and sometimes
incompatible) semantics.

The thumb rule for choosing being:

* Use C when efficiency and portability are key points;
* Use C++ when modularity and maintainability are key points.

Regards
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Lib�ration  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
2/21/2007 8:58:19 AM
Josef Moellers <josef.moellers@fujitsu-siemens.com> writes:

[...]

> Bear in mind that C -> C++ is more than just "learning a new
> language". To do it properly, IMHO, requires a complete new approach:
> object orientedness. I've never managed to switch my brains over to
> that.

I managed to switch my brains over and switched them back. :->
0
Rainer
2/21/2007 9:11:04 AM
Josef Moellers <josef.moellers@fujitsu-siemens.com> writes:

> Mark Hobley wrote:
>> Anthony Irwin <nospam@noemailhere.nowhere> wrote:
>>
>>>Hi All,
>>>
>>> I am starting to learn C and am wondering if C++ may be a better
>>> choice? The purpose is to do free software development and
>>> eventually contribute to existing projects.
>> I prefer C to C++. I suggest you first learn C. You can still learn
>> C++ afterwards.
>
> Bear in mind that C -> C++ is more than just "learning a new
> language". To do it properly, IMHO, requires a complete new approach:
> object orientedness. I've never managed to switch my brains over to
> that.

It is possible to write object oriented code in any language.  Some
languages, like C++, are intended to make it easier, and yet some,
like Java, force it upon the programmer.

While C++ is a powerful language, it takes some skill to use it
properly and create a mess.  The more complicated the language, the
more ways there are of doing bad things, and C++ is very complicated
indeed.

To any aspiring programmer, I would recommend first learning C.  It is
more or less essential knowledge that no programmer can escape in the
long term anyway.  I'd also argue that learning the art of programming
itself, which is largely independent of any one language, is better
done using a simpler language.  It takes a certain amount knowledge
and experience to properly understand many of the concepts introduced
in complex languages like C++.

As for myself, I don't touch C++ unless I have no other choice, and
most of the time do.  I'm quite comfortable with C for most
applications.  When I'm not using C, I'm typically using something
like Perl for doing the things it's good at, or assembler to access
special processor features not available to C.  In neither of these
cases would C++ be appropriate.

-- 
M�ns Rullg�rd
mans@mansr.com
0
iso
2/21/2007 9:18:16 AM
=?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans@mansr.com> writes:

>It is possible to write object oriented code in any language.


Sorry, but this is completely untrue, and demonstrates a lack of
understanding of what O-O programming is.

______________________________________________________________________________ 
Dr Chris McDonald                          E: chris@csse.uwa.edu.au
Computer Science & Software Engineering    W: http://www.csse.uwa.edu.au/~chris
The University of Western Australia, M002  T: +618 6488 2533
Crawley, Western Australia, 6009           F: +618 6488 1089
0
Chris
2/21/2007 10:33:41 AM
Chris McDonald <chris@csse.uwa.edu.au> writes:
> =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans@mansr.com> writes:
>>It is possible to write object oriented code in any language.
>
>
> Sorry, but this is completely untrue, and demonstrates a lack of
> understanding of what O-O programming is.

Since you didn't write what you define as being 'OO programming' (eg
could this be something like 'using one from a certain set of
languages'?), nobody can possibly understand it.

0
Rainer
2/21/2007 11:00:34 AM
Chris McDonald wrote:
> =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans@mansr.com> writes:
> 
>> It is possible to write object oriented code in any language.
> 
> 
> Sorry, but this is completely untrue, and demonstrates a lack of
> understanding of what O-O programming is.

Sorry again, but the Church thesis pretends that any Turing-complete
language are equivalent, so this must be right.

Anyway, some languages makes it harder than others. ;)

Regards
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Lib�ration  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
2/21/2007 11:02:28 AM
Josef Moellers wrote:

> Mark Hobley wrote:
> Bear in mind that C -> C++ is more than just "learning a new language".
> To do it properly, IMHO, requires a complete new approach: object
> orientedness. I've never managed to switch my brains over to that.

I agree. But if you have never learned a programming language before, it
will be really hard to learn C++ (or any other object oriented language).
You should have a more or less advanced understanding of common programming
structures like "if", "for", "while" etc. before trying to understand
object oriented programming.

Keep in mind, that there are many languages which are each optimal for
different purposes. E.g. if you want to do heavy calculations, I would
suggest Fortran would be the better choice, even if it's widely frowned
upon ;) It is the same thing with C and C++ (as others told before in this
thread)...

-- 
Sorry for the fake e-mail address, you need to remove ".NO" and "SPAM."
before sending me any mails...
0
Martin
2/21/2007 11:06:29 AM
Hi.

If you have some kind of programming background, you might want to
read "Accelerated C++ Programming", by Andy Koenig and Barbara Moo.
It guides one in learning how to "think properly" regarding C++
programming.  Moreover, before teaching people how to design classes,
it first introduces them to the art of using existing well-designed
classes (i.e., the STL).

Althoughh it's a relatively thin book, its style is not crabbed.
Moreover, it's written with a certain amount of wit.

-- 
Art Werschulz (agw STRUDEL comcast.net)
207 Stoughton Ave Cranford NJ 07016
(908) 272-1146
0
Art
2/21/2007 11:34:52 AM
Martin Hierholzer wrote:
> Josef Moellers wrote:
> 
>> Mark Hobley wrote:
>> Bear in mind that C -> C++ is more than just "learning a new language".
>> To do it properly, IMHO, requires a complete new approach: object
>> orientedness. I've never managed to switch my brains over to that.
> 
> I agree. But if you have never learned a programming language before, it
> will be really hard to learn C++ (or any other object oriented language).
> You should have a more or less advanced understanding of common programming
> structures like "if", "for", "while" etc. before trying to understand
> object oriented programming.

I do not totally agree with the fact that OO programming is more
difficult than procedural programming.

For example, C programming requires a lot of experience in handling
memory precisely with a lot of complex pointer arithmetic tricks.

On the other hand, OO programming doesn't (shouldn't), but it drags in a
lot of other complex concepts (inheritance, polymorphism, parametric
typing, ...).

I am part of a generation that started to learn programming with
procedural paradigm so I un-objectively think that procedural
programming seems simpler to me. But I definitely try to fight this
feeling as hard as I can !

New generations have the choice to start with procedural,
object-oriented or even functional programming and I pretend that there
is no real silver bullet as a first language. Each language has strong
points and drawbacks and I would be really surprised if somebody could
bring me totally objective arguments demonstrating the superiority of
one of those for pedagogy.

PS: Of course, C++ did totally slipped out of my mind when I wrote this.
:-D (the flamewar can begin !!!)

Regards
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Lib�ration  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
2/21/2007 11:35:50 AM
Anthony Irwin wrote:
> Hi All,
> 
> I am starting to learn C and am wondering if C++ may be a better choice? 
> The purpose is to do free software development and eventually contribute 
> to existing projects.
> 
> I believe that a lot of gnome stuff is c and kde stuff tends to be c++ 
> is that correct?
> 
> what would other people out their recommend. I realize there are lots of 
> different opinions on this but I was just interest to see third party 
> thoughts.

As you can see from the replies so far, the discordance of opinions can
not be higher...

Having *taught* both C and C++ for many years  (as well as used both
for development), it is my opinion that learning C first is the worst
possible idea.

C++ is a complex language, yes, but unlike C (and unlike Java), it has
the virtue that if you want to do simple things, you can do them very
simply --- that's the biggest plus when talking about learning to
program.  You concentrate on the simple stuff first, putting aside
the deeper complexities of the language (which are valuable when you
want to start doing more complex things).

With C, the novice programmer is treated as harshly as possible. Plus,
it makes it incredibly hard to learn C++ *well* afterwards --- the
prorgammer creates many extremely-hard-to-break habits that, given
the alternative C++ techniques that are available, make them bad
practices.

You'll probably want to learn and master *both* --- in which case I
strongly recommend that you learn C++, then C;  in the old days, it
was considered common sense that you had to learn C as a pre-requisite
to learn C++, and that, those many years of using that approach, is
precisely why we know today that it is a very *very* bad idea.

Carlos
--
0
Carlos
2/21/2007 2:00:47 PM
Emmanuel Fleury wrote:

> Each language has strong
> points and drawbacks and I would be really surprised if somebody could
> bring me totally objective arguments demonstrating the superiority of
> one of those for pedagogy.

What about if I told you that some of use have taught both C and C++,
both as a first language and as a non-first language, in both cases
designing our own courses (rather than being forced to teach one
particular language because the School board hears the fuzz words
and the hype), for more than 12 years?

People --- presumably people that know a lot about *programming* and
about the particular languages but that seem to know nothing about
*teaching* and about the psychological process of *learning* ---
stubbornly think that as soon as we mention "learning C++" the student
has to understand virtual and multiple inheritance *the first day*; and
of course, template meta-programming.  <sarcasm> You know, because if
the language contains that, then the beginner *must* learn that the
first day, and that it is the reason why C++ can not be the first
language that one learns. </sarcasm>

As for OO, having tried both approaches (for teaching a first language),
I find that it is a much more natural and more efficient way to abosrve
the ideas for a beginner --- OO *aims* at making the programming tools
be like the real-world problem being solved;  other approaches in
general require that the programmer force/twist the real-life problem
to be expressed in terms of the available tools.

After having taught the basic elements like variables, data types,
if and related, loops, and maybe functions, teaching classes for
simple/basic encapsulation is what makes most sense --- no operator
overloading;  no inheritance;  not even destructors.  Simply develop
the logic of modeling real-life entities as *single entities* in the
program --- yes, you could do that with structures, but that would
be a half-solution:  if we are making the leap to have the students
think in those terms, we might as well teach them the whole truth
and then avoid them developing bad, hard-to-break habits  (creating
classes with all members public, or with get methods for each data
member, possibly --- to make things worse --- returning a reference
to the data member, etc.).


Carlos
--
0
Carlos
2/21/2007 2:17:28 PM
So,

It means that whatever is the language you use to teach programming
skills, it's more about the way you teach than the language you choose
that make the difference...

I agree. ;-)

Regards
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Lib�ration  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
2/21/2007 2:19:23 PM
Carlos Moreno <cm_clcppm_7b8f93f186@mochima.com> writes:

[...]

> Having *taught* both C and C++ for many years  (as well as used both
> for development), it is my opinion that learning C first is the worst
> possible idea.

But why precisely is this your opinion? 

[...]

> With C, the novice programmer is treated as harshly as possible.

What is this supposed to mean (except being a reiteration of your so
far unsubstantiated dislike for C)?

> Plus, it makes it incredibly hard to learn C++ *well* afterwards

Why does it make it incredibly hard to learn C++ well afterwards, what
is 'learning C++ well' and why would one want to do it in the first
place?

> --- the prorgammer creates many extremely-hard-to-break habits that,
> given the alternative C++ techniques that are available, make them
> bad practices.

If anything, the programmer[*] acquires such habits. What are those
habits, what are the alternatives you are talking about and why do you
think they are preferable?

	[*] Do you know that the 'programmer' orginally was the person
	responsible for keying in the already completed program?

> You'll probably want to learn and master *both*

Why again?

> --- in which case I strongly recommend that you learn C++, then C;

You repeat yourself. How about a reason for doing so?

[...]

> and that, those many years of using that approach, is
> precisely why we know today that it is a very *very* bad idea.

Last question: How many different people do you think you are?
0
Rainer
2/21/2007 2:49:46 PM
On 2007-02-21, Mark Hobley <markhobley@hotpop.deletethisbit.com> wrote:
> Anthony Irwin <nospam@noemailhere.nowhere> wrote:
>> Hi All,
>> 
>> I am starting to learn C and am wondering if C++ may be a better 
>> choice? The purpose is to do free software development and eventually 
>> contribute to existing projects.
>
> I prefer C to C++. I suggest you first learn C. You can still learn C++ 
> afterwards.

If you learn C++ as your first language, it could take years to
undo the brain damage...

-- 
Grant Edwards                   grante             Yow!  I'm wearing PAMPERS!!
                                  at               
                               visi.com            
0
Grant
2/21/2007 3:31:05 PM
Anthony writes:
> what would other people out their recommend.

Python.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
0
John
2/21/2007 4:03:56 PM
On Wed, 21 Feb 2007 16:44:21 +1000, Anthony Irwin wrote:

> Hi All,
> 
> I am starting to learn C and am wondering if C++ may be a better 
> choice? 

Learn C then skip the ugly, broken hybrid C++ using instead languages like
Lisp, Ruby or Python.

-- 
Lars Rune Nøstdal
http://nostdal.org/

0
iso
2/21/2007 4:05:15 PM
M�ns Rullg�rd writes:
> While C++ is a powerful language, it takes some skill to use it properly
> and create a mess.

While it is true that it takes some skill to create a large mess with C++,
any programmer can use it to create a small one.  What takes great skill is
not creating any mess at all.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
0
John
2/21/2007 4:06:33 PM
On Wed, 21 Feb 2007 17:05:15 +0100, Lars Rune Nøstdal wrote:

> On Wed, 21 Feb 2007 16:44:21 +1000, Anthony Irwin wrote:
> 
>> Hi All,
>> 
>> I am starting to learn C and am wondering if C++ may be a better 
>> choice? 
> 
> Learn C then skip the ugly, broken hybrid C++ using instead languages like
> Lisp, Ruby or Python.

...and all this talk of object-orientedness in this thread .. C++ doesn't
even have good support for it .. it lacks introspection and reflection
capabilities and a lot of other stuff .. in short it's a clueless
language; I wouldn't call it object oriented _at all_.

As some famous guy once said:

"I invented the term Object-Oriented, and I can tell you I did not have
C++ in mind"

-- 
Lars Rune Nøstdal
http://nostdal.org/

0
iso
2/21/2007 4:13:36 PM
Rainer Weikusat wrote:

>>Having *taught* both C and C++ for many years  (as well as used both
>>for development), it is my opinion that learning C first is the worst
>>possible idea.
> 
> But why precisely is this your opinion? 

Err... uhmmm...  Would you want to read again what I wrote --- the
reason is clearly stated:  because I have *taught* both C and C++
for no less than 6 years each;  to both beginners and non-beginners.

For the non-beginner programmer, either way is roughly the same, I
have found (either C first, then C++, or first C++, then C).  For
the beginner (i.e., someone learning *programming* for the first
time), it's a different story --- learning C++, then C makes a lot
more sense.

>>With C, the novice programmer is treated as harshly as possible.
> 
> What is this supposed to mean 

It's supposed to mean what it means:  the beginner is overwhelmed
with little details that have nothing to do with the basic notion
that they're trying to absorve --- the notion of using a statement
to print the contents of a variable is already "enough magic" in
the mind of a beginner --- throw the fact that they have to match
the %d %f etc. to the data type, and the whole thing feels like a
minefield in the mind of the beginner.

Not to mention the need for & in front of the entities being read
with scanf  (plus the now strict distinction between %f and %lf
with scanf, but not with printf --- of course, because with scanf
*obviously*, the parameters are passed by reference, whereas with
printf they're passed by value and floats are *promoted* to doubles;
so , *obviously* the beginner will know to handle all those details...
[yes, that was sarcasm] )

Things like why the following is wrong do nothing other than
overwhelm the mind of a beginner:

if (name == "")

(where name is, of course, a char * variable).

In general, all these examples illustrate the common theme:  the
beginner should not have to worry about the details of how things
happen --- they should concentrate on understanding *the logic*
and teh basic things;  after they have developed the basic skills
and understanding of the basic things, then they can worry about
pointers, dynamic memory allocation and all the advanced things.

My point keeps being the same:  in C++, it is in general simpler
to avoid the complex things;  in C, a lot less so --- you can do
a lot of (simple) things in C++ with std::string without really
knowing (or caring about) what the underlying principles behind
that are;  same thing with std::vector;  as you advance some more,
you'll get ready to understand how those two beasts work, and even
will have enough skills to create your own versions of those (even
if they wouldn't work as well as the built-in ones) ...  But why
overwhelm the poor mind of a beginner with needing to understand
what's behind to be able to use those tools?  In a sense, C does
that --- one either understands that scanf, being after all a
function that receives parameters, receives parameters as pointers
(obviously: the only way that the actual variables could be
modified, as opposed to the copy of those), and that's why we
need to put the &'s, or simply accept that as an annoying thing
that has no reason for being (and the beginner will have to
choose this last option).  Oh, and don't get me started with
(again, from the point of view of the beginner's perception)
why would *omiting the &'s* in teh variables when calling scanf
would compile, when it unconditionally fails to work when running
it.

Again, regardless of one's opinion about the above details, if
we're talking about someone *beginning* programming, all those
things are simply traps --- some of them subtle --- getting in
the way:  getting in the way as in making it harder to make things
work (because the beginner is bound to fall for those traps), and
making it harder to concentrate on the simple and basic principles
that the beginner should concentrate on (given the amount of little
details that one has to keep in mind to make the simplest program
work)

>>Plus, it makes it incredibly hard to learn C++ *well* afterwards
> 
> Why does it make it incredibly hard to learn C++ well afterwards

I do not know why --- not even the best psychologists know exactly
how the human brain works...   What I can tell you, from my
experience with no less than 10 groups of students, having taught
C and then C++  (which, as I said, at some point in time it was
considered common sense, since C++ was a superset of C), is that
it *does*.

> what
> is 'learning C++ well' and why would one want to do it in the first
> place?

For the same reason that one would want to learn C well.  Or Java
well.  Or PHP well.  Or Fortran well.


>>You'll probably want to learn and master *both*
> 
> Why again?

You don't seem to have read the OP initial message --- the reason
is crystal clear in there.

Carlos
--
0
Carlos
2/21/2007 4:13:37 PM
On 2007-02-21, Lars Rune N�stdal <larsnostdal@gmail.com> wrote:
> On Wed, 21 Feb 2007 16:44:21 +1000, Anthony Irwin wrote:
>
>> Hi All,
>> 
>> I am starting to learn C and am wondering if C++ may be a better 
>> choice? 
>
> Learn C then skip the ugly, broken hybrid C++ using instead languages like
> Lisp, Ruby or Python.  

Bravo!

I think every serious programmer should also learn Smalltalk
and Prolog (just to keep the mind limber).

-- 
Grant Edwards                   grante             Yow!  I was in a HOT
                                  at               TUB! I was NORMAL! I was
                               visi.com            ITALIAN!! I enjoyed th'
                                                   EARTHQUAKE!
0
Grant
2/21/2007 4:21:40 PM
Lars Rune Nøstdal wrote:
> 
> As some famous guy once said:
> 
> "I invented the term Object-Oriented, and I can tell you I did not have
> C++ in mind"

Accordingly to my quotes-file, it was Alan Kay at OOPSLA'97.

I also love this one:

"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out how
to use my telephone."

It is attributed to Bjarne Stroustrup who does claim that it's true
(see: http://www.research.att.com/~bs/bs_faq.html#really-say-that).

:)

Regards
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Libération  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
2/21/2007 4:27:22 PM
Carlos Moreno <cm_clcppm_7b8f93f186@mochima.com> writes:
> Rainer Weikusat wrote:
>>>Having *taught* both C and C++ for many years  (as well as used both
>>>for development), it is my opinion that learning C first is the worst
>>>possible idea.
>> But why precisely is this your opinion?
>
> Err... uhmmm...  Would you want to read again what I wrote --- the
> reason is clearly stated:  because I have *taught* both C and C++
> for no less than 6 years each;  to both beginners and non-beginners.

Technically, that is an 'appeal to authority' with the person
appealing appealing to itself, ie not a reason.

[ another repetition ]

>>>With C, the novice programmer is treated as harshly as possible.
>> What is this supposed to mean
>
> It's supposed to mean what it means:

But it doesn't express anything except that you dislike it.

> the beginner is overwhelmed with little details that have nothing to
> do with the basic notion that they're trying to absorve --- the
> notion of using a statement to print the contents of a variable is
> already "enough magic" in the mind of a beginner --- throw the fact
> that they have to match the %d %f etc. to the data type, and the
> whole thing feels like a minefield in the mind of the beginner.

Well, but that is the very stuff this mythical beginner is supposed to
learn: Call library subroutines, passing arguments of certain types to
them, to accomplish specific tasks. 

> Not to mention the need for & in front of the entities being read
> with scanf  (plus the now strict distinction between %f and %lf
> with scanf, but not with printf --- of course, because with scanf
> *obviously*, the parameters are passed by reference, whereas with
> printf they're passed by value and floats are *promoted* to doubles;

Subroutine arguments are always passed by value in C. &f passes the
value of a pointer to f (its 'address' -- are your beginners supposed
to understand enough of the postal system to not wonder how stuff
'magically' appears in letter boxes?). Argument promotion is obviously
not a topic for people not already knowing about the concept of
'types' in general, so, to me, this looks like a didactical problem.

> Things like why the following is wrong do nothing other than
> overwhelm the mind of a beginner:
>
> if (name == "")
>
> (where name is, of course, a char * variable).

Considering that this 'beginner' wasn't born with knowledge of C
operators, who made him believe that the text above should compare the
contents of the arrays involved?

> In general, all these examples illustrate the common theme:  the
> beginner should not have to worry about the details of how things
> happen

The 'details of how things happen', at least at the software level,
look like this, for instance:

    87d8:       e92d4ff0        stmdb   sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
    87dc:       ebffff80        bl      85e4 <init>
    87e0:       e59f8058        ldr     r8, [pc, #88]   ; 8840 <main+0x68>
    87e4:       e59f6058        ldr     r6, [pc, #88]   ; 8844 <main+0x6c>
    87e8:       e1a07008        mov     r7, r8
    87ec:       e1a05000        mov     r5, r0
    87f0:       e3a0b901        mov     fp, #16384      ; 0x4000
    87f4:       e1a0a008        mov     sl, r8
    87f8:       e1a09006        mov     r9, r6
    87fc:       e59f2040        ldr     r2, [pc, #64]   ; 8844 <main+0x6c>
    8800:       e7983002        ldr     r3, [r8, r2]
    8804:       e798200b        ldr     r2, [r8, fp]
    8808:       e0623003        rsb     r3, r2, r3
    880c:       e2634901        rsb     r4, r3, #16384  ; 0x4000
    8810:       e7971006        ldr     r1, [r7, r6]
    8814:       e1a00005        mov     r0, r5
    8818:       e1a02004        mov     r2, r4
    881c:       ebffff10        bl      8464 <_init+0x40>
    8820:       e3500000        cmp     r0, #0  ; 0x0
    8824:       dafffff9        ble     8810 <main+0x38>
    8828:       e79a3009        ldr     r3, [sl, r9]
    882c:       e59f2014        ldr     r2, [pc, #20]   ; 8848 <main+0x70>
    8830:       e0833000        add     r3, r3, r0
    8834:       e78a3002        str     r3, [sl, r2]
    8838:       ebffff95        bl      8694 <process_data>
    883c:       eaffffee        b       87fc <main+0x24>

And C (or every high-level programming language) is a good distance
away from that. And even this 'detailed level' has one thing going
for it from 'learn afresh': The 'primitives' it consists of are all
fairly simple (and close to things people likely already know
something about, eg because of having used a pocket calculator in
school).     

> --- they should concentrate on understanding *the logic*
> and teh basic things;  after they have developed the basic skills
> and understanding of the basic things, then they can worry about
> pointers, dynamic memory allocation and all the advanced things.

I can see nothing 'advanced' in 'variable addresses' (except that it
is 'advanced' enough that one needs to understand a few more basic
concepts first) and 'dynamic memory allocation' certainly isn't needed
for basic (beginner-style) algorithms. IIRC, C++ includes it as well,
so this would be an argument against both.

> My point keeps being the same:  in C++, it is in general simpler
> to avoid the complex things;

Only if you (as you did), define one as being 'simple' and the other
as being 'complex'. 

> in C, a lot less so --- you can do a lot of (simple) things in C++
> with std::string without really knowing (or caring about) what the
> underlying principles behind that are;

This means that 'std::string' is a lot more complex than simpler
manipulation of the contents of character arrays. And you have to
learn about the high-level concept of strings before you can use it,
so this doesn't appear to be a quantitative difference to me.

[...]

>  and that's why we need to put the &'s, or simply accept that as an
>  annoying thing that has no reason for being (and the beginner will
>  have to choose this last option).

Nobody has to refuse to understand what he or she is trying to do.
And that operators manipulate values is again on of the very basic
concepts this person is supposed to learn. Only that it would be
sensible to start with more familiar operators first.

> Again, regardless of one's opinion about the above details, if
> we're talking about someone *beginning* programming, all those
> things are simply traps --- some of them subtle --- getting in
> the way: getting in the way as in making it harder to make things
> work (because the beginner is bound to fall for those traps), and
> making it harder to concentrate on the simple and basic principles
> that the beginner should concentrate on (given the amount of little
> details that one has to keep in mind to make the simplest program
> work)

That would call for something like 'logo'. But after having learned a
language that leaves everything related to 'computers' out in favor of
(to a real beginner) equally mysterious 'other abstractions', the person
hasn't really learned anything usuable in a different context.

[...]

>> what
>> is 'learning C++ well' and why would one want to do it in the first
>> place?
>
> For the same reason that one would want to learn C well.  Or Java
> well.  Or PHP well.  Or Fortran well.

I have learnt C++ at some point in time, because, mainly coming from
the usual 'Turbo Pascal with Objects' background, it felt more natural
to me than going back to procedural languages at that
time. Considering that 'some people' meanwhile have three or more
different, mutually incompatible  compiler versions installed on their
computers, just to be able to compile all the C++-sources they are
using, I wouldn't do it again and wouldn't recommend it to others. 

>>>You'll probably want to learn and master *both*
>> Why again?
>
> You don't seem to have read the OP initial message --- the reason
> is crystal clear in there.

I did. I just think he has this backwards. If I want to contribute (or
just work with) a particular piece of software, I will have to learn
the language it is written in. Why learn C++ if one is never going to
use it? Or C? Or any other language?
0
Rainer
2/21/2007 5:02:41 PM
Anthony Irwin wrote:
> Hi All,
> 
> I am starting to learn C and am wondering if C++ may be a better choice? 

No.

> The purpose is to do free software development and eventually contribute 
> to existing projects.

C covers much larger part of really free programs than C++.

> I believe that a lot of gnome stuff is c and kde stuff tends to be c++ 
> is that correct?

Yes. Gnome project chose C for portability across UNIX-es. KDE chose C++ 
for compatibility with proprietary QT toolkit from Trolltech. Feel the 
difference.

> what would other people out their recommend. I realize there are lots of 
> different opinions on this but I was just interest to see third party 
> thoughts.

Python, then Java, then C, then C++. GNU GCC can compile Java code into 
native code (via GNU Compiler for Java), so you even can mix C (gcc), 
C++ (g++) and Java (gcj) code in the single program.

First try to learn how to write programs properly using newer languages. 
Then learn ancient languages, with lot of old mistakes in their design.

PS.

OOP is not a panacea. Many OO programs has major flaw in their design - 
they use too many objects, so they use LOT of memory. Be warned.
0
Volodymyr
2/21/2007 5:10:51 PM
Rainer Weikusat wrote:
> 
> If I want to contribute (or
> just work with) a particular piece of software, I will have to learn
> the language it is written in. Why learn C++ if one is never going to
> use it? Or C? Or any other language?

I agree. Teaching a language is blindly stupid (imho). We should teach
_concepts_ and get the help of one (or more) language only to illustrate
the concepts.

The fact is that you won't use C to teach OO programming and software
design. And, in the same manner, you won't use C++ to teach low-level
memory handling and OS programming. Languages may vary, concepts won't.

If you think that beginners should grasp first the concept of
inheritance, then go for C++ or Java (or whatever language that can
easily express this concept).

If you think that beginners should grasp first the way memory works down
to the bits, go for C.

I'm always afraid of people coming to me and claiming: � Hey dude, I
know C/C++/Java ! �... What does that mean ? The guy did teach it, did a
big software in this language, ... and what ? Why should this
demonstrate he knows the language ? What if he did teach it wrong ? What
if his software is a bloat ?

What I like better is when the same guy is claiming: � Hey, I know how
to write a lexer/parser/scheduler/multiple inheritance/plugins/... �
without mentioning any language because you should be able to reproduce
what you learned in any other language if you did it right in one. ;)

Regards
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Lib�ration  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
2/21/2007 5:25:13 PM
On 2007-02-21, Volodymyr M. Lisivka <vlisivka@gmail.com> wrote:

> GNU GCC can compile Java code into native code (via GNU
> Compiler for Java), so you even can mix C (gcc), C++ (g++) and
> Java (gcj) code in the single program.

You will, of course, go to hell if you do that.

Or be in hell if you do that.

Probably both.

-- 
Grant Edwards                   grante             Yow!  KARL MALDEN'S NOSE
                                  at               just won an ACADEMY AWARD!!
                               visi.com            
0
Grant
2/21/2007 5:27:57 PM
On Wednesday 21 Feb 2007 14:49 in article
<87649vpnud.fsf@semtex.sncag.com> of comp.os.linux.development.apps,
Rainer Weikusat wrote:

[snip]
>> --- the prorgammer creates many extremely-hard-to-break habits that,
>> given the alternative C++ techniques that are available, make them
>> bad practices.
> 
> If anything, the programmer[*] acquires such habits. What are those
> habits, what are the alternatives you are talking about and why do you
> think they are preferable?
> 
> [*] Do you know that the 'programmer' orginally was the person
> responsible for keying in the already completed program?

This is incorrect.

More than 30 years ago I was working as a "programmer" and I would write
my code on 80-column coding sheets. When the program was complete I
would hand the coding sheets to a young lady called a "key-punch
operator" who would then type the code onto Hollerith cards.

-- 
Regards

Dave  [RLU#314465]
======================================================
dwnoon@spamtrap.ntlworld.com (David W Noon)
Remove spam trap to reply via e-mail.
======================================================

0
David
2/21/2007 6:44:28 PM
John Hasler <john@dhh.gt.org> writes:

> M�ns Rullg�rd writes:
>> While C++ is a powerful language, it takes some skill to use it properly
>> and create a mess.
>
> While it is true that it takes some skill to create a large mess with C++,
> any programmer can use it to create a small one.  What takes great skill is
> not creating any mess at all.

I think I lost a "not" somewhere along the way.  Just in case that
wasn't obvious.

-- 
M�ns Rullg�rd
mans@mansr.com
0
iso
2/21/2007 6:53:03 PM
Emmanuel Fleury wrote:
> If you think that beginners should grasp first the way memory works down
> to the bits, go for C.

The saying was, all the power of assembler with all the convenience of assembler.

I happen to like assembler, so that isn't necessarily bad.  It's independent
of the machine, pretty much.
-- 
Ron Hardin
rhhardin@mindspring.com

On the internet, nobody knows you're a jerk.
0
Ron
2/21/2007 7:05:12 PM
Emmanuel Fleury wrote:

> I agree. Teaching a language is blindly stupid (imho). We should teach
> _concepts_ and get the help of one (or more) language only to illustrate
> the concepts.

Careful --- though I 100% agree with the principle, you as a teacher
should also know that it is an entirely different story when dealing
with beginners (beginners in *prorgamming*).  They have not yet
developed the capacity to understand that what's really important
is the notions, and not the syntax.

It's like trying to teach a toddler that is beginning to utter some
words about semantics, verbs and nouns and conjugations and how what
really is important is expressing the idea and organizing the
sentences and not the actual words being uttered in a particular
language (English, French, Spanish, etc.)

I don't know if you teach people that *already* have progammed in
some languages, or if you teach them in a conetxt where they have
already studied algorithms and data structures from an abstract
point of view --- but when that is not the case, the beginner can
not possibly understand that the important thing is the concept and
not the actual syntax or the command-line statement to compile the
program, or which button to click on the IDE (and believe me that I
always spend a considerable amount of time trying to emphasize that
very point ...  I like to believe that the time I spend doing that
pays off after a while --- in the short term, it always feels like
I'm talking to a wall)

> What I like better is when the same guy is claiming: � Hey, I know how
> to write a lexer/parser/scheduler/multiple inheritance/plugins/... �
> without mentioning any language because you should be able to reproduce
> what you learned in any other language if you did it right in one. ;)

Agreed --- but two details:  1) see above.   And 2), when you are
talking in the context of a thread where the OP explicitly asks
about C or C++, having given the reasons that he wants to work on
typical Open Source Linux-oriented projects, it makes sense to
focus on the topic at hand.  Agreed (again) that it is a good
thing to point out how being concerned about the choice of language
is not the best way to go around it ... You know, as complementary
information to answer his question.

My point keeps being that, if for whatever reason, logical or not,
the objective is to learn *both* C and C++, I am convinced, after
more than a decade of experience teaching both languages to
beginners and to non-beginners, that the best approach is to
learn C++ first, then learn C.

Perhaps it would be healthy, for the OP, to point him to read
Peter Norvig's (sp??) "Teach Yourself Programming in Ten Years".
Don't have the link right here, but a quick Google search typing
in that phrase will point you directly there.

Carlos
--
0
Carlos
2/21/2007 7:05:35 PM
Grant Edwards wrote:
> On 2007-02-21, Volodymyr M. Lisivka <vlisivka@gmail.com> wrote:
> 
>> GNU GCC can compile Java code into native code (via GNU
>> Compiler for Java), so you even can mix C (gcc), C++ (g++) and
>> Java (gcj) code in the single program.
> 
> You will, of course, go to hell if you do that.

Tomcat 5.5 is written in Java, compiled to native code in in Fedora Core 
4+ and uses Apache Portable Runtime library written in C.

Eclipse IDE is written in Java, compiled to native code in Fedora Core 
4+ and uses SWT library, which use GTK+ library written in C.

Bla, bla, bla.

Why not write critical parts of application in C or ASM for speed and 
GUI in Java for portability?

 > Or be in hell if you do that.

Welcome to real world, Neo.
0
Volodymyr
2/21/2007 8:17:32 PM
On 2007-02-21, Volodymyr M. Lisivka <vlisivka@gmail.com> wrote:
> Grant Edwards wrote:
>> On 2007-02-21, Volodymyr M. Lisivka <vlisivka@gmail.com> wrote:
>> 
>>> GNU GCC can compile Java code into native code (via GNU
>>> Compiler for Java), so you even can mix C (gcc), C++ (g++) and
>>> Java (gcj) code in the single program.
>> 
>> You will, of course, go to hell if you do that.
>
> Tomcat 5.5 is written in Java, compiled to native code in in Fedora Core 
> 4+ and uses Apache Portable Runtime library written in C.
>
> Eclipse IDE is written in Java, compiled to native code in Fedora Core 
> 4+ and uses SWT library, which use GTK+ library written in C.

Neither of those is an example of a programmer mixing C, C++,
and Java in a single program.  From your description, I'd say
they're both programs written in a single language (Java).

Small portions of the Linux kernel are written in assembly. I
don't thing that means that my C program which makes Linux
system calls is "C and ASM mixed in a single program".

> Why not write critical parts of application in C or ASM for speed and 
> GUI in Java for portability?
>
> > Or be in hell if you do that.
>
> Welcome to real world, Neo.

Where there's apparently no such thing as humor or irony.

-- 
Grant Edwards                   grante             Yow!  HELLO, everybody,
                                  at               I'm a HUMAN!!
                               visi.com            
0
Grant
2/21/2007 8:26:52 PM
Grant Edwards wrote:
> On 2007-02-21, Volodymyr M. Lisivka <vlisivka@gmail.com> wrote:
>> Grant Edwards wrote:
>>> On 2007-02-21, Volodymyr M. Lisivka <vlisivka@gmail.com> wrote:
>>>
>>>> GNU GCC can compile Java code into native code (via GNU
>>>> Compiler for Java), so you even can mix C (gcc), C++ (g++) and
>>>> Java (gcj) code in the single program.
>>> You will, of course, go to hell if you do that.
>> Tomcat 5.5 is written in Java, compiled to native code in in Fedora Core 
>> 4+ and uses Apache Portable Runtime library written in C.
>>
>> Eclipse IDE is written in Java, compiled to native code in Fedora Core 
>> 4+ and uses SWT library, which use GTK+ library written in C.
> 
> Neither of those is an example of a programmer mixing C, C++,
> and Java in a single program.  From your description, I'd say
> they're both programs written in a single language (Java).

What you expect to see? 30% of Java code, 30% of C++ code, 30% of C code 
and 10% of assembly?

C++ allows to mix C++ and C code in single program. Did you saw program 
with 50% of C++ code and 50% of C code?

I see no reason to mix languages (Java with C++ or C++ with C) except 
when you need to do something that your primary language cannot do. Most 
of the time this will be very small portion of code in another language 
or simple wrapper to library.

Why developer should go to hell when it uses "extern "C" {}" or "public 
native void ..."???
0
Volodymyr
2/21/2007 8:42:55 PM
On 2007-02-21, Volodymyr M. Lisivka <vlisivka@gmail.com> wrote:
> Grant Edwards wrote:
>> On 2007-02-21, Volodymyr M. Lisivka <vlisivka@gmail.com> wrote:
>>> Grant Edwards wrote:
>>>> On 2007-02-21, Volodymyr M. Lisivka <vlisivka@gmail.com> wrote:
>>>>
>>>>> GNU GCC can compile Java code into native code (via GNU
>>>>> Compiler for Java), so you even can mix C (gcc), C++ (g++) and
>>>>> Java (gcj) code in the single program.
>>>> You will, of course, go to hell if you do that.
>>> Tomcat 5.5 is written in Java, compiled to native code in in Fedora Core 
>>> 4+ and uses Apache Portable Runtime library written in C.
>>>
>>> Eclipse IDE is written in Java, compiled to native code in Fedora Core 
>>> 4+ and uses SWT library, which use GTK+ library written in C.
>> 
>> Neither of those is an example of a programmer mixing C, C++,
>> and Java in a single program.  From your description, I'd say
>> they're both programs written in a single language (Java).
>
> What you expect to see? 30% of Java code, 30% of C++ code, 30% of C code 
> and 10% of assembly?

In those cases (AFAICT), the code written by the authors of
both tomcat and eclipse was 100% Java.  I don't see how the
language in which a library was written by somebody else has
anything to do with the topic at hand.  Those authors wrote
their programs in Java utilizing various libraries according to
their published APIs.  

You don't have to learn the language in which a library was
written in order to call it according to its API.  I write
applications all the time that use libraries written in TCL, C,
C++, and Fortran. Yet those applications are written in 100%
Python.

> C++ allows to mix C++ and C code in single program. Did you
> saw program with 50% of C++ code and 50% of C code?

Yes, I've seen programs like that, and they're a bitch to
maintain.

> I see no reason to mix languages (Java with C++ or C++ with C)
> except when you need to do something that your primary
> language cannot do. Most of the time this will be very small
> portion of code in another language or simple wrapper to
> library.
>
> Why developer should go to hell when it uses "extern "C" {}"
> or "public native void ..."???

Personally, I wouldn't count either of those as "mixing
languages in a single program".

-- 
Grant Edwards                   grante             Yow!  Where's SANDY DUNCAN?
                                  at               
                               visi.com            
0
Grant
2/21/2007 8:55:48 PM
M�ns Rullg�rd writes:
> While C++ is a powerful language, it takes some skill to use it properly
> and create a mess.

I wrote:
> While it is true that it takes some skill to create a large mess with C++,
> any programmer can use it to create a small one.  What takes great skill is
> not creating any mess at all.

M�ns Rullg�rd writes:
> I think I lost a "not" somewhere along the way.  Just in case that wasn't
> obvious.

It was obvious.  My attempt at humor evidently was not.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
0
John
2/21/2007 9:42:48 PM
Emmanuel Fleury wrote:
> If you think that beginners should grasp first the way memory works down
> to the bits, go for C.

No.  Go for MIX.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
0
John
2/21/2007 9:44:04 PM
Hi All,

Thanks to all who responded it was an interesting read. It seems as if 
most of the posters are pro C and a smaller number pro C++. I was in 
fact looking for the best language to use to contribute to the free 
software community as some posters noted.

My background with programming is strong knowledge of php and bash 
scripting. I have also played with python and perl from time to time.

In regards to what languages to begin with for a beginner I kind of 
regret starting with higher level languages like php and python over a 
more lower level language like C because it has stopped me from 
getting in and learning a language like c because I know I can do 
things in other languages without having to worry about memory 
management, pointers, buffer overflows and all that.

A perfect example is getting input from a user in c you need to make 
sure that the variable you are using has enough space allocated where 
in other languages it is taken care of for you.

Anyway as I said in my original post I have started learning c and am 
about half way through the o'reilly practical C book which seems to be 
pretty good.

I have a range of things that I would like to play around with 
including a few basic sdl games maybe like (tetris, space invaders, 
pacman clones), some sort of gui apps probably gtk and maybe a look at 
some os development probably look at minix for that as it is designed 
for learning os development and has a book to go with it.

for this I believe I will get more mileage with c but the os 
development stuff is low priority as it is probably going to be very 
intensive to get into and something to work towards if other things 
don't take my interest first.

Anyway I would prefer to spend the majority of my spare home computer 
time working with one language to get proficient at it so does anyone 
know if most free software apps are using c or c++.

I think you used to be able to search sourceforge projects by 
programming language but that doesn't seem to be the case anymore. How 
can I find out what the majority of projects are using these days.

Is sourceforge the best place to search for possible projects to 
contribute to and look at the source base of or is there other better 
places to check out.

Anyway thanks for your input.

Anthony
0
Anthony
2/22/2007 6:48:27 AM
In article news:<erh93k$gr8$1@sagnix.uni-muenster.de>, Martin Hierholzer 
wrote:
> I agree. But if you have never learned a programming language before,
> it will be really hard to learn C++ (or any other object oriented
> language). You should have a more or less advanced understanding of
> common programming structures like "if", "for", "while" etc. before
> trying to understand object oriented programming.

I think that's completely untrue. Knowing C tends to make you look for a 
C style solution in C++ (using "if", "for", and "while", etc.) when the 
best (i.e. clearest, simplest, most readable and maintainable) solutions 
in C++ may use features that C doesn't have (such as algorithms). If 
anything it is necessary to *forget* C to become a good C++ programmer.

There are some very good books that aim to teach C++ from scratch without 
using the legacy baggage of C as a crutch. Take a look at /Accelerated 
C++/ by Andy Koenig and Barbara Moo, or "You Can Program in C++" by 
Francis Glassboro as examples (I confess I haven't read Francis's book 
myself but it has a good reputation).

Cheers,
 Daniel.
 

0
Daniel
2/22/2007 10:24:54 AM
Daniel James <wastebasket@nospam.aaisp.org> writes:
> In article news:<erh93k$gr8$1@sagnix.uni-muenster.de>, Martin Hierholzer 
> wrote:
>> I agree. But if you have never learned a programming language before,
>> it will be really hard to learn C++ (or any other object oriented
>> language). You should have a more or less advanced understanding of
>> common programming structures like "if", "for", "while" etc. before
>> trying to understand object oriented programming.
>
> I think that's completely untrue. Knowing C tends to make you look for a 
> C style solution in C++ (using "if", "for", and "while", etc.) when the 
> best (i.e. clearest, simplest, most readable and maintainable) solutions 
> in C++ may use features that C doesn't have (such as algorithms).

This is a statement containing two assertions, namely

	a) people who know C tend to avoid using the C++ standard
	   library

	b) if the C++ standard library can be used, using it is
           sui generis the best way to solve any particular problem

The first could be 'proven' to some degree by a formal social
study. Is there such a study? The second is obviously untrue (it would
at least depend on a particular implementation of the C++-standard
library is the 'best' solution for a particular problem, except if -
and this appears to be a trap C++-advocates are prone to fall into -
'best' is defined as 'using the C++-standard library').

> If  anything it is necessary to *forget* C to become a good C++
> programmer.

So, we (participiants of this thread) have the same nonsense again,
still without reason and still without some sensible definition of
what exactly comprises 'a good C++-programmer'.
0
Rainer
2/22/2007 10:43:29 AM
Daniel James wrote:
> In article news:<erh93k$gr8$1@sagnix.uni-muenster.de>, Martin Hierholzer 
> wrote:
>> I agree. But if you have never learned a programming language before,
>> it will be really hard to learn C++ (or any other object oriented
>> language). You should have a more or less advanced understanding of
>> common programming structures like "if", "for", "while" etc. before
>> trying to understand object oriented programming.
> 
> I think that's completely untrue. Knowing C tends to make you look for a 
> C style solution in C++ (using "if", "for", and "while", etc.) when the 
> best (i.e. clearest, simplest, most readable and maintainable) solutions 
> in C++ may use features that C doesn't have (such as algorithms).

C++ has "algorithms"?

 > If
> anything it is necessary to *forget* C to become a good C++ programmer.

I started in turbo pascal then C, then C++. I found C++ overly complex
and restrictive for the same things that can be done easily in C + macros.

After reading the Stroustrup book and flirting with C++ and looking at
projects in C++, i went back to doing my own objects in C which are
completely baggage-free and far more flexible than C++ objects.

> There are some very good books that aim to teach C++ from scratch without 
> using the legacy baggage of C as a crutch. Take a look at /Accelerated 
> C++/ by Andy Koenig and Barbara Moo, or "You Can Program in C++" by 
> Francis Glassboro as examples (I confess I haven't read Francis's book 
> myself but it has a good reputation).
0
Russell
2/22/2007 11:22:37 AM
Hi.

Russell Shaw <rjshawN_o@s_pam.netspace.net.au> writes:

> Daniel James wrote:
> > In article news:<erh93k$gr8$1@sagnix.uni-muenster.de>, Martin
> > Hierholzer wrote:
> >> I agree. But if you have never learned a programming language before,
> >> it will be really hard to learn C++ (or any other object oriented
> >> language). You should have a more or less advanced understanding of
> >> common programming structures like "if", "for", "while" etc. before
> >> trying to understand object oriented programming.
> > I think that's completely untrue. Knowing C tends to make you look
> > for a C style solution in C++ (using "if", "for", and "while", etc.)
> > when the best (i.e. clearest, simplest, most readable and
> > maintainable) solutions in C++ may use features that C doesn't have
> > (such as algorithms).
> 
> C++ has "algorithms"?

Yes:
  #include <algorithm>
Consult a C++ book that talks about the Standard Template Library
(STL) for more details.

-- 
Art Werschulz (agw STRUDEL comcast.net)
207 Stoughton Ave Cranford NJ 07016
(908) 272-1146
0
Art
2/22/2007 12:38:10 PM
Art Werschulz wrote:
> Hi.
> 
> Russell Shaw <rjshawN_o@s_pam.netspace.net.au> writes:
> 
>> Daniel James wrote:
>>> In article news:<erh93k$gr8$1@sagnix.uni-muenster.de>, Martin
>>> Hierholzer wrote:
>>>> I agree. But if you have never learned a programming language before,
>>>> it will be really hard to learn C++ (or any other object oriented
>>>> language). You should have a more or less advanced understanding of
>>>> common programming structures like "if", "for", "while" etc. before
>>>> trying to understand object oriented programming.
>>> I think that's completely untrue. Knowing C tends to make you look
>>> for a C style solution in C++ (using "if", "for", and "while", etc.)
>>> when the best (i.e. clearest, simplest, most readable and
>>> maintainable) solutions in C++ may use features that C doesn't have
>>> (such as algorithms).
>> C++ has "algorithms"?
> 
> Yes:
>   #include <algorithm>
> Consult a C++ book that talks about the Standard Template Library
> (STL) for more details.

Hmm, the book doesn't seem to show the BNF for them.
0
Russell
2/22/2007 12:51:57 PM
On Thu, 22 Feb 2007 16:48:27 +1000, Anthony Irwin wrote:

> A perfect example is getting input from a user in c you need to make 
> sure that the variable you are using has enough space allocated where 
> in other languages it is taken care of for you.

You'll find that the libraries you mention later in your post might handle
this for you. Working with the console as a UI (and not using ncurses for
instance) you'll find stuff that can help you with this:

  man 3 getline ( http://www.die.net/doc/linux/man/man3/getline.3.html )
  man 3 asprintf ( http://www.die.net/doc/linux/man/man3/asprintf.3.html )

Note that you must add #define _GNU_SOURCE before including headers as
stated. You'll also need to free (man 3 free) the result.


> I have a range of things that I would like to play around with 
> including a few basic sdl games maybe like (tetris, space invaders, 
> pacman clones), some sort of gui apps probably gtk 

I've written a couple of short writings showing how one can get started
with GTK+/Glade (`ubuntu-programming3.pdf'):

  http://nostdal.org/~lars/writings/

...not sure if you'll find them useful; they where written in a rush and
might contain errors/typos/etc. Also see http://www.gtk.org/tutorial/

-- 
Lars Rune Nøstdal
http://nostdal.org/

0
iso
2/22/2007 3:22:13 PM
[...]

>> I agree. Teaching a language is blindly stupid (imho). We should teach
>> _concepts_ and get the help of one (or more) language only to illustrate
>> the concepts.
>
> Careful --- though I 100% agree with the principle, you as a teacher
> should also know that it is an entirely different story when dealing
> with beginners (beginners in *prorgamming*).  They have not yet
> developed the capacity to understand that what's really important
> is the notions, and not the syntax.

Considering that they know neither notions nor any syntax, that
appears to be a promising opportunity to do it right from the
beginning, eg by presenting constructs commonly found in high-level
languages and giving examples in multiple languages.

> It's like trying to teach a toddler that is beginning to utter some
> words about semantics, verbs and nouns and conjugations and how what
> really is important is expressing the idea and organizing the
> sentences and not the actual words being uttered in a particular
> language (English, French, Spanish, etc.)

That's a really bad analogy, because you are teaching to grown-ups (or
at least 'mostly grown-ups') and not small children. 

[...]

>> What I like better is when the same guy is claiming: � Hey, I know how
>> to write a lexer/parser/scheduler/multiple inheritance/plugins/... �
>> without mentioning any language because you should be able to reproduce
>> what you learned in any other language if you did it right in one. ;)
>
> Agreed --- but two details:  1) see above.   And 2), when you are
> talking in the context of a thread where the OP explicitly asks
> about C or C++, having given the reasons that he wants to work on
> typical Open Source Linux-oriented projects, it makes sense to
> focus on the topic at hand.

In this respect, the answer is very easy: Learn C, it is a lot simpler
and with much better compiler support and more frequently used. Learn
C++ if you have to work with C++ sources. Avoid it for new
developments at least until three sucessive gcc-releases did not
proudly state that backward compatibility has been broken again in the
release notes. Which likely means 'forever'.

> My point keeps being that, if for whatever reason, logical or not,
> the objective is to learn *both* C and C++, I am convinced, after
> more than a decade of experience teaching both languages to
> beginners and to non-beginners, that the best approach is to
> learn C++ first, then learn C.

You still haven't offered a reason for this conviction of yours,
beyond that people learning C will have to learn C and not C++.
0
Rainer
2/22/2007 3:26:35 PM
Rainer Weikusat wrote:

>>It's like trying to teach a toddler that is beginning to utter some
>>words about semantics, verbs and nouns and conjugations and how what
>>really is important is expressing the idea and organizing the
>>sentences and not the actual words being uttered in a particular
>>language (English, French, Spanish, etc.)
> 
> That's a really bad analogy, because you are teaching to grown-ups (or
> at least 'mostly grown-ups') and not small children. 

Errrr, sorry, but I think you're misinterpreting the meaning of the
term "analogy" --- it is a very accurate analogy, because I was
emphasizing the fact that for someone without *maturity* to see and
understand the bigger picture, it's no use complicate things with
an excessive amount of information and notions.  It does not matter
that the beginner programmer is an adult --- they're like innocent
clueless children when you try to make them think of programming.

The little one+ year old has no maturity to understand the abstract
notion of *communicating ideas* and the fact that the actual words
simply happen to be arbitrary utterances, and that the same ideas
and the same communication process can happen exactly the same even
if the syntax and actual words are entirely different.

Same thing for a 6 (or 7?) year old learning their basic math;
learning to add, multiply, etc. --- there's no point in trying to
teach them about the mathematical properties of numbers, and use
binary and hexadecimal notation to illustrate the principle that
adding numbers is nothing other than applying the fundamental
principles of the operations .... etc. etc. etc.

Again --- an *analogy*, not another instance of the *exact* same
situation, and exact from any conceivable point of view.

> In this respect, the answer is very easy: Learn C, it is a lot simpler

Not as a "beginner's" programming language.  Once you get maturity
and experience, it is indeed a simpler language (from a certain
point of view).  But for a beginner, the amount of details that
are the entire responsibility of the programmer is what makes it
unsuitable as a language to teach programming.

Again, I'm not speaking based on my language preference --- the
above statement is based on my personal experience *teaching*
both C and C++ to both beginners and non-beginners --- for non-
beginners, the subtleties in C are, at worst, annoying because
they're already used to other languages in which the programmer
doesn't need to care about so many things...  But that's about
it --- they really have no problem dealing with all the new
stuff;  for *beginner programmers*, the experience of C is a
true horror story.

C++ has a quite unique virtue, from the didactic point of view:
even though it is an extremely complex language, the complexity
is "optional", and it goes (in general) with the complexity of
the task that you're solving --- IOW, if you simply want a
program that receives two numbers from the user and prints
them, you do that extremely simply.  That is not the case with
C (or with Java, for that matter!!)

>>My point keeps being that, if for whatever reason, logical or not,
>>the objective is to learn *both* C and C++, I am convinced, after
>>more than a decade of experience teaching both languages to
>>beginners and to non-beginners, that the best approach is to
>>learn C++ first, then learn C.
> 
> You still haven't offered a reason for this conviction of yours,
> beyond that people learning C will have to learn C and not C++.

Funny how you all keep ignoring the part that clearly states
"based on more than a decade of experience teaching both C and
C++" --- and also all the other reasons, which I repeat in this
message  (see the several paragraphs above).

Carlos
--
0
Carlos
2/22/2007 10:24:06 PM
--=-=-=
Content-Transfer-Encoding: quoted-printable

"Volodymyr M. Lisivka" <vlisivka@gmail.com> writes:

>> I believe that a lot of gnome stuff is c and kde stuff tends to be
>> c++ is that correct?
>
> Yes. Gnome project chose C for portability across UNIX-es.

We need to be careful with GTK+ and GNOME use of "C".  If you want to
write programs in C for GTK+/GNOME, you'll need to know C++ very well,
right down to the implementation details of vtables and
typeinfo/dynamic_cast<>, so you can then reinvent them in C.  That's
because they replicate, by hand in C, its own type and object system,
GObject.  It's pretty horrible, and for the programmer a wonderful
source of bugs, since the compiler type checking is woefully adequate
due to the abuse GObject inflicts on the C language.

If this is your reason for wanting to learn C, you'll need to learn C,
then learn C++, and then you'll be able to write buggy
GObject-oriented C of your own!  Or, you could just use the GTK+/GNOME
C++ bindings (gtkmm/gnomemm), or better, not use GTK+/GNOME at all.

> KDE chose C++ for compatibility with proprietary QT toolkit from
> Trolltech.  Feel the difference.

Or read the code and see the difference.  GTK+ and GNOME are a
poorly-maintained buggy mess due to all the brain damaged stupidity.
If they were to rewrite it all in C++, based on the existing
Gtkmm/Gnomemm APIs, it might be worth considering once more.  In the
meantime, Qt is probably the safer choice.


Regards,
Roger

=2D-=20
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF3iaaVcFcaSW/uEgRAvG5AKCBsIfojc84sbpgVmhizK764vTOowCg1FX0
x7LOgNxUMRxx5sRISwv10Ls=
=NSLv
-----END PGP SIGNATURE-----
--=-=-=--
0
Roger
2/22/2007 11:26:16 PM
Rainer Weikusat wrote:
> This is a statement containing two assertions, namely
> 	a) people who know C tend to avoid using the C++ standard
> 	   library

Or at least it takes time to move to it. Four years into C++ I was still 
using printf, before I switched to std::cout. OTOH, switch to use 
std::string and container classes was almost instant (within few weeks). 
So, I believe this would fall into that category:

> 	b) if the C++ standard library can be used, using it is
>            sui generis the best way to solve any particular problem

"The best" is hard to prove, but it is certainly better to use some 
string class instead of char *.

>>If  anything it is necessary to *forget* C to become a good C++
>>programmer.
> 
> So, we (participiants of this thread) have the same nonsense again,
> still without reason and still without some sensible definition of
> what exactly comprises 'a good C++-programmer'.

I believe it's all about object-oriented way of thinking and some other 
minor stuff:

- use const instead of #define
- use templates instead of macros
- use singleton instead of global variables (although this can be done 
in C as well)
- use other design patterns. Although it is possible with C, it's 
natural to do it with C++.


-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
2/23/2007 9:35:23 AM
Rainer Weikusat wrote:
> Avoid it for new
> developments at least until three sucessive gcc-releases did not
> proudly state that backward compatibility has been broken again in the
> release notes.

I'm not sure what you mean? I've been using GCC since version 3.2, and 
all my code still compiles with latest 4.x series. If you write standard 
code and don't use any exotic GCC features, there is nothing to get 
broken. Other thing is ABI compatibilty, but that's a non-issue: just 
recompile everything you need with latest compiler.



-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
2/23/2007 9:40:54 AM
Milan Babuskov <mbabuskov@yahoo.com> writes:
> Rainer Weikusat wrote:
>> Avoid it for new
>> developments at least until three sucessive gcc-releases did not
>> proudly state that backward compatibility has been broken again in the
>> release notes.
>
> I'm not sure what you mean? I've been using GCC since version 3.2, and
> all my code still compiles with latest 4.x series. If you write
> standard code and don't use any exotic GCC features, there is nothing
> to get broken.

As long as the language the comilers accepts keeps changing, you'll
always run the risk that something you believed to be 'standard code'
etc pp actually wasn't and future compiler versions may cause the code
to not compile anymore. You are free to believe that this doesn't
happen if it hasn't yet happened to you.

0
Rainer
2/23/2007 10:32:00 AM
In article news:<87slcyo4ku.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
> This is a statement containing two assertions, namely
> 
>  a) people who know C tend to avoid using the C++ standard
>     library

I wouldn't say "tend to avoid" ... but it is certainly an observable 
phenomenon that newcomers to C++ who already know C tend to do things the 
way they know, rather than considering alternatives offered by the new 
language.

> b) if the C++ standard library can be used, using it is
>            sui generis the best way to solve any particular problem

I was talking specifically about the best way to learn C++ -- not about 
whether C++ is in every (or any) sense "better" than C. The thread topic 
had drifted a little from the OP's original question (or so it seemed to 
me).

> > If  anything it is necessary to *forget* C to become a good C++
> > programmer.
> 
> So, we (participiants of this thread) have the same nonsense again,
> still without reason and still without some sensible definition of
> what exactly comprises 'a good C++-programmer'.

I'm sorry. I should have written:

   If  anything it is necessary to *forget* C to learn C++

To be a "good" C++ programmer I am sure it is necessary to relearn C after 
learning C++, so as to be able to make the best, informed, decisions as to 
whether the "C++ way" or the "C way" (which is still available to us, 
within C++) is the more appropriate for a particular solution.

Cheers,
 Daniel.
 

0
Daniel
2/23/2007 11:04:21 AM
Carlos Moreno <cm_clcppm_7b8f93f186@mochima.com> writes:
> Rainer Weikusat wrote:
>
>>>It's like trying to teach a toddler that is beginning to utter some
>>>words about semantics, verbs and nouns and conjugations and how what
>>>really is important is expressing the idea and organizing the
>>>sentences and not the actual words being uttered in a particular
>>>language (English, French, Spanish, etc.)
>> That's a really bad analogy, because you are teaching to grown-ups
>> (or
>> at least 'mostly grown-ups') and not small children.
>
> Errrr, sorry, but I think you're misinterpreting the meaning of the
> term "analogy" --- it is a very accurate analogy, because I was
> emphasizing the fact that for someone without *maturity* to see and
> understand the bigger picture, it's no use complicate things with
> an excessive amount of information and notions.  It does not matter
> that the beginner programmer is an adult --- they're like innocent
> clueless children when you try to make them think of programming.

They are not like 'clueless children' because they have already learnt
a lot of other things since then and should, for instance, be able to
understand the concept of 'abstraction' itself, while the little
children cannot (they don't even know enough words to ask what this
may be yet).

[...]

>> In this respect, the answer is very easy: Learn C, it is a lot simpler
>
> Not as a "beginner's" programming language.  Once you get maturity
> and experience, it is indeed a simpler language (from a certain
> point of view).

Blafasel. The language itself is simpler, indenpedent from any point
of view.

[...]

>> You still haven't offered a reason for this conviction of yours,
>> beyond that people learning C will have to learn C and not C++.
>
> Funny how you all keep ignoring the part that clearly states
> "based on more than a decade of experience teaching both C and
> C++" --- and also all the other reasons, which I repeat in this
> message  (see the several paragraphs above).

Your main point (except the appeal to authority with you being the
authority) as that ignoring most of C++ leads to a simple language
than caring for all of C. This is undisputed.
0
Rainer
2/23/2007 12:00:33 PM
Carlos Moreno <cm_clcppm_7b8f93f186@mochima.com> writes:
> Rainer Weikusat wrote:
>
>>>It's like trying to teach a toddler that is beginning to utter some
>>>words about semantics, verbs and nouns and conjugations and how what
>>>really is important is expressing the idea and organizing the
>>>sentences and not the actual words being uttered in a particular
>>>language (English, French, Spanish, etc.)
>> That's a really bad analogy, because you are teaching to grown-ups
>> (or
>> at least 'mostly grown-ups') and not small children.
>
> Errrr, sorry, but I think you're misinterpreting the meaning of the
> term "analogy" --- it is a very accurate analogy, because I was
> emphasizing the fact that for someone without *maturity* to see and
> understand the bigger picture, it's no use complicate things with
> an excessive amount of information and notions.  It does not matter
> that the beginner programmer is an adult --- they're like innocent
> clueless children when you try to make them think of programming.

They are not like 'clueless children' because they have already learnt
a lot of other things since then and should, for instance, be able to
understand the concept of 'abstraction' itself, while the little
children cannot (they don't even know enough words to ask what this
may be yet).

[...]

>> In this respect, the answer is very easy: Learn C, it is a lot simpler
>
> Not as a "beginner's" programming language.  Once you get maturity
> and experience, it is indeed a simpler language (from a certain
> point of view).

Blafasel. The language itself is simpler, indenpedent from any point
of view.

[...]

>> You still haven't offered a reason for this conviction of yours,
>> beyond that people learning C will have to learn C and not C++.
>
> Funny how you all keep ignoring the part that clearly states
> "based on more than a decade of experience teaching both C and
> C++" --- and also all the other reasons, which I repeat in this
> message  (see the several paragraphs above).

Your main point (except the appeal to authority with you being the
authority) was that ignoring most of C++ leads to a simpler language
than caring for all of C. This is undisputed.
0
Rainer
2/23/2007 12:02:22 PM
Russell Shaw wrote:

>> I think that's completely untrue. Knowing C tends to make you look for 
>> a C style solution in C++ (using "if", "for", and "while", etc.) when 
>> the best (i.e. clearest, simplest, most readable and maintainable) 
>> solutions in C++ may use features that C doesn't have (such as 
>> algorithms).
> 
> C++ has "algorithms"?

Yes.  The C++ Standard Library has algorithms.  Searching, counting,
traversal, binary search, sort, etc.  Very elegant and very powerful,
IMHO.

The previous poster was referring to the fact that given the problem
of determining, say, the highest value in an array of ints, the
solution using if's, for's, etc., would be:

int pos_highest = 0;
for (i = 0; i < array's size; i++)
{
     if (array[i] > array[pos_highest])
         pos_highest = i;
}
int highest = array[pos_highest];

Whereas we can count on a more elegant and mainly less error-prone
solution using C++'s Standard Library max_element algorithm:

int highest = *max_element (strings.begin(), strings.end());


True that this deviates a little bit from the previous comment, in
that it really doesn't deal with object-oriented vs. non-OO ...  But
it is still a handy example that illustrates rather nicely the
principle.

The example (this *particular* example) also has a valid counter-
argument, in that, as already mentioned, it is more important to
teach *programming* than to teach one particular programming
language --- the example of wanting beginners to use STL algorithms
goes a bit against this, since the solution is quite C++ specific;
the apprentice could simply form the bad habit of relying too much
on "magic" provided by the language or the compiler.

However, a valid argument in favor of that is:  the apprentice
first learns to deal with the ideas at a high level --- they have
to first understand that *what has to be done* is to determine
the highest value, then do something with it;  no need to worry
(as a beginner) with a larger amount of details.

I mean, yes, of course the guy will then learn to hand-code a
search for the highest implementation --- in any language.  But
why overload the beginner's mind if there's no need to?

Another valid argument in favor of this example is that it also
forms the good habit of organizing code properly --- the beginner
quickly learns to appreciate code that looks like pseudo-code
and that expresses the idea of what's happening --- it would
likely lead to, as the apprentice gains more experience, writing
code that is more modular, making good use of functions if using
a procedural approach, or better class designs if in OO;  as
opposed to wanting to write a program that has only one function
called main, where all the details are right there.

Dealing with the large(r) amount of details should come *after*,
and not before everything else.

Carlos
--
0
Carlos
2/23/2007 7:46:30 PM
On Wed, 21 Feb 2007 09:18:16 +0000, M�ns Rullg�rd 
  <mans@mansr.com> wrote:
>
> It is possible to write object oriented code in any language. 

Just take the 12-line object oriented Forth and translate it. :)


-- 
There is an innocence in admiration; it is found in those to whom it
has not yet occurred that they, too, might be admired some day.
		-- Friedrich Nietzsche
0
Bill
2/23/2007 8:23:40 PM
Volodymyr M. Lisivka wrote:

> KDE chose C++
> for compatibility with proprietary QT toolkit from Trolltech. Feel the
> difference.

For your information Trolltech releases Qt under the GPL. They also sell
licenses for Qt that enables developing proprietary applications but that
doesn't cover up the fact that Qt is GPL and therefore as FOSS as it gets.

So exactly what is that "difference" you incite others to "feel"?


Rui Maciel
-- 
Running Kubuntu 6.10 with KDE 3.5.6 and proud of it.
jabber:rui_maciel@jabber.org
0
Rui
2/23/2007 9:38:46 PM
>>>>> "Emmanuel" =3D=3D Emmanuel Fleury <emmanuel.fleury@labri.fr> writes:

    >> Sorry, but this is completely untrue, and demonstrates a lack
    >> of understanding of what O-O programming is.

    Emmanuel> Sorry again, but the Church thesis pretends that any
    Emmanuel> Turing-complete language are equivalent, so this must be
    Emmanuel> right.

No.  You're comparing apples and oranges.

Church's  thesis  says  that all  Turing-complete  language  can
express  the same  class of  algorithms and  solve the  same  class of
problems.  It's about *computability*.

OO  is *methodology*,  which  is a  separate  dimension than  Church's
thesis.  Just like how to put  the bricks and blocks together to build
a house (engineering) is different from  how to design a house to suit
the users' needs (architect's job).



    Emmanuel> Anyway, some languages makes it harder than others. ;)

True.  Use the  right tools for the  task at hand.  Using C  for OO is
possible (look  at the  Xt library, or  the linux kernel).   It's just
less convenient than C++.  Not impossible.


--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
2/24/2007 1:29:17 AM
>>>>> "Carlos" =3D=3D Carlos Moreno <cm_clcppm_7b8f93f186@mochima.com> writ=
es:

    Carlos> As for OO, having tried both approaches (for teaching a
    Carlos> first language), I find that it is a much more natural and
    Carlos> more efficient way to abosrve the ideas for a beginner ---
    Carlos> OO *aims* at making the programming tools be like the
    Carlos> real-world problem being solved;=20

I  don't agree.   The aim  of  OO, in  my opinion,  is modularity  and
reusablity of source code, so that big programs are more managable.


    Carlos> other approaches in general require that the programmer
    Carlos> force/twist the real-life problem to be expressed in terms
    Carlos> of the available tools.

OO  also forces  the  programmer  to twist  real-life  problems to  be
expressed in terms  of objects under class hierarchies.   e.g. C++ STL
has  a concept  of "function  objects".  Why?   Why must  functions be
wrapped  as  objects?   Well...   because  C++  is  not  a  functional
programming language:  it lacks lambda  expressions.  Function objects
are just a bad immitation of lambda expressions in LISP dialects.

Is  OO  that  natural?   No.    In  the  literature,  there  has  been
discussions  of whether  Rectangle  should  be a  made  a subclass  of
Square, or  the other way around.  Square  subclassing Rectangle looks
"natural"  because it  agrees with  what we've  learnt in  maths.  But
Rectangle subclassing Square *is* done  quite often (esp.  back in the
early days  of OO and C++),  because a programmer  sees that Rectangle
has 2 parameters (2 degrees of  freedom) while Square has only 1.  So,
a  Rectangle is  an _extension_  (you know  why Java  use  the keyword
"extends"?) of  a Square.   So, which is  correct?  Which  is logical?
Which has better memory and speed performance?


    Carlos> After having taught the basic elements like variables,
    Carlos> data types, if and related, loops, and maybe functions,
    Carlos> teaching classes for simple/basic encapsulation is what
    Carlos> makes most sense --- no operator overloading; no
    Carlos> inheritance; not even destructors.

No inheritance?  Then no polymorphism,  either.  And why are you still
using OO?

And you won't teach them templates/generics either?


    Carlos> Simply develop the logic of modeling real-life entities
    Carlos> as *single entities* in the program --- yes, you could do
    Carlos> that with structures, but that would be a half-solution:

Not a  big loss.   If you're not  using inheritance  nor polymorphism,
then you can do  that kind of restricted OO easily in  C.  Look at the
vfs in the linux kernel.


    Carlos> if we are making the leap to have the students think in
    Carlos> those terms, we might as well teach them the whole truth
    Carlos> and then avoid them developing bad, hard-to-break habits
    Carlos> (creating classes with all members public, or with get
    Carlos> methods for each data member, possibly --- to make things
    Carlos> worse --- returning a reference to the data member, etc.).



--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
2/24/2007 1:43:54 AM
>>>>> "Daniel" =3D=3D Daniel James <wastebasket@nospam.aaisp.org> writes:

    Daniel> In article news:<erh93k$gr8$1@sagnix.uni-muenster.de>,
    Daniel> Martin Hierholzer
    Daniel> wrote:
    >> I agree. But if you have never learned a programming language
    >> before, it will be really hard to learn C++ (or any other
    >> object oriented language). You should have a more or less
    >> advanced understanding of common programming structures like
    >> "if", "for", "while" etc. before trying to understand object
    >> oriented programming.

    Daniel> I think that's completely untrue. Knowing C tends to make
    Daniel> you look for a C style solution in C++ (using "if", "for",
    Daniel> and "while", etc.)

Not necessarily.  It  depends on how well you've  learnt C++ (after C)
and how serious you're at the learning.


    Daniel> when the best (i.e. clearest, simplest, most readable and
    Daniel> maintainable) solutions in C++ may use features that C
    Daniel> doesn't have (such as algorithms). If anything it is
    Daniel> necessary to *forget* C to become a good C++ programmer.

My  first language  was  Applesoft  BASIC (on  an  Apple II).   Second
language was  6502 assembly.  Third language: Pascal.   Then, I learnt
some LOGO, and  switched to PC platform.  Used  Turbo Pascal and Turbo
C.  My first  exposure to an OO language was a  later version of Turbo
Pascal.  But  then, I started  learning C++ --  some 6 years  after my
first BASIC programs.

At  the  beginning  of learning  C++,  I  really  did what  you  said:
resorting  to   procedural  approaches  very  often,   because  of  my
procedural programming  background.  It took  years to get used  to OO
thinking.   But it's  completely  do-able.   I can  use  STL to  write
compact  code,  and  code  a  lot  in  Java  nowadays.   I  often  use
templates/generics, too.   But I still  haven't forgotten C.   I still
use C occasionally for kernel-hacking and for performance.

So, it's  possible to know C  and at the  same time become a  good C++
program.  It  just takes  time and effort  -- something that  this new
generation  are  reluctant  to  invest,  for no  reasons  that  I  can
understand.


The problem you mentioned usually  boils down to the learner being not
serious enough when he makes the  transition from C to C++.  "It looks
like C, so  there is little new to learn" is  the biggest mistake they
make in their  mind.  That makes them not  learn seriously.  The makes
them spend little  effort to learn the OO  concepts.  They don't start
to  think  in an  OO  way.  They  don't  really  understand why  those
features are there  in an OO language.  They just use  C++ as a better
and  neater C  compiler.  And  that's all  they learnt.   They haven't
really learnt OO.



    Daniel> There are some very good books that aim to teach C++ from
    Daniel> scratch without using the legacy baggage of C as a
    Daniel> crutch. Take a look at /Accelerated C++/ by Andy Koenig
    Daniel> and Barbara Moo, or "You Can Program in C++" by Francis
    Daniel> Glassboro as examples (I confess I haven't read Francis's
    Daniel> book myself but it has a good reputation).





--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
2/24/2007 1:52:57 AM
>>>>> "Milan" =3D=3D Milan Babuskov <mbabuskov@yahoo.com> writes:

    Milan> - use const instead of #define=20
    Milan> - use templates instead of macros

Yeah!


    Milan> - use singleton instead of global variables (although this
    Milan> can be done in C as well)=20

No.  I don't agree on this.

To me,  singletons are  just another kind  of global  variables.  Just
that it is not identified by a simple identifier, but by a class name.
It is still a globally accessible object.

Using such  global things  is usually problematic  when you  start use
more than 1 threads in your program.  Those threads may compete on the
use (or  worse on  modifying) those global  objects.  This  results in
race conditions and hence incorrect and non-deterministic behaviour.

The correct  way to  do it  is: don't use  singletons (unless  you can
write a 10 page paper convincing me why you absolutely need to do it).
Put all  your "global"  objects into a  wrapper class  called Context.
Create and initialize  an instance of Context in  your main() and pass
it to  all those classes that  need to access  those "global" objects.
By introducing this Context  object, you have effectively deglobalized
those  global  objects.   (Without  the Context  object,  you're  just
exploiting  the  runtime process-context  as  your convenient  Context
object.)  What's  the gain?   Firstly, by inspecting  the code  of the
Context class, you immediately know what deglobalized "global" objects
your program  accesses.  Secondly,  if you need  to make  your program
multithreaded  later, you  can easily  create additional  instances of
Context and assign one to each thread.  In the simpliest scenario, you
just need to modify your main()  to add a loop that repeatedly creates
a new thread,  pass a new instance  of Context to it and  kick it off.
(The Context objects  are then thread-local.)  No need  to search your
program to locate all those global objects.


    Milan> - use other design patterns. Although it is possible with
    Milan> C, it's natural to do it with C++.

Or any other OO language.   But isn't that because people usually talk
about design patterns in OO terms?



--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
2/24/2007 2:06:03 AM
LEE Sau Dan writes:
> Use the right tools for the task at hand.  Using C for OO is possible
> (look at the Xt library...

I have.  "Shudder".
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
0
John
2/24/2007 2:19:59 AM
>>>>> "Carlos" =3D=3D Carlos Moreno <cm_clcppm_7b8f93f186@mochima.com> writ=
es:

    Carlos> It's supposed to mean what it means: the beginner is
    Carlos> overwhelmed with little details that have nothing to do
    Carlos> with the basic notion that they're trying to absorve ---
    Carlos> the notion of using a statement to print the contents of a
    Carlos> variable is already "enough magic" in the mind of a
    Carlos> beginner --- throw the fact that they have to match the %d
    Carlos> %f etc. to the data type, and the whole thing feels like a
    Carlos> minefield in the mind of the beginner.

FYI, Sun has introduce printf() in Java 1.5.  You should ask: why?

see: http://java.sun.com/j2se/1.5.0/docs/api/java/io/PrintWriter.html#print=
f(java.lang.String,%20java.lang.Object...)



--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
2/24/2007 2:27:43 AM
In article news:<87y7mouxs6.fsf@informatik.uni-freiburg.de>, LEE Sau Dan 
wrote:
> Daniel> I think that's completely untrue. Knowing C tends to make
>     Daniel> you look for a C style solution in C++ (using "if", "for",
>     Daniel> and "while", etc.)
> 
> Not necessarily.  It  depends on how well you've  learnt C++ (after C)
> and how serious you're at the learning.

You're missing my point ... I'm talking about what people who are going 
through the process of learning C++ tend to do -- they, by definition, 
are people who have NOT already learnt C++ well. 

If they already know how to tackle a problem in C their instinct is to 
write the C solution (which is also valid in C++) and so not look for a 
more C++-like approach, and so not learn the C++ approach. This impairs 
the learning process. If they're serious about learning C++ they will try 
to work around this impediment (with varying degrees of success), but the 
tendency of the mind to run along well-worn paths exists for everyone.

> So, it's  possible to know C  and at the  same time become a  good C++
> program.  It  just takes  time and effort  -- something that  this new
> generation  are  reluctant  to  invest,  for no  reasons  that  I  can
> understand.

Yes, sure. I actually think that the best C++ programmers do also know C 
-- but I'd argue that the most natural way to learn is to learn the 
language with the higher-level abstractions (C++) first, and then learn 
to drill down into the details as and when you need to. Those of us who 
learnt C when there was no C++ perforce did this the hard way, there's no 
need to inflict that on future generations.

> The problem you mentioned usually  boils down to the learner being not
> serious enough when he makes the  transition from C to C++.  "It looks
> like C, so  there is little new to learn" is  the biggest mistake they
> make in their  mind.  That makes them not  learn seriously.

That is more-or-less what I said ... I didn't insult the learner by 
saying he wasn't "serious" about learning, I just said that it's easy to 
be lazy and do things the way you already know rather than taking the 
trouble to learn.

Th point is that if you don't already know C you don't have the option.

> They don't start to  think  in an  OO  way.  They  don't  really
> understand why  those features are there  in an OO language.

This is not (just) about OO -- but about using the higher-level 
constructs of the language as and when appropriate.

C++ is so much more than just an OO language (and in some ways rather 
less -- it does lack some features like reflection and introspection that 
are believed by some to be requirements for a truly OO language).

Cheers,
 Daniel.
 

0
Daniel
2/24/2007 12:15:58 PM
LEE Sau Dan wrote:

>     Carlos> After having taught the basic elements like variables,
>     Carlos> data types, if and related, loops, and maybe functions,
>     Carlos> teaching classes for simple/basic encapsulation is what
>     Carlos> makes most sense --- no operator overloading; no
>     Carlos> inheritance; not even destructors.
> 
> No inheritance?  Then no polymorphism,  either.  And why are you still
> using OO?
> 
> And you won't teach them templates/generics either?

Oh man ...  Have you been even *reading* a single word that I have
written????

templates/generics??  No, I do not teach them that *on the first
day* of class --- not even during the first week of class.

Please re-read the entire discussion and please this time *do
understand* that we're talking about ***beginning*** ....   Not
what you're going to do with the given language after you have
5 or 10 years of experience ....  We're talking *teaching* people
who don't even haev 5 to 10 *days* of programming experience.

Carlos
--
0
Carlos
2/24/2007 8:58:26 PM
Rui Maciel <rui.maciel@gmail.com> writes:
> Volodymyr M. Lisivka wrote:
>
>> KDE chose C++
>> for compatibility with proprietary QT toolkit from Trolltech. Feel the
>> difference.
>
> For your information Trolltech releases Qt under the GPL.
> They also sell licenses for Qt that enables developing proprietary
> applications but that doesn't cover up the fact that Qt is GPL and
> therefore as FOSS as it gets.
>
> So exactly what is that "difference" you incite others to "feel"?

Both of the original statements refer to past events and by the time
those past events took place, Qt was not GPL-licensed. So, whom are
you trying fool?
0
Rainer
2/25/2007 4:19:40 PM
Rainer Weikusat writes:
> Both of the original statements refer to past events and by the time
> those past events took place, Qt was not GPL-licensed. So, whom are you
> trying fool?

The original Qt license, while not GPL compatible, was free.  The problem
was that the KDE developers linked GPL code to Qt without the permission of
the authors of the GPL code and also licensed their own Qt-linked code
under the GPL without explicitly granting permission to link to Qt.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
0
John
2/25/2007 4:50:14 PM
Carlos Moreno <cm_clcppm_7b8f93f186@mochima.com> writes:
> Russell Shaw wrote:
>>> I think that's completely untrue. Knowing C tends to make you look
>>> for a C style solution in C++ (using "if", "for", and "while",
>>> etc.) when the best (i.e. clearest, simplest, most readable and
>>> maintainable) solutions in C++ may use features that C doesn't have
>>> (such as algorithms).
>> C++ has "algorithms"?
>
> Yes.  The C++ Standard Library has algorithms.  Searching, counting,
> traversal, binary search, sort, etc.  Very elegant and very powerful,
> IMHO.
>
> The previous poster was referring to the fact that given the problem
> of determining, say, the highest value in an array of ints, the
> solution using if's, for's, etc., would be:
>
> int pos_highest = 0;
> for (i = 0; i < array's size; i++)
> {
>     if (array[i] > array[pos_highest])
>         pos_highest = i;
> }
> int highest = array[pos_highest];

I bet the C you claim to teach to other people looks just like that.
Have considered trying with less noise and more function, eg

static int largest_of(int const *a, unsigned len)
{
        int max;

        max = a[--len];
        while (len--) if (a[len] > max) max = a[len];
        return max;
}                                    
[obviously assumes  len > 0]

At the expense of an additional pointer calculation, the loop can be
written with even less optical clutter:

	int const *e;
        int max;

        e = a + len;
        max = *a;
        while (++a < e) if (*a > max) max = *a

> Whereas we can count on a more elegant and mainly less error-prone
> solution using C++'s Standard Library max_element algorithm:

You are not really arguing about the 'error-proneness' of three lines
of code, are you?

> int highest = *max_element (strings.begin(), strings.end());
>
>
> True that this deviates a little bit from the previous comment, in
> that it really doesn't deal with object-oriented vs. non-OO ...  But
> it is still a handy example that illustrates rather nicely the
> principle.

It illustrates (nicely) the two-facedness of 'OO': While its
proponents claim to use it to model the problem domain more
adequately, what they usually do is to model the solution domain, ie
they build abstraction that correspond to (often perceveived)
programming problems and not to application problems.

[...]

> However, a valid argument in favor of that is:  the apprentice
> first learns to deal with the ideas at a high level --- they have
> to first understand that *what has to be done* is to determine
> the highest value, then do something with it;  no need to worry
> (as a beginner) with a larger amount of details.

You are (again!) constructing exercises that suit you. Instead of 'do
something with the largest value', the problem could as well be
'determine the largest value'. In this case, the 'apprentice' would
learn to traverse an array, which is certainlty a very basic 'skill'
he or she should be familar with, while in the C++ example, he would
learn nothing useful outside C++.

> Another valid argument in favor of this example is that it also
> forms the good habit of organizing code properly --- the beginner
> quickly learns to appreciate code that looks like pseudo-code
> and that expresses the idea of what's happening

Judging from real-world source code, it is to complicated for a
majority of people to even abstract to this degree and they usually
don't do it.

> --- it would likely lead to, as the apprentice gains more
> experience, writing code that is more modular, making good use of
> functions if using a procedural approach, or better class designs if
> in OO;  as opposed to wanting to write a program that has only one
> function called main, where all the details are right there.

But that is exactly what those 'apprentices' are going to do after
having escaped their teachers.
0
Rainer
2/25/2007 4:55:09 PM
LEE Sau Dan wrote:
> To me,  singletons are  just another kind  of global  variables.  Just
> that it is not identified by a simple identifier, but by a class name.
> It is still a globally accessible object.

Actually, I usually use static functions to get reference to global
objects. I forbit object creation (private constructor) and then do
something like:

Class S;

S& getS()
{
	return S::getInstance();
}

All other code uses getS() to get it. So I can alter this easily.

> Secondly,  if you need  to make  your program
> multithreaded  later, you  can easily  create additional  instances of
> Context and assign one to each thread

The point of global variable is that *all* parts of program need a
single "registry" for some information. You can't separate it and have
additional instances as all parts of program need to share common data.
If you can separate it, then it isn't really a case for singleton.

>     Milan> - use other design patterns. Although it is possible with
>     Milan> C, it's natural to do it with C++.
> 
> Or any other OO language.   But isn't that because people usually talk
> about design patterns in OO terms?

I don't think so. Applying design patterns in C is much harder in terms
of sticking to it. If you work alone, then it's ok, but if you have
multiple programmers, it's much easier to prevent others from calling
code function or hiding some variables by making them private members of
a class. In C it's almost impossible to do. And that's just encapsulation.


-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
2/26/2007 10:14:09 AM
Daniel James wrote:
> Yes, sure. I actually think that the best C++ programmers do also know C 
> -- but I'd argue that the most natural way to learn is to learn the 
> language with the higher-level abstractions (C++) first, and then learn 
> to drill down into the details as and when you need to. Those of us who 
> learnt C when there was no C++ perforce did this the hard way, there's no 
> need to inflict that on future generations.

I agree with this.


-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
2/26/2007 10:16:12 AM
Roger Leigh wrote:
> Or read the code and see the difference.  GTK+ and GNOME are a
> poorly-maintained buggy mess due to all the brain damaged stupidity.
> If they were to rewrite it all in C++, based on the existing
> Gtkmm/Gnomemm APIs, it might be worth considering once more.  In the
> meantime, Qt is probably the safer choice.

This is one of the main reasons why I use wxWidgets to write GTK+ 
applications. So yes, C++ development of Gtk+ apps is possible.

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
2/26/2007 10:18:08 AM
LEE Sau Dan wrote:
> 
> No.  You're comparing apples and oranges.
> 
> Church's  thesis  says  that all  Turing-complete  language  can
> express  the same  class of  algorithms and  solve the  same  class of
> problems.  It's about *computability*.

You *must* be joking... aren't you ? :)

> True.  Use the  right tools for the  task at hand.  Using C  for OO is
> possible (look  at the  Xt library, or  the linux kernel).   It's just
> less convenient than C++.  Not impossible.

Which means that I am right. So, you just said A and not(A) in the same
mail... therefore, "woof", you will disappear in a cloud of pure logic. :)

PS: Sorry, but I can't be serious with such arguments. :o)

Regards
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Lib�ration  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
2/26/2007 10:43:54 AM
Milan Babuskov <mbabuskov@yahoo.com> writes:
> Rainer Weikusat wrote:
>> This is a statement containing two assertions, namely
>> 	a) people who know C tend to avoid using the C++ standard
>> 	   library
>
> Or at least it takes time to move to it. Four years into C++ I was
> still using printf, before I switched to std::cout.

There is actually a reason to prefer printf over the native C++-I/O,
namely, it helps I18N (insofar one considers that to be a goal to
achieve).

>> 	b) if the C++ standard library can be used, using it is
>>            sui generis the best way to solve any particular problem
>
> "The best" is hard to prove, but it is certainly better to use some
> string class instead of char *.

I don't think so. For me, the std::string showstopper has always been
that it is not guaranteed that its representation is compatible to the
one system calls (or calls to C library routines, although I consider
that to be less important) need, eventually necessitating an internal
copy, which, in turn, means it may sensible to do an explicit copy if
caching could benefit somehow, which, in turn, just reintroduces plain
C string handling. Additionally, string operations I do in C are
usually fairly trivial and I use languages with more stuff happening
automatically (like all of memory management) than C++ if I need
non-trivial ones. 

>>>If  anything it is necessary to *forget* C to become a good C++
>>>programmer.
>> So, we (participiants of this thread) have the same nonsense again,
>> still without reason and still without some sensible definition of
>> what exactly comprises 'a good C++-programmer'.
>
> I believe it's all about object-oriented way of thinking and some
> other minor stuff:

At the 'ground' level, OO (in C++) is just a clever trick to make people
use codepointers who otherwise won't for a variety of reasons (there
is more in it and sometimes, the concept of object hierarchies is
really useful, but that can be done in C sufficiently as well).

> - use const instead of #define

Even in C, using the preprocessor for integer constants should be
considered bad practice. They can be done with enum as well, assuming
one can get over the Pascal/ Ada nonsense concept of enumerated types
(which are nothing but 'integer constants that won't behave like
integer constants towards arithmetic operators'), and doing them with
enum avoids nasty surprise caused by unintended text substituions (eg
in function names).

[...]

> - use singleton instead of global variables (although this can be done
> in C as well)

A 'singleton' is a Java-originated way of kludging around the Jave
limitation of not being able to express the concept of a 'subsystem'
(eg a thing that is logically separate from the other code, provides a
somewhat abstract interface and should exist only once in the whole
program).

> - use other design patterns. Although it is possible with C, it's
> natural to do it with C++.

'Design patterns' are (like 'codepointers') just best practices
smuggled cleverly past the average programmers' desire to principally
never do something that can be considered sensible, but rather choose
the most complicated and contorted way that can be chosen easily.

This is all IMO, of course.
0
Rainer
2/26/2007 12:19:52 PM
Roger Leigh <${rleigh}@invalid.whinlatter.ukfsn.org.invalid> writes:
> "Volodymyr M. Lisivka" <vlisivka@gmail.com> writes:
>>> I believe that a lot of gnome stuff is c and kde stuff tends to be
>>> c++ is that correct?
>>
>> Yes. Gnome project chose C for portability across UNIX-es.
>
> We need to be careful with GTK+ and GNOME use of "C".  If you want to
> write programs in C for GTK+/GNOME, you'll need to know C++ very well,
> right down to the implementation details of vtables and
> typeinfo/dynamic_cast<>, so you can then reinvent them in C.

If you want to implement a C++-compiler as translator to C, you need
to know enough about certain language features of C so that you are
able to implement things like 'vtables' in C. You don't need any
knowledge of C++ to use any C language feature. 

> That's because they replicate, by hand in C, its own type and object
> system, GObject.  It's pretty horrible,

"because I say so" ?

> and for the programmer a wonderful source of bugs, since the
> compiler type checking is woefully adequate

Not spectacularly worse than it ususally is for advanced C
programming. 

> due to the abuse GObject inflicts on the C language.

It is not 'an abuse of C' to use language features of C to implement
useful things (like late binding).

[...]

>> KDE chose C++ for compatibility with proprietary QT toolkit from
>> Trolltech.  Feel the difference.
>
> Or read the code and see the difference.  GTK+ and GNOME are a
> poorly-maintained buggy mess due to all the brain damaged stupidity.

If you resort to name calling, that is a strong hint that you haven't
any better arguments, and that you just plan to preach to the choir,
anyway ... (I dislike GTK+ as well, but I have no problems stateting
that 'I dislike it' instead of 'it is so ...').
0
Rainer
2/26/2007 2:30:33 PM
Rainer Weikusat wrote:
>>Or at least it takes time to move to it. Four years into C++ I was
>>still using printf, before I switched to std::cout.
> 
> There is actually a reason to prefer printf over the native C++-I/O,
> namely, it helps I18N (insofar one considers that to be a goal to
> achieve).

Makes sense.

>>>	b) if the C++ standard library can be used, using it is
>>>           sui generis the best way to solve any particular problem
>>
>>"The best" is hard to prove, but it is certainly better to use some
>>string class instead of char *.
> 
> I don't think so. For me, the std::string showstopper has always been
> that it is not guaranteed that its representation is compatible to the
> one system calls

One of the reasons why I don't use std::string in some of programs where 
it is important. I wrote my own MString class, tailored for the task at 
hand. But for most stuff, regular std::string is quite enough.

> Additionally, string operations I do in C are
> usually fairly trivial

 From my POV, string operations are least of the problem. There is 
always a chance to get buffer overflow, especially when multiple 
developers are developing on the same code base, but don't share 
each-other's assumptions of how some part of the system should work.

(probably not so good) example: Someone could make char[2000] buffer for 
something and build an entire set of functions on it. Other developers 
take that for granted and work on it. Then someone else joins the team, 
goes into that char[2000] code - examines the area around it, and 
everything seems fine. Ok, we don't really need 2000, in fact 100 seems 
to does it just fine... He changes it... Nothing happens for 3 months, 
before you see some strange application behavior at one of your clients. 
All other 50 clients work fine... so you replace RAM, and try other 
stuff...etc. Probably not so good example (real world problems are 
non-trivial), but you get the idea.

I'd always sacrifice a little of efficiency for a lot of robustness.

> At the 'ground' level, OO (in C++) is just a clever trick to make people
> use codepointers who otherwise won't for a variety of reasons (there
> is more in it and sometimes, the concept of object hierarchies is
> really useful, but that can be done in C sufficiently as well).

But you cannot (for example) enforce encapsulation in C. If you have a 
team of programmers, and you have newbies as well, who don't understand 
stuff too much, it's easy for them to forget about some rule and just 
use the "internal" variable of the class. Later, when you change the 
interface, it could mean disaster.

>>- use const instead of #define
> 
> Even in C, using the preprocessor for integer constants should be
> considered bad practice. They can be done with enum as well

Yes, ok. Not a real C++ advantage.

> A 'singleton' is a Java-originated way of kludging around the Jave
> limitation of not being able to express the concept of a 'subsystem'
> (eg a thing that is logically separate from the other code, provides a
> somewhat abstract interface and should exist only once in the whole
> program).

Aren't you referring to namespaces here?

> 'Design patterns' are (like 'codepointers') just best practices
> smuggled cleverly past the average programmers' desire to principally
> never do something that can be considered sensible, but rather choose
> the most complicated and contorted way that can be chosen easily.

Agreed. However, most of us has to deal with average programmers simply 
because of the fact that there isn't enough excellent programmers in the 
world and there is a lot of work to be done.

> This is all IMO, of course.

ditto.

-- 
Milan Babuskov
http://swoes.blogspot.com
0
Milan
2/26/2007 2:32:59 PM
Emmanuel Fleury <emmanuel.fleury@labri.fr> writes:

> LEE Sau Dan wrote:
> > 
> > No.  You're comparing apples and oranges.
> > 
> > Church's  thesis  says  that all  Turing-complete  language  can
> > express  the same  class of  algorithms and  solve the  same  class of
> > problems.  It's about *computability*.
> 
> You *must* be joking... aren't you ? :)

I don't see an error there...

> > True.  Use the  right tools for the  task at hand.  Using C  for OO is
> > possible (look  at the  Xt library, or  the linux kernel).   It's just
> > less convenient than C++.  Not impossible.
> 
> Which means that I am right. So, you just said A and not(A) in the same
> mail... therefore, "woof", you will disappear in a cloud of pure logic. :)

No, he's pointing out that two completely different things are being
discussed.  So you might say that he's said both A and not(B) in the
same post, as part of saying A != B.
0
Joe
2/26/2007 3:34:38 PM
Joe Pfeiffer wrote:
> Emmanuel Fleury <emmanuel.fleury@labri.fr> writes:
> 
>> LEE Sau Dan wrote:
>>> No.  You're comparing apples and oranges.
>>>
>>> Church's  thesis  says  that all  Turing-complete  language  can
>>> express  the same  class of  algorithms and  solve the  same  class of
>>> problems.  It's about *computability*.
>> You *must* be joking... aren't you ? :)
> 
> I don't see an error there...

Damn, they are several !!!

Regards
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Lib�ration  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
2/26/2007 5:33:00 PM
--=-=-=
Content-Transfer-Encoding: quoted-printable

Rainer Weikusat <rainer.weikusat@sncag.com> writes:

> Milan Babuskov <mbabuskov@yahoo.com> writes:
>> Rainer Weikusat wrote:
>>> This is a statement containing two assertions, namely
>>> 	a) people who know C tend to avoid using the C++ standard
>>> 	   library
>>
>> Or at least it takes time to move to it. Four years into C++ I was
>> still using printf, before I switched to std::cout.
>
> There is actually a reason to prefer printf over the native C++-I/O,
> namely, it helps I18N (insofar one considers that to be a goal to
> achieve).

Not in 2007.  We now have boost::format for type-safe printf-like
formatted output, which works fantastically with e.g. gettext, is
superior feature-wise to printf, and works with iostreams.

> I don't think so. For me, the std::string showstopper has always been
> that it is not guaranteed that its representation is compatible to the
> one system calls (or calls to C library routines, although I consider
> that to be less important) need, eventually necessitating an internal
> copy, which, in turn, means it may sensible to do an explicit copy if
> caching could benefit somehow, which, in turn, just reintroduces plain
> C string handling.

Can't you just use the string::c_str() method when you need a C
string?  It usually doesn't involve any copy at all, and in nearly all
cases will be just as efficient, if not more efficient, than the
equivalent C string handling code.

>>>>If  anything it is necessary to *forget* C to become a good C++
>>>>programmer.
>>> So, we (participiants of this thread) have the same nonsense again,
>>> still without reason and still without some sensible definition of
>>> what exactly comprises 'a good C++-programmer'.
>>
>> I believe it's all about object-oriented way of thinking and some
>> other minor stuff:
>
> At the 'ground' level, OO (in C++) is just a clever trick to make people
> use codepointers who otherwise won't for a variety of reasons (there
> is more in it and sometimes, the concept of object hierarchies is
> really useful, but that can be done in C sufficiently as well).

It really comes down not to whether one language can do certain
things, but a tradeoff between factors such as

=2D ease of use
=2D performance
=2D type safety

With a modern GCC, C++ support is now excellent, so I am now happy to
use it in almost all cases, where 5-6 years ago I wouldn't have been
keen at all.  The peformance is very good, and the extra type-safety
makes up for the steeper learning curve many times over.


=2D-=20
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF41UAVcFcaSW/uEgRAg4jAJ9wni39snc4Of/vwJ83iMEntit8awCeKmT1
dVPhOcu6Qxgf15k+gxJMvxg=
=sbO4
-----END PGP SIGNATURE-----
--=-=-=--
0
Roger
2/26/2007 9:45:34 PM
Roger Leigh <${rleigh}@invalid.whinlatter.ukfsn.org.invalid> writes:
> Rainer Weikusat <rainer.weikusat@sncag.com> writes:
>> Milan Babuskov <mbabuskov@yahoo.com> writes:
>>> Rainer Weikusat wrote:
>>>> This is a statement containing two assertions, namely
>>>> 	a) people who know C tend to avoid using the C++ standard
>>>> 	   library
>>>
>>> Or at least it takes time to move to it. Four years into C++ I was
>>> still using printf, before I switched to std::cout.
>>
>> There is actually a reason to prefer printf over the native C++-I/O,
>> namely, it helps I18N (insofar one considers that to be a goal to
>> achieve).
>
> Not in 2007.  We now have boost::format for type-safe printf-like
> formatted output, which

is neither standard C++ nor standard C and consequently, not the 'native
C++-I/O' I was talking about.

>> I don't think so. For me, the std::string showstopper has always been
>> that it is not guaranteed that its representation is compatible to the
>> one system calls (or calls to C library routines, although I consider
>> that to be less important) need, eventually necessitating an internal
>> copy, which, in turn, means it may sensible to do an explicit copy if
>> caching could benefit somehow, which, in turn, just reintroduces plain
>> C string handling.
>
> Can't you just use the string::c_str() method when you need a C
> string?  It usually doesn't involve any copy at all,

It may or may not, depending on a particular implementation. I wasn't
writing about particular implementations, but about what the language
defines, which, in this case, is 'nothing'. 

> and in nearly all cases will be just as efficient, if not more
> efficient, than the equivalent C string handling code.

It cannot be 'more efficient' generally, because it has to do the same
basic operations. Computers don't work by magic. Anything more
specific would again be comparing specific implementations of both
(and I can certainly write a CPU-specific assembly routine and use
that either from C++ or C that will outperform every version
implemented in some high level language for every specific test
someone can come up with, so, this is pointless).

>>>>>If  anything it is necessary to *forget* C to become a good C++
>>>>>programmer.
>>>> So, we (participiants of this thread) have the same nonsense again,
>>>> still without reason and still without some sensible definition of
>>>> what exactly comprises 'a good C++-programmer'.
>>>
>>> I believe it's all about object-oriented way of thinking and some
>>> other minor stuff:
>>
>> At the 'ground' level, OO (in C++) is just a clever trick to make people
>> use codepointers who otherwise won't for a variety of reasons (there
>> is more in it and sometimes, the concept of object hierarchies is
>> really useful, but that can be done in C sufficiently as well).
>
> It really comes down not to whether one language can do certain
> things,

A 'language' can do nothing. It's passive.

> but a tradeoff between factors such as
>
> - ease of use
> - performance
> - type safety
>
> With a modern GCC, C++ support is now excellent, so I am now happy to
> use it in almost all cases, where 5-6 years ago I wouldn't have been
> keen at all.

5-6 years ago, I was using g++ and had no reasons to complain about
that (and didn't expect to have them, either. Computer really don't
work by magic). 

> The peformance is very good, and the extra type-safety
> makes up for the steeper learning curve many times over.

I remember to actually have had a problem where stricter type-checking
than C has would have helped me insignficantly. That was in 2003.
0
Rainer
2/27/2007 10:34:05 AM
Roger Leigh wrote:
> Not in 2007.  We now have boost::format for type-safe printf-like

FWIW, I noticed that never versions of GCC do the type checking for 
printf by comparing the % placeholders with supplied datatypes.

> With a modern GCC, C++ support is now excellent, so I am now happy to
> use it in almost all cases, where 5-6 years ago I wouldn't have been
> keen at all.  The peformance is very good, and the extra type-safety
> makes up for the steeper learning curve many times over.

I agree with everything, but performance. Although it is much faster 
than earlier versions, and it supports precompiled headers, it's still 
5-6 times slower than commercial (Microsoft, Borland) C++ compilers.

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
2/28/2007 9:06:20 AM
Milan Babuskov <mbabuskov@yahoo.com> writes:
> Roger Leigh wrote:

[...]

>> With a modern GCC, C++ support is now excellent, so I am now happy to
>> use it in almost all cases, where 5-6 years ago I wouldn't have been
>> keen at all.  The peformance is very good, and the extra type-safety
>> makes up for the steeper learning curve many times over.
>
> I agree with everything, but performance. Although it is much faster
> than earlier versions, and it supports precompiled headers, it's still
> 5-6 times slower than commercial (Microsoft, Borland) C++ compilers.

Since there are no Microsoft or Borland C++ compilers for Linux,
comparions are impossible and your statement is
meaningless. Considering that CPUs really don't work with magic (all
compilers for a particular CPU have to output machine code containing
instructions drawn from the same instruction set), I doubt that it can
be correct and this generality, too.
0
Rainer
2/28/2007 10:38:31 AM
Rainer Weikusat wrote:
>>I agree with everything, but performance. Although it is much faster
>>than earlier versions, and it supports precompiled headers, it's still
>>5-6 times slower than commercial (Microsoft, Borland) C++ compilers.
> 
> Since there are no Microsoft or Borland C++ compilers for Linux,
> comparions are impossible and your statement is
> meaningless.

1. GCC exists for Windows. Compiling the same code with MinGW GCC is 
much slower than MS/Borland compiler.

2. There is various cross-platform code that you can compile. For 
example, compiling wxWidgets library and FlameRobin was my benchmark. 
And also other cross-platform projects I worked on, some of which don't 
even have a single #ifdef to differentiate among compilers or platforms.

3. I hope that when you write "compilers for Linux" don't mean the 
compiler to compile kernel itself, but rather compiler that "runs on Linux".

> Considering that CPUs really don't work with magic (all
> compilers for a particular CPU have to output machine code containing
> instructions drawn from the same instruction set), I doubt that it can
> be correct and this generality, too.

I'm not talking about speed of *generated* code. I'm talking about speed 
of *compiling*. Of course that CPU's don't work with magic, but compiler 
internal algorithms (used to parse and compile code) are subject to 
human ability to engineer that process. Both Borland's and Microsoft's 
have many optimizations in compiler logic that make it run less amount 
of code while producing the exectables.

The end product of compiling: executable, runs ok on all systems.


-- 
Milan Babuskov
http://www.flamerobin.org
0
Milan
2/28/2007 1:33:08 PM
Milan Babuskov wrote:
> 
> I'm not talking about speed of *generated* code. I'm talking about speed
> of *compiling*. Of course that CPU's don't work with magic, but compiler
> internal algorithms (used to parse and compile code) are subject to
> human ability to engineer that process. Both Borland's and Microsoft's
> have many optimizations in compiler logic that make it run less amount
> of code while producing the exectables.
> 
> The end product of compiling: executable, runs ok on all systems.

What version of gcc are you speaking about ?

Version 4.1.x has drastically improved both in compilation speed and
optimization level.

Anyway, I would be interested to get a timing of GNU/Borland/Microsoft
compilers both in compile time and execution. If you know where to find
such comparison...

Regards
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Lib�ration  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
2/28/2007 1:50:07 PM
Emmanuel Fleury writes:
> Anyway, I would be interested to get a timing of GNU/Borland/Microsoft
> compilers both in compile time and execution.

Not, of course, using a published "benchmark"...
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
0
John
2/28/2007 2:20:04 PM
On 2007-02-28, Milan Babuskov <mbabuskov@yahoo.com> wrote:
> Rainer Weikusat wrote:
>>>I agree with everything, but performance. Although it is much faster
>>>than earlier versions, and it supports precompiled headers, it's still
>>>5-6 times slower than commercial (Microsoft, Borland) C++ compilers.
>> 
>> Since there are no Microsoft or Borland C++ compilers for Linux,
>> comparions are impossible and your statement is
>> meaningless.
>
> 1. GCC exists for Windows. Compiling the same code with MinGW GCC is 
> much slower than MS/Borland compiler.

If you're referring to iss GCC under Cygwin, I don't think you
can blame GCC.  I've run the exact same version of GCC
(compiled myself from the same sources) under Cygwin and Linux
on the same dual-boot machine.  The GCC running under
Cygwin+Windows was about 5X slower than it was running under
Linux.

-- 
Grant Edwards                   grante             Yow!  Yow! Is my fallout
                                  at               shelter termite proof?
                               visi.com            
0
Grant
2/28/2007 2:25:39 PM
Rainer Weikusat wrote:

>> - use singleton instead of global variables (although this can be done
>> in C as well)
> 
> A 'singleton' is a Java-originated way of kludging around the Jave
> limitation of not being able to express the concept of a 'subsystem'
> (eg a thing that is logically separate from the other code, provides a
> somewhat abstract interface and should exist only once in the whole
> program).

Use IoC container, e.g. Spring, and forget about singletons. Singleton 
is well known *anti*-pattern in Java.


BTW: What is "whole" program in application container? Whole 
application? Whole application container? Whole JVM?
0
Volodymyr
2/28/2007 7:13:10 PM
Grant Edwards wrote:
>>1. GCC exists for Windows. Compiling the same code with MinGW GCC is 
>>much slower than MS/Borland compiler.
> 
> If you're referring to iss GCC under Cygwin

No, I'm referring to GCC under MinGW.

> I don't think you
> can blame GCC.  I've run the exact same version of GCC
> (compiled myself from the same sources) under Cygwin and Linux
> on the same dual-boot machine.  The GCC running under
> Cygwin+Windows was about 5X slower than it was running under
> Linux.

I know, that's why I switched to MinGW.

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/1/2007 9:16:04 AM
Emmanuel Fleury wrote:
>>I'm not talking about speed of *generated* code. I'm talking about speed
>>of *compiling*. Of course that CPU's don't work with magic, but compiler
>>internal algorithms (used to parse and compile code) are subject to
>>human ability to engineer that process. Both Borland's and Microsoft's
>>have many optimizations in compiler logic that make it run less amount
>>of code while producing the exectables.
>>
>>The end product of compiling: executable, runs ok on all systems.
> 
> What version of gcc are you speaking about ?
> 
> Version 4.1.x has drastically improved both in compilation speed and
> optimization level.

Well, I have to admit I didn't try 4.1.x series yet. I do use 3.4.4 and 
4.0.x series on daily basis.

> Anyway, I would be interested to get a timing of GNU/Borland/Microsoft
> compilers both in compile time and execution. If you know where to find
> such comparison...

Well, I'm downloading 4.1.2 right now, so I'll probably give it a go 
this evening.

As for some older benchmark, take a look here:

http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html


-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/1/2007 9:22:41 AM
Milan Babuskov <mbabuskov@yahoo.com> writes:
> Rainer Weikusat wrote:
>>>I agree with everything, but performance. Although it is much faster
>>>than earlier versions, and it supports precompiled headers, it's still
>>>5-6 times slower than commercial (Microsoft, Borland) C++ compilers.
>> Since there are no Microsoft or Borland C++ compilers for Linux,
>> comparions are impossible and your statement is
>> meaningless.
>
> 1. GCC exists for Windows.

This is a Linux newsgroup. 

[...]

> I'm not talking about speed of *generated* code. I'm talking about
> speed of *compiling*. Of course that CPU's don't work with magic, but
> compiler internal algorithms (used to parse and compile code) are
> subject to human ability to engineer that process. Both Borland's and
> Microsoft's have many optimizations in compiler logic that make it run
> less amount of code while producing the exectables.

Maybe, maybe not. In any case, both compilers are (or were originally)
developed to be sold to developers developing for Windows, which means
that it is more than likely that they have been tuned to execute fast
on this particular OS, while gcc hasn't.
0
Rainer
3/1/2007 9:54:54 AM
Milan Babuskov wrote:
> Emmanuel Fleury wrote:
>> What version of gcc are you speaking about ?
>>
>> Version 4.1.x has drastically improved both in compilation speed and
>> optimization level.
> 
> Well, I'm downloading 4.1.2 right now, so I'll probably give it a go 
> this evening.

Hoping to gain something I did it right away. Here are the results:

Configuration:
Pentium4 3GHz
512MB RAM
Slackware 10.2 running 2.6.13 kernel


1. wxWidgets 2.8.0 taken from .tar.bz2 archive on wxWidgets.org website, 
configured with:

../configure --disable-debug --disable-shared --disable-unicode --enable-gtk2

Results (measured with "time -p make"):

GCC 4.1.2
real 484.04
user 405.60
sys 23.94

GCC 3.4.4
real 476.03
user 387.29
sys 30.94


2. FlameRobin, current HEAD from Subversion repository (see 
www.flamerobin.org), configured with:

.../configure --disable-debug --disable-shared

GCC 4.1.2
real 270.24
user 242.25
sys 11.06

GCC 3.4.4
real 241.22
user 219.90
sys 11.88


I also took some time to release various CHANGES files for GCC, and I 
didn't find a single place where it would say that compilation time has 
improved. There are improvements in compiled code itself, but as you can 
see the compilation speed itself hasn't changed significantly.

If we figure in my old tests of GCC 3.4.4 versus Borland/Microsoft 
compiler, I can safely state that GCC 4.1.2 is still much slower than 
those two.

Please note that all of this are tests on C++ code. I find GCC to be on 
par with other compilers when compiling C code.

-- 
Milan Babuskov
http://www.flamerobin.org
0
Milan
3/1/2007 12:29:25 PM
Rainer Weikusat wrote:
>>1. GCC exists for Windows.
> 
> This is a Linux newsgroup. 

So what?

You seem to be a Linux zealot who won't admit that GCC is slow and it 
should be improved. If we are satisfied with status quo, we will never 
see progress. GCC is slow and since other compilers are faster than 
there is suerly a way to improve it. Instead of defending the slowness 
with some arguments it would be better to search for ways to make it faster.

> Maybe, maybe not. In any case, both compilers are (or were originally)
> developed to be sold to developers developing for Windows, which means
> that it is more than likely that they have been tuned to execute fast
> on this particular OS, while gcc hasn't.

They are still many times faster than GCC on Linux - compiling the same 
code!

If you knew anything about compilers you would know that they don't make 
code for Windows or Linux, but for CPUs. Both GCC and MSVC produce the 
bunch of binary instructions that will run on your Pentium or whatever 
processor. Compiler is all about translating C++ code into binary. Now, 
there are various formats of executables (.exe, ELF, ...) but the main 
bottleneck of compilers is not writing code to disk on those formats. 
It's rather crunching a lot of code in .h and .cpp files from something 
meaningful to humans into something meaningful to CPU.


-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/1/2007 12:50:11 PM
Milan Babuskov <mbabuskov@yahoo.com> writes:
> Rainer Weikusat wrote:
>>>1. GCC exists for Windows.
>> This is a Linux newsgroup.
>
> So what?

Simply put, your ramblings about how wonderful commercial compilers
for Windows are are totally off topic here. I don't care. I don't use
Windows. I don't develop for Windows. I don't discuss Windows.

> You seem to be a Linux zealot who won't admit that GCC is slow and it
> should be improved.

Additionally, I am not a compiler developer and don't plan to become
one (unless someone pays me to, of course). If you think you can
improve gcc, be my guest. If you think it badly needs improvement, try
one of the associated mailing lists. To me, this is a sufficiently
well working tool. 

[...]

>> Maybe, maybe not. In any case, both compilers are (or were originally)
>> developed to be sold to developers developing for Windows, which means
>> that it is more than likely that they have been tuned to execute fast
>> on this particular OS, while gcc hasn't.
>
> They are still many times faster than GCC on Linux - compiling the
> same code!

And I can go faster upstairs than even the fastest car (comparison is
about as sensible). 
0
Rainer
3/1/2007 1:07:10 PM
I wrote:
> Configuration:
> Pentium4 3GHz
> 512MB RAM
> Slackware 10.2 running 2.6.13 kernel

Ok, same computer using Windows XP:

wxWidgets 2.8.0
---------------
GCC 4.1.2    484.04 sec
GCC 3.4.4    476.03 sec
Borland 5.5   83.16 sec

FlameRobin
----------
GCC 4.1.2    270.24 sec
GCC 3.4.4    241.22 sec
Borland 5.5   48.77 sec


I don't have Microsoft's compiler and I don't want to download and 
install it just for this.

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/1/2007 1:46:28 PM
Rainer Weikusat wrote:
> Simply put, your ramblings about how wonderful commercial compilers
> for Windows are are totally off topic here. I don't care. I don't use
> Windows. I don't develop for Windows. I don't discuss Windows.

My "ramblings" are not about how wonderful commercial compilers for 
Windows are, but how GCC should be improved.

>>They are still many times faster than GCC on Linux - compiling the
>>same code!
> 
> And I can go faster upstairs than even the fastest car (comparison is
> about as sensible). 

Rabbits eat carrots (that adds to discussion as much as your sentence).

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/1/2007 3:01:53 PM
On Thu, 01 Mar 2007 14:46:28 +0100, Milan Babuskov wrote:

 > I wrote:
 >> Configuration:
 >> Pentium4 3GHz
 >> 512MB RAM
 >> Slackware 10.2 running 2.6.13 kernel
 >
 > Ok, same computer using Windows XP:
 >
 > wxWidgets 2.8.0
 > ---------------
 > GCC 4.1.2    484.04 sec
 > GCC 3.4.4    476.03 sec
 > Borland 5.5   83.16 sec
 >
 > FlameRobin
 > ----------
 > GCC 4.1.2    270.24 sec
 > GCC 3.4.4    241.22 sec
 > Borland 5.5   48.77 sec

How are you running gcc on Windows: cygwin, mingw, etc.? What
optimization level? Note that there are fast compilers for Linux too (if
you don't care about architecture independence or code efficiency):

Compiler        Time(s) lines/second    MBytes/second
TinyCC 0.9.22   2.27    859000          29.6
GCC 3.2 -O0     20.0    98000           3.4

Compilation time includes compilation, assembly and linking.

The latest version of tcc has support for "the Windows target".

Bob T.
0
Bob
3/1/2007 3:51:35 PM
"Volodymyr M. Lisivka" <vlisivka@gmail.com> writes:
> Rainer Weikusat wrote:
>>> - use singleton instead of global variables (although this can be done
>>> in C as well)
>> A 'singleton' is a Java-originated way of kludging around the Jave
>> limitation of not being able to express the concept of a 'subsystem'
>> (eg a thing that is logically separate from the other code, provides a
>> somewhat abstract interface and should exist only once in the whole
>> program).
>
> Use IoC container, e.g. Spring, and forget about singletons. Singleton
> is well known *anti*-pattern in Java.

A 'singleton' is always something that should be avoided if the
language offers the option to (which C++ does). The very purpose of
having a 'class' in the first place is because multiple instance of it
may be needed. If multiple instances are not only not needed but must
not be created, the 'class' serves just as an obfuscation layer.

> BTW: What is "whole" program in application container? Whole
> application? Whole application container? Whole JVM?

The 'whole program' is what cannot exist several times within a
single process.
0
Rainer
3/1/2007 5:26:22 PM
In article news:<k22jb4-ln1.ln1@milanws.saruman.dnsalias.org>, Milan 
Babuskov wrote:
> GCC 3.4.4    476.03 sec
> Borland 5.5   83.16 sec

Doesn't prove a lot, really ... gcc is a much more correct compiler than 
bcc. I'd rather have good ISO C++ compliance and bug-free code than a fast 
compile!

I note, also, that you're compiling wxWidgets ... What are you actually 
building, here the libraries or an application? In my own experience the 
wxWidgets libraries take a lot longer than that to compile.

If you *are* compiling the libraries you must be aware that a number of 
options are controlled by the contents of the setup.h file for your 
compiler. If you are building a lot of templated library code for gcc 
(which can handle the templates) but not for bcc (which probably can't) 
that would account for a big difference in speed.

I am surprised that you see so *much* difference, though.

Cheers,
 Daniel.
 

0
Daniel
3/2/2007 1:40:25 PM
Bob Tennent wrote:
>  > Ok, same computer using Windows XP:
>  >
>  > wxWidgets 2.8.0
>  > ---------------
>  > GCC 4.1.2    484.04 sec
>  > GCC 3.4.4    476.03 sec
>  > Borland 5.5   83.16 sec
>  >
>  > FlameRobin
>  > ----------
>  > GCC 4.1.2    270.24 sec
>  > GCC 3.4.4    241.22 sec
>  > Borland 5.5   48.77 sec
> 
> How are you running gcc on Windows: cygwin, mingw, etc.?

I'm not. Those figures show GCC on Linux and Borland on Windows.

> if
> you don't care about architecture independence or code efficiency

But I do.

> TinyCC 0.9.22   2.27    859000          29.6

Does it support all C++ stuff like templates for example?


-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/5/2007 9:20:38 AM
Daniel James wrote:
>>GCC 3.4.4    476.03 sec
>>Borland 5.5   83.16 sec
> 
> Doesn't prove a lot, really ... gcc is a much more correct compiler than 
> bcc. I'd rather have good ISO C++ compliance and bug-free code than a fast 
> compile!

Well, bugs are made in C++ code, compilers don't "invent" them. It's 
rather a problem in programmer than in compiler. Both GCC and BCC report 
useful sets of warnings and possible bugs in code. In fact, even though 
I develop with GCC, periodically I run my code throught BCC to check for 
some oddities.

> I note, also, that you're compiling wxWidgets ... What are you actually 
> building, here the libraries or an application? In my own experience the 
> wxWidgets libraries take a lot longer than that to compile.

Libraries. I wrote the exact "configure" line in one of my previous 
messages, and I also wrote what kind of computer I'm using. Yes, Borland 
compiles and links the entire wxWidgets library (in release, ANSI 
configuration) in just 83.16 on my Pentium4 3GHz machine.

> If you *are* compiling the libraries you must be aware that a number of 
> options are controlled by the contents of the setup.h file for your 
> compiler.

I am aware. That's why I compiled FlameRobin after that, which is an 
application written by me (and few other guys - it's open source) and 
has almost none #ifdef's for different platforms. Everyone who used both 
GCC and MSVC/BCC is a litte disappointed with GCC when it comes to time 
needed to compile C++ code.

> If you are building a lot of templated library code for gcc 
> (which can handle the templates) but not for bcc (which probably can't) 

BCC handles templates quite fine.

> that would account for a big difference in speed.
> I am surprised that you see so *much* difference, though.

Why not test yourself? BCC is freeware.

If I had enough knowledge about compiler internals and knew some ways to 
  make improvements, I would surely join GCC team and try to help.

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/5/2007 9:33:17 AM
Rainer Weikusat wrote:
> A 'singleton' is always something that should be avoided if the
> language offers the option to (which C++ does). The very purpose of
> having a 'class' in the first place is because multiple instance of it
> may be needed. If multiple instances are not only not needed but must
> not be created, the 'class' serves just as an obfuscation layer.

What about the need for encapsulation?

> The 'whole program' is what cannot exist several times within a
> single process.

So, following your line of reasoning, a 'whole program' should never be 
a class? I don't think Java guys would agree?

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/5/2007 9:35:21 AM
Milan Babuskov wrote:
[...]
>> TinyCC 0.9.22   2.27    859000          29.6
> 
> Does it support all C++ stuff like templates for example?

TinyCC's a C compiler, not a C++ compiler. (Incidentally, if anyone knows of a
C++ to C preprocessor like the old Cfront that still works, I'd love to know...)

(Also incidentally, http://tack.sf.net. I'm currently working on adding Linux
i386 support to it, which is more of a pain in the arse than you might think.)

-- 
┌── dg@cowlark.com ─── http://www.cowlark.com ───────────────────
│
│ "The first 90% of the code takes the first 90% of the time. The other 10%
│ takes the other 90% of the time." --- Anonymous
0
David
3/5/2007 11:00:23 AM
Milan Babuskov <mbabuskov@yahoo.com> writes:
> Rainer Weikusat wrote:
>> A 'singleton' is always something that should be avoided if the
>> language offers the option to (which C++ does). The very purpose of
>> having a 'class' in the first place is because multiple instance of it
>> may be needed. If multiple instances are not only not needed but must
>> not be created, the 'class' serves just as an obfuscation layer.
>
> What about the need for encapsulation?

The amount of coupling between different parts of a program depends on
the interfaces they use to communicate with each other. 'use' implies
that what actually matters is how the code is written, not how it
could have been written. A nice quote regarding this:

	       Perl does not enforce private and public parts of its
	       modules as you may have been used to in other languages
	       like C++, Ada, or Modula-17.  Perl doesn't have an
	       infatuation with enforced privacy.  It would prefer
	       that you stayed out of its living room because you
	       weren't invited, not because it has a shotgun.
               [perlmodlib(3pm)]

No amount of smoke and mirrors is going to really prevent code from
deliberately sabotaging the 'encapsulation' of something that exists
in the same address space at runtime. Apart from this theoretical
objection: If the only publically visible part of a subsystem is a set
of subroutine prototypes, the state is totally encapsulated (and more
encapsulated than ordinary private parts of a C++-class).

>> The 'whole program' is what cannot exist several times within a
>> single process.
>
> So, following your line of reasoning, a 'whole program' should never
> be a class? I don't think Java guys would agree?

"The Java guys" don't have another option except forcing everything to
ultimatively resolve to a class. That's a deficiency of the language.
0
Rainer
3/5/2007 12:34:25 PM
David Given wrote:
> Milan Babuskov wrote:
>>>TinyCC 0.9.22   2.27    859000          29.6
>>Does it support all C++ stuff like templates for example?
> 
> TinyCC's a C compiler, not a C++ compiler

Well, not much use then. I'm quite happy with GCC's speed when comiling 
C code.

> (Also incidentally, http://tack.sf.net. I'm currently working on adding Linux
> i386 support to it, which is more of a pain in the arse than you might think.)

:)

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/5/2007 3:23:39 PM
Rainer Weikusat wrote:
> Milan Babuskov <mbabuskov@yahoo.com> writes:
>>Rainer Weikusat wrote:
>>>A 'singleton' is always something that should be avoided if the
>>>language offers the option to (which C++ does). The very purpose of
>>>having a 'class' in the first place is because multiple instance of it
>>>may be needed. If multiple instances are not only not needed but must
>>>not be created, the 'class' serves just as an obfuscation layer.
>>
>>What about the need for encapsulation?
> 
> No amount of smoke and mirrors is going to really prevent code from
> deliberately sabotaging the 'encapsulation' of something that exists
> in the same address space at runtime.

Contrary, I find that it gives good guidelines to fellow programmers 
when they get into your code.

> If the only publically visible part of a subsystem is a set
> of subroutine prototypes, the state is totally encapsulated (and more
> encapsulated than ordinary private parts of a C++-class).

So, what is your suggestion if you have a rather complex "entity" with 
many interfaces to it?

For example, I have a singleton Database class in one of my programs. It 
has methods like connect(), disconnect() and other stuff related to 
transaction start, transaction end, etc. It has data members which hold 
internal state (connection object, vector of transaction objects, 
cursors, etc.). Application has such requirements that it only needs one 
database connection.

Now, without using classes, how would do what? Scatter database handling 
code in a bunch of functions that always need to pass the database 
connection state to each other? How would you make the database 
connection and transactions available? Use globals? Have them as static 
variables in functions that return them?

>>So, following your line of reasoning, a 'whole program' should never
>>be a class? I don't think Java guys would agree?
> 
> "The Java guys" don't have another option except forcing everything to
> ultimatively resolve to a class. That's a deficiency of the language.

Yes, I guess you're right.


-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/5/2007 3:45:47 PM
In article news:<bLSGh.52410$Da4.19682@newsfe6-gui.ntli.net>, David Given 
wrote:
> (Incidentally, if anyone knows of a C++ to C preprocessor like the
> old Cfront that still works, I'd love to know...)

Well, C++ is much more complex now, so a simple translator like CFront 
couldn't be expected to do a very good job of compiling it ... but there 
are C++ compilers that emit C as output. Comeau C++ does this and is 
readily (if not freely, as in beer) available:

http://www.comeaucomputing.com/

Cheers,
 Daniel.



0
Daniel
3/6/2007 11:31:24 PM
In article news:<un4tb4-q52.ln1@milanws.saruman.dnsalias.org>, Milan 
Babuskov wrote:
> Well, bugs are made in C++ code, compilers don't "invent" them.

Most C++ compilers *are* C++ code. Some have more bugs than others.

The Borland 5.5 compiler was pretty good in its day, but it was by no means 
bug-free and it is a pre-ISO-standard compiler with all the non-conformance 
that that implies.

> In fact, even though I develop with GCC, periodically I run my code
> throught BCC to check for some oddities.

It's always good to check one's code by running it through more than one 
compiler ... but using a compiler as old as that Borland one is not the 
most useful test imaginable.

> Yes, Borland compiles and links the entire wxWidgets library (in
> release, ANSI configuration) in just 83.16 on my Pentium4 3GHz machine.

Hmm. I've built wxMSW with Visual Studio 2005 and wxGTK with gcc on a 3GHz 
P4 ... I didn't time either of the builds but my impression is that it took 
several minutes.

What are your settings for, e.g.,  wxUSE_STL and wxUSE_STD_IOSTREAM (which 
default to 0, but I set to 1).

> I am aware. That's why I compiled FlameRobin after that, ...

OK, I can't (and won't) argue with that.

> BCC handles templates quite fine.

Not as fine as it ought. I've had some real problems trying to use STL 
bindings and algorithms. As I recall, I never things working 
satisfactorily.

> Why not test yourself? BCC is freeware.

I have a licensed copy (of BCB5 Pro), I used to use it quite a lot, but no 
longer do. Partly because of a shift in my interest towards linux, and 
partly because recent Visual Studio releases have a MUCH better Windows 
compile for client work. I really hope CodeGear can do something about 
that!

Cheers,
 Daniel.
 

0
Daniel
3/6/2007 11:31:25 PM
In article news:<87vehfoomm.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
> A nice quote regarding this:
> 
>    Perl does not enforce private and public parts of its
>    modules as you may have been used to in other languages
>    like C++, Ada, or Modula-17.  Perl doesn't have an
>    infatuation with enforced privacy.  It would prefer
>    that you stayed out of its living room because you
>    weren't invited, not because it has a shotgun.
>           [perlmodlib(3pm)]

... and that remark *really* misses the point of encapsulation.

Encapsulation is not there to force you to keep out of the living room, 
it's there to put a big sign saying "this is just our living room, you 
don't need to look in here to buy our stuff ... it's all on display in the 
shop".

IOW encapsulation is there to help the programmer by giving him less detail 
to worry about ... it's an aid, not an impediment (when correctly used, of 
course). It's a safety railing not a cage.

> No amount of smoke and mirrors is going to really prevent code from
> deliberately sabotaging the 'encapsulation'

No, of course not. You're not supposed to want or need to sabotage the 
encapsulation. If you feel you do need to sabotage it then it's probably 
been done badly.

Cheers,
 Daniel.

0
Daniel
3/6/2007 11:31:25 PM
Daniel James wrote:
>>Yes, Borland compiles and links the entire wxWidgets library (in
>>release, ANSI configuration) in just 83.16 on my Pentium4 3GHz machine.
> 
> Hmm. I've built wxMSW with Visual Studio 2005 and wxGTK with gcc on a 3GHz 
> P4 ... I didn't time either of the builds but my impression is that it took 
> several minutes.
> 
> What are your settings for, e.g.,  wxUSE_STL and wxUSE_STD_IOSTREAM (which 
> default to 0, but I set to 1).

I left everything at default. Just unpacked the archive and:

cd build/msw
make -f makefile.bcc BUILD=release RUNTIME_LIBS=static

> partly because recent Visual Studio releases have a MUCH better Windows 
> compile for client work.

Yes, other people told me that as well. I also find out that Borland's 
linker bombs out often when projects get bigger.

> I really hope CodeGear can do something about that!

I didn't try new Turbo C++, but reportedly nobody's been able to compile 
wxWidgets on it yet. So it doesn't interest me too much.

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/7/2007 9:25:23 AM
Daniel James <wastebasket@nospam.aaisp.org> writes:
> In article news:<87vehfoomm.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
>> A nice quote regarding this:
>> 
>>    Perl does not enforce private and public parts of its
>>    modules as you may have been used to in other languages
>>    like C++, Ada, or Modula-17.  Perl doesn't have an
>>    infatuation with enforced privacy.  It would prefer
>>    that you stayed out of its living room because you
>>    weren't invited, not because it has a shotgun.
>>           [perlmodlib(3pm)]
>
> .. and that remark *really* misses the point of encapsulation.

Considering that this not my text, you should perhaps move this
discussion to some perl related mailing list instead of pretending to
reply to me.

> Encapsulation is not there to force you to keep out of the living room, 
> it's there to put a big sign saying "this is just our living room, you 
> don't need to look in here to buy our stuff ... it's all on display in the 
> shop".

And that is roughly a copy of the parts of my posting that you kindly
deleted, which basically said that degrees of _coupling_ do not depend on
forced encapsulation by the language but on interface design and use.

So, what are you up to, precisely?

[...]

>> No amount of smoke and mirrors is going to really prevent code from
>> deliberately sabotaging the 'encapsulation'
>
> No, of course not. You're not supposed to want or need to sabotage the 
> encapsulation.

Ergo: Enforcement by $environment not an advantage.

If I am not very much mistaken, I wrote that already in the post you
pretend to be replying to.
0
Rainer
3/7/2007 9:47:46 AM
In article news:<87wt1twfjx.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
> Considering that this not my text, you should perhaps move this
> discussion to some perl related mailing list instead of pretending to
> reply to me.

You saw fit to post that text here, so I replied to you. My point was 
about encapsulation (which is fairly relevant to the discussion here) not 
about perl.

> > Encapsulation is not there to force you to keep out of the living
> > room, it's there to put a big sign saying "this is just our living
> > room, you don't need to look in here to buy our stuff ... it's all
> > on display in the shop".
> 
> And that is roughly a copy of the parts of my posting that you kindly
> deleted, which basically said that degrees of _coupling_ do not depend
> on forced encapsulation by the language but on interface design and
> use.

Sorry, what I wrote is not the same as what I understood by what you 
wrote. 

My point is that C++ encapsulation shouldn't be seen as a security 
mechanism -- it's not there to confound people deliberately try to 
circumvent the privacy of the non-public parts of a class, it's there to 
help those who are happy to honour the privacy of non-public parts of the 
class to write clearer and more maintainable code. What you seemed to be 
saying, though, was that C++ can enforce privacy as well.

I agree that it can, but I don't think that's the point.

Perhaps what you were getting at, though, is that by hiding the 
implementation of a class within another class (e.g. pImpl idiom) one can 
reduce the coupling between compilation units. That's another good point.

Cheers,
 Daniel.
 


0
Daniel
3/8/2007 11:45:36 AM
Daniel James <wastebasket@nospam.aaisp.org> writes:
> In article news:<87wt1twfjx.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
>> Considering that this not my text, you should perhaps move this
>> discussion to some perl related mailing list instead of pretending to
>> reply to me.
>
> You saw fit to post that text here, so I replied to you.

As I wrote, you didn't reply to me but to something I used as an
example.

>> > Encapsulation is not there to force you to keep out of the living
>> > room, it's there to put a big sign saying "this is just our living
>> > room, you don't need to look in here to buy our stuff ... it's all
>> > on display in the shop".
>> 
>> And that is roughly a copy of the parts of my posting that you kindly
>> deleted, which basically said that degrees of _coupling_ do not depend
>> on forced encapsulation by the language but on interface design and
>> use.
>
> Sorry, what I wrote is not the same as what I understood by what you 
> wrote. 
>
> My point is that C++ encapsulation shouldn't be seen as a security 
> mechanism -- it's not there to confound people deliberately try to 
> circumvent the privacy of the non-public parts of a class, it's there to 
> help those who are happy to honour the privacy of non-public parts of the 
> class to write clearer and more maintainable code.

The purpose of enforced access control is to control access, ie to
prevent what is not supposed to happen. That's why it's called
'encapsulation'. But you can have the same benefit by simply using
what is supposed to be the public interface of some module, no matter
if you are forced to use it (to some degree) by some language feature.
If you really want to break it, you can use the private parts of a
C++-Object as you see fit (for instance, by declaring a struct with a
compatible data layout and converting a pointer to the object to a
pointer to such a structure). If you don't want to break it, just
documenting which parts are supposed to be public is sufficient.

And occasionally, there is a real need for some clever hack that
technically constitutes module (or class) abuse. 
0
Rainer
3/8/2007 6:27:52 PM
Chris McDonald wrote, On 21.02.2007 11:33 Uhr:
>> It is possible to write object oriented code in any language.
> 
> Sorry, but this is completely untrue, and demonstrates a lack of
> understanding of what O-O programming is.

It all depends on the definitions...

Some of you might be interested by:

Object-Oriented Programming With ANSI-C
http://www.planetpdf.com/codecuts/pdfs/ooc.pdf

0
Olivier
3/8/2007 8:54:34 PM
LEE Sau Dan wrote, On 24.02.2007 3:06 Uhr:

> The correct  way to  do it  is: don't use  singletons (unless  you can
> write a 10 page paper convincing me why you absolutely need to do it).

Have a look at:
http://www-128.ibm.com/developerworks/library/co-single.html

The typical example given is a Logging class.

> Put all  your "global"  objects into a  wrapper class  called Context.
> Create and initialize  an instance of Context in  your main() and pass
> it to  all those classes that  need to access  those "global" objects.
[...]
> Secondly,  if you need  to make  your program
> multithreaded  later, you  can easily  create additional  instances of
> Context and assign one to each thread.

If you can do that, it was not proper to use a singleton in the first place.

0
Olivier
3/9/2007 12:16:08 AM
In article news:<87irdb380n.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
> > You saw fit to post that text here, so I replied to you.
> 
> As I wrote, you didn't reply to me but to something I used as an
> example.

You wrote "A nice quote regarding this:" as though you thought the passage 
you were quoting was (a) sensible, and (b) supportive of the argument you 
were trying to make. I merely exposed it for the piece of arrant idiocy 
that it is.

> The purpose of enforced access control is to control access, ie to
> prevent what is not supposed to happen. That's why it's called
> 'encapsulation'.

No, I don't agree. The thing that is called "encapsulation" is 
encapsulation. If it were enforced access control then it would be called 
"enforced access control". They are different animals.

There is more to encapsulation than merely defining public and private 
interfaces. Encapsulation can hide things from the compiler as well as from 
the programmer -- and so can reduce dependencies between modules and lead 
to better code clarity, simpler maintenance, and even improved compilation 
times. 

It matters not a jot the programmer may be able to access the private 
interfaces with a few malicious casts -- encapsulation isn't there to 
control access, it's there to remove unnecessary implementation detail from 
the bigger picture and to make it easier for everyone to focus on what 
matters.

Cheers,
 Daniel.
 



0
Daniel
3/9/2007 10:34:44 AM
Daniel James <wastebasket@nospam.aaisp.org> writes:
> In article news:<87irdb380n.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
>> > You saw fit to post that text here, so I replied to you.
>> 
>> As I wrote, you didn't reply to me but to something I used as an
>> example.
>
> You wrote "A nice quote regarding this:" as though you thought the passage 
> you were quoting was (a) sensible, and (b) supportive of the argument you 
> were trying to make.

I actually did so. Nevertheless, you were still replying to a piece of
perl documentation and not to some text I had written, and somebody
reading your reply can impossibly determine what the original context
of the quote was.

> I merely exposed it for the piece of arrant idiocy that it is.

You have done nothing of this sort. 

>> The purpose of enforced access control is to control access, ie to
>> prevent what is not supposed to happen. That's why it's called
>> 'encapsulation'.
>
> No, I don't agree.

This means that you are disputing the meaning of the word
'encapsulation', basically claiming that what you have after
'encapsulating' something is not supposed to be a single,
non-externally decomposible object.

> The thing that is called "encapsulation" is  encapsulation. If it
> were enforced access control then it would be called "enforced
> access control".

A fairly pointless execise in sophistry, because enforcing the
specified visibility rules is actually a language feature of C++ and
the perl quote you claim to have addressed was talking about 'enforced
privacy'.

So, the conclusion is that you basically missed the point completely.

0
Rainer
3/9/2007 11:20:58 AM
In article news:<87ejny3bol.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
> ... somebody reading your reply can impossibly determine what the
> original context of the quote was.

I quoted as much source as you did. Go and take another look at my 
posting: <VA.00001034.003e84a7@nospam.aaisp.org> 

> This means that you are disputing the meaning of the word
> 'encapsulation' ...

No, it means that I see the difference between encapsulation and access 
control -- which you apparently do not.

> A fairly pointless execise in sophistry, because enforcing the
> specified visibility rules is actually a language feature of C++ and
> the perl quote you claim to have addressed was talking about 'enforced
> privacy'.

Pay attention at the back!

Milan Babuskov wrote:
> What about the need for encapsulation?

... and you replied with that bit of trite perlish nonsense about 
enforcing access protection as though it had something to do with his 
question. I have been pointing out that the two are not the same -- and 
now *you* accuse *me* of confusing the two.

> So, the conclusion is that you basically missed the point completely.

I don't see how even you can reach that conclusion.

Cheers,
 Daniel.
 

0
Daniel
3/10/2007 12:27:22 PM
Daniel James <wastebasket@nospam.aaisp.org> writes:
> In article news:<87ejny3bol.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
>> ... somebody reading your reply can impossibly determine what the
>> original context of the quote was.
>
> I quoted as much source as you did. Go and take another look at my 
> posting: <VA.00001034.003e84a7@nospam.aaisp.org>

You deleted my text, moron.
0
Rainer
3/11/2007 7:14:31 PM
Rainer Weikusat <rainer.weikusat@sncag.com> writes:

> Daniel James <wastebasket@nospam.aaisp.org> writes:
>> In article news:<87ejny3bol.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
>>> ... somebody reading your reply can impossibly determine what the
>>> original context of the quote was.
>>
>> I quoted as much source as you did. Go and take another look at my 
>> posting: <VA.00001034.003e84a7@nospam.aaisp.org>
>
> You deleted my text, moron.

This is a newsgroup for applications development on GNU/Linux systems,
not for mindless abuse.  If you don't have anything constructive and
helpful to contribute, please go elsewhere.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
0
Roger
3/11/2007 10:26:17 PM
Roger Leigh <${rleigh}@invalid.whinlatter.ukfsn.org.invalid> writes:
> Rainer Weikusat <rainer.weikusat@sncag.com> writes:
>> Daniel James <wastebasket@nospam.aaisp.org> writes:
>>> In article news:<87ejny3bol.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
>>>> ... somebody reading your reply can impossibly determine what the
>>>> original context of the quote was.
>>>
>>> I quoted as much source as you did. Go and take another look at my 
>>> posting: <VA.00001034.003e84a7@nospam.aaisp.org>
>>
>> You deleted my text, moron.
>
> This is a newsgroup for applications development on GNU/Linux systems,
> not for mindless abuse.

.... which you prove quite nicely ...
0
Rainer
3/12/2007 2:53:39 PM
Roger Leigh <${rleigh}@invalid.whinlatter.ukfsn.org.invalid> writes:
> Rainer Weikusat <rainer.weikusat@sncag.com> writes:
>> Daniel James <wastebasket@nospam.aaisp.org> writes:
>>> In article news:<87ejny3bol.fsf@semtex.sncag.com>, Rainer Weikusat wrote:
>>>> ... somebody reading your reply can impossibly determine what the
>>>> original context of the quote was.
>>>
>>> I quoted as much source as you did. Go and take another look at my 
>>> posting: <VA.00001034.003e84a7@nospam.aaisp.org>
>>
>> You deleted my text, moron.
>
> This is a newsgroup for applications development on GNU/Linux systems,
> not for mindless abuse.

Consistently ignoring what other people intend to say and as
consistently trying to drag them into totally useless quarrels fits my
definition of 'mindless abuse' quite well. As does your post. So,
please consider taking your own advice.

BTW, I've immediatly put you alongside the other entity, so don't
bother to much with mindlessly flaming me again.
0
Rainer
3/12/2007 2:57:37 PM
>>>>> "Daniel" =3D=3D Daniel James <wastebasket@nospam.aaisp.org> writes:

    Daniel> You're missing my point ... I'm talking about what people
    Daniel> who are going through the process of learning C++ tend to
    Daniel> do -- they, by definition, are people who have NOT already
    Daniel> learnt C++ well.

The general picture is: People who're used to *procedural* programming
need  some effort  to switch  to think  and program  in OO.   That's a
**paradigm** shift.   Similarly, people who're used  to the procedural
or OO  paradigms would have a  hard time adapting  to the *functional*
paradigm.



    Daniel> If they already know how to tackle a problem in C their
    Daniel> instinct is to write the C solution (which is also valid
    Daniel> in C++) and so not look for a more C++-like approach, and
    Daniel> so not learn the C++ approach. This impairs the learning
    Daniel> process.

This is also  true for those who're fluent  in Pascal (not necessarily
C) or BASIC before starting to learn C++.

It's more a  problem with a paradigm shift,  rather than the languages
in their  own rights.  From  imperative, procedural programming  to OO
takes  some time.   One  needs to  "unlearn"  some methods  one is  so
accustomed to.



    Daniel> If they're serious about learning C++ they will try to
    Daniel> work around this impediment (with varying degrees of
    Daniel> success), but the tendency of the mind to run along
    Daniel> well-worn paths exists for everyone.

I was  serious enough  to read Stroustroup's  books.  So, I  know more
than my  classmates about C++.   They're often tripped by  things like
the  automatically generated  calls  to copy  constructors, which  are
themselves also  automatically generated.   I've developed a  habit of
declaring (but  not implementing) default  constructors and assignment
operators as  "private" so as  to avoid those nuisances.   (Of course,
when  I  really  need  these,  I'll  "re-enable"  them.)   The  recent
"explicit"  keyword is  helpful, but  it's a  very late  feature.  But
C++'s history is to be blamed.  It could have been designed with fewer
such traps for those who come from a C background.


    >> So, it's possible to know C and at the same time become a good
    >> C++ program.  It just takes time and effort -- something that
    >> this new generation are reluctant to invest, for no reasons
    >> that I can understand.

    Daniel> Yes, sure. I actually think that the best C++ programmers
    Daniel> do also know C -- but I'd argue that the most natural way
    Daniel> to learn is to learn the language with the higher-level
    Daniel> abstractions (C++) first,

Unfortunately,  when  I started  teaching  myself  programming, no  OO
languages were  available to  me.  (I'm not  saying it's  not invented
yet.  Just that there were no ways for me to access the resources.)


    Daniel> and then learn to drill down into the details as and when
    Daniel> you need to. Those of us who learnt C when there was no
    Daniel> C++ perforce did this the hard way, there's no need to
    Daniel> inflict that on future generations.

But  I think our  C (or  procedural programming  background --  I know
Pascal before  C) background does help us  understand programming much
better.  How  many people nowadays know clearly  the whole compilation
process: compilation, linking, dynmaic-linking, etc.?



    >> They don't start to think in an OO way.  They don't really
    >> understand why those features are there in an OO language.

    Daniel> This is not (just) about OO -- but about using the
    Daniel> higher-level constructs of the language as and when
    Daniel> appropriate.

Paradigm shift.  It's always difficult.


    Daniel> C++ is so much more than just an OO language (and in some
    Daniel> ways rather less -- it does lack some features like
    Daniel> reflection and introspection that are believed by some to
    Daniel> be requirements for a truly OO language).

Yeah.  Reflection is very useful.  But it is also easily abused.  Many
people  nowadays   use  reflection  to  write   very  "generic"  code,
neglecting the performance  overhead of reflection-ary operations over
native method calls, field  accesses, etc.  By using reflection, these
people have forgone  the nice and strict checks  that the compiler can
offer  you.  e.g.  instead of  writing "new  MyClass();",  some people
write "class.forName("MyClass").newInstance()" to create a new object.
(Yes,  even hard-coding the  string "MyClass",  instead of  reading it
from a config  file!!!)  They just rely on  throwing exceptions during
runtime, and then tracing the problems from the stack trace.  Had they
used  native  accesses,  the  compiler  would  have  pointed  out  the
offending code  much earlier, with  much friendlier and  helpful error
messages.

Of course,  when used properly,  reflection is very useful.   You can,
for  instance,  use  reflection  to  extract  your  in-line  specified
object-relation  mapping directives and  generate code  for performing
the  mapping automatically.   So, you  don't  have to  write your  own
little parser (which is  usually incomplete) to extract the directives
anymore.   Just use  reflection  to  exploit what  the  parser in  the
compiler has done.


--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
3/13/2007 5:53:47 AM
>>>>> "Milan" =3D=3D Milan Babuskov <mbabuskov@yahoo.com> writes:

    >> Secondly, if you need to make your program multithreaded later,
    >> you can easily create additional instances of Context and
    >> assign one to each thread

    Milan> The point of global variable is that *all* parts of program
    Milan> need a single "registry" for some information.=20

I've encountered many situations where your simple program needed only
1 registry  at first.   But as the  program evolved, you'll  find that
this  single-registry  assumption has  to  be  broken.   You may  need
several registries, maybe for different types of registrants.  You may
find that the same registry code can be used with little modification.
But  the  singleton  pattern  puts  a hurdle  there.   You'll  end  up
rewriting  most  parts of  this  registry code  so  as  to remove  all
singleton assumptions.  So,  you end up doing more  than if you didn't
use the singleton for the original version.


    Milan> You can't separate it  and have additional instances as all
    Milan> parts  of program  need to share  common data.=20=20

Sometimes, you  really want  to enhance your  program beyond  what you
assumed it should  be.  For instance, you may  have thought that eachs
instance   of  your  web-server   would  only   serve  one   web  site
(http://abc.com).  So,  you put  in the WebSiteRegistry  the key-value
pair ("hostname"  -> "abc.com").   It is a  singleton: why  not?  Your
web-server is to  server one site only.  So, why do  you need to think
for a second instance of WebSiteRegistry?

But later, you want to do virtual-hosting, so that it can server other
sites  as well  (http://abcd.com and  http://abcde.com).   Now, you're
stuck!


    Milan> If  you can separate  it, then it  isn't really a  case for
    Milan> singleton.

In practice, many situations are  like that: people use singletons not
because it is appropriate, but because they're lazy and short-sighted.

If you filter  out all these cases, where the  class in question isn't
really a  case for  singleton, then you're  left with FEW  cases where
singleton is really needed.

You think  a Cache  should be  a singleton, right?   No.  Look  at the
CPU's we're  now using.   The Pentium had  a unified  code+data cache.
So, a single cache.  But  Pentium-II and later use separate caches for
code and data.   (The difference in access patterns  for code vs. data
is enough  for separating the  caches, so that more  tailor-made cache
replacment algorithms can be  designed to boost performance.)  So, now
2 separate  instances of  caches.  Similarly, you  may, at  some later
stages of  your project,  find the need  to have several  instances of
Cache.  But then, it's too late.  Too many modules have used the Cache
with a  singleton assumption.  Changing  that assumption may  break many
modules.  (I hope you have regression testing!)




    Milan> I don't think so. Applying design patterns in C is much
    Milan> harder in terms of sticking to it. If you work alone, then
    Milan> it's ok, but if you have multiple programmers, it's much
    Milan> easier to prevent others from calling code function or
    Milan> hiding some variables by making them private members of a
    Milan> class. In C it's almost impossible to do. And that's just
    Milan> encapsulation.

In C,  you can  hide functions  by not putting  them in  header files.
Even more  strictly, you  can make them  static, so that  they're only
accessible in the same .c file.   (You should do that: if the compiler
detects  that a  static  function is  only  called once  (or is  short
enough), the optimizer would inline it!)

Of course, without strictly enforced policies, you have to rely on the
self-discipline of  your teammates.  But that  isn't impossible.  Look
at the Linux  kernel (e.g. the VFS), which is quite  OO in design, but
written in C.


It's paradigm, not language that matters.  You can do OO in C, and you
can do procedural programming in Java.  Functional programming is less
easy in  C because it doesn't  support closures directly,  but you can
always implement it yourself.  It's a Turing-complete language anyway.
;)


--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
3/13/2007 6:11:36 AM
Am I the only one to have problems with some posts like this ?
My e-mail client is displaying them in a very odd manner ! :-/

Regards
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Lib�ration  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
3/13/2007 8:25:10 AM
>>>>> "Milan" =3D=3D Milan Babuskov <mbabuskov@yahoo.com> writes:

    Milan> So, what is your suggestion if you have a rather complex
    Milan> "entity" with many interfaces to it?

    Milan> For example, I have a singleton Database class in one of my
    Milan> programs. It has methods like connect(), disconnect() and
    Milan> other stuff related to transaction start, transaction end,
    Milan> etc.

What if  you are  now required  to enhance your  program, so  that you
connect  to not  just  one, but  multiple  databases?  Your  singleton
pattern will become a hurdle.  You  would now need to patch it to make
it  safe  to instantiate  multiple  instance  of  Database, each  with
different  connection parameters.   Of course,  transaction boundaries
between different  databases may now  overlap in time  (without anyone
being aborted).   So, you'll  have to rewrite  any code that  has made
assumptions  upon  the  singletonity.   Such  code is  often  hard  to
identify.  You would  have saved time if you  didn't use the singleton
pattern in the first place.  Yes,  the code may be a bit more complex,
but  it  will   be  easier  to  maintain  than   the  now  wide-spread
singletonity assumption.

What's even worse, based on  a recent experience of correcting others'
left-over code,  is that  singleton patterns tend  to spread.   If you
have a singleton Database, then you'll be tempted to use singleton for
things related  to it, such as  Transaction, DatabaseApplication, etc.
In that case, there would be not only 1 class, but multiple classes to
patch before you can get your program work with multiple Databases.



    Milan>  It has data members which hold internal state (connection
    Milan> object, vector of transaction objects, cursors,
    Milan> etc.). Application has such requirements that it only needs
    Milan> one database connection.

Requirements  can change  overtime.  Don't  be short-sighted.   With a
little bit extra  work, you'll save a lot of work  in future.  Even if
your current  program really need  only one database, what  about your
next project?  You don't expect to reuse most of your current Database
code in  your next Database-related projects?  Would  the next project
require access to multiple databases?


    Milan> Now, without using classes, how would do what? Scatter
    Milan> database handling code in a bunch of functions that always
    Milan> need to pass the database connection state to each other?

Yes.  What's wrong with that?


    Milan> How would you make the database connection and transactions
    Milan> available? Use globals?

No.  Use HANDLEs, which internally (within a compilation unit) maps to
structs that  are "context" objects.  The  C I/O library  makes use of
this pattern, and this is very robust and efficient.


    Milan> Have them as static variables in functions that return
    Milan> them?

No.  That would  make your code behave like  singletons, but also make
it non-reentrant.  So, your function won't be thread-safe.


Both globals variables and static variables in functions have problems
common  with singletons:  you  cannot use  it  from various  different
*contexts*  simultaneously.   That's  because globals,  function-local
static  variables and singletons  all refer  to an  *implicit* context
associated with the process's address  space.  Since there is only one
such implicit  context per  process, you cannot  use those  things for
multiple contexts.  This is  very inflexible, and very undesirable for
server-like programs, which have to handle multiple clients at once.





--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
3/13/2007 8:49:55 AM
>>>>> "Milan" =3D=3D Milan Babuskov <mbabuskov@yahoo.com> writes:

    Milan> Roger Leigh wrote:
    >> Not in 2007.  We now have boost::format for type-safe
    >> printf-like

    Milan> FWIW, I noticed that never versions of GCC do the type
.................................^^^^^
    Milan> checking for printf by comparing the % placeholders with
    Milan> supplied datatypes.

"never"?  Do you mean "newer"?

Anyway, gcc has got that feature for at least 12 years, as far as I
remember.  You just need to use "-Wall" to enable it.


--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
3/13/2007 8:55:14 AM
In article news:<87fy89eljo.fsf@informatik.uni-freiburg.de>, LEE Sau Dan 
wrote:
> The general picture is: People who're used to *procedural* programming
> need  some effort  to switch  to think  and program  in OO.   That's a
> **paradigm** shift.

Yes, that's exactly the point. C++ is a multi-paradigm language and allows 
people who are already used to the procedural programming paradigm to 
continue to use it. That's great in situations where a procedural approach 
is the best approach for the problem being solved. 

When the aim is not to solve any particular problem, but rather to learn 
the C++ language as thoroughly as possible, one has to learn to shift out 
of any paradigm -- to abandon ingrained programming habits -- otherwise one 
will tend to exercise only those parts of C++ that support those 
habits/paradigms.

> This is also  true for those who're fluent  in Pascal (not necessarily
> C) or BASIC before starting to learn C++.

Agreed. 

> It's more a  problem with a paradigm shift,  rather than the languages
> in their  own rights.

Except that Pascal and BASIC don't *look like* C++, whereas C does -- even 
to the extent that most C programs will compile quite happily in the C++ 
compiler. I think it's easier to for programmers in languages other than C 
to make the paradigm shift because nothing looks familiar.

Cheers,
 Daniel.

0
Daniel
3/13/2007 9:22:11 AM
LEE Sau Dan wrote:
> I've encountered many situations where your simple program needed only
> 1 registry  at first.   But as the  program evolved, you'll  find that
> this  single-registry  assumption has  to  be  broken.

As you stated, this happens to shortsighted programmers. I only use
singleton in applications where the design has been done before going
into writing the actual code. If you just go into writing application
without thinking about it first, then you deserve that.

> Milan> If  you can separate  it, then it  isn't really a  case for
> Milan> singleton.
> 
> In practice, many situations are  like that: people use singletons not
> because it is appropriate, but because they're lazy and short-sighted.

In practive, it never happened to me. If it happened to you, then please
apply this characterization to yourself.

> If you filter  out all these cases, where the  class in question isn't
> really a  case for  singleton, then you're  left with FEW  cases where
> singleton is really needed.

Well know fact by everyone here.

> You think  a Cache  should be  a singleton, right?

I never said that. Did you happen to have such misconception in past?

>     Milan> I don't think so. Applying design patterns in C is much
>     Milan> harder in terms of sticking to it. If you work alone, then
>     Milan> it's ok, but if you have multiple programmers, it's much
>     Milan> easier to prevent others from calling code function or
>     Milan> hiding some variables by making them private members of a
>     Milan> class. In C it's almost impossible to do. And that's just
>     Milan> encapsulation.
> 
> In C, you can hide functions by not putting them in header files.

Ok, good point.

> Of course, without strictly enforced policies, you have to rely on the
> self-discipline of  your teammates.  But that  isn't impossible.  Look
> at the Linux  kernel (e.g. the VFS), which is quite  OO in design, but
> written in C.

Of course. But it isn't always easy to find top-notch developers for
your team, and they always cost a lot.

> It's paradigm, not language that matters.  You can do OO in C, and you
> can do procedural programming in Java.

The question is not whether you could do it, but whether you should do
it. You could use nuclear bomb to kill an insect, but it doesn't mean
you should - and if you do, you need to face the consequences.


-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/13/2007 9:45:15 AM
LEE Sau Dan wrote:
> But  I think our  C (or  procedural programming  background --  I know
> Pascal before  C) background does help us  understand programming much
> better.  How  many people nowadays know clearly  the whole compilation
> process: compilation, linking, dynmaic-linking, etc.?

I'd say the moment first IDEs show up with ability to do it with a
single click 80% of programmer population got lost. Adding a library to
the project is a "mystical" thing to a lot of programmers I know. They
only know where to click in their IDE and haven't got a clue what really
happens underneath.

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/13/2007 9:50:33 AM
Emmanuel Fleury wrote:
> Am I the only one to have problems with some posts like this ?
> My e-mail client is displaying them in a very odd manner ! :-/

Sau Dan's Chinese and is posting in the Big5 character set. This degrades
nicely to ASCII, so this isn't a problem to people whose newsreaders don't
understand Big5, but your newsreader may be picking an odd font to display the
post (Thunderbird does this, for example).

If you're having problems it usually indicates that your newsreader is trying
to be clever, but isn't clever *enough*. A dumb newsreader will work, and one
that properly understands text encodings will work, but one that tries to
understand text encodings but gets them wrong may not work.

Does my post come out right? I post in UTF-8, and the same thing may happen here.

-- 
┌── dg@cowlark.com ─── http://www.cowlark.com ───────────────────
│ "Wizards get cranky, / Dark days dawn, / Riders smell manky, / The road
│ goes on. / Omens are lowering, / Elves go West; / The Shire needs
│ scouring, / You may as well quest." - John M. Ford
0
David
3/13/2007 11:17:56 AM
LEE Sau Dan wrote:
>     Milan> FWIW, I noticed that never versions of GCC do the type
> ................................^^^^^
> 
> "never"?  Do you mean "newer"?

Yes, sorry about that.

> Anyway, gcc has got that feature for at least 12 years, as far as I
> remember.  You just need to use "-Wall" to enable it.

It is possible that I just noticed it recently.

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/13/2007 11:52:36 AM
LEE Sau Dan wrote:
> Milan> For example, I have a singleton Database class in one of my
> Milan> programs. It has methods like connect(), disconnect() and
> Milan> other stuff related to transaction start, transaction end,
> Milan> etc.
> 
> What if  you are  now required  to enhance your  program, so  that you
> connect  to not  just  one, but  multiple  databases?

I'm not. Program had very clear requirements. It is now long completed
and working (for 2 years). If I thought that there would be any, even
remote possibility that it might need multiple connections, I wouldn't
use singleton.

> What's even worse, based on  a recent experience of correcting others'
> left-over code,  is that  singleton patterns tend  to spread.   If you
> have a singleton Database, then you'll be tempted to use singleton for
> things related  to it, such as  Transaction, DatabaseApplication, etc.

No. If you do good OO design, Transaction should never be visible to any
other layer, but the database layer. The reason is that underlying
database engine may or may not support transactions, while applications
code requires atomic updates to data.

> In that case, there would be not only 1 class, but multiple classes to
> patch before you can get your program work with multiple Databases.

Luckily, it is not the case.

>     Milan>  It has data members which hold internal state (connection
>     Milan> object, vector of transaction objects, cursors,
>     Milan> etc.). Application has such requirements that it only needs
>     Milan> one database connection.
> 
> Requirements  can change  overtime.  Don't  be short-sighted.   With a
> little bit extra  work, you'll save a lot of work  in future.  Even if
> your current  program really need  only one database, what  about your
> next project?

I have projects that are over 5 years old an use singletons happily. I
have yet to get into situation where I made bad estimation and used
singleton where I shouldn't.

> You don't expect to reuse most of your current Database
> code in your next Database-related projects?

Reuse what? Anything that isn't project specific is like 20-30 lines of
code.

> Would  the next project require access to multiple databases?

Most of them do.

>     Milan> Now, without using classes, how would do what? Scatter
>     Milan> database handling code in a bunch of functions that always
>     Milan> need to pass the database connection state to each other?
> 
> Yes.  What's wrong with that?

It works against principle of self-documenting code.

>     Milan> How would you make the database connection and transactions
>     Milan> available? Use globals?
> 
> No.  Use HANDLEs, which internally (within a compilation unit) maps to
> structs that  are "context" objects.  The  C I/O library  makes use of
> this pattern, and this is very robust and efficient.

You cut out the most important sentence in that paragraph: "Now, without
using classes, how would do what?". AFAIK, struct == class in C++.

> Since there is only one
> such implicit  context per  process, you cannot  use those  things for
> multiple contexts.  This is  very inflexible, and very undesirable for
> server-like programs, which have to handle multiple clients at once.

I'm using singleton in client-side programs which don't have to handle
multiple servers at once.

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
3/13/2007 12:03:28 PM
Olivier Croquette wrote:
> LEE Sau Dan wrote, On 24.02.2007 3:06 Uhr:
> 
>> The correct  way to  do it  is: don't use  singletons (unless  you can
>> write a 10 page paper convincing me why you absolutely need to do it).
> 
> Have a look at:
> http://www-128.ibm.com/developerworks/library/co-single.html
> 
> The typical example given is a Logging class.

I stuck into that problem recently. Imagine, you has business 
requirements for log content. You need to write test cases for these 
requirements, so you need to use mock logger to validate log content. 
You also need to log test results, so you need plain logger. These 
loggers must not intermix their content.

These conditions are not satisfied:

 > * Will every application use this class exactly the same way? 
(exactly is the key word)
 > * Will every application ever need only one instance of this class? 
(ever and one are the key words)

So logger should be normal object, not a singleton.

Use IoC container and Dependency Injection pattern and forget singletons.

http://en.wikipedia.org/wiki/Inversion_of_Control
http://en.wikipedia.org/wiki/Dependency_injection
0
Volodymyr
3/13/2007 12:23:20 PM
David Given wrote:
> 
> Sau Dan's Chinese and is posting in the Big5 character set. This degrades
> nicely to ASCII, so this isn't a problem to people whose newsreaders don't
> understand Big5, but your newsreader may be picking an odd font to display the
> post (Thunderbird does this, for example).
> 
> If you're having problems it usually indicates that your newsreader is trying
> to be clever, but isn't clever *enough*. A dumb newsreader will work, and one
> that properly understands text encodings will work, but one that tries to
> understand text encodings but gets them wrong may not work.

Ok.

> Does my post come out right? I post in UTF-8, and the same thing may happen here.

Yes, I don't have any problem about iso-8859/utf-8 encoding but big5. :)

Thanks for your reply
-- 
Emmanuel Fleury              | Room:  261
Associate Professor,         | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax:   +33 (0)5 40 00 66 69
351, Cours de la Libération  | Email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France  | URL:   http://www.labri.fr/~fleury
0
Emmanuel
3/13/2007 1:20:18 PM
>>>>> "Milan" =3D=3D Milan Babuskov <mbabuskov@yahoo.com> writes:

    Milan> LEE Sau Dan wrote:
    >> But I think our C (or procedural programming background -- I
    >> know Pascal before C) background does help us understand
    >> programming much better.  How many people nowadays know clearly
    >> the whole compilation process: compilation, linking,
    >> dynmaic-linking, etc.?

    Milan> I'd say the moment first IDEs show up with ability to do it
    Milan> with a single click 80% of programmer population got
    Milan> lost. Adding a library to the project is a "mystical" thing
    Milan> to a lot of programmers I know. They only know where to
    Milan> click in their IDE and haven't got a clue what really
    Milan> happens underneath.

So, I don't encourage CS majors to use IDEs in their early years.  And
I don't  like seeing junior  Java programmers using Eclipse.   If they
have grown  such a big reliance  on those tools, they  won't learn the
insides.  This is  OK for writing casual programs.   But when it comes
to  performance   tuning  and  optimizations,   understanding  of  the
internals  is   needed.   (e.g.   many  popular   Java  libraries  use
java.lang.reflect  shamelessly when  it is  not  necessarily, ignoring
performance overhead, as well as forgoing compile-time type-checking.)



--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
4/2/2007 7:16:13 AM
>>>>> "Milan" =3D=3D Milan Babuskov <mbabuskov@yahoo.com> writes:

    [about using OO programs in C...]
    >> Of course, without strictly enforced policies, you have to rely
    >> on the self-discipline of your teammates.  But that isn't
    >> impossible.  Look at the Linux kernel (e.g. the VFS), which is
    >> quite OO in design, but written in C.

    Milan> Of course. But it isn't always easy to find top-notch
    Milan> developers for your team, and they always cost a lot.

Either you pay for  what you get, or you get what  you pay for.  There
is no free lunch for employers.  You want quality at zero cost?  Go to
Utopia, then.


    >> It's paradigm, not language that matters.  You can do OO in C,
    >> and you can do procedural programming in Java.

    Milan> The question is not whether you could do it, but whether
    Milan> you should do it.

This is no absolute answers.  If  OO fits the problem that you need to
solve, you use OO.  If functional programming fits the problem better,
do  in   this  way.   If   procedural  is  more  appropriate,   do  it
procedurally.

The  most important message  I want  to bring  up is  that programming
PARADIGM and  programming LANGUAGES are not tightly  coupled with each
other.  They're different dimensions.  You  can do OO in C, functional
programming in C++ as well as procedural programming in Java.  Whether
it's wise to do so depends on the problem you're solving.  (And _most_
of the time, you'll find it most makes sense to do OO in Java, etc.)



--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
4/2/2007 7:22:45 AM
>>>>> "Milan" =3D=3D Milan Babuskov <mbabuskov@yahoo.com> writes:

    Milan> You cut out the most important sentence in that paragraph:
    Milan> "Now, without using classes, how would do what?". AFAIK,
    Milan> struct =3D=3D class in C++.

Then, you're wrong.

There's  is an  important difference:  declaractions in  a  struct has
"public:" access by default.  In  a class, the access is "private:" by
default.  And this is the only difference.



--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
4/2/2007 7:31:42 AM
>>>>> "Volodymyr" =3D=3D Volodymyr M Lisivka <vlisivka@gmail.com> writes:

    Volodymyr> Use IoC container and Dependency Injection pattern and
    Volodymyr> forget singletons.

    Volodymyr> http://en.wikipedia.org/wiki/Inversion_of_Control
    Volodymyr> http://en.wikipedia.org/wiki/Dependency_injection

I've just studied these things recently, using Java and Spring framework.

In theory, it is OK.

But in practice, there are many problems:

1) Writing the config file to bind the objects together is no less
   complicated than writing a few lines of Java (or C++, if you like)
   code to do it.  You still need to know which classes to
   instantiate, what properties to be set, and which objects to be
   linked.

2) If anything  goes wrong  in the config  file, the library  throws a
   runtime exception, which can't be used to easily trace the cause of
   the problem.  If  I use a Java code fragment to  do the same thing,
   then  by  compile-time, those  problems  will  already  show up  as
   compile-time errors.  Further, the  Java compile does a much better
   job at type checking than the runtime IoC library functions.

3) Yes, I  know it suffices just  to change the config  file to change
   the  object connections.   It's  very flexible.   And  it avoids  a
   recompilation.  But unless you can get the config file right in one
   trial, the error messages are  helpless.  It may end up saving more
   time just  to write Java  code instead of  a config file,  and then
   recompile.

4) I  hate having  to use  setter methods  to initialize  the objects.
   that prevents me from making  those variables "final".  (In case of
   C++, I can't use  const-qualification (unless I mistakenly make the
   variables "mutable".)   This means the  compiler can do  much fewer
   sanity checks  (e.g. trying to  modify a final variable  because of
   typos) and optimizations.  Why abandon the constructors?

5) Related to (4), I cannot use the IIA (initialization is
   acquisition) approach anymore.


I'm  not completely  against the  IoC pattern.   I use  it,  too.  But
instead of  doing the  injecting the dependency  in config  files, I'd
rather do that in a separate  fragment of code -- which can be checked
and  optimized  by a  *compiler*.   I'm  more  afraid of  debugging  a
complicated   config  file   than  to   recompile  that   fragment  of
dependency-injecting code.  Compilers nowadays are very helpful.  :)


--=20
Lee Sau Dan                     =A7=F5=A6u=B4=B0                          ~=
{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
0
LEE
4/2/2007 7:44:18 AM
LEE Sau Dan wrote:
> The  most important message  I want  to bring  up is  that programming
> PARADIGM and  programming LANGUAGES are not tightly  coupled with each
> other.

But they are, and I don't think your 'most important message' is correct.

> They're different dimensions.  You  can do OO in C, functional
> programming in C++ as well as procedural programming in Java.  Whether
> it's wise to do so depends on the problem you're solving

I disagree. If the problem is such that it requires OO, then it's better
to use language that is built for it.

And _most_ of the time, you'll find it most makes sense to do OO in
Java, etc.)

Why 'most'? Please, give one example where it doesn't make sense to do
OO in Java.


-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
4/2/2007 12:48:59 PM
LEE Sau Dan wrote:
>>>>>>"Milan" == Milan Babuskov <mbabuskov@yahoo.com> writes:
> 
> 
>     Milan> You cut out the most important sentence in that paragraph:
>     Milan> "Now, without using classes, how would do what?". AFAIK,
>     Milan> struct == class in C++.
> 
> Then, you're wrong.
> 
> There's  is an  important difference:  declaractions in  a  struct has
> "public:" access by default.  In  a class, the access is "private:" by
> default.  And this is the only difference.

So, struct is equal to class in the context of discussion we were having
and I was correct.

-- 
Milan Babuskov
http://njam.sourceforge.net
0
Milan
4/2/2007 12:50:22 PM
LEE Sau Dan wrote:
>>>>>> "Volodymyr" == Volodymyr M Lisivka <vlisivka@gmail.com> writes:
> 
>     Volodymyr> Use IoC container and Dependency Injection pattern and
>     Volodymyr> forget singletons.
> 
>     Volodymyr> http://en.wikipedia.org/wiki/Inversion_of_Control
>     Volodymyr> http://en.wikipedia.org/wiki/Dependency_injection
> 
> I've just studied these things recently, using Java and Spring framework.

IoC != Spring.  Spring is not good to learn IoC pattern, because Spring 
is bloated beast but IoC pattern itself is very simple thing.

Learn other IoC containers (e.g. PicoContainer) or write your own to 
understand pattern properly.


> In theory, it is OK.
> 
> But in practice, there are many problems:
> 
> 1) Writing the config file to bind the objects together is no less
>    complicated than writing a few lines of Java (or C++, if you like)
>    code to do it.  You still need to know which classes to
>    instantiate, what properties to be set, and which objects to be
>    linked.

Yes, you will still need to know how to assemble program and configure 
beans but this logic is separated from main code.  You can use external 
tools or IDE (springide.org) to help in editing of Spring configuration 
files.

> 2) If anything  goes wrong  in the config  file, the library  throws a
>    runtime exception, which can't be used to easily trace the cause of
>    the problem.  If  I use a Java code fragment to  do the same thing,
>    then  by  compile-time, those  problems  will  already  show up  as
>    compile-time errors.  Further, the  Java compile does a much better
>    job at type checking than the runtime IoC library functions.

Use Java code to do same thing, if you wish. IoC pattern has no limits 
on that.

I, personally, prefer to use Java files for assembling because I can use 
any refactoring tool freely.

> 3) Yes, I  know it suffices just  to change the config  file to change
>    the  object connections.   It's  very flexible.   And  it avoids  a
>    recompilation.  But unless you can get the config file right in one
>    trial, the error messages are  helpless.  It may end up saving more
>    time just  to write Java  code instead of  a config file,  and then
>    recompile.
Use XML and Spring-enabled IDE, or/and Java code, or/and 
Jython/JavaScript/Groovy/etc scripts, or/and anything else to assemble 
and configure you program. It is not problem of IoC patter itself.


> 4) I  hate having  to use  setter methods  to initialize  the objects.
>    that prevents me from making  those variables "final".  (In case of
>    C++, I can't use  const-qualification (unless I mistakenly make the
>    variables "mutable".)   This means the  compiler can do  much fewer
>    sanity checks  (e.g. trying to  modify a final variable  because of
>    typos) and optimizations.  Why abandon the constructors?

I hate setters too. I use constructors when I can. Spring is able to do 
dependency injection via constructor but it heavy _oriented_ to setters 
and Java beans. PicoContainer is  oriented to constructors.


> 5) Related to (4), I cannot use the IIA (initialization is
>    acquisition) approach anymore.

You can.


> I'm  not completely  against the  IoC pattern.   I use  it,  too.  But
> instead of  doing the  injecting the dependency  in config  files, I'd
> rather do that in a separate  fragment of code -- which can be checked
> and  optimized  by a  *compiler*.   I'm  more  afraid of  debugging  a
> complicated   config  file   than  to   recompile  that   fragment  of
> dependency-injecting code.  Compilers nowadays are very helpful.  :)

I prefer to use IoC in same way. :-)
0
Volodymyr
4/3/2007 4:28:49 PM
On 2007-04-02, LEE Sau Dan <danlee@informatik.uni-freiburg.de> wrote:
>>>>>> "Milan" == Milan Babuskov <mbabuskov@yahoo.com> writes:
>
>
> The  most important message  I want  to bring  up is  that programming
> PARADIGM and  programming LANGUAGES are not tightly  coupled with each
> other.  They're different dimensions.  You  can do OO in C, functional
> programming in C++ as well as procedural programming in Java.

???

 how do you emulate lambda in c++


Bye.
   Jasen
0
jasen
4/6/2007 10:00:34 AM
--=-=-=
Content-Transfer-Encoding: quoted-printable

jasen <jasen@free.net.nz> writes:

> On 2007-04-02, LEE Sau Dan <danlee@informatik.uni-freiburg.de> wrote:
>>>>>>> "Milan" =3D=3D Milan Babuskov <mbabuskov@yahoo.com> writes:
>>
>>
>> The  most important message  I want  to bring  up is  that programming
>> PARADIGM and  programming LANGUAGES are not tightly  coupled with each
>> other.  They're different dimensions.  You  can do OO in C, functional
>> programming in C++ as well as procedural programming in Java.
>
> ???
>
>  how do you emulate lambda in c++

boost::lambda gets you mostly (but not quite) there.  You can't do
"true" lisp-like lambda functions, but you can do an approximation.

Generally, I just inline functions from the unnamed namespace and use
function pointers, which while not the same thing, can be used to
similar effect.  Function objects can also be used to achive similar
things, which is a big part of the functional programming part of the
standard library (<functional>).


Regards,
Roger

=2D-=20
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGFjypVcFcaSW/uEgRAowOAJ4ldaxsQwpJkoFmizg151lf+9+3dgCaAnZR
UZYPqcfg/aW/kr2xU+m8xnk=
=9sXH
-----END PGP SIGNATURE-----
--=-=-=--
0
Roger
4/6/2007 12:27:18 PM
Reply: