[hcs-d] learning C++

Greg Price gprice at post.harvard.edu
Wed Apr 6 16:57:01 EDT 2011

Yes, definitely.


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

More information about the hcs-discuss mailing list