f



C or C++?

Hi,

I am a newbie to programming, and sorry again that I have to ask the C
or C++ questions. Is C required before learning C++? And become better
in C does it also make you a better C++ programmer? Or that to be a C+
+ programmer, it's better not to have any knowledge of C and start a
new in the C++ way as some books suggest?

0
weidongtom (17)
5/12/2007 3:55:29 AM
comp.lang.c++ 49423 articles. 7 followers. Post Follow

140 Replies
1474 Views

Similar Articles

[PageSpeed] 23

weidongtom@gmail.com wrote:
> Hi,
> 
> I am a newbie to programming, and sorry again that I have to ask the C
> or C++ questions. Is C required before learning C++?

No.

 And become better
> in C does it also make you a better C++ programmer?

Not necessarily.  Sometimes you have to "unlearn" some C ways of thinking.

 Or that to be a C+
> + programmer, it's better not to have any knowledge of C and start a
> new in the C++ way as some books suggest?

Again, not necessarily.  C and C++ are two separate languages, much as
many people want to confuse them.  However, if you know C++, I suspect
it's easier to learn C (since it's a not-quite-perfect subset of C++).

0
no.spam9 (2339)
5/12/2007 4:04:33 AM
On May 11, 11:55 pm, "weidong...@gmail.com" <weidong...@gmail.com>
wrote:
> Hi,
>
> I am a newbie to programming, and sorry again that I have to ask the C
> or C++ questions. Is C required before learning C++? And become better
> in C does it also make you a better C++ programmer? Or that to be a C+
> + programmer, it's better not to have any knowledge of C and start a
> new in the C++ way as some books suggest?

Learn C++ first, C is not required to understand C++.
In many cases, learning C first is a detriment.

[28.2] Should I learn C before I learn OO/C++?
http://www.parashift.com/c++-faq-lite/how-to-learn-cpp.html#faq-28.2

book: Accelerated C++
[28.7] What are some best-of-breed C++ programming-by-example guides?

0
pj_hern (970)
5/12/2007 5:55:51 AM
On May 12, 5:55 am, "weidong...@gmail.com" <weidong...@gmail.com>
wrote:
> Hi,
>
> I am a newbie to programming, and sorry again that I have to ask the C
> or C++ questions. Is C required before learning C++?

No.

And become better
> in C does it also make you a better C++ programmer?

No.

Or that to be a C+
> + programmer, it's better not to have any knowledge of C and start a
> new in the C++ way as some books suggest?

Yes.

I have to comment that it is common misconception that C
is required to learn C++ as C++ is based on C.
You can just adopt bad habits from C ;) It is easier
to peek language and work either in C or C++.
C is little bit more then portable assembler and that's
where it is it's power.
But, in order to understand how things work you will
need to learn at least one assembler first.
If you learn assembler beside C++ you can use it in
combination with it , and then you can fully understand C
part of C++.
Rhetorical question:
Why is nobody asking about learning assembler, then C ?:)
It makes much more sense.

Greetings, Branimir.




0
bmaxa209 (243)
5/12/2007 6:03:13 AM
Branimir Maksimovic wrote:

> On May 12, 5:55 am, "weidong...@gmail.com" <weidong...@gmail.com>
> wrote:
> > Hi,
> > 
> > I am a newbie to programming, and sorry again that I have to ask
> > the C or C++ questions. Is C required before learning C++?

> I have to comment that it is common misconception that C
> is required to learn C++ as C++ is based on C.

It's also a common misconception that C is a hindrance.

> You can just adopt bad habits from C ;)

You can learn bad habits in any language.

> C is little bit more then portable assembler and that's
> where it is it's power.

This comment indicates that you really know nothing of the C language,
and are just parroting back things others have told you.

C is not in any way shape or form an assembler, portable or otherwise. 




Brian
0
defaultuserbr (3656)
5/12/2007 7:31:25 AM
Default User wrote:
:: Branimir Maksimovic wrote:
::
::: On May 12, 5:55 am, "weidong...@gmail.com" <weidong...@gmail.com>
::: wrote:
:::: Hi,
::::
:::: I am a newbie to programming, and sorry again that I have to ask
:::: the C or C++ questions. Is C required before learning C++?
::
::: I have to comment that it is common misconception that C
::: is required to learn C++ as C++ is based on C.
::
:: It's also a common misconception that C is a hindrance.
::
::: You can just adopt bad habits from C ;)
::
:: You can learn bad habits in any language.
::

But after learning about malloc(), C string handling, casting, printf, and 
using pointers to simulate pass by reference, you have a lot to unlearn. If 
you want to learn C++, do that!


Bo Persson


0
bop (1086)
5/12/2007 8:39:53 AM
On May 12, 9:31 am, "Default User" <defaultuse...@yahoo.com> wrote:
> Branimir Maksimovic wrote:
> > On May 12, 5:55 am, "weidong...@gmail.com" <weidong...@gmail.com>
> > wrote:
> > > Hi,
>
> > > I am a newbie to programming, and sorry again that I have to ask
> > > the C or C++ questions. Is C required before learning C++?
> > I have to comment that it is common misconception that C
> > is required to learn C++ as C++ is based on C.
>
> It's also a common misconception that C is a hindrance.

I don;t think so. C community is large and this language is main
tool in it's area.

>
> > You can just adopt bad habits from C ;)
>
> You can learn bad habits in any language.

Well, I am joking here .

>
> > C is little bit more then portable assembler and that's
> > where it is it's power.
>
> This comment indicates that you really know nothing of the C language,
> and are just parroting back things others have told you.
>
> C is not in any way shape or form an assembler, portable or otherwise.

Look, I have learned assembler first, then C.
Things  like address of , dereference, pre and post increment/
decrement
operators, C arrays/strings and pointer arithmetic came from assembler
 style programming and instruction sets obviously.
I had 17 years when first met C, with previous assembler experience,
I immediately recognized what this language is all about
and felt like home.
Only difference is that C has strict type system, structures,
 parameter passing / cleanup is done automatically
and language has higher level constructs like if/switch/for/while ....
But then again any modern assembler have advanced features ,
even support for OO programming ;)
So real question is what can be done with assembly ,
that can't be done with C. In practice, except direct access to
 hardware features that are unavailable to language due portability
issues, there are no real differences.
Other question is how C maps to machine code.
If you look at generated code it maps pretty close.
So in theory, yes , C can be very far from real hardware,
but always very close to it's abstract machine which
is in reality pretty close model to real machine
or, if not, (remember dos days?)
there are always non standard extensions to bring it closer;)

Greetings, Branimir.


0
bmaxa209 (243)
5/12/2007 8:51:53 AM
On 11 May 2007 20:55:29 -0700, "weidongtom@gmail.com" wrote:
>I am a newbie to programming, and sorry again that I have to ask the C
>or C++ questions. 

Why would you want to learn C++ today?

>Is C required before learning C++? 

No in theory, yes in practice. C++ is an extension of C done in
several evolutionary steps. If you don't know the roots of the
language it just appears weird to you.  

>And become better
>in C does it also make you a better C++ programmer? 

Certainly. Many basic programming concepts are the same. Some C++
libraries, e.g. STL, are directly derived from C.  

>Or that to be a C+
>+ programmer, it's better not to have any knowledge of C and start a
>new in the C++ way as some books suggest?

This point of view was propagated for some time and it probably left
many students in confusion. 


-- 
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
0
rpbg123 (870)
5/12/2007 9:25:13 AM
On 2007-05-12 11:25, Roland Pibinger wrote:
> On 11 May 2007 20:55:29 -0700, "weidongtom@gmail.com" wrote:
>>I am a newbie to programming, and sorry again that I have to ask the C
>>or C++ questions. 
> 
> Why would you want to learn C++ today?

Why not, it's still one of the most commonly used languages out there 
and it's also one of the more advanced ones. I claim that anything you 
learn while working with C++ can be of use in other languages as well, 
the reverse however is not always true since some other languages are 
simplified (to allow faster learning) which makes some constructs 
impossible.

>>Is C required before learning C++? 
> 
> No in theory, yes in practice. C++ is an extension of C done in
> several evolutionary steps. If you don't know the roots of the
> language it just appears weird to you.  

Most (I among them) would probably disagree with that statement, 
knowledge of C is in no way necessary to learn C++, however if you want 
to learn how to use "all" of the C++ language you'll sooner or later 
come in contact with the C heritage of C++ and thus will learn how to 
program in C also.

The roots of modern C++ (which is mostly concerned with OO and generic 
programming and less with procedural programming) are not in C, but 
rather Simula and I doubt that you'll recommend the OP to learn that, 
will you?

>> And become better in C does it also make you a better C++
>> programmer?
> 
> Certainly. Many basic programming concepts are the same. Some C++
> libraries, e.g. STL, are directly derived from C.  

I'd say perhaps, that depends on which parts of C++ you'll be using, if 
you focus on the OO parts you'll have less use of what you learned from 
C, if you want to use C++ as C with classes then you'll have more use of it.

>> Or that to be a C++ programmer, it's better not to have any
>> knowledge of C and start a new in the C++ way as some books
>> suggest?
> 
> This point of view was propagated for some time and it probably left
> many students in confusion. 

The reason is simple, old habits die hard, and by learning to program in 
C first you'll learn a certain "style", certain ways to do thing and 
organizing your code, store data and so on. The problem is that C is a 
procedural language while C++ is a multi-paradigm language supporting 
procedural, object-oriented and generic programming, and all of these 
paradigms leads to different "styles". If you learn C first it might be 
harder to learn the "styles" needed to efficiently use the other 
paradigms and to make the most use of C++ is to use a mix of them.

-- 
Erik Wikstr�m
0
Erik-wikstrom (1881)
5/12/2007 10:35:48 AM
Roland Pibinger wrote:
> On 11 May 2007 20:55:29 -0700, "weidongtom@gmail.com" wrote:
>> And become better
>> in C does it also make you a better C++ programmer? 
> 
> Certainly. Many basic programming concepts are the same. Some C++
> libraries, e.g. STL, are directly derived from C.  
> 
Do what?  How does say, std::vector derive form C?  The C standard
library (with some modifications) is part of C++, but that part of the
standard library that used to be know as the STL has nothing to do with C.

-- 
Ian Collins.
0
ian-news (10155)
5/12/2007 10:53:30 AM
weidongtom@gmail.com wrote:
> And become better
> in C does it also make you a better C++ programmer?

  I would say the exact opposite: The "better" you are at C, the
worse you are at C++.

  Most "advanced" C programmers have learned tons of kludges to
circumvent the limitations of the language, and in many cases there
are much better and cleaner solutions in C++ for the same things.
The problem with C programmers who have self-taught these kludges
is that the more they have used them, the more difficult is to
unlearn them. Coding too much C also tends to develop resistance to
change and make you prejudiced against C++.
0
nospam270 (2948)
5/12/2007 12:55:35 PM
Bo Persson wrote:

> Default User wrote:
> :: Branimir Maksimovic wrote:
> ::
> ::: On May 12, 5:55 am, "weidong...@gmail.com" <weidong...@gmail.com>
> ::: wrote:
> :::: Hi,
> ::::
> :::: I am a newbie to programming, and sorry again that I have to ask
> :::: the C or C++ questions. Is C required before learning C++?
> ::
> ::: I have to comment that it is common misconception that C
> ::: is required to learn C++ as C++ is based on C.
> ::
> :: It's also a common misconception that C is a hindrance.
> ::
> ::: You can just adopt bad habits from C ;)
> ::
> :: You can learn bad habits in any language.
> ::
> 
> But after learning about malloc(), C string handling, casting,
> printf, and using pointers to simulate pass by reference, you have a
> lot to unlearn. If you want to learn C++, do that!

That's absolutely true, and you'll see that I never said learning C was
a prerequiste, or even helpful. I'm not sure. I learned C first, as did
many, and found it to be helpful. Others report a different experience.



Brian
0
defaultuserbr (3656)
5/12/2007 3:20:11 PM
Branimir Maksimovic wrote:

> On May 12, 9:31 am, "Default User" <defaultuse...@yahoo.com> wrote:

> > C is not in any way shape or form an assembler, portable or
> > otherwise.
> 
> Look, I have learned assembler first, then C.

Then you have little excuse for stating such bogus information. That
list of programming language features is no evidence of C being a
"portable assembler".




Brian



0
defaultuserbr (3656)
5/12/2007 3:24:06 PM
Juha Nieminen wrote:

> weidongtom@gmail.com wrote:
> > And become better
> > in C does it also make you a better C++ programmer?
> 
>   I would say the exact opposite: The "better" you are at C, the
> worse you are at C++.
> 
>   Most "advanced" C programmers have learned tons of kludges to
> circumvent the limitations of the language, and in many cases there
> are much better and cleaner solutions in C++ for the same things.
> The problem with C programmers who have self-taught these kludges
> is that the more they have used them, the more difficult is to
> unlearn them. Coding too much C also tends to develop resistance to
> change and make you prejudiced against C++.

What a load of crap. Seriously. Most C programmers I know are flexible
and knowledgable in multiple languages.




Brian
0
defaultuserbr (3656)
5/12/2007 3:26:22 PM
On Sat, 12 May 2007 10:35:48 GMT, <Erik-wikstrom@...com> wrote:
>The reason is simple, old habits die hard, and by learning to program in 
>C first you'll learn a certain "style", certain ways to do thing and 
>organizing your code, store data and so on. The problem is that C is a 
>procedural language while C++ is a multi-paradigm language supporting 
>procedural, object-oriented and generic programming, and all of these 
>paradigms leads to different "styles". If you learn C first it might be 
>harder to learn the "styles" needed to efficiently use the other 
>paradigms and to make the most use of C++ is to use a mix of them.

IMO, that's the "you can't teach old dogs new tricks" myth that is
employed when a new technology isn't adopted by the real world as
expected. We saw it with OOP ("nobody can learn OOP who has been
contaminated with procedural programming") and later - under different
circumstances - with STL or "generic" programming ("nobody can learn
STL who has been contaminated with procedural or OO programming").
It's just a myth.



-- 
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
0
rpbg123 (870)
5/12/2007 5:02:17 PM
On Sat, 12 May 2007 22:53:30 +1200, Ian Collins  wrote:
>Roland Pibinger wrote:
>> Many basic programming concepts are the same. Some C++
>> libraries, e.g. STL, are directly derived from C.  
>> 
>Do what?  How does say, std::vector derive form C?  

STL is a mix of functional programming concepts and C idioms. A
container is an abstraction of a C array, an iterator is an
abstraction of a C pointer and algorithms are designed in C style,
e.g. std::sort has almost the same interface as qsort (sans template
obfuscation). That's pretty obvious. The success of STL among 'geeks'
(and only among them) was mainly driven by the fact that it ditched
(falsely used and overused) OOP and reverted to the C programming
style in new templatized cloths.


-- 
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
0
rpbg123 (870)
5/12/2007 5:15:05 PM
Juha Nieminen <nospam@thanks.invalid> writes:

> The problem with C programmers who have self-taught these kludges
> is that the more they have used them, the more difficult is to
> unlearn them. Coding too much C also tends to develop resistance to
> change and make you prejudiced against C++.

Speak for yourself. Maybe *you* have these difficulties and prejudices,
but I certainly don't - I can adapt to different languages quite easily.

sherm--

-- 
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
0
spamtrap25 (371)
5/12/2007 6:57:28 PM
On May 12, 5:24 pm, "Default User" <defaultuse...@yahoo.com> wrote:
> Branimir Maksimovic wrote:
> > On May 12, 9:31 am, "Default User" <defaultuse...@yahoo.com> wrote:
> > > C is not in any way shape or form an assembler, portable or
> > > otherwise.
>
> > Look, I have learned assembler first, then C.
>
> Then you have little excuse for stating such bogus information. That
> list of programming language features is no evidence of C being a
> "portable assembler".
>
> Brian
Let's not be formalists here ;)
Well, I will quote someone who wroted following blog on internet
as I couldn't said it better in my previous post:):

"

C has been the "new assembly language" for at least 20 years. The
problem is too many developers hadn't noticed this.

I think I noticed it first when I read an article about using a
limited subset of C that mapped one-to-one on 68K assembler. The
registers were name d0-d7, a0-a7, you could assign to registers, add
to them, etc., e.g.:
a0=some calculation;
a0+=sizeof(int);
*a0++=d0;

It was eye-opening not because I realized that C could map to
assembler, but because I realized that C was so close to the original
PDP-11 instruction set, which has echoes in 68K.

So C has ALWAYS been "portable assembly language", where "portable"
depends more on the libraries than on anything inherent in the C
language itself.

And I'm referring to original K&R C, not that sissy standardized
thing.

And yeah, that was when I were a lad.

"

To conclude my posting. C is designed to attract assembler
programers. C++ is designed to attract C programmers.
So techniqally, claim that C is required to learn C++
is same one as claim that assembler is required to learn C.
That is my point ;)

Greetings, Branimir.

0
bmaxa209 (243)
5/12/2007 8:35:56 PM
Branimir Maksimovic wrote:

> C has been the "new assembly language" for at least 20 years. The
> problem is too many developers hadn't noticed this.

Pure and utter nonsense.
 
> I think I noticed it first when I read an article about using a
> limited subset of C that mapped one-to-one on 68K assembler. 

What does that have to do with the C language? You could probably do
the same thing with C++.

> The
> registers were name d0-d7, a0-a7, you could assign to registers, add
> to them, etc., e.g.:
> a0=some calculation;
> a0+=sizeof(int);
> *a0++=d0;

That's not something you can do in C. 

> It was eye-opening not because I realized that C could map to
> assembler, but because I realized that C was so close to the original
> PDP-11 instruction set, which has echoes in 68K.

No it couldn't. Some particular dialect of pre-standard C could. So
what does ANY of this have to do with the modern C language?

> So C has ALWAYS been "portable assembly language", where "portable"
> depends more on the libraries than on anything inherent in the C
> language itself.

You've produced no evidence at all of that.

> And I'm referring to original K&R C, not that sissy standardized
> thing.

Ridiculous. Do you make the same references about C++?

> To conclude my posting. C is designed to attract assembler
> programers.

False. C is a procedural language with robust standard library,
designed to attract programmers who wish to work in a compact language.

> C++ is designed to attract C programmers.

I don't believe that to be true either.

> So techniqally, claim that C is required to learn C++
> is same one as claim that assembler is required to learn C.
> That is my point ;)

Your point is bullshit. And all the winkies and other emoticons don't
change that fact.



Brian
0
defaultuserbr (3656)
5/12/2007 9:24:07 PM
Branimir Maksimovic wrote:
> 
> C has been the "new assembly language" for at least 20 years. The
> problem is too many developers hadn't noticed this.
> 
There's a huge difference between being "close to the machine" and being
a "portable assembler".  C++ is as close to the machine as C, but I
don't hear you calling C++ a "portable assembler".

Patch panels, machine code, assembler, C and C++ are just steps along
the evolutionary path of programming languages.

-- 
Ian Collins.
0
ian-news (10155)
5/12/2007 10:05:26 PM
Default User wrote:

> Your point is bullshit. And all the winkies and other emoticons don't
> change that fact.

