Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #17592 > unrolled thread

[OT] Quick intro to C++ for a Python and C user?

Back to article view | Back to comp.lang.python

Contents

  [OT] Quick intro to C++ for a Python and C user? Grant Edwards <invalid@invalid.invalid> - 2011-12-20 17:40 +0000
    Re: [OT] Quick intro to C++ for a Python and C user? Neil Cerutti <neilc@norwich.edu> - 2011-12-20 18:36 +0000
      Re: [OT] Quick intro to C++ for a Python and C user? Grant Edwards <invalid@invalid.invalid> - 2011-12-20 20:41 +0000
        Re: [OT] Quick intro to C++ for a Python and C user? Paul Rubin <no.email@nospam.invalid> - 2011-12-20 13:00 -0800
          Re: [OT] Quick intro to C++ for a Python and C user? Neil Cerutti <neilc@norwich.edu> - 2011-12-21 14:04 +0000
            Re: [OT] Quick intro to C++ for a Python and C user? Roy Smith <roy@panix.com> - 2011-12-21 09:26 -0500
            Re: [OT] Quick intro to C++ for a Python and C user? Grant Edwards <invalid@invalid.invalid> - 2011-12-21 15:37 +0000
              Re: [OT] Quick intro to C++ for a Python and C user? Neil Cerutti <neilc@norwich.edu> - 2011-12-21 16:16 +0000
                Re: [OT] Quick intro to C++ for a Python and C user? Grant Edwards <invalid@invalid.invalid> - 2011-12-21 21:02 +0000
                  Re: [OT] Quick intro to C++ for a Python and C user? Ethan Furman <ethan@stoneleaf.us> - 2011-12-21 13:15 -0800
                  Re: [OT] Quick intro to C++ for a Python and C user? Roy Smith <roy@panix.com> - 2011-12-21 20:02 -0500
                    Re: [OT] Quick intro to C++ for a Python and C user? Neil Cerutti <neilc@norwich.edu> - 2011-12-22 13:19 +0000
    Re: [OT] Quick intro to C++ for a Python and C user? Paul Rubin <no.email@nospam.invalid> - 2011-12-20 11:43 -0800
    Re: [OT] Quick intro to C++ for a Python and C user? Grant Edwards <invalid@invalid.invalid> - 2011-12-20 20:51 +0000
      Re: [OT] Quick intro to C++ for a Python and C user? Paul Rubin <no.email@nospam.invalid> - 2011-12-20 13:06 -0800

#17592 — [OT] Quick intro to C++ for a Python and C user?

Would anybody care to recommend online C++ resources for a long time C
and Python user?  (I'm also familiar with Smalltalk, Scheme, FORTRAN,
bash, Javascript, and a variety of assembly languages.)

I have a C++ library to which I need to add a couple minor
wrappers/extensions. I've already done the same for the C version of
the library.  Writing test suites for C libraries using Python/ctypes
is pretty cool. :)

After googling a bit, I found several recommendations for the book
"Thinking in C++" by Bruce Eckel.  I've skimmed through it, and it's
_way_ too long-winded.  It takes him 200+ pages before he gets to data
encapsulation and 600+ pages before he introduces inheritence. The
writing is also a bit too condesending for my taste:

   You literally take the form of the existing class and add code to
   it, without modifying the existing class. This magical act is
   called _inheritance_, and most of the work is done by the compiler.

Magical act?

Seriously?
   
-- 
Grant Edwards               grant.b.edwards        Yow! Are you the
                                  at               self-frying president?
                              gmail.com            

[toc] | [next] | [standalone]

#17598

On 2011-12-20, Grant Edwards <invalid@invalid.invalid> wrote:
> Would anybody care to recommend online C++ resources for a long
> time C and Python user?  (I'm also familiar with Smalltalk,
> Scheme, FORTRAN, bash, Javascript, and a variety of assembly
> languages.)

The best book I know of to get you writing useful C++ quickly is
Accelerated C++ by Koenig/Moo. It's not free online, though. It
starts with an excellent introduction to using the STL and works
it's way slowly down the abstraction ladder to using pointers and
inheritance last of all.

Iterators turn out to be an excellent starting point for learning
pointers, though since you already know C that won't do you as
much good.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#17611

On 2011-12-20, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2011-12-20, Grant Edwards <invalid@invalid.invalid> wrote:

>> Would anybody care to recommend online C++ resources for a long
>> time C and Python user?  (I'm also familiar with Smalltalk,
>> Scheme, FORTRAN, bash, Javascript, and a variety of assembly
>> languages.)
>
> The best book I know of to get you writing useful C++ quickly is
> Accelerated C++ by Koenig/Moo. It's not free online, though. It
> starts with an excellent introduction to using the STL and works
> it's way slowly down the abstraction ladder to using pointers and
> inheritance last of all.

Oops. I should have mentioned this is for embedded systems programming
so templates in general (and STL in particular) are probably off the
table.

> Iterators turn out to be an excellent starting point for learning
> pointers, though since you already know C that won't do you as
> much good.

-- 
Grant Edwards               grant.b.edwards        Yow! Boy, am I glad it's
                                  at               only 1971...
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#17617

Grant Edwards <invalid@invalid.invalid> writes:
> Oops. I should have mentioned this is for embedded systems programming
> so templates in general (and STL in particular) are probably off the
> table.

Templates are how C++ does generics and I'd expect them to appear in be
used in embedded programming as well as elsewhere.  They can bloat up
the code if you're not careful (if function f has several parameters,
you can end up with a separate, specialized copy of f for every
combination of types that f is called with in the program), but in the
typical monomorphic situation they don't add any overhead.  I'm not sure
about the situation with STL.  Anyway, templates aren't terribly hard to
understand.

[toc] | [prev] | [next] | [standalone]

#17664

On 2011-12-20, Paul Rubin <no.email@nospam.invalid> wrote:
> Grant Edwards <invalid@invalid.invalid> writes:
>> Oops. I should have mentioned this is for embedded systems
>> programming so templates in general (and STL in particular)
>> are probably off the table.
>
> Templates are how C++ does generics and I'd expect them to
> appear in be used in embedded programming as well as elsewhere.
> They can bloat up the code if you're not careful (if function f
> has several parameters, you can end up with a separate,
> specialized copy of f for every combination of types that f is
> called with in the program), but in the typical monomorphic
> situation they don't add any overhead.  I'm not sure about the
> situation with STL.  Anyway, templates aren't terribly hard to
> understand.

Moreover, if you don't plan to take advantage of templates or
inheritance, then you could as well write C++ compatible C and be
pretty happy with the results.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#17665

In article <9le7c5F1lsU1@mid.individual.net>,
 Neil Cerutti <neilc@norwich.edu> wrote:

> On 2011-12-20, Paul Rubin <no.email@nospam.invalid> wrote:
> > Grant Edwards <invalid@invalid.invalid> writes:
> >> Oops. I should have mentioned this is for embedded systems
> >> programming so templates in general (and STL in particular)
> >> are probably off the table.
> >
> > Templates are how C++ does generics and I'd expect them to
> > appear in be used in embedded programming as well as elsewhere.
> > They can bloat up the code if you're not careful (if function f
> > has several parameters, you can end up with a separate,
> > specialized copy of f for every combination of types that f is
> > called with in the program), but in the typical monomorphic
> > situation they don't add any overhead.  I'm not sure about the
> > situation with STL.  Anyway, templates aren't terribly hard to
> > understand.
> 
> Moreover, if you don't plan to take advantage of templates or
> inheritance, then you could as well write C++ compatible C and be
> pretty happy with the results.

Well, C++ still gives you constructors, destructors, and the ability to 
write class-specific operators.

But, you'd be missing one of C++'s biggest selling points; safe 
containers.  Even if you never explore anything in STL beyond std:string 
and std:vector, you will have saved yourself a world of buffer overflow 
pain.

[toc] | [prev] | [next] | [standalone]

#17669

On 2011-12-21, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2011-12-20, Paul Rubin <no.email@nospam.invalid> wrote:
>> Grant Edwards <invalid@invalid.invalid> writes:
>>> Oops. I should have mentioned this is for embedded systems
>>> programming so templates in general (and STL in particular)
>>> are probably off the table.
>>
>> Templates are how C++ does generics and I'd expect them to
>> appear in be used in embedded programming as well as elsewhere.

I've only worked on the perphery of a couple embedded projects that
used C++, but it seems to be farily common practice to prohibit the
use of templates in embedded code.  The problem seems to be that
people writing C++ code don't really understand the language, how
templates work, or (in general) the implications of the code they
write.  So, you have to prohibit anything that can be easily misused
or cause non-obvious problems.

