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

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

Python vs C++

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

Contents

  Python vs C++ David Palao <dpalao.python@gmail.com> - 2014-08-21 14:54 +0200
    Re: Python vs C++ wxjmfauth@gmail.com - 2014-08-21 07:08 -0700
    Re: Python vs C++ Rustom Mody <rustompmody@gmail.com> - 2014-08-21 07:10 -0700
    Re: Python vs C++ Grant Edwards <invalid@invalid.invalid> - 2014-08-21 14:59 +0000
      Re: Python vs C++ Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-08-21 23:12 -0400
    Re: Python vs C++ Christian Gollwitzer <auriocus@gmx.de> - 2014-08-22 10:05 +0200
      Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-22 18:50 +1000
        Re: Python vs C++ Marko Rauhamaa <marko@pacujo.net> - 2014-08-22 12:29 +0300
          Re: Python vs C++ "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-22 08:51 -0400
          Re: Python vs C++ Skip Montanaro <skip@pobox.com> - 2014-08-22 07:58 -0500
            Re: Python vs C++ Marko Rauhamaa <marko@pacujo.net> - 2014-08-22 20:16 +0300
              Re: Python vs C++ mm0fmf <none@mailinator.com> - 2014-08-23 17:47 +0100
                Re: Python vs C++ Marko Rauhamaa <marko@pacujo.net> - 2014-08-23 19:54 +0300
          Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-22 23:00 +1000
          Re: Python vs C++ Christian Gollwitzer <auriocus@gmx.de> - 2014-08-22 21:25 +0200
            Re: Python vs C++ Stefan Behnel <stefan_ml@behnel.de> - 2014-08-22 21:58 +0200
            Re: Python vs C++ Marko Rauhamaa <marko@pacujo.net> - 2014-08-22 23:06 +0300
              Re: Python vs C++ Michael Torrie <torriem@gmail.com> - 2014-08-22 15:38 -0600
                Re: Python vs C++ wxjmfauth@gmail.com - 2014-08-23 03:00 -0700
              Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-23 07:49 +1000
                Re: Python vs C++ Rustom Mody <rustompmody@gmail.com> - 2014-08-23 05:38 -0700
                  Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-23 23:00 +1000
                  Re: Python vs C++ Ian Kelly <ian.g.kelly@gmail.com> - 2014-08-23 08:02 -0600
                    Re: Python vs C++ Rustom Mody <rustompmody@gmail.com> - 2014-08-23 07:21 -0700
                      Re: Python vs C++ Terry Reedy <tjreedy@udel.edu> - 2014-08-23 16:51 -0400
                  Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-24 00:21 +1000
                  Re: Python vs C++ Terry Reedy <tjreedy@udel.edu> - 2014-08-23 15:09 -0400
                  Re: Python vs C++ Joseph Martinot-Lagarde <joseph.martinot-lagarde@m4x.org> - 2014-08-24 14:54 +0200
                  Re: Python vs C++ "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-25 09:01 -0400
              Re: Python vs C++ Michael Torrie <torriem@gmail.com> - 2014-08-22 15:56 -0600
              Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-23 08:00 +1000
                Re: Python vs C++ Marko Rauhamaa <marko@pacujo.net> - 2014-08-23 10:27 +0300
              Re: Python vs C++ dieter <dieter@handshake.de> - 2014-08-23 07:56 +0200
              Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-23 16:11 +1000
                Re: Python vs C++ Paul Rudin <paul.nospam@rudin.co.uk> - 2014-08-23 08:36 +0100
                  Re: Python vs C++ Chris Angelico <rosuav@gmail.com> - 2014-08-23 18:04 +1000
            Re: Python vs C++ dieter <dieter@handshake.de> - 2014-08-23 07:48 +0200

Page 1 of 2  [1] 2  Next page →

#76731 — Python vs C++

Hello,
I consider myself a python programmer, although C++ was one of the
first languages I learned (not really deeply and long time ago).

Now I decided to retake C++, to broaden my view of the business.
However, as I progress in learning C++, I cannot take out of my head
one question

 Why to use C++ instead of python?