Hey guys, cool down! The point is quite easy in my opinion:

1) the difference between the languages is a difference in paradigms: 
assembly is unstructured programming, C is procedural programming, and 
c++ is object oriented programming, so they are all different.

2) c has got some support for unstructured programming, like goto or 
labels, that are probably included to make easy for an unstructured 
program like an assembly one to be ported easily to C, and not to create 
a too big gap between C and previous languages. Anyway, the unstructured 
programming and its constructs are clearly deprecated in C. The same is 
with C++: you can use it like a C, you will find it easy because all the 
C it's supported in C++, but that use of C++ is deprecated, because C++ 
is an OO language. From this point of view, C doesn't help too much to 
learn C++ because it teaches you the wrong paradigm. Of course, if you 
are already confident with functional programming, and you are able not 
to be biased from that, you can take advantage of that in C++: in the 
same way, if you know low-level unstructured programming, pointers, 
variables and this sort of stuff from assembly, you can take advantage 
of it in c.

Regards,

Zeppe
0
zeppe8273 (21)
5/12/2007 10:53:32 PM
On May 13, 4:57 am, Sherm Pendley <spamt...@dot-app.org> wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
> > The problem with C programmers who have self-taught these kludges
> > is that the more they have used them, the more difficult is to
> > unlearn them. Coding too much C also tends to develop resistance to
> > change and make you prejudiced against C++.
>
> Speak for yourself. Maybe *you* have these difficulties and prejudices,
> but I certainly don't - I can adapt to different languages quite easily.

Claiming your special does not prove anything.

I think Juha's point is more correct than it is wrong.  I have seen
far too many C programmers claiming to know C++ and only to find they
don't.

Quite a few things that make good C code, bad for C++ code.

e.g.

A) In C++. don't pass function pointers, pass a class pointer (or
reference) with virtual methods.
B) In C++, don't use malloc/free - use std::vector if you have to.
C) In C++, dont use char *, use std::string
D) In C++, preference is to pass const references, not by value
E) In C++, use the initializer list not the body of the function
F) In C++, creating a class or a function should be at the same design
decision point
G) In C++, your code should be exception safe, C has no exceptions
H) In C++, use RAII, C has no RAII idiom
I) In C++, avoid macros is possible, in C you use macros for too many
things
J) In C++, restrict your interface by 'public', 'private' and
'protected' members, in C everything is public.

I can go on and on.  I get complaints from C programmers all the time
that some C++ idiom is too complex or that overloading the assignment
operator is a bad thing etc.

I don't know about you but I have yet to meet a pre C come C++
programmer that has not struggled loosening the knots of the C
methodologies.  Actually, not even just C but Java, C# and Javascript
coders as well.


0
gi3nospam (995)
5/13/2007 1:19:49 AM
On May 13, 12:05 am, Ian Collins <ian-n...@hotmail.com> wrote:
> Branimir Maksimovic wrote:
>
> > C has been the "new assembly language" for at least 20 years. The
> > problem is too many developers hadn't noticed this.
>
> There's a huge difference between being "close to the machine" and being
> a "portable assembler".  C++ is as close to the machine as C, but I
> don't hear you calling C++ a "portable assembler".

That's right. This is because when I met C I didn't change programming
style at all. Continued to program in same way I would do
in assembler. C++ on the under hand changed my point of view
on programming from the ground up and I needed much more time
to learn new style(s).

>
> Patch panels, machine code, assembler, C and C++ are just steps along
> the evolutionary path of programming languages.

Exactly.

Greetings, Branimir.

0
bmaxa209 (243)
5/13/2007 3:56:17 AM
On May 12, 11:24 pm, "Default User" <defaultuse...@yahoo.com> wrote:
> Branimir Maksimovic wrote:
> > C has been the "new assembly language" for at least 20 years. The
> > problem is too many developers hadn't noticed this.
>
> Pure and utter nonsense.

All that ugly and hackish C programs with bunch of casts
that try to do tasks which are cleanly and safely done in
assembler programs out there, speak for my word.
On the other hand you are replying to something I have quoted.
and I didn't tell that C is successful in it's task.
C++ is language done right. High level language that can actually
fulfill tasks where C failed. This is of course my opinion,
you don;t have to agree, and really I don;t care.

>
>
> > So techniqally, claim that C is required to learn C++
> > is same one as claim that assembler is required to learn C.
> > That is my point ;)
>
> Your point is bullshit.

Are you sure? You didn't provide any evidence on the contrary.

Greetings, Branimir.


0
bmaxa209 (243)
5/13/2007 4:43:29 AM
Branimir Maksimovic wrote:

>> > C has been the "new assembly language" for at least 20 years. The
>> > problem is too many developers hadn't noticed this.
>>
>> Pure and utter nonsense.
>
> All that ugly and hackish C programs with bunch of casts
> that try to do tasks which are cleanly and safely done in
> assembler programs out there, speak for my word.

Branimir is absolutely correct. C has always been considered "portable 
assembler". You have to know how memory is laid out, and how stacks and 
pointers work in hardware, even just to _avoid_ implementation-defined and 
undefined behavior.

> On the other hand you are replying to something I have quoted.
> and I didn't tell that C is successful in it's task.
> C++ is language done right. High level language that can actually
> fulfill tasks where C failed. This is of course my opinion,
> you don;t have to agree, and really I don;t care.

C++ only smooths over C's rougher spots, and adds some OO abstractions. 
That's enough for us to program far beyond C, because OO is good. But C++ 
should still be considered "very high level portable assembler".

C++ is hard to use, and hard to avoid undefined behavior. The benefit is 
high performance. So if you need high performance, then you need to learn 
C++'s quirks, and then you need to learn how it compiles into opcodes, so 
you can reduce those and make a program faster. So the best way to use C++ 
is still as "portable assembler".

>> Your point is bullshit.
>
> Are you sure?

You may want to consider using your newsreader's killfile mechanism. Some 
people are not here to learn.

-- 
  Phlip
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax


0
phlipcpp (2771)
5/13/2007 5:00:29 AM
Branimir Maksimovic wrote:

> On May 12, 11:24 pm, "Default User" <defaultuse...@yahoo.com> wrote:
> > Branimir Maksimovic wrote:
> > > C has been the "new assembly language" for at least 20 years. The
> > > problem is too many developers hadn't noticed this.
> > 
> > Pure and utter nonsense.
> 
> All that ugly and hackish C programs with bunch of casts
> that try to do tasks which are cleanly and safely done in
> assembler programs out there, speak for my word.

That doesn't even make sense. 

> On the other hand you are replying to something I have quoted.
> and I didn't tell that C is successful in it's task.

What does that even mean? What task? Portable assembler? That's still a
crock.

> C++ is language done right. High level language that can actually
> fulfill tasks where C failed.

No, it was an attempt to introduce a new language paradigm while
retaining nearly all the features of the past. I personally like it
fine, but many others out there feel it's clunky and bloated.

> This is of course my opinion,
> you don;t have to agree, and really I don;t care.

Apparently you do, as you keep trying to justify your ridiculous claims.


Brian
0
defaultuserbr (3656)
5/13/2007 6:39:29 AM
Phlip wrote:

> Branimir Maksimovic wrote:
 
> > All that ugly and hackish C programs with bunch of casts
> > that try to do tasks which are cleanly and safely done in
> > assembler programs out there, speak for my word.
> 
> Branimir is absolutely correct.

No, he's not.

> C has always been considered "portable assembler". 

Yes, there have always been idiots who believe anything they're told,
even when a few minutes research would tell them that they're wrong.

> You have to know how memory is laid out,

Oh? Why is that? 

> and how stacks

Oh, why is that?

> and pointers work in hardware,

No you don't. You only need to know how pointers work in the abstract.
That's why C has typed pointers, to automatically adjust the stride of
the pointer for pointer arithmetic.

> even just to avoid
> implementation-defined and undefined behavior.

Give some examples.

> C++ only smooths over C's rougher spots, and adds some OO
> abstractions. That's enough for us to program far beyond C, because
> OO is good. But C++ should still be considered "very high level
> portable assembler".

Only by people you.

> You may want to consider using your newsreader's killfile mechanism.
> Some people are not here to learn.

Well, you are one of them, so you should know.




Brian
0
defaultuserbr (3656)
5/13/2007 6:43:07 AM
Gianni Mariani wrote:


> I think Juha's point is more correct than it is wrong.  I have seen
> far too many C programmers claiming to know C++ and only to find they
> don't.

That's ok, a lot of C++ programmers don't know C++ either.



Brian
0
defaultuserbr (3656)
5/13/2007 6:44:04 AM
On May 13, 7:00 am, "Phlip" <phlip...@yahoo.com> wrote:
> Branimir Maksimovic wrote:
>
> C++ only smooths over C's rougher spots, and adds some OO abstractions.

I can't completely agree here.
C++ allow possibility to have proper string instead of assembler
string,
real array and so fort. With templates and possibilities to pass
different types through pointer/reference to single type it allows
type safe operations. For example I use event handling template
classes that can be embedded into any C event handling
system, which dispatch events to handlers (virtual or non virtual)
without single cast.

> That's enough for us to program far beyond C, because OO is good.

Not just OO. OO is not enough to provide type safety.
Both OO and templates accomplish that task.

 But C++
> should still be considered "very high level portable assembler".

Agreed, as C++ is also built on assembler constructs.

>
> C++ is hard to use, and hard to avoid undefined behavior.

I thought so, but then again I learned language myself.
But I had young programmers who used language to
do everyday tasks after couple of months when day first
saw language. With one experienced C++ programmer,
,there are good books too,I never saw that young programmers
produce undefined behavior programs or that they had
problems with language.
But then again, problem arises because there are lot of things
that can be done in other languages (functional, scripting,assembler),
and can't be done in C++ easily or at all.
Then fight with a language starts, but then again, I just
figured out, not to fight with a language, but to use other
ones when appropriate ;)


 The benefit is
> high performance. So if you need high performance, then you need to learn
> C++'s quirks, and then you need to learn how it compiles into opcodes, so
> you can reduce those and make a program faster.

Not necessarily. For everyday tasks I don;t have to even think
about performance and I don;t care because I have never had
problems with performance.
But I have tried Haskell and concluded that for reasonable performance
and memory usage I have to use assembler arrays, strings, and malloc/
free with even more unsafe techniques ;)
When I looked that I got that for free with high level constucts in C+
+,
and that C++ programs work with required performance
without any effort, but I have to be ultra guru to barely get
required performance in Haskell, I give up on that language.

So the best way to use C++
> is still as "portable assembler".

C++ can be used as portable assembler,too,
but rarely as most task does not require low level programming.
But then again, when low level constructs are needed I use
real assembler more and more.

>
> >> Your point is bullshit.
>
> > Are you sure?
>
> You may want to consider using your newsreader's killfile mechanism. Some
> people are not here to learn.

My principle is basically not to filter anyone's messages except
spamers
that advertise products on newsgroups and are not
interested in discussion. Default user does not behaves like a
educated gentlemen, but that is his problem, not mine.
Perhaps this is because he is young and has
strong emotions about this.

Greetings, Branimir.

0
bmaxa209 (243)
5/13/2007 6:53:08 AM
On May 13, 3:15 am, rpbg...@yahoo.com (Roland Pibinger) wrote:
> On Sat, 12 May 2007 22:53:30 +1200, Ian Collins  wrote:
> >Roland Pibinger wrote:
> >> Many basic programming concepts are the same. Some C++
> >> libraries, e.g. STL, are directly derived from C.
>
> >Do what?  How does say, std::vector derive form C?
>
> STL is a mix of functional programming concepts and C idioms. A
> container is an abstraction of a C array, an iterator is an
> abstraction of a C pointer and algorithms are designed in C style,
> e.g. std::sort has almost the same interface as qsort (sans template
> obfuscation). That's pretty obvious.

I fail to see the obviousness of your argument.

> .... The success of STL among 'geeks'
> (and only among them) was mainly driven by the fact that it ditched
> (falsely used and overused) OOP and reverted to the C programming
> style in new templatized cloths.

This conclusion all because std::sort is a templated function ?

std::sort does far more than qsort would ever do mainly because of
OOP.

a) qsort operates on pointers - std::sort operates on iterators
(including pointers)
b) std::sort is type safe, qsort is not
c) std::sort can be optimized for the types it's working on, qsort
cannot (big performance gain for std::sort here)
d) std::sort compare method can be a functor which allows for much
more utility (oop wise) that qsort which only allows a comparison
func.

Because of "C"'s very limited scope for reusability, qsort is
significantly more error prone and less useful than C++'s std::sort.


0
gi3nospam (995)
5/13/2007 7:17:03 AM
Branimir Maksimovic wrote:

>> C++ only smooths over C's rougher spots, and adds some OO abstractions.
>
> I can't completely agree here.
> C++ allow possibility to have proper string instead of assembler
> string

Absolutely. Most C++ code should work as a very-high level language. 
However, if you need such a language, you must also ask why you think you 
need the tedium of C++'s remaining rough spots. You can still run off the 
end of a std::string, unless you only use its simplest functions.

So if you need a very-high level language, sometimes you should use a real 
one. Not all programs need C++ speed. You get that speed by running close to 
the metal.

Your remaining points are just variations on the same theme. I am not 
advocating any language (unlike some folks on this thread who will remain 
nameless).

> But I have tried Haskell

Ouch. Try Ruby or Smalltalk. You might need more experience staying in the 
problem space. C++ forces you to spend a lot of time in the solution space, 
screwing with the plumbing of your design.

> C++ can be used as portable assembler, too,

You are reciting the standard C++ description that "C++ is a multi-paradigm 
language". I agree, but all those paradigms will all remain assembler-aware. 
The portable assembler aspect is not one of the paradigms, it is the primary 
motivation underlying all of them. C++ requires you to understand what the 
silicon oxide is doing, to stay safe.

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html 


0
phlipcpp (2771)
5/13/2007 8:55:56 AM
On 13 May 2007 00:17:03 -0700, Gianni Mariani wrote:
>> STL is a mix of functional programming concepts and C idioms. A
>> container is an abstraction of a C array, an iterator is an
>> abstraction of a C pointer and algorithms are designed in C style,
>> e.g. std::sort has almost the same interface as qsort (sans template
>> obfuscation). That's pretty obvious.
>
>I fail to see the obviousness of your argument.

Sorry, I can't help you. I just wanted to point out conceptual
similarities between STL and C programming.

>std::sort does far more than qsort would ever do mainly because of
>OOP.

STL has nothing in common with OOP. It is neither implemented
according to OO design principles nor does it support OO programming.
You are completely on the wrong track.


-- 
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
0
rpbg123 (870)
5/13/2007 9:41:45 AM
On May 13, 7:41 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
> On 13 May 2007 00:17:03 -0700, Gianni Mariani wrote:
....
> STL has nothing in common with OOP. It is neither implemented
> according to OO design principles nor does it support OO programming.
> You are completely on the wrong track.

You seem to have a strange definition of OOP.  Please elaborate why
you consider the STL to not support OO programming.




0
gi3nospam (995)
5/13/2007 11:02:25 AM
On 12 May, 18:02, rpbg...@yahoo.com (Roland Pibinger) wrote:
> On Sat, 12 May 2007 10:35:48 GMT, <Erik-wikstrom@...com> wrote:
> >The reason is simple, old habits die hard, and by learning to program in
> >C first you'll learn a certain "style", certain ways to do thing and
> >organizing your code, store data and so on. The problem is that C is a
> >procedural language while C++ is a multi-paradigm language supporting
> >procedural, object-oriented and generic programming, and all of these
> >paradigms leads to different "styles". If you learn C first it might be
> >harder to learn the "styles" needed to efficiently use the other
> >paradigms and to make the most use of C++ is to use a mix of them.
>
> IMO, that's the "you can't teach old dogs new tricks" myth that is
> employed when a new technology isn't adopted by the real world as
> expected. We saw it with OOP ("nobody can learn OOP who has been
> contaminated with procedural programming") and later - under different
> circumstances - with STL or "generic" programming ("nobody can learn
> STL who has been contaminated with procedural or OO programming").
> It's just a myth.

I think that's overstating it. "Learning C is not a prerequisite to
lerning C++ and may indeed make learning C++ harder" is completely
different to "nobody can learn C++ who has been contaminated with C".
The latter is IMO nonsense and I don't think anyone is suggesting it.
On the other hand, in response to

"Is C required before learning C++?"

you said

"No in theory, yes in practice."

which is equivalent to "in practice, you can't teach a dog trick B
unless you've taught it trick A first." Whether one believes that
depends on how much one believes the ability to perform trick B is
simply a natural extension the ability to peform trick A. In my
opionion, very little. It is like trying to teach a tennis player to
play badminton. Superficially, both are very similar - they involve
hitting something back and forth with a racquet. But the techniques
(e.g. use of the arm, wrist and racquet) are completely different.
There is nothing preventing a tennis player from learning badminton,
but they will have to unlearn some instincts and habits. However, if
someone who currently plays neither game wants to learn to play
badminton, why would you teach them to play tennis, with all it's
techniques and instincts that are irrelevant or contradictory to
playing badminton, first?

But I reiterate, that argument only holds if you believe that "the
ability to program in C++" is not simply "the ability to program in C
plus some extra ability on top of that". I imagine that is where the
disagreement lies.

Gavin Deane

0
deane_gavin (897)
5/13/2007 11:36:11 AM
Default User wrote:
> What a load of crap. Seriously. Most C programmers I know are flexible
> and knowledgable in multiple languages.

  I have met many C "hackers" with irrational prejudices against C++
and the way of doing things there. It's not even uncommon to see the
claim that "C is better than C++", and if you ask for the reasons,
all of them are completely fallacious, based on prejudices and not
knowing how things really work in C++.
0
nospam270 (2948)
5/13/2007 12:47:45 PM
Sherm Pendley wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
> 
>> The problem with C programmers who have self-taught these kludges
>> is that the more they have used them, the more difficult is to
>> unlearn them. Coding too much C also tends to develop resistance to
>> change and make you prejudiced against C++.
> 
> Speak for yourself. Maybe *you* have these difficulties and prejudices,

  That sentence just doesn't make sense. If I had all these prejudices
and difficulties, how come I wrote the above paragraph? The thing with
these prejudices and false information is precisely that the person
having them doesn't know they are simply prejudices and fallacies but
instead believes them to be true. If I were such a person, why would
I write the above?

> but I certainly don't - I can adapt to different languages quite easily.

  Right. Because you don't have prejudices then nobody has.
0
nospam270 (2948)
5/13/2007 12:50:01 PM
Gianni Mariani wrote:
> J) In C++, restrict your interface by 'public', 'private' and
> 'protected' members, in C everything is public.

  In my experience one common difficulty self-taught C programmers,
who haven't learned nor understand object-oriented programming and
the abstraction/modularity related to it, is that they often have
hard time accepting the notion of public member variables being,
in the general case, a bad thing. They just can't understand why
everything can't just be public and why information hiding and
abstraction are a good thing. It often takes long time for them
to finally understand why.

  Another slightly related issue is that, for some reason, they
(and in fact many other coders too, not just C ones) have an odd
aversion towards having to write anything extra. For example, many
coders prefer putting a member variable in the public part of the
class instead of putting it in the private part and writing an
accessor method for it, which they detest. They just don't like
having to write any extra code and can't see the benefit in abstracting
that member variable away.

  I often see this phenomenon in C++ code out there. One good example
of this is the PopCap library. The vast majority of member variables
in the classes of that library are public, and the only reason for
this is that the developers were lazy and wouldn't bother creating a
more abstract design.

  Of course this causes some negative side-effects. For example,
certain optimizations are impossible to implement in the library
without breaking tons of existing programs which use the library
and access the member variables directly (the library itself probably
also constantly accesses the variables directly, and thus would
require a major cleanup if this was changed).
0
nospam270 (2948)
5/13/2007 1:01:10 PM
On May 13, 10:55 am, "Phlip" <phlip...@yahoo.com> wrote:
> Branimir Maksimovic wrote:
>
> > But I have tried Haskell
>
> Ouch. Try Ruby or Smalltalk. You might need more experience staying in the
> problem space. C++ forces you to spend a lot of time in the solution space,
> screwing with the plumbing of your design.

Downloaded Ruby. I'll see if it performs reasonably well, and if
it has necessary support for what I need, I'll use it.
 I have to mention that I have picked Haskell for emotional reasons,
language is one of the most beautiful ones, ever saw.
 Unfortunately tools are not mature yet,
optimization is bad, both on speed and memory consumption so
programmer has to leave beauty and dig into ugliness ;)
C++ is much better and easier for that task, but I really miss
run time parametric polymorphism :(

Greetings, Branimir.

0
bmaxa209 (243)
5/13/2007 1:28:41 PM
Juha Nieminen wrote:

> Default User wrote:
> > What a load of crap. Seriously. Most C programmers I know are
> > flexible and knowledgable in multiple languages.
> 
>   I have met many C "hackers" with irrational prejudices against C++
> and the way of doing things there. It's not even uncommon to see the
> claim that "C is better than C++", and if you ask for the reasons,
> all of them are completely fallacious, based on prejudices and not
> knowing how things really work in C++.

I don't doubt that you can find such people. I can find irrational
programmers in most any language. However, that's not general trend of
the programmers I know. It could well be a function of where I work, of
course, which is in software research and development at an aerospace
company.



Brian
0
defaultuserbr (3656)
5/13/2007 3:39:56 PM
Roland Pibinger wrote:

> STL has nothing in common with OOP. It is neither implemented
> according to OO design principles nor does it support OO programming.
> You are completely on the wrong track.

That assessment rests on the definition of OO. If you define it strictly as 
jump tables for virtual functions, STL doesn't apply.

If you define it as the ability to swap in many implementations for one 
function call - many different bar() implementations for one call to 
foo.bar(), based on multiple derived foo types - then STL's generic template 
program qualifies. It's duck-typing in action.

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html


0
phlipcpp (2771)
5/13/2007 4:34:41 PM
Gavin Deane wrote:

> But I reiterate, that argument only holds if you believe that "the
> ability to program in C++" is not simply "the ability to program in C
> plus some extra ability on top of that". I imagine that is where the
> disagreement lies.

The distinction is simply which features newbies should use. They should use 
std::string first, long long before ever using char *.

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html 


0
phlipcpp (2771)
5/13/2007 4:37:47 PM
Branimir Maksimovic wrote:

>> Ouch. Try Ruby or Smalltalk. You might need more experience staying in 
>> the
>> problem space. C++ forces you to spend a lot of time in the solution 
>> space,
>> screwing with the plumbing of your design.
>
> Downloaded Ruby. I'll see if it performs reasonably well,

Uh, no. Use Ruby for high developer performance. The kind you need on 80% of 
your code. ;-)

