[hcs-d] learning C++

Brandon Liu bliu at college.harvard.edu
Fri Apr 15 13:24:29 EDT 2011


In case anyone still wants to learn C++, I just found this awesome list on
StackOverflow:
http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list

On Wed, Apr 6, 2011 at 4:57 PM, Greg Price <gprice at post.harvard.edu> wrote:

> Yes, definitely.
>
> Greg
>
>
> On Wed, Apr 6, 2011 at 13:37, Zak Stone <zstone at gmail.com> wrote:
> > Thanks for the quick feedback from both of you. Returning to the
> > original subject of this thread, then, would you advise people who are
> > considering making the investment to master C++ to stick with pure C
> > and a higher-level wrapper language such as Python unless they truly
> > have specialized needs?
> >
> > Zak
> >
> >
> > On Wed, Apr 6, 2011 at 4:31 PM, Greg Price <gprice at post.harvard.edu>
> wrote:
> >> I think that's a good general-purpose approach. It's basically what
> >> Quora (my company) does. Minus the part about Cython, it's basically
> >> been conventional wisdom in the Python world for some time.
> >>
> >> I am looking forward to PyPy (http://pypy.org) making step 3 much less
> >> frequently necessary, by making the pure Python code faster --
> >> bleeding-edge early adopters can use it in 2011, and I think the
> >> mainstream will be able to use it around 2013.
> >>
> >> I don't think it eliminates cases where it makes sense to write in C++
> >> or Java or C in the first place, in specialized circumstances.
> >>
> >> Greg
> >>
> >>
> >> On Wed, Apr 6, 2011 at 13:21, Zak Stone <zstone at gmail.com> wrote:
> >>> Hello again,
> >>>
> >>> In hopes of heading off a flame war, let me provide a bit more
> >>> context. I'm impressed with Cython [ http://cython.org/ ], a project
> >>> that attempts to make Python and C integration as smooth as possible.
> >>> It seems to me that tools such as Cython finally make the following
> >>> attractive development process possible:
> >>>
> >>> 1. Quickly prototype a system in Python with a minimal amount of code.
> >>>
> >>> 2. Run the system with real data and profile it.
> >>>
> >>> 3. Rewrite the performance-critical sections in Cython or C.
> >>>
> >>> 4. Return to Step 2 and repeat until system performance is
> satisfactory.
> >>>
> >>> The advantage I perceive to this development process is that it should
> >>> converge to a correct, high-performing solution with a minimal amount
> >>> of code in a minimal amount of developer time with a minimal amount of
> >>> system complexity, which should then make future modifications easier.
> >>>
> >>> Naively, it seems that a Python/Cython/C system produced by the
> >>> development process above could be strictly preferable to one produced
> >>> from scratch in either C++ or Java. Earlier comments suggest that C++
> >>> and Java are currently popular for their combination of speed and
> >>> resistance to memory bugs, but the integration of C in
> >>> performance-critical regions of a Python/Cython/C system should
> >>> address the speed issue, and the use of Python and Cython everywhere
> >>> else should make memory issues rare and easy to isolate in small
> >>> stretches of C code.
> >>>
> >>> Have we reached the stage where the development process above is
> >>> reasonable even for very large projects, or is it still absolutely
> >>> necessary to start from scratch in something like C++ or Java?
> >>>
> >>> For those of you who are curious, here is the original thread that I
> quoted:
> >>>
> >>> http://www.mail-archive.com/numpy-discussion@scipy.org/msg30470.html
> >>>
> >>> Thanks,
> >>> Zak
> >>>
> >>>
> >>> On Wed, Apr 6, 2011 at 4:12 PM, William Josephson <
> wkj at post.harvard.edu> wrote:
> >>>> On Wed, Apr 06, 2011 at 12:37:52PM -0700, Greg Price wrote:
> >>>>> > This is more or less bunk. ?Some time back Brian Kernighan showed
> me
> >>>>> > a small benchmark he had written in which C++ loses pretty handily
> to
> >>>>> > Java and a number of scripting languages. ?C++ is bloated and slow
> and
> >>>>> > memory corruption is still common enough.
> >>>>>
> >>>>> I don't know what this benchmark is or how the C++ code in question
> >>>>> was written, but this is not a common result. As for memory
> >>>>
> >>>> Umm...awk beats C++ STL sort.  What's impressive is that C++ STL
> >>>> loses to Python and awk.  A big problem with C++ is that its idea
> >>>> of polymorphism is rampant inlining and generation of almost identical
> >>>> code.  The result is blown I-caches.  Take a look at the recent
> >>>> work on a new ld at Google by Ian Lance Taylor to see what I mean.
> >>>>
> >>>> C++ is an archaic mess.  It may still be a marketable skill, but
> >>>> otherwise learn C (not C++) and move on.
> >>>>
> >>>>> corruption, the way you write the code is critical. If you use
> >>>>> pointers and arrays the same way as you would in C, of course memory
> >>>>> corruption bugs are just as likely. If you systematically use
> >>>>> abstractions like Boost shared pointers or scoped pointers, you are
> >>>>> much better off in that respect.
> >>>>
> >>>> Poor man's GC is still not GC.  Here's a dime...buy a real language
> :-)
> >>>>
> >>>> I say this as someone who has used AWK to generate templates to
> >>>> implement continuation passing in C++ to schedule concurrent code
> >>>> for cache locality.
> >>>>
> >>>> On a related note, have a gander at this:
> >>>>        http://www.scs.stanford.edu/~dm/home/papers/c++-new.html
> >>>>
> >>>> Cyclicly yours,
> >>>>
> >>>>  -WJ
> >>>> _______________________________________________
> >>>> hcs-discuss mailing list
> >>>> hcs-discuss at lists.hcs.harvard.edu
> >>>> https://lists.hcs.harvard.edu/mailman/listinfo/hcs-discuss
> >>>>
> >>>
> >>
> >
> _______________________________________________
> hcs-discuss mailing list
> hcs-discuss at lists.hcs.harvard.edu
> https://lists.hcs.harvard.edu/mailman/listinfo/hcs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.hcs.harvard.edu/pipermail/hcs-discuss/attachments/20110415/0ed73b81/attachment.htm 


More information about the hcs-discuss mailing list