It is not ranting against C++. I was/am looking for small-medium
projects to exercise my C++ skills. But I'm interested in a "genuine"
C++ project: some task where C++ is really THE language (and where
python is actually a bad ab initio choice).
The usual argument in favour of C++ (when comparing to python) is
performance. But I'm convinced that, in general, the right approach is
"python-profiling-(extension/numpy/Cython/...)". At least for a python
programmer. I might be wrong, though.

This is, perhaps, a bit off-topic, but I really want to know the
thoughts of experienced python programmers on it.

Thanks in advance,

David

[toc] | [next] | [standalone]

#76736

Le jeudi 21 août 2014 14:54:18 UTC+2, David Palao a écrit :
> Hello,
> 
> I consider myself a python programmer, although C++ was one of the
> 
> first languages I learned (not really deeply and long time ago).
> 
> 
> 
> Now I decided to retake C++, to broaden my view of the business.
> 
> However, as I progress in learning C++, I cannot take out of my head
> 
> one question
> 
> 
> 
>  Why to use C++ instead of python?
> 
> 
> 
> It is not ranting against C++. I was/am looking for small-medium
> 
> projects to exercise my C++ skills. But I'm interested in a "genuine"
> 
> C++ project: some task where C++ is really THE language (and where
> 
> python is actually a bad ab initio choice).
> 
> The usual argument in favour of C++ (when comparing to python) is
> 
> performance. But I'm convinced that, in general, the right approach is
> 
> "python-profiling-(extension/numpy/Cython/...)". At least for a python
> 
> programmer. I might be wrong, though.
> 
> 
> 
> This is, perhaps, a bit off-topic, but I really want to know the
> 
> thoughts of experienced python programmers on it.
> 

C++ : I do not know.
Python 3 : a disaster.

jmf

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

#76737

On Thursday, August 21, 2014 6:24:18 PM UTC+5:30, David Palao wrote:
> Hello,
> I consider myself a python programmer, although C++ was one of the
> first languages I learned (not really deeply and long time ago).

> Now I decided to retake C++, to broaden my view of the business.
> However, as I progress in learning C++, I cannot take out of my head
> one question

>  Why to use C++ instead of python?

> It is not ranting against C++. I was/am looking for small-medium
> projects to exercise my C++ skills. But I'm interested in a "genuine"
> C++ project: some task where C++ is really THE language (and where
> python is actually a bad ab initio choice).
> The usual argument in favour of C++ (when comparing to python) is
> performance. But I'm convinced that, in general, the right approach is
> "python-profiling-(extension/numpy/Cython/...)". At least for a python
> programmer. I might be wrong, though.

> This is, perhaps, a bit off-topic, but I really want to know the
> thoughts of experienced python programmers on it.

Not C++ but (mostly) C:
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html

And someone opposed to that view:
http://dieswaytoofast.blogspot.in/2013/01/why-i-grown-to-loathe-c.html

I said something about it here:
http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html

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

#76740

On 2014-08-21, David Palao <dpalao.python@gmail.com> wrote:

>  Why to use C++ instead of python?

 1) C++ is the only language available for your platform, and for some
    reason you are unable to build Python from source.

 2) You need money, and the only person willing to pay you says use
    C++ and won't listen to reason.

 3) You're a masochist.    

That's all I can think of...

-- 
Grant Edwards               grant.b.edwards        Yow! I want a WESSON OIL
                                  at               lease!!
                              gmail.com            

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

#76770

On Thu, 21 Aug 2014 14:59:05 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> declaimed the following:

>On 2014-08-21, David Palao <dpalao.python@gmail.com> wrote:
>
>>  Why to use C++ instead of python?
>
> 1) C++ is the only language available for your platform, and for some
>    reason you are unable to build Python from source.
>
> 2) You need money, and the only person willing to pay you says use
>    C++ and won't listen to reason.
>
> 3) You're a masochist.    
>
>That's all I can think of...

	4)	Your last name is Stroustup

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#76783