> C++ is much better and easier for that task, but I really miss
> run time parametric polymorphism :(

Yep. You will be so far beyond that in so few statements...

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html 


0
phlipcpp (2771)
5/13/2007 4:39:43 PM
On May 11, 8:55 pm, "weidong...@gmail.com" <weidong...@gmail.com>
wrote:
> Hi,
>
> I am a newbie to programming, and sorry again that I have to ask the C
> or C++ questions. Is C required before learning C++? And become better
> in C does it also make you a better C++ programmer? Or that to be a C+
> + programmer, it's better not to have any knowledge of C and start a
> new in the C++ way as some books suggest?

At the college where I teach C++ (part-time, in the evenings),  I used
to teach only "C++ for C Progammers" courses.  Now my C++ courses no
longer require students to know C programming.  In fact, I teach an
intermediate C programming course, that has as it's prerequsite my
introductory C++ programming course!   I still teach one "C++ for C
Programmers course" a year -- people enrolling seem to be mostly old
time embedded C programmers wanting to evolve to C++ programming.

It seems that the C++ community (at least the C++ community that posts
on this site) is pretty unanimous in recommending the "Accelerated C+
+" text for learning C++.  If you take a peek at this book, you will
discover that it definitely does not teach C programming first, and
then go on to teach the OOP features of the C++ language.  I think
this answers your question.

I am currently using the Deitel and Deitel "C++ How To Program" 5th
edition as my text in my C++ courses (if I ever find my self
unemployed and with 1000 hours of free time on my hands, I will take
those 1000 hours to convert my courses to the text discussed above).
This text covers the introduction of classes in Chapter 3 and does not
cover the introduction of pointers (a C programming staple) until
Chapter 8.  I believe that this text is the most widely used C++
college text in the world! Again, I think this demonstrates that it i
definitely not necessary (or recommended) to learn C programming
before learning to program C++.

Cheers,

Bob


0
5/13/2007 6:11:22 PM
On Sun, 13 May 2007 16:37:47 GMT, "Phlip" wrote:
>Gavin Deane wrote:
>> But I reiterate, that argument only holds if you believe that "the
>> ability to program in C++" is not simply "the ability to program in C
>> plus some extra ability on top of that". I imagine that is where the
>> disagreement lies.
>
>The distinction is simply which features newbies should use. They should use 
>std::string first, long long before ever using char *.

Without char* (or wchar_t*) you cannot even open a file in C++. The
newbie then asks you why C++ has two different string types and why he
gets those 'std::basic_string<_Elem,_Traits, _Ax>' in the compiler
error messages.


-- 
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
0
rpbg123 (870)
5/13/2007 8:51:59 PM
On 13 May 2007 04:02:25 -0700, Gianni Mariani wrote:
>On May 13, 7:41 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
>> STL has nothing in common with OOP. It is neither implemented
>> according to OO design principles nor does it support OO programming.
>> You are completely on the wrong track.
>
>You seem to have a strange definition of OOP.  

I have no own definition of OOP. I merely use the common definiton.

>Please elaborate why
>you consider the STL to not support OO programming.

OOP is usually characterized by encapsulation, inheritance and
polymorphism. The latter, polymorphism, is the most important because
genuine OO attribute. STL uses no polymorphism, i.e. no interfaces, no
virtual functions and no inheritance (except for some negligible
implementation inheritance). Moreover, STL containers, iterators and
algorithms are designed only for values, not for objects. In sum, STL
is not object oriented.
  

-- 
Roland Pibinger
"Don�t believe in magic; understand what your libraries do, 
how they do it, and at what cost they do it." - Bjarne Stroustrup
0
rpbg123 (870)
5/13/2007 9:10:29 PM
On May 14, 7:10 am, rpbg...@yahoo.com (Roland Pibinger) wrote:
> On 13 May 2007 04:02:25 -0700, Gianni Mariani wrote:
>
> >On May 13, 7:41 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
> >> STL has nothing in common with OOP. It is neither implemented
> >> according to OO design principles nor does it support OO programming.
> >> You are completely on the wrong track.
>
> >You seem to have a strange definition of OOP.
>
> I have no own definition of OOP. I merely use the common definiton.
>
> >Please elaborate why
> >you consider the STL to not support OO programming.
>
> OOP is usually characterized by encapsulation, inheritance and
> polymorphism. The latter, polymorphism, is the most important because
> genuine OO attribute. STL uses no polymorphism, i.e. no interfaces, no
> virtual functions and no inheritance (except for some negligible
> implementation inheritance). Moreover, STL containers, iterators and
> algorithms are designed only for values, not for objects. In sum, STL
> is not object oriented.
>

That's a very constrained definition.  The basis of OOP is
encapsulation which then allows for many other things which includes
polymorphism as another.  There is no prerequisite to use polymorphism
to be designing using OOP.


0
gi3nospam (995)
5/13/2007 9:35:12 PM
Juha Nieminen wrote:
> 
>   Another slightly related issue is that, for some reason, they
> (and in fact many other coders too, not just C ones) have an odd
> aversion towards having to write anything extra. For example, many
> coders prefer putting a member variable in the public part of the
> class instead of putting it in the private part and writing an
> accessor method for it, which they detest. They just don't like
> having to write any extra code and can't see the benefit in abstracting
> that member variable away.
> 
Either way (public data members or accessors) in a class is a smell.


-- 
Ian Collins.
0
ian-news (10155)
5/13/2007 9:43:27 PM
On May 14, 7:43 am, Ian Collins <ian-n...@hotmail.com> wrote:
> Juha Nieminen wrote:
>
> >   Another slightly related issue is that, for some reason, they
> > (and in fact many other coders too, not just C ones) have an odd
> > aversion towards having to write anything extra. For example, many
> > coders prefer putting a member variable in the public part of the
> > class instead of putting it in the private part and writing an
> > accessor method for it, which they detest. They just don't like
> > having to write any extra code and can't see the benefit in abstracting
> > that member variable away.
>
> Either way (public data members or accessors) in a class is a smell.

Hey, I resemble that remark.

Being a C guy pre C++, I still make everything public and then fix the
code later ... Having said that, I do think that it's not a clear cut
rule that all member variables need to be private in every class.  For
example, returning a value that contains a number of different
elements.  A "message" in a protocol.  There is an Austria C++ class
to parse and combine URL's.  I'd probably do it differently today but
the class itself is the result.  Making accessors for all the
different components is neither useful nor necessary.

Yes, I know, I'm the one who raised this criticism so why am I
defending myself from my own criticism.  Go figure,

0
gi3nospam (995)
5/13/2007 11:34:31 PM
On May 13, 5:00 pm, "Phlip" <phlip...@yahoo.com> wrote:
> Branimir is absolutely correct. C has always been considered "portable
> assembler". You have to know how memory is laid out, and how stacks and
> pointers work in hardware, even just to _avoid_ implementation-defined and
> undefined behavior.

Either that, or you have to know C!

I have no idea how memory is laid out in x86. I heard there is
a 'data segment' and a 'code segment' but I'd have no idea
where to find them; nor if there are any stacks in there -- but
my programs work just fine and do not have any undefined
behaviour. Sometimes they have implementation-defined
behaviour but I'm aware of those cases and approve of them.

What's required to avoid undefined behaviour, is the ability
to read the C standard, or appropriate paraphrasing such
as the c.l.c FAQ.

> This is of course my opinion, you don;t have to agree, and really I don;t care.

Why bother posting then?

> C++ is hard to use, and hard to avoid undefined behavior. The benefit is
> high performance.

The 1990s called, they want their one eye back.

0
oldwolf (2279)
5/13/2007 11:54:50 PM
On May 13, 12:55 am, Juha Nieminen <nos...@thanks.invalid> wrote:
>   Most "advanced" C programmers have learned tons of kludges to
> circumvent the limitations of the language, and in many cases there
> are much better and cleaner solutions in C++ for the same things.

I find that the more C I write, the *fewer* kludges I use, because I
learn how to write portable code in the first place. In fact the only
time I use kludges now is to work around compiler bugs, or to
access memory in some third-party library where they didn't
specify their interface properly -- neither of which should be
considered a problem with C, or something that is fixed with C++!

> Coding too much C also tends to develop resistance to
> change and make you prejudiced against C++.

Now that is true, although of course you could replace 'C' with
'anything' and 'C++' with 'anything else' and still get a true
statement.
For example, people who mostly develop in C++ often have
a low opinion of C.

0
oldwolf (2279)
5/14/2007 12:02:28 AM
On May 14, 1:54 am, Old Wolf <oldw...@inspire.net.nz> wrote:
> On May 13, 5:00 pm, "Phlip" <phlip...@yahoo.com> wrote:
>
> > Branimir is absolutely correct. C has always been considered "portable
> > assembler". You have to know how memory is laid out, and how stacks and
> > pointers work in hardware, even just to _avoid_ implementation-defined and
> > undefined behavior.
>
> Either that, or you have to know C!
>
> I have no idea how memory is laid out in x86. I heard there is
> a 'data segment' and a 'code segment' but I'd have no idea
> where to find them; nor if there are any stacks in there -- but
> my programs work just fine and do not have any undefined
> behaviour.

Of course, C is portable, you can;t access segment registers
without extensions.But stack can be problem.
I have written some medical application in C back in 92. on AT&T unix
(non pc hardware).
Os provided very small stack (4-8kb if I remember correctly).
Without knowing about stack, I would perhaps use automatic
arrays instead of using malloc, and application could crash.
But as long as you are writing,
high level applications you don;t have to know
how particular platform works. If you are writing operating
system kernel or device driver, things are different.

>
> > This is of course my opinion, you don;t have to agree, and really I don;t care.
>
> Why bother posting then?

To express opinion?

Greetings, Branimir.

0
bmaxa209 (243)
5/14/2007 3:01:30 AM
On 13 May 2007 14:35:12 -0700, Gianni Mariani wrote:
>The basis of OOP is
>encapsulation which then allows for many other things which includes
>polymorphism as another.  

Encapsulation is a general design principle independant of the
programming paradigm. Polymorphism is a fundamental and distinctive
OOP concept, see e.g.
http://en.wikipedia.org/wiki/Object-oriented_programming


-- 
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
0
rpbg123 (870)
5/14/2007 8:07:28 AM
On May 13, 3:01 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Gianni Mariani wrote:
> > J) In C++, restrict your interface by 'public', 'private' and
> > 'protected' members, in C everything is public.

>   In my experience one common difficulty self-taught C programmers,
> who haven't learned nor understand object-oriented programming and
> the abstraction/modularity related to it, is that they often have
> hard time accepting the notion of public member variables being,
> in the general case, a bad thing. They just can't understand why
> everything can't just be public and why information hiding and
> abstraction are a good thing. It often takes long time for them
> to finally understand why.

It probably depends on where you learned C.  I was a
"self-taught" C programmer, but the usual way I've always seen C
written (even 20 years ago) was to define a struct and a set of
functions to manipulate it, and then to cross your fingers that
no one accessed any of the struct except for your functions.  I
adopted C++ originally solely for private---I hadn't the
slightest idea what OO was, and there weren't templates at the
time.  Even today, the rest is just icing on the cake.

Encapsulation is essential, regardless of the paradigm.
Otherwise, the code rapidly becomes unmaintainable.  That was
true already back before C++ came along.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

0
james.kanze (9769)
5/14/2007 8:14:00 AM
Gianni Mariani wrote:

> Being a C guy pre C++,

Me too.

> I still make everything public and then fix the
> code later ... Having said that, I do think that it's not a clear cut
> rule that all member variables need to be private in every class.

Correct; a program could wildly abuse semantic encapsulation, and still have 
private data. The most important rule here is to avoid "long distance access 
to low-level things". The farther apart two things are, the more formal 
their communication should be. The other ways to say that are generally 
"encapsulation is hierarchical", and "avoid inappropriate intimacy".

> For example, returning a value that contains a number of different
> elements.  A "message" in a protocol.  There is an Austria C++ class
> to parse and combine URL's.  I'd probably do it differently today but
> the class itself is the result.  Making accessors for all the
> different components is neither useful nor necessary.

Correct - that's just one big data object. If it's not an object with public 
behavior and private state, then there's no behavior to defend from 
unexpected changes to that state.

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html 


0
phlipcpp (2771)
5/14/2007 8:19:52 AM
Gianni Mariani wrote:
> Being a C guy pre C++, I still make everything public and then fix the
> code later

  And I suppose "fixing the code later" often doesn't get done at
all? ;)

> ... Having said that, I do think that it's not a clear cut
> rule that all member variables need to be private in every class.  For
> example, returning a value that contains a number of different
> elements.

  Well, I think a return value is a bit of an exception.
  Functions return things by value all the time, and it's completely
normal. For example, a function may return an integer.
  Of course in some cases you might need to, for example, return
*two* integers instead of one. Thus it makes sense to return them
in a struct.
  In a way one could think that return values are not internal
implementation.

  But anyways, as someone already insinuated, if you find yourself
having to write tons of accessor methods (or alternatively, if you
are lazy, having to put tons of variables in the public part of the
class), then there's probably a flaw in your OO design. It means that
there's way too much dependency between two or more classes. When a
program is well designed then you usually don't need tons of accessors.

  Sometimes a module just has some values which are accessed constantly.
For example, you might have an object which has screen coordinates, and
these coordinates are used all the time everywhere. One would be tempted
to put these coordinates in the public part of the class instead of
having some stupid getX(), getY() and setCoords() functions.
  However, abstracting those coordinates away is still a good thing.
It may be that at some point you might want to make some optimizations
to that class. For example, you might want to create a piece of code
which searches for the closest object to a given point. In that case
it would be handy if the objects were arranged in a Kd-tree or such.
Of course if you didn't abstract the coordinates of the object, but
everything accesses these coordinates directly, you can't optimize
the objects in such way that they are stored in the Kd-tree (and
moved inside it when the setCoords() function is called).
0
nospam270 (2948)
5/14/2007 8:55:53 AM
Old Wolf wrote:
> For example, people who mostly develop in C++ often have
> a low opinion of C.

  But I think that opinion is not completely baseless. The problem
with C is that it simply doesn't offer the tools for making safe code
(unless you use some kind of garbage collection extension for C, and
even that only helps with memory allocation but nothing else).
0
nospam270 (2948)
5/14/2007 8:58:33 AM
Juha Nieminen wrote:

>  And I suppose "fixing the code later" often doesn't get done at
> all? ;)

Winki noted. But...

One of the most important concepts in software engineering is that nothing 
is ever finished, and that "premature complexity" is just as bad as 
"premature optimization".

When you type a new function, you know you are making many compromises. The 
most important thing is to get the function to pass its test. If you think 
of improvements that would interrupt your flow, write them with // TODO on 
them.

Then, when you have slack time between features, search for the TODOs and 
fix them, easiest ones first.

Note that strategy depends on two further assets:

 - wall-to-wall unit tests
 - slack time between

If you don't have those, you have more problems than just the occassional 
public method!

>> ... Having said that, I do think that it's not a clear cut
>> rule that all member variables need to be private in every class.  For
>> example, returning a value that contains a number of different
>> elements.
>
>  Well, I think a return value is a bit of an exception.

He means the design difference between an object with members and a 
structure, used as a data bucket. The bucket should be private to its 
module.

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html 