For exaple (quoting from http://en.wikipedia.org/wiki/Embedded_C%2B%2B):

  Embedded C++ is a proper subset of C++. The following language
  features have been removed:

    Multiple inheritance
    Virtual base classes
    Run-time type information (typeid)
    New style casts (static_cast, dynamic_cast, reinterpret_cast and const_cast)
    The mutable type qualifier
    Namespaces
    Exceptions
    Templates

Some people go further and prohibit any run-time object creation.
    
>> They can bloat up the code if you're not careful

Bingo.  In my experience, many (if not most) C++ programmers don't
understand enough of the language to realize what "being careful"
means.

>> (if function f has several parameters, you can end up with a
>> separate, specialized copy of f for every combination of types that f
>> is called with in the program), but in the typical monomorphic
>> situation they don't add any overhead.  I'm not sure about the
>> situation with STL.  Anyway, templates aren't terribly hard to
>> understand.
>
> Moreover, if you don't plan to take advantage of templates or
> inheritance, then you could as well write C++ compatible C and be
> pretty happy with the results.

Well, there are other C++ features that C doesn't have (e.g.
exceptions -- but they're often prohibitted in embedded programming as
well).

Personally, I think C++ is an awful language in general and a _really_
awful language for embedded systems work.

-- 
Grant Edwards               grant.b.edwards        Yow! PEGGY FLEMMING is
                                  at               stealing BASKET BALLS to
                              gmail.com            feed the babies in VERMONT.

[toc] | [prev] | [next] | [standalone]

#17671

On 2011-12-21, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2011-12-21, Neil Cerutti <neilc@norwich.edu> wrote:
>> On 2011-12-20, Paul Rubin <no.email@nospam.invalid> wrote:
>>> Grant Edwards <invalid@invalid.invalid> writes:
>>>> Oops. I should have mentioned this is for embedded systems
>>>> programming so templates in general (and STL in particular)
>>>> are probably off the table.
>>>
>>> Templates are how C++ does generics and I'd expect them to
>>> appear in be used in embedded programming as well as elsewhere.
>
> I've only worked on the perphery of a couple embedded projects that
> used C++, but it seems to be farily common practice to prohibit the
> use of templates in embedded code.  The problem seems to be that
> people writing C++ code don't really understand the language, how
> templates work, or (in general) the implications of the code they
> write.  So, you have to prohibit anything that can be easily misused
> or cause non-obvious problems.

I cheerfully agree that programmers ignorant of C++ should not
write programs in it. But furthermore, they should also not
define a subset of C++ for use in embedded programming. ;)

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#17702

On 2011-12-21, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2011-12-21, Grant Edwards <invalid@invalid.invalid> wrote:
>>
>>>> Templates are how C++ does generics and I'd expect them to
>>>> appear in be used in embedded programming as well as elsewhere.
>>
>> I've only worked on the perphery of a couple embedded projects that
>> used C++, but it seems to be farily common practice to prohibit the
>> use of templates in embedded code.  The problem seems to be that
>> people writing C++ code don't really understand the language, how
>> templates work, or (in general) the implications of the code they
>> write.  So, you have to prohibit anything that can be easily misused
>> or cause non-obvious problems.
>
> I cheerfully agree that programmers ignorant of C++ should not
> write programs in it. But furthermore, they should also not
> define a subset of C++ for use in embedded programming. ;)

I fully agree that programmers ignorant of C++ should not write
programs in it.  However C++ is a vast, complex, and dangerous
language -- and industry doesn't seem to be willing to limit itself to
using the seven people on the planet who understand it.

I'm only half joking...  :)

It seems to me that you need to know far more about C++ to use it
safely than you need to know about most other languages to use them
safely.

-- 
Grant Edwards               grant.b.edwards        Yow! Hey, waiter!  I want
                                  at               a NEW SHIRT and a PONY TAIL
                              gmail.com            with lemon sauce!

[toc] | [prev] | [next] | [standalone]

#17703