Am 21.08.14 14:54, schrieb David Palao:
> I consider myself a python programmer, although C++ was one of the
> first languages I learned (not really deeply and long time ago).
>
> Now I decided to retake C++, to broaden my view of the business.
> However, as I progress in learning C++, I cannot take out of my head
> one question
>
>   Why to use C++ instead of python?

You are asking in the wrong group; ask this in comp.lang.c++ Here most 
of the programmers know Python well and maybe some C++

> It is not ranting against C++. I was/am looking for small-medium
> projects to exercise my C++ skills. But I'm interested in a "genuine"
> C++ project: some task where C++ is really THE language (and where
> python is actually a bad ab initio choice).

The truth is, that both languages have a fairly large overlap. C++ spans 
a very wide gap, from tight low-level loops and direct memory access 
"close to the metal" up to composing a GUI application from ready-made 
building blocks. There is a variety of programming paradigmata, like 
functional (so-so), object oriented (quite good), generic (very good), 
imperative (shiny = the C subset). Graphically

C++:
metal |----------------------------------|

Python:
metal         |------------------------------------|


If your application lives within the overlap region, and a lot of them 
do, the choice is a matter of taste. I'm not even convinced that the 
development time is significantly lower in Python within this overlap. 
It becomes different at both ends: The more you go to the higher level, 
the more will Python outperform C++ in terms of development costs, but 
conversely C++ will win if you go closer to the metal. Then, as a Python 
programmer, you will find yourself rewriting parts of the application in 
Cython, trying PyPy, numpy, finally embedding C...

A few arguments outside of "what I can do with it" have already been given:

* For deployment, it is nice to compile and link a self-contained small 
binary. Try that with matplotlib - pyinstaller gets me a 100MB 
executable containing OS libraries, while the linker in C++ is able to 
only link what is needed.

* Access to the hardware: C structs, raw pointers, unboxed datatypes are 
needed in a painless and efficient way if you want to write, say,  a 
middle-level device driver

* performance is not only speed, but also memory usage. In most cases a 
C++ program will consume less memory

* static type checking can find bugs at compile-time. C++ is easier to 
compile (though on of the harder languages for compiler implementers), 
and therefore many tools exist for static analysis.

> The usual argument in favour of C++ (when comparing to python) is
> performance. But I'm convinced that, in general, the right approach is
> "python-profiling-(extension/numpy/Cython/...)".

Well, that's Ousterhouts dichotomy.

	Christian

	Christian

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

#76784

On Fri, Aug 22, 2014 at 6:05 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> I'm not even convinced that the development time is significantly lower in
> Python within this overlap.

It usually will be, though not always.

ChrisA

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

#76785

Chris Angelico <rosuav@gmail.com>:

> On Fri, Aug 22, 2014 at 6:05 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:
>> I'm not even convinced that the development time is significantly
>> lower in Python within this overlap.
>
> It usually will be, though not always.

Even more to the point, it is far easier to program correctly in Python
than C++. The higher-level concepts let you concentrate on the
high-level problem at hand instead of the low-level chores where you are
bound to make careless mistakes or take dangerous shortcuts.

So my advise is, use as high-level programming language as you can. If
you can't, deal with it, but often you can break your system into parts
where only a small corner needs to be implemented at the low level.

Remember, too, that there is a whole sliding scale of programming
languages:

   assembly
       C
          C++
              Go
                 Java/C#
                     Python
                         Scheme
                             Bash

In my current work, the choice is between C, Python and Bash. Some
non-STL C++ in the mix.

In my previous job, it was Java, Python and Bash, with some JNI in the
mix.

I think Python's abstraction level is excellent for most needs. C++ is
squeezed from all sides. Its downfall is that it is trying to cover
everything instead of just ceding the high-level turf to other
languages. Thus, it is too elaborate for the nimble stuff, and you will
often simply use C where you need nimble.

C is readily supported by all extension APIs. Its calling conventions
are stable and well-understood. Its runtime requirements are trivial.
Plus, you don't have to be a Medieval Scholar to program in it.