0
phlipcpp (2771)
5/14/2007 9:07:52 AM
On May 14, 10:14 am, James Kanze <james.ka...@gmail.com> wrote:
> On May 13, 3:01 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>
> > Gianni Mariani wrote:
> > > J) In C++, restrict your interface by 'public', 'private' and
> > > 'protected' members, in C everything is public.
> >   In my experience one common difficulty self-taught C programmers,
> > who haven't learned nor understand object-oriented programming and
> > the abstraction/modularity related to it, is that they often have
> > hard time accepting the notion of public member variables being,
> > in the general case, a bad thing. They just can't understand why
> > everything can't just be public and why information hiding and
> > abstraction are a good thing. It often takes long time for them
> > to finally understand why.
>
> It probably depends on where you learned C.  I was a
> "self-taught" C programmer, but the usual way I've always seen C
> written (even 20 years ago) was to define a struct and a set of
> functions to manipulate it, and then to cross your fingers that
> no one accessed any of the struct except for your functions.

Couldn't you just use forward declaration of
struct, while hiding definition in implementation file,
if data members are not meant for public access?

Greetings, Branimir.

0
bmaxa209 (243)
5/14/2007 9:07:58 AM
On May 14, 6:07 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
> On 13 May 2007 14:35:12 -0700, Gianni Mariani wrote:
>
> >The basis of OOP is
> >encapsulation which then allows for many other things which includes
> >polymorphism as another.
>
> Encapsulation is a general design principle independant of the
> programming paradigm. Polymorphism is a fundamental and distinctive
> OOP concept, see e.g.http://en.wikipedia.org/wiki/Object-oriented_programming

Read that URL more carefully.


0
gi3nospam (995)
5/14/2007 9:18:06 AM
Gianni Mariani wrote:

>> Encapsulation is a general design principle independant of the
>> programming paradigm. Polymorphism is a fundamental and distinctive
>> OOP concept, see e.g.

> http://en.wikipedia.org/wiki/Object-oriented_programming
>
> Read that URL more carefully.

What's wrong with it?

Last year, the first few paragraphs on that WikiPedia page repeated the 
fallacy that "OO is better because it lets you match program objects to 
real-world objects". Paraphrased.

That verbiage appears at the top of many introductions to OO, and it's 
wrong. If two people want to debate two designs, one can't say "mine is 
better because my objects more closely match real-world objects." That 
brings nothing to the debate.

So it's awesome to see someone has completely tuned up the page and put in a 
much better summary, with the voodoo stuff moved down to one probationary 
segment.

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html 


0
phlipcpp (2771)
5/14/2007 9:47:03 AM
On 14 May 2007 02:07:58 -0700, Branimir Maksimovic wrote:
>On May 14, 10:14 am, James Kanze wrote:
>> It probably depends on where you learned C.  I was a
>> "self-taught" C programmer, but the usual way I've always seen C
>> written (even 20 years ago) was to define a struct and a set of
>> functions to manipulate it, and then to cross your fingers that
>> no one accessed any of the struct except for your functions.
>
>Couldn't you just use forward declaration of
>struct, while hiding definition in implementation file,
>if data members are not meant for public access?

Yes, you can and C developers often do so. The 'handle' is also a
typical C idiom that hides implementation data. Static functions in
the implementation file serve as 'private' functions.


-- 
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
0
rpbg123 (870)
5/14/2007 1:43:20 PM
> > C has always been considered "portable assembler".
>
> Yes, there have always been idiots who believe anything they're told,
> even when a few minutes research would tell them that they're wrong.

w00f w00f! The bark is loud but a barking dog doesn't bite. =^)

Abstract: . Of late it has become very common for research compilers
to emit C as their target code, relying on a C compiler to generate
machine code. In effect, C is being used as a portable compiler target
language. It offers a simple and effective way of avoiding the need to
re-implement effective register allocation, instruction selection, and
instruction scheduling, and so on, all for a variety of target
architectures. The trouble is that C was designed as a programming
language not as a... (Update)

Active bibliography (related documents):   More   All
0.5:   Annotating the Java Bytecodes in Support of Optimization -
Hummel, Azevedo, Kolson.. (1997)   (Correct)
0.3:   C-: A Portable Assembly Language That Supports Garbage.. -
Jones, Ramsey, Reig   (Correct)
0.2:   Type-Secure Meta-Programming - Christopher Bentley Dornan
(1998)   (Correct)

Similar documents based on text:   More   All
0.1:   Modular Lazy Search for Constraint Satisfaction Problems -
Nordin, Tolmach (2001)   (Correct)
0.1:   Featherweight Concurrency in a Portable Assembly Language -
Ramsey, Jones (2001)   (Correct)
0.1:   Advice On Structuring Compiler Back Ends And Proving Them
Correct - Oliva (1994)   (Correct)

BibTeX entry:   (Update)


@article{ jones98portable,
    author = "Simon Peyton Jones and Thomas Nordin and Dino Oliva",
    title = "{C}--: {A} Portable Assembly Language",
    journal = "Lecture Notes in Computer Science",
    volume = "1467",
    pages = "1--??",
    year = "1998",
    url = "citeseer.ist.psu.edu/341046.html" }



<snip snip>

There's more to be said about opinions in this tangent. I'm not here
to say that C is a portable assembler. I am here to say that a lot of
smart people consider it as such in specific contexts WHICH ARE OUT OF
SCOPE OF THIS SPECIFIC NEWSGROUP and the interests it represents. But
it doesn't mean that it is, quote,  "utter nonsense".

Keeping open mind and being able to connect things from different
contexts is a marvelous skill to possess, please restrain from further
abuse of other's opinion. They are entitled to it and you are entitled
to yours; maybe some times you are not in possession of all the
relevant facts to draw a conclusion on someone's _opinion_, you
clearly had no insight on possible factors that might affect forming
of such opinion!

Thanks!


0
jukka (294)
5/14/2007 4:10:38 PM
persenaama wrote:

> > > C has always been considered "portable assembler".
> > 
> > Yes, there have always been idiots who believe anything they're
> > told, even when a few minutes research would tell them that they're
> > wrong.
> 
> w00f w00f!

Learn how to post correctly.



Brian
0
defaultuserbr (3656)
5/14/2007 4:47:10 PM
> > w00f w00f!
>
> Learn how to post correctly.

The barking dog has no bite. But it sometimes has a little dog,
barking with it!

--
  Phlip

0
phlip2005 (2215)
5/14/2007 7:37:50 PM
On May 14, 7:47 pm, "Phlip" <phlip...@yahoo.com> wrote:
> Gianni Mariani wrote:
> >> Encapsulation is a general design principle independant of the
> >> programming paradigm. Polymorphism is a fundamental and distinctive
> >> OOP concept, see e.g.
> >http://en.wikipedia.org/wiki/Object-oriented_programming
>
> > Read that URL more carefully.
>
> What's wrong with it?

I don't think it supports the previous posters argument that OOP
requires polymorphism. I'm no OOP crtitic so I don't know if there is
anything wrong  with it if it smacked me in the head.

0
gi3nospam (995)
5/14/2007 7:43:10 PM
Gianni Mariani wrote:

> I don't think it supports the previous posters argument that OOP
> requires polymorphism. I'm no OOP crtitic so I don't know if there is
> anything wrong  with it if it smacked me in the head.

This question is a book unto itself. OO _should_ be defined so its
root principle is polymorphism, but the term OO is too abused for
WikiPedia to arbitrate any consensus.

One Robert C Martin says it best (IIRC): "Structured programming is
discipline imposed upon direct transfer of control flow. OO
programming is discipline imposed upon indirect transfer of control
flow."

By "discipline" he means that the statement if(foo){ int bar = 42; }
will refuse to compile that 'bar' outside its block {}. That is
Structured Programming - matching the scopes of variables to branches
of control flow.

In a structural paradigm, you can call methods indirectly, achieving
polymorphism, in one of two ways. You can write a 'switch' statement
that reads a type code, and branches to each target type, or you can
use a function pointer. Both systems suck, because to add another type
you must add a case to every matching switch statement, and to use a
function pointer you must generally assign the pointer, possibly
typecast it to call it, possibly check it for NULL, etc. All this
cruft raises the cost of polymorphism.

An OO language fixes this by merging the switch and function pointer
into a secret jump table. The language will typesafely manage the jump
table for you, mostly at compile time. That allows programmers to
impose discipline on how they partition a program into polymorphic
code blocks. And, once again, the compiler helps match variable scope
to code block scope. Objects are variables bound to polymorphic
behavior behind typesafe interfaces.

--
  Phlip

0
phlip2005 (2215)
5/14/2007 8:00:11 PM
* Phlip:
> 
> ... OO _should_ be defined so its
> root principle is polymorphism, but the term OO is too abused for
> WikiPedia to arbitrate any consensus.
> 
> One Robert C Martin says it best (IIRC): "Structured programming is
> discipline imposed upon direct transfer of control flow. OO
> programming is discipline imposed upon indirect transfer of control
> flow."

My simple definition of object-oriented versus routine-oriented 
(procedural, functional decomposition) is mainly based on how knowledge 
about and control of the system is distributed in the system:

   Routine-oriented:                  Object-oriented:

   * Routines have knowledge of       * Objects (or classes) have
     relevant objects (or classes)      knowledge of relevant routines
     and of other routines.             and of other objects/classes.

   * Centralized/hierarchical         * Distributed/local execution
     execution flow control;            flow control; cooperative.
     commander/subject-oriented.

Of course there are umpteen shades of system architecture in between and 
besides, for example routines communicating via a common "blackboard". 
But in practice they aren't much used.  And I think that's because to do 
something one needs to have the necessary knowledge: by deciding on 
knowledge distribution, responsibility distribution is implicitly also 
decided, and vice versa; it hangs together.

By this operational, knowledge-distribution based definition, the STL 
parts of the standard library are mainly routine-oriented.

Further distinctions are IMHO not very relevant, because more selective 
terms cannot be used in general to convey meaning (they can if they're 
defined, of course).

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
0
alfps (7389)
5/14/2007 8:42:12 PM
On May 15, 6:00 am, Phlip <phlip2...@gmail.com> wrote:
> Gianni Mariani wrote:
> > I don't think it supports the previous posters argument that OOP
> > requires polymorphism. I'm no OOP crtitic so I don't know if there is
> > anything wrong  with it if it smacked me in the head.
>
> This question is a book unto itself. OO _should_ be defined so its
> root principle is polymorphism, but the term OO is too abused for
> WikiPedia to arbitrate any consensus.
>
> One Robert C Martin says it best (IIRC): "Structured programming is
> discipline imposed upon direct transfer of control flow. OO
> programming is discipline imposed upon indirect transfer of control
> flow."
>
> By "discipline" he means that the statement if(foo){ int bar = 42; }
> will refuse to compile that 'bar' outside its block {}. That is
> Structured Programming - matching the scopes of variables to branches
> of control flow.
>
> In a structural paradigm, you can call methods indirectly, achieving
> polymorphism, in one of two ways. You can write a 'switch' statement
> that reads a type code, and branches to each target type, or you can
> use a function pointer. Both systems suck, because to add another type
> you must add a case to every matching switch statement, and to use a
> function pointer you must generally assign the pointer, possibly
> typecast it to call it, possibly check it for NULL, etc. All this
> cruft raises the cost of polymorphism.
>
> An OO language fixes this by merging the switch and function pointer
> into a secret jump table. The language will typesafely manage the jump
> table for you, mostly at compile time. That allows programmers to
> impose discipline on how they partition a program into polymorphic
> code blocks. And, once again, the compiler helps match variable scope
> to code block scope. Objects are variables bound to polymorphic
> behavior behind typesafe interfaces.


Then I and many many others I know of use the term OO very
incorrectly.

The first time I'd heard the term "object oriented" was at a talk in
'82 about Simula.  IIRC there was never any discussion about
polymorphism at that talk.

I subsequently defined a language named "clone" and wrote a compiler
for it that pushed the idea of state machines in control systems (the
state of the art at the time was ladder logic).  It was "object
oriented" because it broke the monolithic aspect of code development
at the time.  If you looked at the state of the art at the time, there
was very little in the idea of objects.  Wirth's book, Data Structues
+ Algorithms = Programs was breaking new ground for crusty old
programmers.

The "class" (where the compiler enforced the "this" parameter) which
was the pivot point where languages enforced Wirth's premise and
started calling sturctures + methods "objects" and hence "object
oriented".

It seems like a rewrite of history to say that the pivotal moment for
OO was polymorphism. It seems to me to not be supported by the history
I know.  I was one of the few programmers that created function tables
and to some extent had polymorphic C code.  For example a generic AVL
balanced binary tree algorithm which was not dissimilar to std::map
(in function not form).  It had iterators !   No-one told me that it
was any different to other parts of the system and the system was
referred to as "object oriented" at the time.

Besides, are templates not viewed as a "static" polymorphism ?  In the
example, std::map, it may do use polymorphism, but it sure does
everything my (at the time) polymorphic AVL tree class did.


0
gi3nospam (995)
5/14/2007 8:43:58 PM
Gianni Mariani wrote:

> The first time I'd heard the term "object oriented" was at a talk in
> '82 about Simula.  IIRC there was never any discussion about
> polymorphism at that talk.

Yet Simula had polymorphism - that was the point. It's unfortunate that, 
this far back, people generally didn't think to call it that. They probably 
talked about methods and messages...

> Besides, are templates not viewed as a "static" polymorphism ?

Absolutely. Given foo.bar(), foo could be a reference to a base class with 
polymorphic derivatives of bar(). Or foo could be a templated item, and 
bar() is anything that syntactically fits. Both situations are OO, because 
they are polymorphic.

The benefit of a super-narrow definition for something is it's distinct. We 
may not agree what is OO, but we both will [almost!] always agree what is 
polymorphic. So defining OO as polymorphism is very useful.

> In the
> example, std::map, it may do use polymorphism, but it sure does
> everything my (at the time) polymorphic AVL tree class did.

And that's why it was useful - you could minimize the abstract code and 
extend the concrete code.

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html


0
phlipcpp (2771)
5/15/2007 1:15:40 AM
On May 15, 11:15 am, "Phlip" <phlip...@yahoo.com> wrote:
..=2E.

> ... So defining OO as polymorphism is very useful.

You had me agreeing with you all the way until this.  That's a jump to
light speed I can't see how you achieved.

(Not that it bothers me at all, just jumps out as A=E2=87=9BB =E2=88=B4 B=
=E2=87=9BX).

..=2E. testing out my unicode characters !

0
gi3nospam (995)
5/15/2007 3:59:29 AM
Gianni Mariani wrote:

> > ... So defining OO as polymorphism is very useful.

> You had me agreeing with you all the way until this.  That's a jump to 
> light speed I can't see how you achieved.

If I were collaborating with someone over Visual Basic Classic code, and 
they call their design OO, I don't mind. I use the verbiage, in kind, to 
facilitate collaboration. And our code will naturally have lots of classes, 
objects, methods, etc.

However, if we are later consuming intoxicants in a non-work setting, and 
they ask me to dish on VB, I will cheerfully tell them that it's "Object 
Based", not "Object Oriented". Given a derived class method, if you have a 
reference to a base class object, you can call the derived method using 
foo.bar(). But if you have a reference with the derived type, you must call 
foo.MyClass_bar(). This isn't very polymorphic!

So I didn't mean the first kind of usefulness. One uses ones team's verbiage 
first. I meant the second kind. It's very easy to distinguish the OO 
languages from the poseurs, using only a simple criteria, not an endless 
list of WikiPedia-linked ratings.

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html 


0
phlipcpp (2771)
5/15/2007 4:38:31 AM
On May 14, 11:07 am, Branimir Maksimovic <b...@hotmail.com> wrote:
> On May 14, 10:14 am, James Kanze <james.ka...@gmail.com> wrote:
> > On May 13, 3:01 pm, Juha Nieminen <nos...@thanks.invalid> wrote:

> > > Gianni Mariani wrote:
> > > > J) In C++, restrict your interface by 'public', 'private' and
> > > > 'protected' members, in C everything is public.
> > >   In my experience one common difficulty self-taught C programmers,
> > > who haven't learned nor understand object-oriented programming and
> > > the abstraction/modularity related to it, is that they often have
> > > hard time accepting the notion of public member variables being,
> > > in the general case, a bad thing. They just can't understand why
> > > everything can't just be public and why information hiding and
> > > abstraction are a good thing. It often takes long time for them
> > > to finally understand why.

> > It probably depends on where you learned C.  I was a
> > "self-taught" C programmer, but the usual way I've always seen C
> > written (even 20 years ago) was to define a struct and a set of
> > functions to manipulate it, and then to cross your fingers that
> > no one accessed any of the struct except for your functions.

> Couldn't you just use forward declaration of
> struct, while hiding definition in implementation file,
> if data members are not meant for public access?

It depends.  That was the usual solution when all of the objects
were to be dynamically allocated anyway.  It doesn't work too
well when you want objects to allocated on the stack.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

0
james.kanze (9769)
5/15/2007 9:44:00 AM
Assembler programming is not generally necessary or desirable on the
RISC based UNIX systems presently in use. RISC system performance is
so heavily dependent on pipelining and various caches that it is
extremely difficult, if not impossible, for an individual to write
more efficient assembler code than is generated by the higher level
language compilers. The C language provides all the hardware access
and system service capabilities traditionally provided by Assembler.

As noted above, C has filled the programming niche traditionally
occupied by Assembly language. In addition to its normal use as a high-
level programming language, C can act as a universally portable
Assembler.

....

Sugar with the Tea?

0
jukka (294)
5/15/2007 1:04:15 PM
"persenaama" wrote:

> Assembler programming is not generally necessary or desirable on the
> RISC based UNIX systems presently in use. RISC system performance is
> so heavily dependent on pipelining and various caches that it is
> extremely difficult, if not impossible, for an individual to write
> more efficient assembler code than is generated by the higher level
> language compilers. The C language provides all the hardware access
> and system service capabilities traditionally provided by Assembler.

What about the circular shift?  What is that called in C?  I think "most' 
would be a better word choice than "all'.

> As noted above, C has filled the programming niche traditionally
> occupied by Assembly language. In addition to its normal use as a high-
> level programming language, C can act as a universally portable
> Assembler.


0
r124c4u1022 (2303)
5/15/2007 1:28:52 PM
persenaama wrote:

> Assembler programming is not generally necessary or desirable on the
> RISC based UNIX systems presently in use. RISC system performance is
> so heavily dependent on pipelining and various caches that it is
> extremely difficult, if not impossible, for an individual to write
> more efficient assembler code than is generated by the higher level
> language compilers. The C language provides all the hardware access
> and system service capabilities traditionally provided by Assembler.

May I translate that as "the chip manufacturers have snuggled up so tightly 
with known compiler technology that their opcodes have matured from 
comprehensible instruction sets, into complex things that can almost only be 
compiled"?

The point is the chip manufacturers no longer consider the raw assembly 
programmer as one of their customers. Hence they are able to focus on only 
one customer, the compiler author...

-- 
  Phlip
  http://flea.sourceforge.net/PiglegToo_1.html 


0
phlipcpp (2771)
5/15/2007 1:54:03 PM
On May 15, 3:04 pm, persenaama <j...@liimatta.org> wrote:
> Assembler programming is not generally necessary or desirable on the
> RISC based UNIX systems presently in use. RISC system performance is
> so heavily dependent on pipelining and various caches that it is
> extremely difficult, if not impossible, for an individual to write
> more efficient assembler code than is generated by the higher level
> language compilers.