Grant Edwards wrote:
> On 2011-12-21, Neil Cerutti <neilc@norwich.edu> wrote:
>> I cheerfully agree that programmers ignorant of C++ should not
>> write programs in it. But furthermore, they should also not
>> define a subset of C++ for use in embedded programming. ;)
> 
> I fully agree that programmers ignorant of C++ should not write
> programs in it.  However C++ is a vast, complex, and dangerous
> language -- and industry doesn't seem to be willing to limit itself to
> using the seven people on the planet who understand it.
> 
> I'm only half joking...  :)


Ah -- so there's actually 14?

;)

~Ethan~

[toc] | [prev] | [next] | [standalone]

#17712

In article <jcthh3$8vd$1@reader1.panix.com>,
 Grant Edwards <invalid@invalid.invalid> wrote:

> C++ is a vast, complex, and dangerous language -- and industry 
> doesn't seem to be willing to limit itself to using the seven people 
> on the planet who understand it.

> I'm only half joking...  :)

Half joking, indeed.  I happen to know for a fact that there are 
*fourteen* people on the planet who understand it.

[toc] | [prev] | [next] | [standalone]

#17731

On 2011-12-22, Roy Smith <roy@panix.com> wrote:
> In article <jcthh3$8vd$1@reader1.panix.com>,
>  Grant Edwards <invalid@invalid.invalid> wrote:
>> C++ is a vast, complex, and dangerous language -- and industry
>> doesn't seem to be willing to limit itself to using the seven
>> people on the planet who understand it.
>
>> I'm only half joking...  :)
>
> Half joking, indeed.  I happen to know for a fact that there
> are *fourteen* people on the planet who understand it.

One of its greatest contributions to computer science were
Glassbarrow's C++ puzzles. They likely couldn't have been as
challenging in any other language. ;)

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#17603

Grant Edwards <invalid@invalid.invalid> writes:
> Would anybody care to recommend online C++ resources for a long time C
> and Python user?  (I'm also familiar with Smalltalk, Scheme, FORTRAN,
> bash, Javascript, and a variety of assembly languages.)

Stroustrup's web site has lots of good stuff on it.  I also like his C++
book "The C++ Programming Language" in preference to the many me-too
books that are out there.  He also has another C++ book that I haven't
looked at but which sounded interesting.  C++ is quite a bit different
from those other languages you mention in that contemporary C++ style
revolves a lot more around a reasonably serious static type system with
typed generics.  By comparison, C and Fortran have minimal static type
systems and Smalltalk, Python, etc. have none at all.

[toc] | [prev] | [next] | [standalone]

#17616

On 2011-12-20, Grant Edwards <invalid@invalid.invalid> wrote:

> Would anybody care to recommend online C++ resources for a long time C
> and Python user?  (I'm also familiar with Smalltalk, Scheme, FORTRAN,
> bash, Javascript, and a variety of assembly languages.)
>
> I have a C++ library to which I need to add a couple minor
> wrappers/extensions. I've already done the same for the C version of
> the library.  Writing test suites for C libraries using Python/ctypes
> is pretty cool. :)

I stumbled across an undergrad CSci lesson that showed in a couple
pages how to subclass something and add a couple methods.  All I
needed to do was add four methods containing two lines of code each.

Unfortunately, I had to muck about with the original library's code to
change a couple things from "private" to "protected" to allow me to
extend the class to do what needed to be done.  Every time I have to
do anything with C++ (once every handfull of years) it feels like
swimming against the current...

It probably would have been simpler to just add the code to the
original library's implementation, but that would have introduced a
"backwards" dependency in the system's libraries.

-- 
Grant Edwards               grant.b.edwards        Yow! A dwarf is passing out
                                  at               somewhere in Detroit!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#17619

Grant Edwards <invalid@invalid.invalid> writes:
> Unfortunately, I had to muck about with the original library's code to
> change a couple things from "private" to "protected" to allow me to
> extend the class to do what needed to be done.  Every time I have to
> do anything with C++ (once every handfull of years) it feels like
> swimming against the current...

I think this is what's called "the expression problem" and it's a
perennial sore point in statically typed PL design.  Different languages
have different approaches to dealing with it.  I'm no C++ expert so I
don't know what the gurus would say for your particular situation.  But,
I do get the impression that PL mavens now tend to think that OO and
inheritance was a 1990's thing that didn't work out as well as expected,
that Java is a painful wreck because of it, and that C++ culture has
moved somewhat away from OO in favor of template-based generics.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web