Marko

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

#76787

On 8/22/2014 5:29 AM, Marko Rauhamaa wrote:
> C is readily supported by all extension APIs. Its calling conventions
> are stable and well-understood. Its runtime requirements are trivial.
> Plus, you don't have to be a Medieval Scholar to program in it.

C itself is very simple (albeit not simple to use). But I contend you do 
need to be a Medieval Scholar to compile and link it. My mind boggles 
watching a ./configure vomit ASCII all over my screen. I have to avert 
my eyes, make a wish, and make install. ;)

-- 
Neil Cerutti

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

#76788

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 22, 2014 at 7:51 AM, Neil D. Cerutti <neilc@norwich.edu> wrote:

> But I contend you do need to be a Medieval Scholar to compile and link it.


That's only because whoever wrote your Makefile wasn't skilled in the art
of make recipes. :-)

Skip

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

#76803

Skip Montanaro <skip@pobox.com>:

> On Fri, Aug 22, 2014 at 7:51 AM, Neil D. Cerutti <neilc@norwich.edu> wrote:
>> But I contend you do need to be a Medieval Scholar to compile and link it.
>
> That's only because whoever wrote your Makefile wasn't skilled in the
> art of make recipes. :-)

Make shouldn't be involved in any serious work. It was designed for the
case where you have a handful of source files in a single directory. Its
use has gotten completely out of hand.

I sincerely recommend SCons for anything more serious. A word of
warning, though: SCons gives you the power of Python. Don't use that
power except in utmost need.


Marko

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

#76880

On 22/08/2014 18:16, Marko Rauhamaa wrote:
> SCons gives you the power of Python. Don't use that
> power except in utmost need.

Ah, you've seen our build system at work!

Andy

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

#76881

mm0fmf <none@mailinator.com>:

> On 22/08/2014 18:16, Marko Rauhamaa wrote:
>> SCons gives you the power of Python. Don't use that
>> power except in utmost need.
>
> Ah, you've seen our build system at work!

Where I've used SCons, I've striven to make the SConscript files obvious
to a casual visitor, who might not even know Python. Adding one more
file in the right spot should be possible just from the looks of the
SConscript file.

A SConscript file should *not* involve programming, even if it means
some redundancy. Don't create libraries. Don't create your own rules.
Keep it simple, keep it plain.

A colleague had to deal with a different SCons setup that had reached
self-awareness. It knew what needed to be built without specific
instructions before you, the developer, knew it yourself. The developers
no longer had any idea how it worked nor did they dream of touching the
code. Not a good place to be.


Marko

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

#76789

On Fri, Aug 22, 2014 at 10:51 PM, Neil D. Cerutti <neilc@norwich.edu> wrote:
> C itself is very simple (albeit not simple to use). But I contend you do
> need to be a Medieval Scholar to compile and link it. My mind boggles
> watching a ./configure vomit ASCII all over my screen. I have to avert my
> eyes, make a wish, and make install. ;)

Bah, it's more fun to actually read it, and to imagine what manner of
system might fail some of those tests :)

checking for candle... no
checking whether the C compiler works... yes
checking for stdlib.h... yes
checking for windows.h usability... no
checking for windows.h presence... no
(these last two on a system that had already been probed and found to be Linux)

And of course:
checking whether build environment is sane...
http://xkcd.com/371/

ChrisA

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

#76810

Am 22.08.14 11:29, schrieb Marko Rauhamaa:
> So my advise is, use as high-level programming language as you can. If
> you can't, deal with it, but often you can break your system into parts
> where only a small corner needs to be implemented at the low level.

Agreed. This is called Ousterhout's dichotomy.

> Remember, too, that there is a whole sliding scale of programming
> languages:
>
>     assembly
>         C
>            C++
>                Go
>                   Java/C#
>                       Python
>                           Scheme
>                               Bash


My point is that this picture is incomplete: it shows the programming 
languages as *points* on the complexity line, whereas they are rather 
*intervals*. And these intervals have large overlaps.