While generally true, compiler can schedule instructions much better
then human, performance is not only reason to code in assembly.
There are real limitations in both C and C++, like regarding run time
code
generation as these languages are designed in a way that code will
always
execute from ROM.
On the other hand, while  human will certainly not be more efficient
then compiler in general, human written assembly tend to be optimized
in a different way, leading to much shorter programs.
So I guess, this is draw situation.

Greetings, Branimir.

0
bmaxa209 (243)
5/15/2007 3:20:02 PM
On May 15, 4:28 pm, "osmium" <r124c4u...@comcast.net> wrote:
> What about the circular shift?  What is that called in C?  I think "most'
> would be a better word choice than "all'.

Possible:
v = (v << n) | (v >> m);

Now it is quality of implementation issue to detect when the
combination of n and m can be implemented with a barrel shift.

I don't personally use C or C++ "as portable assembler", I think
pursuing such thing is folly, but that is just my opinion and as such
not interesting. I'm more inclined to use factory design pattern and
create implementation of the interface which MAY be optimized to the
platform / architecture.

I been working on OpenGL (ES) drivers for graphics hardware couple of
late years. The driver's job is pretty much to configure the hardware
into a state that can execute a compiled fragment and vertex programs
which are generated by the driver. The code generation is the most
demanding function of the driver, hands down, no contest.

All the .NET, Java, Shading Language etc. development of late is
steering the high-performance computing on desktop (and mobile)
environments to runtime code generation to be essential. This is area
where a lot of research is being done as we chat. Knowing how the
underlying hardware works is essential to the few that do this kind of
work, assembly is part of that. That's what I think where we're at
regarding assembly.

C and C++, these are tools which are used far and wide as interface
between the low-level and possible higher level code. On large number
of applications I observe (just personal, one man's point of view!)
the C/C++ _is_ the highest level of language hierarchy, if some random
scripting isn't considered. Universally this isn't true of course.

0
jukka (294)
5/16/2007 6:10:37 AM
On May 16, 4:10 pm, persenaama <j...@liimatta.org> wrote:
....
> All the .NET, Java, Shading Language etc. development of late is
> steering the high-performance computing on desktop (and mobile)
> environments to runtime code generation to be essential. This is area
> where a lot of research is being done as we chat. Knowing how the
> underlying hardware works is essential to the few that do this kind of
> work, assembly is part of that. That's what I think where we're at
> regarding assembly.
....
I've heard it said so many times that dynamic code optimizers are so
much better than static ones. Well, I have heard of a number of
isolated cases where that may make sense.  However, there is somthing
happening now which kind of makes this all mute and it's a little hard
to beat. Since the MIPS R10000, there has been a steady improvement in
the ability for the CPU to do much of the dynamic optimization.  If
you look at the Transmeta CPU's, you'll see the same thing happening
in software.  However with the latest generation of speculatively
executed, register renaming, branch predicting CPU's, it's hard to
optimize better than the CPU itself.

So yes, dynamic optimization may be better, better done by the CPU
itself.

0
gi3nospam (995)
5/18/2007 6:37:08 AM
> I've heard it said so many times that dynamic code optimizers are so
> much better than static ones. Well, I have heard of a number of
> isolated cases where that may make sense.  However, there is somthing

I never said they were. If you carefully read again, I was talking
about native binary code and that generating it is more productive
with online compiler than by hand using assembler.

It's really about feasibility of using static off line compiler for a
specific task. If you have a very complex state machine, which gives
you thousands or even millions of permutations for the generated code
it means in runtime you will be branching heavily to select the
correct binary to execute.

You can flatten the code with online code generator. Even if the code
isn't "optimal", it is still better than heavily nested conditional
basic blocks.

> happening now which kind of makes this all mute and it's a little hard
> to beat. Since the MIPS R10000, there has been a steady improvement in
> the ability for the CPU to do much of the dynamic optimization.  If
> you look at the Transmeta CPU's, you'll see the same thing happening
> in software.  However with the latest generation of speculatively
> executed, register renaming, branch predicting CPU's, it's hard to
> optimize better than the CPU itself.

That's why we want to avoid branching and flatten the conditional
basic blocks: mis-predicted branches are expensive on setup like you
describe above.


> So yes, dynamic optimization may be better, better done by the CPU
> itself.

By itself it solves problem only partially. It means that low-level
bit-twiddling is less relevant than it was couple of architectures
ago, but still, it is not substitute for writing good code.

For example, you could write graphics code using putpixel(x,y,color)
function. Or, you could write scanline renderer which processes
fragments in order, so address computation logic is simpler:

*scan++ = color;

The putpixel() version of the same would look like this:

buffer[y * stride + x] = color;

What's wrong with above?

1. There is unnecessary multiplication
2. If this is non-inlined function, the call overhead
3. The memory write request is dependent on executing the address
computation logic
4. NOTE: the "extra" addition there might be free, depending on the
addressing modes a specific architecture supports.

The "CPU runtime optimization" can re-order and issue the translated
microcode instructions in more optimal sequence. Still, we added so
much cruft and overhead there for no real tangible gain. We just
burned trace/code cache even if we ran at the same performance without
consideration to the bigger picture. Yay.

The biggest optimization is still between the keyboard and the chair:
the human with living, thinking mind. :)


-- extra section --

Example of what OpenGL state machine's depth compare function would
look like in C++:

bool zpass;
uint32 depth = zbuffer[x];
switch ( depthFunc )
{
    case DEPTHFUNC_LESS: zpass = z < depth; break;
    case DEPTHFUNC_MORE: zpass = z > depth; break;
    case DEPTHFUNC_LEQUAL: zpass = z <= depth; break;
    case DEPTHFUNC_NOTEQUAL: zpass = z != depth; break;
    // .... all depth function cases ....
}

if ( zpass )
{
   process_fragment(...);
}
z += dxdz;

Since there are 8 different depth compare functions, we have to
generate code for all these. Above looks totally retarded way to do
it. Okay, so, smart way to go about it would have different innerloop
for different depth compare functions, right? Right..

OK, we did that. Now what? We have stenciling, alpha testing, alpha
blending, yada yada yada. We cannot realistically generate ALL
combinations of these. So we either make them own functions, call them
and have tens of functions calls PER FRAGMENT! That is even MORE
idiotic than what we have above!

So what the heck we going to do about this? At this moment in time, it
looks fairly attractive to GENERATE (!) the code dynamically. Doesn't
matter if we got 10,000,000 different innerloops to write.

The SIMPLEST mechanics to do this is to stitch the code. You write
nice neat pieces and stitch them together like lego blocks. You need
to specify carefully how you broadcast data from one stage to the
next. Not too difficult.

The next step in evolution is to generate intermediate representation
of the operations we want to do. Then we take this representation and
transform in meaningful ways. We could do constant folding, we could
do strength reduction, constant propagation. We could do instruction
selection and register allocation, we could do these in different ways
or combine some of the steps and so on and on. Effectively we would be
writing optimizing code generator. :)

Combine static and dynamic code generation, shake (don't stir!) and
enjoy the cocktail! :)

0
jukka (294)
5/18/2007 7:46:28 AM
On May 14, 1:14 am, James Kanze <james.ka...@gmail.com> wrote:

> It probably depends on where you learned C.  I was a
> "self-taught" C programmer, but the usual way I've always seen C
> written (even 20 years ago) was to define a struct and a set of
> functions to manipulate it, and then to cross your fingers that
> no one accessed any of the struct except for your functions.  I
> adopted C++ originally solely for private---I hadn't the
> slightest idea what OO was, and there weren't templates at the
> time.  Even today, the rest is just icing on the cake.
>
> Encapsulation is essential, regardless of the paradigm.
> Otherwise, the code rapidly becomes unmaintainable.  That was
> true already back before C++ came along.

I am a long-time C programmer and relative newcomer to C++.  When I
really need tight encapsulation in C, I use opaque pointers.  When I
really need encapsulation in C++, I use PIMPL or opaque pointers.

Private fields are nice, but the fact that private fields have to be
in a public header is irksome to me.

Tim

0
thockin (72)
5/19/2007 3:34:58 AM
Tim H wrote:
> Private fields are nice, but the fact that private fields have to be
> in a public header is irksome to me.

  The compiler has to know the size of the class. Do you have any
suggestions about how it can know that if the member variables for
the class are not listed?

  As for private member functions, I agree. There just isn't any
technical reason for them to be mandatory in the class definition.
0
nospam270 (2948)
5/19/2007 8:26:59 AM
On May 19, 10:26 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> Tim H wrote:
> > Private fields are nice, but the fact that private fields have to be
> > in a public header is irksome to me.
>
>   The compiler has to know the size of the class.

Not just size of class. It has to see definition in
order to know exact memory layout.

 Do you have any
> suggestions about how it can know that if the member variables for
> the class are not listed?

C++ class is same thing as struct. Only difference is that
in class everything is private by default and in struct public.
Definitions of class/struct have to be same across all compilation
units. But I think that I have saw in language D that different
definitions work. For example one class with same name just declares
member functions while other defines functions and adds member
variables. This can also work in C++ if implementation always
places vtable pointer first, but I guess this will severely
restrict implementations and I don;t know what will
happen when casting across multiple inheritance bases
or virtual inheritance bases.

>
>   As for private member functions, I agree. There just isn't any
> technical reason for them to be mandatory in the class definition.

Well it is. What about virtual functions? Compiler can't know
vtable layout without seeing all virtual functions.

Greetings, Branimir.


0
bmaxa209 (243)
5/19/2007 11:45:26 AM
On May 19, 1:45 pm, Branimir Maksimovic <b...@hotmail.com> wrote:
> On May 19, 10:26 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> > Tim H wrote:
> > > Private fields are nice, but the fact that private fields have to be
> > > in a public header is irksome to me.

> >   The compiler has to know the size of the class.

> Not just size of class. It has to see definition in
> order to know exact memory layout.

You're supposing a very classical compiler/linker organization.
There's nothing to prevent a compiler from generating some sort
of abstract code, with actual code generation only taking place
at link time.  Most modern compilers already do this anyway, for
optimization purposes.  Most still fix things like stack layout
at compile time, but this is mainly because of historical
reasons; there's no real technical justification.

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

0
james.kanze (9769)
5/19/2007 6:55:57 PM
Branimir Maksimovic wrote:
>>   As for private member functions, I agree. There just isn't any
>> technical reason for them to be mandatory in the class definition.
> 
> Well it is. What about virtual functions? Compiler can't know
> vtable layout without seeing all virtual functions.

  I referred to non-virtual functions.
0
nospam270 (2948)
5/19/2007 10:34:11 PM
On May 20, 4:55 am, James Kanze <james.ka...@gmail.com> wrote:
> On May 19, 1:45 pm, Branimir Maksimovic <b...@hotmail.com> wrote:
>
> > On May 19, 10:26 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> > > Tim H wrote:
> > > > Private fields are nice, but the fact that private fields have to be
> > > > in a public header is irksome to me.
> > >   The compiler has to know the size of the class.
> > Not just size of class. It has to see definition in
> > order to know exact memory layout.
>
> You're supposing a very classical compiler/linker organization.
> There's nothing to prevent a compiler from generating some sort
> of abstract code, with actual code generation only taking place
> at link time.  Most modern compilers already do this anyway, for
> optimization purposes.  Most still fix things like stack layout
> at compile time, but this is mainly because of historical
> reasons; there's no real technical justification.
>

You're not implying being able to export templates are you ?


0
gi3nospam (995)
5/20/2007 10:21:59 AM
On May 20, 12:21 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> On May 20, 4:55 am, James Kanze <james.ka...@gmail.com> wrote:

> > On May 19, 1:45 pm, Branimir Maksimovic <b...@hotmail.com> wrote:

> > > On May 19, 10:26 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> > > > Tim H wrote:
> > > > > Private fields are nice, but the fact that private fields have to=
 be
> > > > > in a public header is irksome to me.
> > > >   The compiler has to know the size of the class.
> > > Not just size of class. It has to see definition in
> > > order to know exact memory layout.

> > You're supposing a very classical compiler/linker organization.
> > There's nothing to prevent a compiler from generating some sort
> > of abstract code, with actual code generation only taking place
> > at link time.  Most modern compilers already do this anyway, for
> > optimization purposes.  Most still fix things like stack layout
> > at compile time, but this is mainly because of historical
> > reasons; there's no real technical justification.

> You're not implying being able to export templates are you ?

I'm not implying anything.  I'm saying very bluntly and directly
that today (2007), there is no real technical reason not to
implement export.  It means a bit of programming work, but the
techniques and the problems are known (thanks to the people at
EDG).  That a compiler vendor could have some hesitations in
1999, I can understand; it's not always a bad policy to let
others do the hard work of finding out where the problems might
be.  Today, the hard (in the sense of difficult) work has been
done.  And while it obviously involves investing some resources,
EDG has made enough information about how they did it available
so that other companies should be able to plan and budget it
with a reasonable degree of assurance of not ending up
completely out of budget.  And experience with the EDG
implementation has proved that it does bring the claimed
advantages.

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34


0
james.kanze (9769)
5/20/2007 8:53:23 PM
On May 21, 6:53 am, James Kanze <james.ka...@gmail.com> wrote:
> On May 20, 12:21 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:
>
....
> > You're not implying being able to export templates are you ?
>
> I'm not implying anything.  I'm saying very bluntly and directly
> that today (2007), there is no real technical reason not to
> implement export.

You seem to be sitting on the fence on this one, can you tell us what
you really think ?

> ... It means a bit of programming work, but the
> techniques and the problems are known (thanks to the people at
> EDG). ...

A simple matter of programming ?

Maybe you missed the implied smiley on my previous post however, I
think there is a little more to it to do it right.  I would not hold
doing it now on my account.

To do export "properly", there needs to be an kernel support if you
want to support dynamic linking/exporting.  The extra processing cost
on start-up of dynamically linked libs because of exports needs to be
worked so that it is not paid for every time a program starts up.  I
have yet to see an export implementation but I suspect that debugging
will need to be worked out as well.  It also introduces a new failure
mode, static assert on dynamic link.  I'd need to think through that
one a little.



0
gi3nospam (995)
5/20/2007 11:11:23 PM
On May 21, 1:11 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> On May 21, 6:53 am, James Kanze <james.ka...@gmail.com> wrote:
>
>
> > ... It means a bit of programming work, but the
> > techniques and the problems are known (thanks to the people at
> > EDG). ...
>
> A simple matter of programming ?
>
> Maybe you missed the implied smiley on my previous post however, I
> think there is a little more to it to do it right.  I would not hold
> doing it now on my account.
>
> To do export "properly", there needs to be an kernel support if you
> want to support dynamic linking/exporting.

No need for kernel support, but run time compiler.
Exports can not be fully created object files.
Both calls and definitions have to be instantiated at run
time in this case. Note that I would like that feature very much
since I'm doing similar work in assembler currently,
but only for value based template functions as then templates
are just binaries with "holes" that are copied into buffer
then patched  by constructor functions in run time.
Run time generated templates will be slow first few passes
then they'll work same as ordinary code.
But since export is just user code reorganization, but everything
have to be recompiled anyway, I think that actually there is no
dynamic linking problem regarding exports.
Note that I know nothing about EDG implementation and never
used exports.

Greetings, Branimir.



0
bmaxa209 (243)
5/21/2007 3:04:36 AM
On May 21, 1:11 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> On May 21, 6:53 am, James Kanze <james.ka...@gmail.com> wrote:

> > On May 20, 12:21 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:

> ...
> > > You're not implying being able to export templates are you ?

> > I'm not implying anything.  I'm saying very bluntly and directly
> > that today (2007), there is no real technical reason not to
> > implement export.

> You seem to be sitting on the fence on this one, can you tell us what
> you really think ?

What I just said: there is no real technical reason for not
implementing export today.  It does require a certain amount of
effort (i.e. cost), but nothing a company like Microsoft
couldn't easily afford.

> > ... It means a bit of programming work, but the
> > techniques and the problems are known (thanks to the people at
> > EDG). ...

> A simple matter of programming ?

> Maybe you missed the implied smiley on my previous post however, I
> think there is a little more to it to do it right.

That's true of just about anything:-).  It obviously does
require preliminary design, development of tests, etc., as well
as pure programming.  And like most non-trivial things, it's
easy to get wrong if you aren't careful.  But that's true of a
lot of other things as well---correct implementation of two
phase lookup isn't trivial either, nor is template type
deduction.

> I would not hold
> doing it now on my account.

I rather suspect that it is more than a one man project.  (From
what I understand, it was implemented by a single person at EDG.
But not every company has the chance to have someone that gifted
on their staff.)

> To do export "properly", there needs to be an kernel support if you
> want to support dynamic linking/exporting.

If you want to resolve templates when dynamically linking, yes.
But that's independant of export, and as far as I know, no
implementation supports this for normal templates, either.  I'm
most familiar with the Sun compiler, and their model of template
instantiation, and that would support export without much effort
at that level---the real work is in synthesizing the separate
context in which the template is instantiated---some of that
work is already implicit in two phase look-up, but not all.

> The extra processing cost
> on start-up of dynamically linked libs because of exports needs to be
> worked so that it is not paid for every time a program starts up.  I
> have yet to see an export implementation

Why not?  They're readily available.  Because they're not the
"standard" compiler, or the "mainstream" compiler on any
particular plateform (or are they?  SGI uses the EDG front-end,
I think), it's often very difficult, if not impossible, to
convince management to use them as a production compiler, but
they are certainly available to experiment with.

> but I suspect that debugging
> will need to be worked out as well.

> It also introduces a new failure
> mode, static assert on dynamic link.  I'd need to think through that
> one a little.

Export does *not* mean instantiating templates on dynamic link.
That's an orthogonal issue.  Export means, prinicipally,
compiling templates in a "clean" environment, unpoluted by any
headers I might have included previously.  It means, too, not
triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
projects.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

0
james.kanze (9769)
5/21/2007 7:11:06 AM
James Kanze wrote:
> On May 21, 1:11 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
....
> 
>> To do export "properly", there needs to be an kernel support if you
>> want to support dynamic linking/exporting.
> 
> If you want to resolve templates when dynamically linking, yes.
> But that's independant of export, and as far as I know, no
> implementation supports this for normal templates, either. 

I think your reply indicates I didn't make my point.

> ... I'm
> most familiar with the Sun compiler, and their model of template
> instantiation, and that would support export without much effort
> at that level---the real work is in synthesizing the separate
> context in which the template is instantiated---some of that
> work is already implicit in two phase look-up, but not all.
> 
>> The extra processing cost
>> on start-up of dynamically linked libs because of exports needs to be
>> worked so that it is not paid for every time a program starts up.  I
>> have yet to see an export implementation
> 
> Why not?  They're readily available.  Because they're not the
> "standard" compiler, or the "mainstream" compiler on any
> particular plateform (or are they?  SGI uses the EDG front-end,
> I think), it's often very difficult, if not impossible, to
> convince management to use them as a production compiler, but
> they are certainly available to experiment with.

The coup de gr�ce for export is dynamic libs where the run time dynamic 
linker does it's code generation business.  Entire programs could need 
code generation, and it would be impractical to expect that the code is 
generated upon every invocation.  I take back my kernel support comment 
but you will need some kind of "server" that resolves templates (i.e. 
instantiates them) to share the instantiated application.

The BIG plus in doing this of course is that you can have (in theory) 
platform independant C++ binaries - if the entire application is an 
exported template.

> 
>> but I suspect that debugging
>> will need to be worked out as well.
> 
>> It also introduces a new failure
>> mode, static assert on dynamic link.  I'd need to think through that
>> one a little.
> 
> Export does *not* mean instantiating templates on dynamic link.
> That's an orthogonal issue.  Export means, prinicipally,
> compiling templates in a "clean" environment, unpoluted by any
> headers I might have included previously.

Hmm.  I don't see any relevance in that comment.  I think it's pointless 
having non-dynamic binaries given that almost everything is a dynamic 
binary.

> ...  It means, too, not
> triggering the recompilation of the entire project just because
> a small, implementation detail changes in one
> template---something which makes it almost a must for large
> projects.

That small implementation detail may very well require recompilation of 
the entire applications.

0
gi3nospam (995)
5/21/2007 9:49:38 AM
On May 21, 9:11 am, James Kanze <james.ka...@gmail.com> wrote:
  It means, too, not
> triggering the recompilation of the entire project just because
> a small, implementation detail changes in one
> template---something which makes it almost a must for large
> projects.

I have found this article that says:
"If either the context of the template's instantiation or the context
of the template's definition changes, both get recompiled. That's why,
if the template definition changes, we have to go back to all the
points of instantiation and rebuild those translation units. (In the
case of the EDG compiler, the compiler recompiles all the calling
translation units needed to recreate every distinct specialization, in
order to recreate all of the instantiation contexts, and for each of
those calling translation units it also recompiles the file containing
the template definition in order to recreate the definition context.)
"

http://www.gotw.ca/publications/mill23-x.htm
and this is also interesting:
http://www.ddj.com/showArticle.jhtml?articleID=184401584#1


Greetings, Branimir

0
bmaxa209 (243)
5/21/2007 1:16:57 PM
On May 21, 11:49 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> James Kanze wrote:
> > On May 21, 1:11 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> ...

> >> To do export "properly", there needs to be an kernel support if you
> >> want to support dynamic linking/exporting.

> > If you want to resolve templates when dynamically linking, yes.
> > But that's independant of export, and as far as I know, no
> > implementation supports this for normal templates, either.

> I think your reply indicates I didn't make my point.

> > ... I'm
> > most familiar with the Sun compiler, and their model of template
> > instantiation, and that would support export without much effort
> > at that level---the real work is in synthesizing the separate
> > context in which the template is instantiated---some of that
> > work is already implicit in two phase look-up, but not all.

> >> The extra processing cost
> >> on start-up of dynamically linked libs because of exports needs to be
> >> worked so that it is not paid for every time a program starts up.  I
> >> have yet to see an export implementation

> > Why not?  They're readily available.  Because they're not the
> > "standard" compiler, or the "mainstream" compiler on any
> > particular plateform (or are they?  SGI uses the EDG front-end,
> > I think), it's often very difficult, if not impossible, to
> > convince management to use them as a production compiler, but
> > they are certainly available to experiment with.

> The coup de gr=E2ce for export is dynamic libs where the run time dynamic
> linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation.  (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.)  They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, =E0 la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time.  But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

> Entire programs could need
> code generation, and it would be impractical to expect that the code is
> generated upon every invocation.  I take back my kernel support comment
> but you will need some kind of "server" that resolves templates (i.e.
> instantiates them) to share the instantiated application.

I'm not sure I see your point.  How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures.  And how does export change
anything here?

> The BIG plus in doing this of course is that you can have (in theory)
> platform independant C++ binaries - if the entire application is an
> exported template.

Now you've really lost me.

> >> but I suspect that debugging
> >> will need to be worked out as well.

> >> It also introduces a new failure
> >> mode, static assert on dynamic link.  I'd need to think through that
> >> one a little.

> > Export does *not* mean instantiating templates on dynamic link.
> > That's an orthogonal issue.  Export means, prinicipally,
> > compiling templates in a "clean" environment, unpoluted by any
> > headers I might have included previously.

> Hmm.  I don't see any relevance in that comment.  I think it's pointless
> having non-dynamic binaries given that almost everything is a dynamic
> binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary".  Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

> > ...  It means, too, not
> > triggering the recompilation of the entire project just because
> > a small, implementation detail changes in one
> > template---something which makes it almost a must for large
> > projects.

> That small implementation detail may very well require recompilation of
> the entire applications.

Unless the template in which it changed was exported.  That's
exactly my point.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34


0
james.kanze (9769)
5/21/2007 1:20:18 PM
On May 21, 11:49 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> James Kanze wrote:
> > On May 21, 1:11 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> ...

> >> To do export "properly", there needs to be an kernel support if you
> >> want to support dynamic linking/exporting.

> > If you want to resolve templates when dynamically linking, yes.
> > But that's independant of export, and as far as I know, no
> > implementation supports this for normal templates, either.

> I think your reply indicates I didn't make my point.

> > ... I'm
> > most familiar with the Sun compiler, and their model of template
> > instantiation, and that would support export without much effort
> > at that level---the real work is in synthesizing the separate
> > context in which the template is instantiated---some of that
> > work is already implicit in two phase look-up, but not all.

> >> The extra processing cost
> >> on start-up of dynamically linked libs because of exports needs to be
> >> worked so that it is not paid for every time a program starts up.  I
> >> have yet to see an export implementation

> > Why not?  They're readily available.  Because they're not the
> > "standard" compiler, or the "mainstream" compiler on any
> > particular plateform (or are they?  SGI uses the EDG front-end,
> > I think), it's often very difficult, if not impossible, to
> > convince management to use them as a production compiler, but
> > they are certainly available to experiment with.

> The coup de gr=E2ce for export is dynamic libs where the run time dynamic
> linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation.  (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.)  They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, =E0 la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time.  But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

> Entire programs could need
> code generation, and it would be impractical to expect that the code is
> generated upon every invocation.  I take back my kernel support comment
> but you will need some kind of "server" that resolves templates (i.e.
> instantiates them) to share the instantiated application.

I'm not sure I see your point.  How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures.  And how does export change
anything here?

> The BIG plus in doing this of course is that you can have (in theory)
> platform independant C++ binaries - if the entire application is an
> exported template.

Now you've really lost me.

> >> but I suspect that debugging
> >> will need to be worked out as well.

> >> It also introduces a new failure
> >> mode, static assert on dynamic link.  I'd need to think through that
> >> one a little.

> > Export does *not* mean instantiating templates on dynamic link.
> > That's an orthogonal issue.  Export means, prinicipally,
> > compiling templates in a "clean" environment, unpoluted by any
> > headers I might have included previously.

> Hmm.  I don't see any relevance in that comment.  I think it's pointless
> having non-dynamic binaries given that almost everything is a dynamic
> binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary".  Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

> > ...  It means, too, not
> > triggering the recompilation of the entire project just because
> > a small, implementation detail changes in one
> > template---something which makes it almost a must for large
> > projects.

> That small implementation detail may very well require recompilation of
> the entire applications.

Unless the template in which it changed was exported.  That's
exactly my point.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34


0
james.kanze (9769)
5/21/2007 1:22:49 PM
On May 21, 11:49 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> James Kanze wrote:
> > On May 21, 1:11 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> ...

> >> To do export "properly", there needs to be an kernel support if you
> >> want to support dynamic linking/exporting.

> > If you want to resolve templates when dynamically linking, yes.
> > But that's independant of export, and as far as I know, no
> > implementation supports this for normal templates, either.

> I think your reply indicates I didn't make my point.

> > ... I'm
> > most familiar with the Sun compiler, and their model of template
> > instantiation, and that would support export without much effort
> > at that level---the real work is in synthesizing the separate
> > context in which the template is instantiated---some of that
> > work is already implicit in two phase look-up, but not all.

> >> The extra processing cost
> >> on start-up of dynamically linked libs because of exports needs to be
> >> worked so that it is not paid for every time a program starts up.  I
> >> have yet to see an export implementation

> > Why not?  They're readily available.  Because they're not the
> > "standard" compiler, or the "mainstream" compiler on any
> > particular plateform (or are they?  SGI uses the EDG front-end,
> > I think), it's often very difficult, if not impossible, to
> > convince management to use them as a production compiler, but
> > they are certainly available to experiment with.

> The coup de gr=E2ce for export is dynamic libs where the run time dynamic
> linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation.  (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.)  They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, =E0 la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time.  But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

> Entire programs could need
> code generation, and it would be impractical to expect that the code is
> generated upon every invocation.  I take back my kernel support comment
> but you will need some kind of "server" that resolves templates (i.e.
> instantiates them) to share the instantiated application.

I'm not sure I see your point.  How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures.  And how does export change
anything here?

> The BIG plus in doing this of course is that you can have (in theory)
> platform independant C++ binaries - if the entire application is an
> exported template.

Now you've really lost me.

> >> but I suspect that debugging
> >> will need to be worked out as well.

> >> It also introduces a new failure
> >> mode, static assert on dynamic link.  I'd need to think through that
> >> one a little.

> > Export does *not* mean instantiating templates on dynamic link.
> > That's an orthogonal issue.  Export means, prinicipally,
> > compiling templates in a "clean" environment, unpoluted by any
> > headers I might have included previously.

> Hmm.  I don't see any relevance in that comment.  I think it's pointless
> having non-dynamic binaries given that almost everything is a dynamic
> binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary".  Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

> > ...  It means, too, not
> > triggering the recompilation of the entire project just because
> > a small, implementation detail changes in one
> > template---something which makes it almost a must for large
> > projects.

> That small implementation detail may very well require recompilation of
> the entire applications.

Unless the template in which it changed was exported.  That's
exactly my point.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34


0
james.kanze (9769)
5/21/2007 1:29:51 PM
On May 21, 11:49 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> James Kanze wrote:
> > On May 21, 1:11 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> ...

> >> To do export "properly", there needs to be an kernel support if you
> >> want to support dynamic linking/exporting.

> > If you want to resolve templates when dynamically linking, yes.
> > But that's independant of export, and as far as I know, no
> > implementation supports this for normal templates, either.

> I think your reply indicates I didn't make my point.

> > ... I'm
> > most familiar with the Sun compiler, and their model of template
> > instantiation, and that would support export without much effort
> > at that level---the real work is in synthesizing the separate
> > context in which the template is instantiated---some of that
> > work is already implicit in two phase look-up, but not all.

> >> The extra processing cost
> >> on start-up of dynamically linked libs because of exports needs to be
> >> worked so that it is not paid for every time a program starts up.  I
> >> have yet to see an export implementation

> > Why not?  They're readily available.  Because they're not the
> > "standard" compiler, or the "mainstream" compiler on any
> > particular plateform (or are they?  SGI uses the EDG front-end,
> > I think), it's often very difficult, if not impossible, to
> > convince management to use them as a production compiler, but
> > they are certainly available to experiment with.

> The coup de gr=E2ce for export is dynamic libs where the run time dynamic
> linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation.  (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.)  They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, =E0 la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time.  But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

> Entire programs could need
> code generation, and it would be impractical to expect that the code is
> generated upon every invocation.  I take back my kernel support comment
> but you will need some kind of "server" that resolves templates (i.e.
> instantiates them) to share the instantiated application.

I'm not sure I see your point.  How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures.  And how does export change
anything here?

> The BIG plus in doing this of course is that you can have (in theory)
> platform independant C++ binaries - if the entire application is an
> exported template.

Now you've really lost me.

> >> but I suspect that debugging
> >> will need to be worked out as well.

> >> It also introduces a new failure
> >> mode, static assert on dynamic link.  I'd need to think through that
> >> one a little.

> > Export does *not* mean instantiating templates on dynamic link.
> > That's an orthogonal issue.  Export means, prinicipally,
> > compiling templates in a "clean" environment, unpoluted by any
> > headers I might have included previously.

> Hmm.  I don't see any relevance in that comment.  I think it's pointless
> having non-dynamic binaries given that almost everything is a dynamic
> binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary".  Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

> > ...  It means, too, not
> > triggering the recompilation of the entire project just because
> > a small, implementation detail changes in one
> > template---something which makes it almost a must for large
> > projects.

> That small implementation detail may very well require recompilation of
> the entire applications.

Unless the template in which it changed was exported.  That's
exactly my point.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34


0
james.kanze (9769)
5/21/2007 1:38:37 PM
On May 21, 11:49 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> James Kanze wrote:
> > On May 21, 1:11 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
> ...

> >> To do export "properly", there needs to be an kernel support if you
> >> want to support dynamic linking/exporting.

> > If you want to resolve templates when dynamically linking, yes.
> > But that's independant of export, and as far as I know, no
> > implementation supports this for normal templates, either.

> I think your reply indicates I didn't make my point.

> > ... I'm
> > most familiar with the Sun compiler, and their model of template
> > instantiation, and that would support export without much effort
> > at that level---the real work is in synthesizing the separate
> > context in which the template is instantiated---some of that
> > work is already implicit in two phase look-up, but not all.

> >> The extra processing cost
> >> on start-up of dynamically linked libs because of exports needs to be
> >> worked so that it is not paid for every time a program starts up.  I
> >> have yet to see an export implementation

> > Why not?  They're readily available.  Because they're not the
> > "standard" compiler, or the "mainstream" compiler on any
> > particular plateform (or are they?  SGI uses the EDG front-end,
> > I think), it's often very difficult, if not impossible, to
> > convince management to use them as a production compiler, but
> > they are certainly available to experiment with.

> The coup de gr=E2ce for export is dynamic libs where the run time dynamic
> linker does it's code generation business.

Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation.  (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.)  They just
patch up offsets.

I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, =E0 la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.

I'm not saying that there isn't any value in instantiating
templates at dynamic load time.  But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.

> Entire programs could need
> code generation, and it would be impractical to expect that the code is
> generated upon every invocation.  I take back my kernel support comment
> but you will need some kind of "server" that resolves templates (i.e.
> instantiates them) to share the instantiated application.

I'm not sure I see your point.  How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures.  And how does export change
anything here?

> The BIG plus in doing this of course is that you can have (in theory)
> platform independant C++ binaries - if the entire application is an
> exported template.

Now you've really lost me.

> >> but I suspect that debugging
> >> will need to be worked out as well.

> >> It also introduces a new failure
> >> mode, static assert on dynamic link.  I'd need to think through that
> >> one a little.

> > Export does *not* mean instantiating templates on dynamic link.
> > That's an orthogonal issue.  Export means, prinicipally,
> > compiling templates in a "clean" environment, unpoluted by any
> > headers I might have included previously.

> Hmm.  I don't see any relevance in that comment.  I think it's pointless
> having non-dynamic binaries given that almost everything is a dynamic
> binary.