My picture:
as     |--|
c       |------------|
c++       |---------------------------|
java         |-------------------------|
python        |--------------------------------|


  * Assembly is really narrow: tiny loops, compiler output snippets, 
firmware for really small embedded devices - anything beyond should be 
written in higher languages.

* C has a much broader scope: you can do most of the tiny loops and 
firmware stuff, unless the device is too small or you are bootstrapping 
a kernel. But it also scales up until command line tools such as sort 
and even can do moderately complex programs like the CPython interpreter 
- even if that would be much easier to write in C++. I guess the only 
reason for CPython instead of C++Python is the better portability of C.

* C++ embraces all of C, and by that definition reaches from the low end 
up to GUI applications  - most modern everyday programs are written in 
C++ in large parts. At the low end, it looses some device driver stuff, 
because exceptions, RTTI and such features are incompatible with code 
running in the kernel of an OS. But it still can make good use of memory 
(class and struct have the same memory layout). On the high end, you can 
write programs managing high-level data structures without a single 
explicit pointer or "new" and "delete" in your code.

* Java: I don't see that it is much higher level than C++. It has a GC, 
but that's all, and you can have that in C++, too, if you want. On the 
other hand, you loose the metaprogramming facilities provided by C++ 
templates (needs a guru to make a library, but can be handy and easy to 
use, e.g. everything in Boost). You loose direct memory access, gaining 
what? no idea.

* Python: On the low end almost on par with Java, slower because of 
dynamic typing, no direct memory access. On the high end manages complex 
libraries with single few invocations, good support for functional-style 
programming (generators, list comprehensions), the first in this list 
with an acceptable REPL in the standard distribution - imagine assembly, 
C++ or even Java with a REPL

Scheme - only played with it some time ago, seems to me like the 
assembly of functional languages. Compare that to Haskell, which is an 
elaborate high-level language. I wouldn't claim that it is higher-level 
than Python.

> I think Python's abstraction level is excellent for most needs. C++ is
> squeezed from all sides. Its downfall is that it is trying to cover
> everything instead of just ceding the high-level turf to other
> languages. Thus, it is too elaborate for the nimble stuff, and you will
> often simply use C where you need nimble.

Ousterhout's dichotomy. It's a good paradigm in many cases, but 
sometimes it might be preferable to have everything in a single 
language. And this is a good domain for C++.

> C is readily supported by all extension APIs. Its calling conventions
> are stable and well-understood. Its runtime requirements are trivial.
> Plus, you don't have to be a Medieval Scholar to program in it.

I'm currently implementing a numpy-like library for another language in 
C. I choosed C for the ABI/portability reason, but I am really missing 
C++ in many, many places. The code is an awful mess of macros to get 
simple metaprogramming facilities, i.e. to support different data types 
and operations. This is a domain where C++ would be the best choice, and 
only the stupid reason of possible runtime dependency guided the 
decision to use C.

Everything which needs string processing, but still has to run fast, is 
another good candidate. Compilers are certainly less painful to write in 
C++ than in C, and could still run with native speed. For sure it is 
much easier to do a compiler in Python, but this will come with a speed 
penalty (of the compilation, not the code, as evidenced by PyPy).

	Christian

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

#76815

If you want to add Cython to that (overly simplified) graph, you might get
something like this:

Christian Gollwitzer schrieb am 22.08.2014 um 21:25:
> as     |--|
> c       |------------|
> c++       |---------------------------|
Cython       |--------------------------------|
> python        |--------------------------------|

Meaning, there is a lot you can do in Cython that can keep you from having
to write C/C++ code at all. And even if you really have to, it still helps
in keeping that down to a couple of well chosen snippets rather than full
programs.

Stefan

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

#76818

>>     assembly
>>         C
>>            C++
>>                Go
>>                   Java/C#
>>                       Python
>>                           Scheme
>>                               Bash
>
>
> My point is that this picture is incomplete: it shows the programming
> languages as *points* on the complexity line,

I don't see any points. I see words.