I disagree. (I'm not 100% sure what you mean by "dynamic
binary".  Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)

But what does the type of binary have to do with the source code
used to generate it?

> > ...  It means, too, not
> > triggering the recompilation of the entire project just because
> > a small, implementation detail changes in one
> > template---something which makes it almost a must for large
> > projects.

> That small implementation detail may very well require recompilation of
> the entire applications.

Unless the template in which it changed was exported.  That's
exactly my point.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34


0
james.kanze (9769)
5/21/2007 2:41:48 PM
"Branimir Maksimovic" <bmaxa@hotmail.com> wrote in message 
news:1179575126.204954.309490@k79g2000hse.googlegroups.com...

> C++ class is same thing as struct.

It would probably be better to make the two concepts (whatever they are) 
separate. If they were different animals, how would you (anyone here) 
distinguish the two for the better?

John 


0
5/22/2007 8:46:33 PM
"James Kanze" <james.kanze@gmail.com> wrote in message 
news:1179731466.398784.300790@x35g2000prf.googlegroups.com...

> What I just said: there is no real technical reason for not
> implementing export today.  It does require a certain amount of
> effort (i.e. cost), but nothing a company like Microsoft
> couldn't easily afford.

And you think that a language spec that only mega-corps can implement is OK?

John 


0
5/22/2007 9:07:31 PM
JohnQ wrote:
> "James Kanze" <james.kanze@gmail.com> wrote in message 
> news:1179731466.398784.300790@x35g2000prf.googlegroups.com...
> 
>> What I just said: there is no real technical reason for not
>> implementing export today.  It does require a certain amount of
>> effort (i.e. cost), but nothing a company like Microsoft
>> couldn't easily afford.
> 
> And you think that a language spec that only mega-corps can implement is OK?
> 

Comeau implements export.  I'd hardly call Comeau a mega-corp.  No 
offense intended to Greg.
0
no.spam9 (2339)
5/22/2007 10:01:33 PM
"red floyd" <no.spam@here.dude> wrote in message 
news:INJ4i.2081$u56.1490@newssvr22.news.prodigy.net...
> JohnQ wrote:
>> "James Kanze" <james.kanze@gmail.com> wrote in message 
>> news:1179731466.398784.300790@x35g2000prf.googlegroups.com...
>>
>>> What I just said: there is no real technical reason for not
>>> implementing export today.  It does require a certain amount of
>>> effort (i.e. cost), but nothing a company like Microsoft
>>> couldn't easily afford.
>>
>> And you think that a language spec that only mega-corps can implement is 
>> OK?
>>
>
> Comeau implements export.  I'd hardly call Comeau a mega-corp.  No offense 
> intended to Greg.

It's already been noted though that they are "gifted" 
(intellectually/technically) over at Comeau. If it's inaccessible to "the 
layman", it's probably just as bad. If 'export' has to do with dynamic 
linking, it sounds like something I want. If it goes "way overboard" into 
binary compatibilty of objects, I can probably do without it.

John 


0
5/22/2007 10:35:03 PM
On May 23, 8:35 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
> "red floyd" <no.s...@here.dude> wrote in message
>
> news:INJ4i.2081$u56.1490@newssvr22.news.prodigy.net...
>
> > JohnQ wrote:
> >> "James Kanze" <james.ka...@gmail.com> wrote in message
> >>news:1179731466.398784.300790@x35g2000prf.googlegroups.com...
>
> >>> What I just said: there is no real technical reason for not
> >>> implementing export today.  It does require a certain amount of
> >>> effort (i.e. cost), but nothing a company like Microsoft
> >>> couldn't easily afford.
>
> >> And you think that a language spec that only mega-corps can implement is
> >> OK?
>
> > Comeau implements export.  I'd hardly call Comeau a mega-corp.  No offense
> > intended to Greg.
>
> It's already been noted though that they are "gifted"
> (intellectually/technically) over at Comeau. If it's inaccessible to "the
> layman", it's probably just as bad. If 'export' has to do with dynamic
> linking, it sounds like something I want. If it goes "way overboard" into
> binary compatibilty of objects, I can probably do without it.
>
> John

It may be easier to implement a binary independant format.  If you're
generating code, you may as well generate all the code rather than
some of the code.

Having said that, there are some interesting new failure modes that
need to be considered.


0
gi3nospam (995)
5/23/2007 1:34:55 AM
weidongtom@gmail.com ha scritto:
> I am a newbie to programming, and sorry again that I have to ask the C
> or C++ questions. Is C required before learning C++? And become better
> in C does it also make you a better C++ programmer? Or that to be a C+
> + programmer, it's better not to have any knowledge of C and start a
> new in the C++ way as some books suggest?

I know many persons that can program in C++, but I don't know a single
C++ professional programmers that cannot program in C.
I think that the only persons that can program in C++ and cannot program
in C are hobbyists or persons who studied programming but never practiced
it as a job.
This comes form the following facts:
* The C programmers and the C++ programmers markets overlap. Often a
company needs a person that is proficient in both, and often C++
programmers are hired to write software in C.
* Many libraries used by C++ programs have a C interface.
* Many libraries built using C++ must have a C interface.
* A lot of code, originally written in C, now has parts in C++ and parts
in C or in C-like C++.
* Many (old) programmers used C in the eighties and nineties and then
migrated to C++.

Therefore, I recommend to learn also C to everyone who wants to become a
professional C++ programmer. It's not important to order, but it's
better to know both.

In addition, I think it's far easier to learn C++ when you know C, than
when you know only another language. But it's also far easier to learn C
when you know C++. So the time to learn both is much shorter than the
sum of the times to learn each of them.

And I think there are never concepts to be "unlearn", just to be "set
aside". For instance, many say "in C++ you should forget about malloc";
but a lot of literature talks about malloc, and if you don't have an
idea of what it's talking about, you can't understand that literature.

-- 
     Carlo Milanesi
     http://digilander.libero.it/carlmila
0
7/5/2007 6:13:06 AM
Carlo Milanesi pisze:
> weidongtom@gmail.com ha scritto:
>> I am a newbie to programming, and sorry again that I have to ask the C
>> or C++ questions. Is C required before learning C++? And become better
>> in C does it also make you a better C++ programmer? Or that to be a C+
>> + programmer, it's better not to have any knowledge of C and start a
>> new in the C++ way as some books suggest?
> 
> I know many persons that can program in C++, but I don't know a single
> C++ professional programmers that cannot program in C.
> I think that the only persons that can program in C++ and cannot program
> in C are hobbyists or persons who studied programming but never practiced
> it as a job.
> This comes form the following facts:
> * The C programmers and the C++ programmers markets overlap. Often a
> company needs a person that is proficient in both, and often C++
> programmers are hired to write software in C.
> * Many libraries used by C++ programs have a C interface.
> * Many libraries built using C++ must have a C interface.
> * A lot of code, originally written in C, now has parts in C++ and parts
> in C or in C-like C++.
> * Many (old) programmers used C in the eighties and nineties and then
> migrated to C++.
> 
> Therefore, I recommend to learn also C to everyone who wants to become a
> professional C++ programmer. It's not important to order, but it's
> better to know both.
> 
> In addition, I think it's far easier to learn C++ when you know C, than
> when you know only another language. But it's also far easier to learn C
> when you know C++. So the time to learn both is much shorter than the
> sum of the times to learn each of them.
> 
> And I think there are never concepts to be "unlearn", just to be "set
> aside". For instance, many say "in C++ you should forget about malloc";
> but a lot of literature talks about malloc, and if you don't have an
> idea of what it's talking about, you can't understand that literature.
> 

Don't listen this bullshits!
An antiquated C language is now outdated and only old lazy coders who 
can't understand and learn object oriented languages seek naive persons 
to hire them as a new C programmers. It is fully understood from their 
perspective because otherwise these lazy C-guys would share dinosaurs' 
fate along with rubbish C language.
Don't listen anything about C superiority and popularity. All things you 
can do in C can also be done in C++ in much simpler and secure way! In 
reality now 95% professional code is written in C++ not C. Only in so 
called GNU programing area C and C++ are equals.
0
7/5/2007 11:50:49 AM
Herhor wrote:
> An antiquated C language is now outdated and only old lazy coders who 
> can't understand and learn object oriented languages seek naive persons 
> to hire them as a new C programmers.
Are coders who seek persons to hire as programmers? No, they are 
managers or businessmen.

> In reality now 95% professional code is written in C++ not C.
Where did you get such figures? I look here, where C looks still more 
popular than C++:
http://www.tiobe.com/index.htm?tiobe_index
Perhaps, most C programmers now build embedded systems or device 
drivers, and few build applications for Windows or Unix, but 
nevertheless they are professional computer programmers.

-- 
     Carlo Milanesi
     http://digilander.libero.it/carlmila
0
7/5/2007 4:56:15 PM
Carlo Milanesi pisze:
> Herhor wrote:
>> An antiquated C language is now outdated and only old lazy coders who 
>> can't understand and learn object oriented languages seek naive 
>> persons to hire them as a new C programmers.
> Are coders who seek persons to hire as programmers? No, they are 
> managers or businessmen.
>

It is simple! There are business managers who hired old C coders to seek 
naive beginning programmers to hire them as their programming in C 
successors.

>> In reality now 95% professional code is written in C++ not C.
> Where did you get such figures? I look here, where C looks still more 
> popular than C++:
> http://www.tiobe.com/index.htm?tiobe_index
> Perhaps, most C programmers now build embedded systems or device 
> drivers, and few build applications for Windows or Unix, but 
> nevertheless they are professional computer programmers.
> 

Because I didn't take into account programming cell phones, iPods, 
microwave kitchens and similar shit but computer systems only.
Moreover, firstly as for now C competes mainly _with Java_ not C++ in 
the embedded systems area, secondly _many people_ don't know that it is 
possible to write OS kernels, device drivers or embedded programs in C++ 
which are *more compact and efficient* than similar ones wrote in C!
0
7/5/2007 5:55:48 PM
Carlo Milanesi pisze:
  >> In reality now 95% professional code is written in C++ not C.
> I look here, where C looks still more popular than C++:
> http://www.tiobe.com/index.htm?tiobe_index
>

Additionally this rating is idiotic!
How can they compare native programming languages (C, C+), interpreted 
languages (C#, Java) and Internet script pseudo-languages (PHP, Perl, 
Javascript) regardless of their structural differences and very diverse 
area of application???

0
7/5/2007 6:18:30 PM
Carlo Milanesi wrote:

> Herhor wrote:

> > In reality now 95% professional code is written in C++ not C.
> Where did you get such figures? 

This guy's a troll, just ignore him.




Brian
0
defaultuserbr (3656)
7/5/2007 6:19:34 PM
On Jul 5, 2:50 pm, Herhor <herhor_ANTYSP...@onet.eu> wrote:
> Don't listen this bullshits!

:)


> An antiquated C language is now outdated and only old lazy coders who
> can't understand and learn object oriented languages seek naive persons
> to hire them as a new C programmers. It is fully understood from their
> perspective because otherwise these lazy C-guys would share dinosaurs'
> fate along with rubbish C language.

Don't we all know that? We subscribe to comp.lang.c++, the point isn't
if we agree with your "evaluation" above, but if it is relevant to the
real world. Like it or not, C is still around and pooping on the
parties all around the coding world. WIN32. C. OpenGL. C. On and on.
It just keeps coming up.

If you don't know about C, and how it relates to C++, how can you know
that passing address-of std::vector<float> isn't the Right Thing to do
for ::glVertexAttribPointer4fv ? You don't; and you're FUCKED.

I said I don't like C much? I have to use it anyway. It's used for ARM
development in hand helds a great deal. Symbian might be really
perverted C++, but the tools are so *****ing old that it can hardly be
called C++ .. but that's different sad story in itself.

You're right from your point of view; YOU don't need C, right, so I'm
curious, what DO you program? What tools you use, what software you
write precisely that you don't need C knowledge. At all.

0
jukka (294)
7/5/2007 7:16:23 PM
Default User pisze:
> Carlo Milanesi wrote:
> 
>> Herhor wrote:
> 
>>> In reality now 95% professional code is written in C++ not C.
>> Where did you get such figures? 
> 
> This guy's a troll, just ignore him.
> 

Take a running jump on your museum c.l.c group, nonagenarian!

0
7/5/2007 7:20:32 PM
persenaama pisze:
> 
> Like it or not, C is still around and pooping on the
> parties all around the coding world. WIN32. C. OpenGL. C. On and on.
> It just keeps coming up.
> 

Are you serious??? So migrate to the "comp.lang.c-ircus" then! You will 
find several other funny weirdos there! :)

> 
> I said I don't like C much? I have to use it anyway. 
> 

If so, it simply proves you don't know C++ *at all*, buddy! :)

> You're right from your point of view; YOU don't need C, right, so I'm
> curious, what DO you program? What tools you use, what software you
> write precisely that you don't need C knowledge. At all.
> 

I am coding many things in C++ without C knowledge (except their 
partially common instruction set of course) in contrary to your coding 
work which seems to be centered on programming /speaking dolls/ only! :)
0
7/5/2007 7:34:56 PM
persenaama wrote:
:: On Jul 5, 2:50 pm, Herhor <herhor_ANTYSP...@onet.eu> wrote:
::: Don't listen this bullshits!
::
:: :)
::
::
::: An antiquated C language is now outdated and only old lazy coders
::: who can't understand and learn object oriented languages seek
::: naive persons to hire them as a new C programmers. It is fully
::: understood from their perspective because otherwise these lazy
::: C-guys would share dinosaurs' fate along with rubbish C language.
::
:: Don't we all know that? We subscribe to comp.lang.c++, the point
:: isn't if we agree with your "evaluation" above, but if it is
:: relevant to the real world. Like it or not, C is still around and
:: pooping on the parties all around the coding world. WIN32. C.
:: OpenGL. C. On and on. It just keeps coming up.
::
:: If you don't know about C, and how it relates to C++, how can you
:: know that passing address-of std::vector<float> isn't the Right
:: Thing to do for ::glVertexAttribPointer4fv ? You don't; and you're
:: FUCKED.

If you have learned proper C++, you would never have come up with the 
idea of passing the address of a std::vector in the first place.

If you want to learn C, learn C.

If you want to learn C++, learn C++.

If you want to learn Java, learn Java.


The fact that these languages have a few braces and type names in 
common, does not mean that learning one of them is any advantage when 
learning another one. On the contrary!


Bo Persson


0
bop (1086)
7/5/2007 9:34:14 PM
Bo Persson pisze:
> :: If you don't know about C, and how it relates to C++, how can you
> :: know that passing address-of std::vector<float> isn't the Right
> :: Thing to do for ::glVertexAttribPointer4fv ? You don't; and you're
> :: FUCKED.
> 
> If you have learned proper C++, you would never have come up with the 
> idea of passing the address of a std::vector in the first place.
> 

Right!
Recently too many ridiculous guys here claim to be fluent in all 
programming languages with "/old good C/" in the forefront of others. 
However they don't know much _about any of them_. Yet in closer look 
these omniscient braggarts often are permanent habitu�s of 
"comp.lang.c-ircus" newsgroup. :)
0
7/5/2007 10:28:36 PM
On Jul 5, 10:34 pm, Herhor <herhor_ANTYSP...@onet.eu> wrote:
> Are you serious??? So migrate to the "comp.lang.c-ircus" then! You will
> find several other funny weirdos there! :)

Why would I? Do you have reading comprehension troubles, I said I
don't like C.


> > I said I don't like C much? I have to use it anyway.
>
> If so, it simply proves you don't know C++ *at all*, buddy! :)

How that proves I don't know C++ at all, please be more specific.


> > You're right from your point of view; YOU don't need C, right, so I'm
> > curious, what DO you program? What tools you use, what software you
> > write precisely that you don't need C knowledge. At all.
>
> I am coding many things in C++ without C knowledge (except their
> partially common instruction set of course) in contrary to your coding
> work which seems to be centered on programming /speaking dolls/ only! :)

You didn't answer the question; "many things" isn't really an answer.
What do you program using C++?

0
jukka (294)
7/6/2007 8:50:59 AM
On Jul 6, 12:34 am, "Bo Persson" <b...@gmb.dk> wrote:
> The fact that these languages have a few braces and type names in
> common, does not mean that learning one of them is any advantage when
> learning another one. On the contrary!

C and C++ have more than just few braces and type names in common; one
is the subset of the other.

0
jukka (294)
7/6/2007 8:54:50 AM
persenaama wrote:
:: On Jul 6, 12:34 am, "Bo Persson" <b...@gmb.dk> wrote:
::: The fact that these languages have a few braces and type names in
::: common, does not mean that learning one of them is any advantage
::: when learning another one. On the contrary!
::
:: C and C++ have more than just few braces and type names in common;
:: one is the subset of the other.

In theory yes, but in practice there are large parts of the C subset 
that isn't very useful in C++. Why bother to learn about things like:

malloc and strcpy
why s1 == s2 is different from strcmp(s1, s2)
why you have library functions named abs, fabs, labs, cabs, etc - why 
not just overload abs?
what does printf("/!%%!%�#") really mean (if anything)
how to use an address passed by value to simulate a pass by reference
how to use name prefixes to simulate namespaces
how to use variadic functions instead of overloads with different 
number of parameters



Bo Persson


0
bop (1086)
7/6/2007 3:09:12 PM
Bo Persson pisze:
>> persenaama wrote:
>> C and C++ have more than just few braces and type names in common;
>> one is the subset of the other.
> 
> In theory yes, but in practice there are large parts of the C subset 
> that isn't very useful in C++. Why bother to learn about things like:
> 
> malloc and strcpy
> why s1 == s2 is different from strcmp(s1, s2)
> why you have library functions named abs, fabs, labs, cabs, etc - why 
> not just overload abs?
> what does printf("/!%%!%�#") really mean (if anything)
> how to use an address passed by value to simulate a pass by reference
> how to use name prefixes to simulate namespaces
> how to use variadic functions instead of overloads with different 
> number of parameters
> 

And many, many more!

I see only one reason to learn all above useless shit: to become _dorky 
member_ of "comp.lang.c-ircus" *squirrely newsgroup*! :)
0
7/6/2007 3:38:58 PM
Herhor wrote:
> Bo Persson pisze:
>>> persenaama wrote:
>>> C and C++ have more than just few braces and type names in common;
>>> one is the subset of the other.
>>
>> In theory yes, but in practice there are large parts of the C subset 
>> that isn't very useful in C++. Why bother to learn about things like:
>>
>> malloc and strcpy
>> why s1 == s2 is different from strcmp(s1, s2)

This is still the case in C++ unless s1 and s2 are something
else than character strings!

>> why you have library functions named abs, fabs, labs, cabs, etc - why 
>> not just overload abs?

Well, abs *is* overloaded in C.

One of the thing it would be nice in this discussion is that
you would know what you are talking about.

>> what does printf("/!%%!%�#") really mean (if anything)
>> how to use an address passed by value to simulate a pass by reference
>> how to use name prefixes to simulate namespaces

Namespaces are easy to do that way.
Why complicate the language unnecessarily?

>> how to use variadic functions instead of overloads with different 
>> number of parameters
>>
> 
> And many, many more!
> 
> I see only one reason to learn all above useless shit: to become _dorky 
> member_ of "comp.lang.c-ircus" *squirrely newsgroup*! :)

I agree that many members of that newsgroup have weird views, and I have
been atacked by those people a number of times...

But the problem is not those people. It is that those people have
reduced that group to a forum for themselves, and the users of
C that are open minded are completely discouraged to participate.
0
jacob (2541)
7/6/2007 4:06:23 PM
"jacob navia" wrote:

>>> why you have library functions named abs, fabs, labs, cabs, etc - why 
>>> not just overload abs?
>
> Well, abs *is* overloaded in C.

Do you have some private meaning for "overloaded" that the rest of don't 
share?

Or what? 


0
r124c4u1022 (2303)
7/6/2007 4:15:19 PM
osmium wrote:
> "jacob navia" wrote:
> 
>>>> why you have library functions named abs, fabs, labs, cabs, etc - why 
>>>> not just overload abs?
>> Well, abs *is* overloaded in C.
> 
> Do you have some private meaning for "overloaded" that the rest of don't 
> share?
> 
> Or what? 
> 
> 

In the C standard, the tgmath.h header file is specified.
That header file specifies that "abs" should accept float/double/long
double/ arguments and should internally call absf, etc etc.

Many other functions like sqrt are specified in this "overloaded" way.

Some C compilers go beyond that and accept

int overloaded fn(/* args */);

for true overloaded functions, for instance lcc-win32.

jacob
0
jacob (2541)
7/6/2007 4:18:58 PM
jacob navia pisze:
> 
> I agree that many members of that newsgroup have weird views, and I have
> been atacked by those people a number of times...
> 
> But the problem is not those people. It is that those people have
> reduced that group to a forum for themselves, and the users of
> C that are open minded are completely discouraged to participate.

Yes, I discovered this after participating _just in one thread_. This 
narrow-minded clique together with their bozo newsgroup should be 
ignored or kicked ass around if they insult someone too much.

However there is another moderated newsgroup about C. Is it also 
controlled by these jerks???
0
7/6/2007 4:35:14 PM
* Bo Persson:
> In theory yes, but in practice there are large parts of the C subset 
> that isn't very useful in C++. Why bother to learn about things like:
>
> malloc and strcpy

Malloc is debateable, but not knowing about strcpy implies not knowing
about char * strings, which implies not knowing exactly why std::string
sucks so bad.

Oh, and not knowing about strcpy is not knowing why you should be using
strncpy to begin with.

> why s1 == s2 is different from strcmp(s1, s2)

Because it implies not knowing the difference between pointers and 
whatever they point to.

> why you have library functions named abs, fabs, labs, cabs, etc - why 
> not just overload abs?

Because they don't do what you want. 

> what does printf("/!%%!%�#") really mean (if anything)

More than <<'ing an iostream *EVER* give you. 

> how to use an address passed by value to simulate a pass by reference

That's nonsense, as this applies to C++ just as bad. If you never had
to pass an object by means of passing a pointer, you never did any programming
besides

std::cout << "hello world" << std::endl

References are *NOT* pointers, pointers are *NOT* bodged references. 

> how to use name prefixes to simulate namespaces

This is the *ONLY* one of your arguments that's not severely flawed or plain
wrong.

> how to use variadic functions instead of overloads with different 
> number of parameters

Because they're not the same.
-- 
Martijn van Buul - pino@dohd.org 
0
pino (81)
7/6/2007 5:12:39 PM
On Jul 6, 6:09 pm, "Bo Persson" <b...@gmb.dk> wrote:
> In theory yes, but in practice there are large parts of the C subset
> that isn't very useful in C++. Why bother to learn about things like:

Because these "things" are C++? It's up to anyone to choose how much
of any language they wish to learn and use. I don't use all of C++;
for example I don't use export and can get work done just fine, if not
better without it.

So you're saying it's better to know less? Or if you are saying:
"don't bother wasting time learning something you will likely have
very little use for" then I would agree 100% -- it's folly to learn
something obfuscated and obsolete, sure. But that is a far cry from
understanding the differences between C and C++ for the areas where
these two overlap.