> whereas they are rather *intervals*. And these intervals have large
> overlaps.

Add line segments as wide as you'd like.

> Ousterhout's dichotomy. It's a good paradigm in many cases, but
> sometimes it might be preferable to have everything in a single
> language. And this is a good domain for C++.

I tend to think the opposite: C++ barely has a niche left. I definitely
wouldn't want to use C++ very far from its (very narrow) sweet spot.

> I'm currently implementing a numpy-like library for another language
> in C. I choosed C for the ABI/portability reason, but I am really
> missing C++ in many, many places. The code is an awful mess of macros
> to get simple metaprogramming facilities, i.e. to support different
> data types and operations. This is a domain where C++ would be the
> best choice, and only the stupid reason of possible runtime dependency
> guided the decision to use C.

C++'s "gift" to programming was to take static typing to its utmost
limits -- to the detriment of usability, learnability and
intelligibility. STL and Boost have been turned into totems that
supposedly turn a dire necessity into a virtue.

C's give to programming is the void pointer. It's the antithesis of C++,
but damn does it get you out of every bind -- no fuss, no semantic
handwringing.

My disillusionment with C++ came from the language's inability to
represent callbacks. C can do it (void *), C# can do it (delegates),
Java can do it (anonymous inner classes), Python can do it (methods),
Scheme can do it (closures).

Qt needs callbacks ("signals" IIRC). It doesn't use C++ to express them.
It uses a fricking metacompiler for them.

And Stroustrup's thick book didn't even seem to be aware of callbacks as
a paradigm and thus didn't show any examples of dealing with them. Too
bad Stroustrup wasn't aware of C#'s delegates; C++ should have defined
function pointers as delegates.

> Everything which needs string processing, but still has to run fast,
> is another good candidate. Compilers are certainly less painful to
> write in C++ than in C, and could still run with native speed. For
> sure it is much easier to do a compiler in Python, but this will come
> with a speed penalty (of the compilation, not the code, as evidenced
> by PyPy).

There is one big advantage C++ has over C: virtual method dispatching.
However, I have been able to come up with C idioms that make practical
method dispatching relatively painless.


Marko

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

#76825

On 08/22/2014 02:06 PM, Marko Rauhamaa wrote:
> I tend to think the opposite: C++ barely has a niche left. I definitely
> wouldn't want to use C++ very far from its (very narrow) sweet spot.

I agree that it's niche is narrowing.  But it's still pretty wide and
widely used.  Many adobe products are C++, for example.  OpenOffice and
LibreOffice is C++.  You could argue that's because they are old
projects and were started in C++. But honestly if you were
reimplementing OpenOffice today what would you choose?  Python would be
appropriate for certain aspects of OO, such as parts of the UI, macros,
filters, etc.  I certainly wouldn't want to use Java (contrary to
popular belief OO is not written in Java; it's definitely C++).  Go is
quite young but promising except that unicode is all UTF-8 byte strings,
so string operations are going to be a bit slow.  C# never lived up to
its promise as the next app development language, even on Windows.  So
at this moment I'd still do it in C++ I think.  Apple chose to use C++
to build clang and llvm in, rather than C.

> My disillusionment with C++ came from the language's inability to
> represent callbacks. C can do it (void *), C# can do it (delegates),
> Java can do it (anonymous inner classes), Python can do it (methods),
> Scheme can do it (closures).

C++ can do it quite well, actually.  Maybe not quite as nicely as
Python.  But boost and libsigc++ both offer nice, type-safe ways to
implement signals and slots.  You can pass references to a callback
around in an easy, safe way.

> Qt needs callbacks ("signals" IIRC). It doesn't use C++ to express them.
> It uses a fricking metacompiler for them.

This is only partially true.  The actual, original, .cpp files with Qt
macros in them compile directly on the C++ compiler.  moc runs on the .h
file to generate some supporting code to help with event dispatching.
There's no such thing as Qt C++.  It's all standard C++, with macros to
help when defining things such as signals.

Macros were chosen instead of templates because at the time, not all C++
compilers supported templates.  Now if it was done all over again,
they'd do something like libsigc++, or boost.

> And Stroustrup's thick book didn't even seem to be aware of callbacks as
> a paradigm and thus didn't show any examples of dealing with them. Too
> bad Stroustrup wasn't aware of C#'s delegates; C++ should have defined
> function pointers as delegates.

Maybe the language doesn't need to implement them as keywords because
it's already possible to do safely with templates.  libsigc++ is a great
implementation that works really well (and it's quite fast at
dispatching events).  libsigc++ has an advantage over Qt in that the
signals are actual type-safe template objects.  Qt's signals are
actually strings under the hood, and I've had weird name clash issues in
the past when I didn't realize that.  Can't remember the circumstances
or the details now.  Basically something that should have been caught at
compile time became a runtime error.

Doing event-driven programming with Gtkmm and libsigc++ is actually
pretty darn nice and is right at home in C++.

> There is one big advantage C++ has over C: virtual method dispatching.
> However, I have been able to come up with C idioms that make practical
> method dispatching relatively painless.

Seems like Vala might fit this niche pretty well.

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

#76860

Le vendredi 22 août 2014 23:38:56 UTC+2, Michael Torrie a écrit :
> [...]
> Go is
> 
> quite young but promising except that unicode is all UTF-8 byte strings,
> 
> so string operations are going to be a bit slow.


Certainly not (mathematics).

>>> # Py 3.4.0
>>> timeit.timeit("(s1*100 + s2)[:-1]", "s1 = 'hundred'; s2 = 'EURO'")
1.9532454724939043
>>> timeit.timeit("(s1*100 + s2)[:-3]", "s1 = 'hundred'.encode('utf-8');\
...     s2 = 'EURO'.encode('utf-8')")
0.982759184290785


There are however valid reasons to not use utf-8. It
is not really direcly tied to the intrisic coding
of the characters, but to linguistics and scriptings.

jmf

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

#76826

On Sat, Aug 23, 2014 at 7:38 AM, Michael Torrie <torriem@gmail.com> wrote:
> On 08/22/2014 02:06 PM, Marko Rauhamaa wrote:
>> I tend to think the opposite: C++ barely has a niche left. I definitely
>> wouldn't want to use C++ very far from its (very narrow) sweet spot.
>
> I agree that it's niche is narrowing.  But it's still pretty wide and
> widely used.  Many adobe products are C++, for example.  OpenOffice and
> LibreOffice is C++.  You could argue that's because they are old
> projects and were started in C++. But honestly if you were
> reimplementing OpenOffice today what would you choose?  Python would be
> appropriate for certain aspects of OO, such as parts of the UI, macros,
> filters, etc. ...

Frankly, I wouldn't write OO in anything, because I think the entire
concept of a WYSIWYG editor is flawed. Much better to use markup and
compile it. But if I were to write something like that, probably what
I'd do would be to write a GUI widget in whatever lowish-level
language is appropriate (probably C, with most GUI toolkits), and then
use a high level language (probably Python or Pike) to build the
application. I'm not familiar with all of OO/LO's components, but I
believe that model will probably work for all of them (the document
editor, obviously; the presentation editor might be done a bit
differently, but it'd still work this way; the spreadsheet quite
possibly doesn't even need a custom widget; etc).

>> My disillusionment with C++ came from the language's inability to
>> represent callbacks. C can do it (void *), C# can do it (delegates),
>> Java can do it (anonymous inner classes), Python can do it (methods),
>> Scheme can do it (closures).
>
> C++ can do it quite well, actually.  Maybe not quite as nicely as
> Python.  But boost and libsigc++ both offer nice, type-safe ways to
> implement signals and slots.  You can pass references to a callback
> around in an easy, safe way.

My main issue with callbacks in either C or C++ is that functions
aren't first-class objects. You can pass function pointers around (and
you don't need (void *) to do it, you can use typed function pointers
just fine), but you can't actually construct a function at run-time.

ChrisA

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web