With the processing power we got these days, it is more safe to say
that both C and C++ are less relevant than they used to. We don't
really need so fine grain control for most of the tasks we do as long
as the binary that actually does time critical sections of processing
is well crafted (in any language).

0
jukka (294)
7/6/2007 5:27:53 PM
persenaama wrote:
:: On Jul 6, 6:09 pm, "Bo Persson" <b...@gmb.dk> wrote:
::: In theory yes, but in practice there are large parts of the C
::: subset that isn't very useful in C++. Why bother to learn about
::: things like:
::
:: Because these "things" are C++?

In theory yes, but in practice no.  :-)

They are hardly ever useful, so why start by learning those?

In C++ we have std::string, std::vector, and the standard library. We 
don't need to START with learning about char*, malloc, strcmp, and 
pointers. Or that you cannot overload functions in C (but that the 
standard library can, using "magic macros").

::It's up to anyone to choose how
:: much of any language they wish to learn and use. I don't use all
:: of C++; for example I don't use export and can get work done just
:: fine, if not better without it.
::
:: So you're saying it's better to know less? Or if you are saying:
:: "don't bother wasting time learning something you will likely have
:: very little use for" then I would agree 100% -- it's folly to learn
:: something obfuscated and obsolete, sure. But that is a far cry from
:: understanding the differences between C and C++ for the areas where
:: these two overlap.

I was saying that it you want to learn C++, start learning C++.

The fact that C and Java might resemble C++, doesn't say that you 
should start by learning one of those. Or that knowing the differences 
between the languages is important if you just want to learn C++.


Bo Persson


0
bop (1086)
7/6/2007 11:49:26 PM
On Jul 7, 2:49 am, "Bo Persson" <b...@gmb.dk> wrote:
> :: Because these "things" are C++?
>
> In theory yes, but in practice no.  :-)

This is getting tiring. I call the Authority Card into play;
Stroustrup says himself the following, <quote>:

C++ is a direct descendant of C that retains almost all of C as a
subset. C++ provides stronger type checking than C and directly
supports a wider range of programming styles than C. C++ is "a better
C" in the sense that it supports the styles of programming done using
C with better type checking and more notational support (without loss
of efficiency). In the same sense, ANSI C is a better C than K&R C. In
addition, C++ supports data abstraction, object-oriented programming,
and generic programming (see The C++ Programming Language (3rd
Edition)"; Appendix B discussing compatibility issues is available for
downloading).

I have never seen a program that could be expressed better in C than
in C++ (and I don't think such a program could exist - every construct
in C has an obvious C++ equivalent). However, there still exist a few
environments where the support for C++ is so weak that there is an
advantage to using C instead.

For a discussion of the design of C++ including a discussion of its
relationship with C see The Design and Evolution of C++.

Please note that "C" in the paragraphs above refers to Classic C and
C89. C++ is not a descendant of C99; C++ and C99 are siblings. C99
introduces several novel opportunities for C/C++ incompatibilities.
Here is a description of the differences between C++98 and C99.

<end quote>

0
jukka (294)
7/7/2007 12:17:27 AM
On Jul 6, 7:49 pm, "Bo Persson" <b...@gmb.dk> wrote:
> persenaama wrote:
>
> :: On Jul 6, 6:09 pm, "Bo Persson" <b...@gmb.dk> wrote:
> ::: In theory yes, but in practice there are large parts of the C
> ::: subset that isn't very useful in C++. Why bother to learn about
> ::: things like:
> ::
> :: Because these "things" are C++?
>
> In theory yes, but in practice no.  :-)
>
> They are hardly ever useful, so why start by learning those?
>
> In C++ we have std::string, std::vector, and the standard library. We
> don't need to START with learning about char*, malloc, strcmp, and
> pointers. Or that you cannot overload functions in C (but that the
> standard library can, using "magic macros").
>
> ::It's up to anyone to choose how
> :: much of any language they wish to learn and use. I don't use all
> :: of C++; for example I don't use export and can get work done just
> :: fine, if not better without it.
> ::
> :: So you're saying it's better to know less? Or if you are saying:
> :: "don't bother wasting time learning something you will likely have
> :: very little use for" then I would agree 100% -- it's folly to learn
> :: something obfuscated and obsolete, sure. But that is a far cry from
> :: understanding the differences between C and C++ for the areas where
> :: these two overlap.
>
> I was saying that it you want to learn C++, start learning C++.
>
> The fact that C and Java might resemble C++, doesn't say that you
> should start by learning one of those. Or that knowing the differences
> between the languages is important if you just want to learn C++.
>
Your ignorant view only shows how poor a C++ programmer you are.  You
clearly don't know what select() is, what system calls are, or never
write any multithread applications.

Programming languages are evolved from assembly to C to C++.  It is
true for an average C++ programmer like you, you only need to learn C+
+ to write mediocre high-level applications.  But for large and high
performance applications, you have to use asynchronous I/O, signals,
and threads which require C knowledge.  If you really want to know how
this works, you need know assembly.  Let me put this way:

the average C++ programmers don't know C
the good C++ programmers know C
the best C++ programmer know assembly as well as C



0
7/7/2007 1:51:47 AM
> On Jul 7, 6:51 am, "davideng2...@yahoo.com" <davideng2...@yahoo.com> wrote:


> Programming languages are evolved from assembly to C to C++.  It is
> true for an average C++ programmer like you, you only need to learn C+
> + to write mediocre high-level applications.  But for large and high
> performance applications, you have to use asynchronous I/O, signals,
> and threads which require C knowledge.  If you really want to know how
> this works, you need know assembly.  Let me put this way:

RIGHT... but that is for becoming an excellent C++ programmer, not for
a person who is just doing a job in the field of C++ application
programming .



> the average C++ programmers don't know C
> the good C++ programmers know C
> the best C++ programmer know assembly as well as C

GREAT... i am impressed. i never understood why there are no
discussion like "should i learn Assembly along with C++" because my
experience says, once you know assembly it is easier to tackle both C
and C++. all i see are "C or C++ arguments". personally i think
retaining C as subset in C++ was the poor idea. Stroustrup could have
created C++ as a new language for system programming with lessons
learnt from C  but he did not :-(.

YES... i say people must learn Assembly if they truly aspire to
understand programming. IMVVHO, your 3rd point of "best C++
programmer" is quite right :-)

0
geek.arnuld (542)
7/7/2007 5:48:38 AM
persenaama <jukka@liimatta.org> wrote:
> On Jul 7, 2:49 am, "Bo Persson" <b...@gmb.dk> wrote:
>> :: Because these "things" are C++?
>>
>> In theory yes, but in practice no.  :-)
> 
> This is getting tiring. I call the Authority Card into play;
> Stroustrup says himself the following, <quote>:
> 
> C++ is a direct descendant of C that retains almost all of C as a
> subset.

He also says:

   Knowing C is a prerequisite for learning C++, right?

   Wrong.  The common subset of C and C++ is easier to learn than C.
   There will be less type errors to catch manually (the C++ type system
   is stricter and more expressive), fewer tricks to learn (C++ allows
   you to express more things without circumlocution), and better
   libraries available.  The best initial subset of C++ to learn is not
   "all of C".

http://www.research.att.com/~bs/bs_faq.html#prerequisite

-- 
Marcus Kwok
Replace 'invalid' with 'net' to reply
0
ricecake6398 (573)
7/9/2007 3:09:19 PM
On Jul 9, 6:09 pm, ricec...@gehennom.invalid (Marcus Kwok) wrote:
> persenaama <j...@liimatta.org> wrote:
> > On Jul 7, 2:49 am, "Bo Persson" <b...@gmb.dk> wrote:
> >> :: Because these "things" are C++?
>
> >> In theory yes, but in practice no.  :-)
>
> > This is getting tiring. I call the Authority Card into play;
> > Stroustrup says himself the following, <quote>:
>
> > C++ is a direct descendant of C that retains almost all of C as a
> > subset.
>
> He also says:

It's already been established that C++ is subset of C.

What else he says is not relevant AS I AM NOT OPPOSING OR DEFENDING
ANY SPECIFIC interpretation of people's OPINIONS. My opinion is that
*I* am better with knowing more languages, more skilled, more demand
for my skills in the market out there. If someone is fine without C,
that's his experience and opinion, they are not necessarily same as
mine. Duh?

I for one would LOVE if people read what I write without jumping into
conclusions. Take care.

<3 <3 --persenaama

0
jukka (294)
7/9/2007 3:39:25 PM
persenaama wrote:
> [..]
> It's already been established that C++ is subset of C.
> [..]
> I for one would LOVE if people read what I write without jumping into
> conclusions. Take care.

Conclusions?  Like that you're either inattentive or dislexic when you
are angry?  Why the hell would I read what you write if not to jump to
conclusions?  Just to waste my time?  Ppppleez... 


0
v.Abazarov (13256)
7/9/2007 5:59:15 PM
In article <468e68a0$0$27385$ba4acef3@news.orange.fr>, jacob navia 
<jacob@jacob.remcomp.fr> writes
>>  And many, many more!
>>  I see only one reason to learn all above useless shit: to become 
>>_dorky  member_ of "comp.lang.c-ircus" *squirrely newsgroup*! :)
>
>I agree that many members of that newsgroup have weird views, and I have
>been atacked by those people a number of times...
>
>But the problem is not those people. It is that those people have
>reduced that group to a forum for themselves, and the users of
>C that are open minded are completely discouraged to participate.

Very true.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



0
chris32 (3361)
7/9/2007 6:20:45 PM
On Jul 9, 8:59 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
> persenaama wrote:
> > [..]
> > It's already been established that C++ is subset of C.
> > [..]
> > I for one would LOVE if people read what I write without jumping into
> > conclusions. Take care.
>
> Conclusions?  Like that you're either inattentive or dislexic when you
> are angry?  Why the hell would I read what you write if not to jump to
> conclusions?  Just to waste my time?  Ppppleez...

Wrong conclucions; looks like the guy was writing to some kind of  pro
C fanatic, which ain't me. I'm saying C skill is relevant with C++ in
a lot of programming tasks beyond the scope of the C++ standard
document (think concrete applications and similar).

C++ is a subset of C. That's a fact; I don't see that being contested
just some random noise which changes nothing.

0
jukka (294)
7/9/2007 7:37:51 PM
persenaama <jukka@liimatta.org> wrote:
> C++ is a subset of C. That's a fact; I don't see that being contested
> just some random noise which changes nothing.

I think you have it backwards.  I would say that C is (mostly) a subset
of C++.  Maybe you meant to say that C++ is a *superset* of C?

-- 
Marcus Kwok
Replace 'invalid' with 'net' to reply
0
ricecake6398 (573)
7/9/2007 7:57:36 PM
On Jul 9, 10:57 pm, ricec...@gehennom.invalid (Marcus Kwok) wrote:
> persenaama <j...@liimatta.org> wrote:
> > C++ is a subset of C. That's a fact; I don't see that being contested
> > just some random noise which changes nothing.
>
> I think you have it backwards.  I would say that C is (mostly) a subset
> of C++.  Maybe you meant to say that C++ is a *superset* of C?

Maybe I do. They call the parts of C++ that are similar to C89 "C
subset of C++", and Stroustrup was even more precise in his wording.
I'm under the opinion that backwards or forwards, the C subset of C++
is pretty important part of C++ to know.

I'm sorry if this opinion offends you so grealy that it requires four
follow ups so far. Just kidding, I'm not so sorry. :) :)

0
jukka (294)
7/9/2007 8:17:41 PM
Chris Hills wrote:

> In article <468e68a0$0$27385$ba4acef3@news.orange.fr>, jacob navia
> <jacob@jacob.remcomp.fr> writes >> And many, many more!
> > > I see only one reason to learn all above useless shit: to become
> > > _dorky  member_ of "comp.lang.c-ircus" *squirrely newsgroup*! :)
> > 
> > I agree that many members of that newsgroup have weird views, and I
> > have been atacked by those people a number of times...
> > 
> > But the problem is not those people. It is that those people have
> > reduced that group to a forum for themselves, and the users of
> > C that are open minded are completely discouraged to participate.
> 
> Very true.

Yeah, you two would think so. Jacob and Chris would like to "expand"
the C newsgroup to include platform-specific topics. There, as here,
that is considered undesirable.




Brian
0
defaultuserbr (3656)
7/9/2007 9:18:37 PM
On Jul 7, 1:48 am, arnuld <geek.arn...@gmail.com> wrote:
> Stroustrup could have created C++ as a new language for
> system programming with lessons learnt from C but he did not :-(.

Had he done that, it is very likely this group wouldn't exist today in
its present forum. Had Stroustrup not catered to the C community, C++
would never have been accepted by the C community (at that time),
something essential to the future success of C++. Stroustrup
acknowledges this in his book "The Design and Evolution of C++".

If you are going to criticize him for his decisions you should first
understand what influenced those decisions. Any serious C++ developer
should read this book. More importantly, anyone who decides to
criticize C++, Stroustrup or his decisions, and have some sense of
credibility doing it, should read this book first. Hindsight is always
20-20; all is not as it seems.

0
gpuchtel (28)
7/9/2007 9:24:40 PM
Default User wrote:
> Chris Hills wrote:
> 
>> In article <468e68a0$0$27385$ba4acef3@news.orange.fr>, jacob navia
>> <jacob@jacob.remcomp.fr> writes >> And many, many more!
>>>> I see only one reason to learn all above useless shit: to become
>>>> _dorky  member_ of "comp.lang.c-ircus" *squirrely newsgroup*! :)
>>> I agree that many members of that newsgroup have weird views, and I
>>> have been atacked by those people a number of times...
>>>
>>> But the problem is not those people. It is that those people have
>>> reduced that group to a forum for themselves, and the users of
>>> C that are open minded are completely discouraged to participate.
>> Very true.
> 
> Yeah, you two would think so. Jacob and Chris would like to "expand"
> the C newsgroup to include platform-specific topics. There, as here,
> that is considered undesirable.
> 
> 
> 
> 
> Brian

This is not true. But there is no gain to discuss with you.
I have had my dose with the C group...
0
jacob (2541)
7/9/2007 10:04:25 PM
Default User pisze:
> 
> Yeah, you two would think so. Jacob and Chris would like to "expand"
> the C newsgroup to include platform-specific topics. There, as here,
> that is considered undesirable.
> 

It seems you are also undesirable on this newsgroup by many!

So in lieu of insulting this two guys here take a running jump to your 
default C-ircus, fossil!
0
7/10/2007 12:03:20 AM
In article <5ffn1dF3cdvgsU1@mid.individual.net>, Default User 
<defaultuserbr@yahoo.com> writes
>Chris Hills wrote:
>
>> In article <468e68a0$0$27385$ba4acef3@news.orange.fr>, jacob navia
>> <jacob@jacob.remcomp.fr> writes >> And many, many more!
>> > > I see only one reason to learn all above useless shit: to become
>> > > _dorky  member_ of "comp.lang.c-ircus" *squirrely newsgroup*! :)
>> >
>> > I agree that many members of that newsgroup have weird views, and I
>> > have been atacked by those people a number of times...
>> >
>> > But the problem is not those people. It is that those people have
>> > reduced that group to a forum for themselves, and the users of
>> > C that are open minded are completely discouraged to participate.
>>
>> Very true.
>
>Yeah, you two would think so. Jacob and Chris would like to "expand"
>the C newsgroup to include platform-specific topics. There, as here,
>that is considered undesirable.

I just have a slightly wider view of clc  than a small group of net 
nannies who spend more time screaming "OT"  than any thing else.  Though 
they bend the rule of "standard C"  to make it anything from K&R1 to 
past the present standard. But not any standards they don't like
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



0
chris32 (3361)
7/10/2007 7:33:23 AM
Dnia 10-07-2007 o 09:33:23 Chris Hills <chris@phaedsys.org> napisa�(a):

> In article <5ffn1dF3cdvgsU1@mid.individual.net>, Default User  
> <defaultuserbr@yahoo.com> writes
>> Chris Hills wrote:
>>
>>> In article <468e68a0$0$27385$ba4acef3@news.orange.fr>, jacob navia
>>> <jacob@jacob.remcomp.fr> writes >> And many, many more!
>>> > > I see only one reason to learn all above useless shit: to become
>>> > > _dorky  member_ of "comp.lang.c-ircus" *squirrely newsgroup*! :)
>>> >
>>> > I agree that many members of that newsgroup have weird views, and I
>>> > have been atacked by those people a number of times...
>>> >
>>> > But the problem is not those people. It is that those people have
>>> > reduced that group to a forum for themselves, and the users of
>>> > C that are open minded are completely discouraged to participate.
>>>
>>> Very true.
>>
>> Yeah, you two would think so. Jacob and Chris would like to "expand"
>> the C newsgroup to include platform-specific topics. There, as here,
>> that is considered undesirable.
>
> I just have a slightly wider view of clc  than a small group of net  
> nannies who spend more time screaming "OT"  than any thing else.  Though  
> they bend the rule of "standard C"  to make it anything from K&R1 to  
> past the present standard. But not any standards they don't like


Just ignore this SENSLESS madman!
0
7/10/2007 12:46:05 PM
Chris Hills wrote:

> In article <5ffn1dF3cdvgsU1@mid.individual.net>, Default User
> <defaultuserbr@yahoo.com> writes
> > Chris Hills wrote:
> > 
> > > In article <468e68a0$0$27385$ba4acef3@news.orange.fr>, jacob navia
> >><jacob@jacob.remcomp.fr> writes >> And many, many more!
> >>> > I see only one reason to learn all above useless shit: to become
> >>> > _dorky  member_ of "comp.lang.c-ircus" *squirrely newsgroup*! :)
> > > > 
> >>> I agree that many members of that newsgroup have weird views, and
> I >>> have been atacked by those people a number of times...
> > > > 
> >>> But the problem is not those people. It is that those people have
> >>> reduced that group to a forum for themselves, and the users of
> >>> C that are open minded are completely discouraged to participate.
> > > 
> > > Very true.
> > 
> > Yeah, you two would think so. Jacob and Chris would like to "expand"
> > the C newsgroup to include platform-specific topics. There, as here,
> > that is considered undesirable.
> 
> I just have a slightly wider view of clc 

A much wider view.

> than a small group of net
> nannies who spend more time screaming "OT"  than any thing else.

This is a bald-faced lie, and you know it.

> Though they bend the rule of "standard C"  to make it anything from
> K&R1 to past the present standard. But not any standards they don't
> like

They only accept C standards. Just as this newsgroup deals with C++
ones. Why not try to get this one to "expand" the way you did in clc?
You'll get about the same reception, because the topicality rules are
pretty similar.




Brian
0
defaultuserbr (3656)
7/10/2007 4:26:59 PM
In my opinion, you should learn them both.  Depending upon the
situation, problem, or task, you may need to encounter both.  Learn
all the programming languages you can, and you will find one that best
suits your needs for your situation.  Each programming language has
its ups and downs.  And when you get used to programming in both
procedural, and objects, you will find that each situation, or problem
needs a different requirement and works better.

~Huck

0
7/10/2007 7:53:34 PM
Reply: