Plotting in C++

Hello all,

I'm starting a new application, and I want to do it in C++. Previously, I've
coded similar things in Python and pygtk, using matplotlib for the
graphics. Now I want to create an application in C++ with a GUI that needs
to display simple plots and hidden surface 3D plots and that runs on Linux
and Windows.

    Part of the problem is that I've been spoiled by matplotlib's
quality :slight_smile: I just can't get myself to use plplot, and AFAIK Gnuplot does
not allow embedding the graphics in the GUI.

   I'm thinking of using wxWidgets because it has more widgets and features
than GTK. Theoretically I could still use matplotlib by embedding python
(see a recent thread "Help with c++ embedding"), but I would rather not do
such things.

   So do you know any free open source library for plotting, that can be
embedded in a GUI (such as wxWidgets or GTK), and usable from C/C++?
Matplotlib may well be a killer application for me in the sense that it
might be easier to just program the whole thing in Python.

Regards,
João Silva

Why not just do the parts you need in c++ and expose them to python,
and then use matplotlib, mayavi2, tvtk, etc, and build your app in
python.

JDH

···

On Fri, Feb 29, 2008 at 9:40 AM, João Luis Silva <jsilva@...668...> wrote:

   So do you know any free open source library for plotting, that can be
embedded in a GUI (such as wxWidgets or GTK), and usable from C/C++?
Matplotlib may well be a killer application for me in the sense that it
might be easier to just program the whole thing in Python.

João Luis Silva wrote:

   So do you know any free open source library for plotting, that can be
embedded in a GUI (such as wxWidgets or GTK), and usable from C/C++?

If you're not committed to a particular GUI, check out QT -- I think there are some plotting tools for QT out there:

http://qwt.sourceforge.net/

I sure wish there was something like that for wxWidgets!

VTK ios worth a look-see too -- it's big and complicated, but very powerful:

http://www.vtk.org/

it can be used with wx, qt, etc, etc...

Matplotlib may well be a killer application for me in the sense that it
might be easier to just program the whole thing in Python.

It's probably easier to program the whole thing in python anyway. It's certainly easier to program wx in python, so what do you have left? your computational code may be able to be written in numpy successfully, and if not, write the core in C or C++, and access it from python with ctypes, SWIG or pyrex, or...

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

Christopher Barker wrote:

João Luis Silva wrote:

   So do you know any free open source library for plotting, that can be
embedded in a GUI (such as wxWidgets or GTK), and usable from C/C++?

If you're not committed to a particular GUI, check out QT -- I think there are some plotting tools for QT out there:

I've heard good things about QT, and, while this program will be open source, I'm doing doing it to learn new technologies that can be applied to big scale commercial applications. I don't like the QT pricing for commercial applications, so it's not an option.

VTK ios worth a look-see too -- it's big and complicated, but very powerful:

http://www.vtk.org/

I've used VTK once, from python. It's big and complicated, and the available documentation is scarce. In the end, it's not what I need.

Matplotlib may well be a killer application for me in the sense that it
might be easier to just program the whole thing in Python.

It's probably easier to program the whole thing in python anyway. It's certainly easier to program wx in python, so what do you have left? your computational code may be able to be written in numpy successfully, and if not, write the core in C or C++, and access it from python with ctypes, SWIG or pyrex, or...

I'm trying to explore new options, and learn new skills. My favorite programming languages are C/C++ and Python. I use Python for small scripts and applications, and C/C++ for everything else. I've started a smallish/medium size open source app in python+pygtk+matplotlib+numpy (laserfoam.sf.net) but I think a large application might be more maintainable in C++. Also, I think C++ is easier to "sell" to the powers that be.

I'm still undecided. As you and John suggest, I may write the GUI in python+wxPython, and everything else in C++, but I was trying to drive the app from C++. The need for python only remains due to its superior plotting tools. Also, I'm trying to keep things simple, so that they just work, on both Linux and Windows.

I guess I have to think this over a bit more. Any further comments or sugestions would be appreciated.

Best Regards,
João Silva

I’m trying to explore new options, and learn new skills. My favorite
programming languages are C/C++ and Python. I use Python for small

scripts and applications, and C/C++ for everything else. I’ve started a
smallish/medium size open source app in python+pygtk+matplotlib+numpy
(laserfoam.sf.net) but I think a large application might be more

maintainable in C++. Also, I think C++ is easier to “sell” to the powers
that be.

I was C++ everywhere before, now I’m C++ only where it matters.
Write your application with Python, there is not scale issue with Python (ILM use it, Google, …), profile it and port what is needed to C or C++ and you will write an efficient and big application in “no” time.

Matthieu

···


French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92

LinkedIn : http://www.linkedin.com/in/matthieubrucher

This is getting OT, but I'd kind of like to see it get archived somewhere...

João Luís Silva wrote:

I'm trying to explore new options, and learn new skills. My favorite programming languages are C/C++ and Python. I use Python for small scripts and applications, and C/C++ for everything else. I've started a smallish/medium size open source app in python+pygtk+matplotlib+numpy (laserfoam.sf.net) but I think a large application might be more maintainable in C++.

I think this is not true AT ALL -- C++ is a big 'ol mess and far too complicated, and not very flexible, no matter how hard it tries.

Also, I think C++ is easier to "sell" to the powers that be.

That can be quite true, depending on who the powers that be are. However, I like a quote from the wxPython list:

"The only difference that my users see between an app written in Python and C++ is that the Python one has more features...and fewer bugs."

I may write the GUI in python+wxPython, and everything else in C++,

I wouldn't write "everything else" in C++ -- I'd only write what you really need to write in C++ - which means only computational code that isn't fast enough with numpy, or device drivers or something like that.

but I was trying to drive the app from C++.

That can be done, but most people do it the other way around, it's easier to drive C++ from python than python from C++. I did get a note on the numpy list from someone driving MPL from C++ for some simple test code, but I don't think it's a robust solution -- I've just forwarded that to you.

The need for python only remains due to its superior plotting tools.

the "need" maybe, but python has many, many, advantages that have nothing to do with plotting (or other libs, though the available libs are a big plus). Really, you'll be writing 1/5 to 1/10 as much code -- that's a BIG savings!

Also, you get built-in scripting -- and I think virtually every app should be scriptable.

Also, I'm trying to keep things simple, so that they just work, on both Linux and Windows.

If you keep your extensions pretty standard C++, that's pretty easy, and python + wxPython is very portable.

I guess I have to think this over a bit more. Any further comments or sugestions would be appreciated.

Here's the key questions:

1) do you need C/C++ at all? maybe not!

2) If so, how much of the functionality of your app really needs to be written in C++? Multi-language development is kind of a pain -- SWIG, Pyrex, ctypes, Boost++, etc help a lot, but it's still a lot of work at the interface, so it only makes sense if you keep that interface small. If there isn't much C++, it's a no-brainer.

3) it seems most projects that do python+C++ development wish they'd done more in Python, not less:

Why do you think that virtually no one writes web apps in C++?

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

Hi all,

Christopher Barker wrote:

"The only difference that my users see between an app written in Python and C++ is that the Python one has more features...and fewer bugs."
  
I'm currently working mostly in C++ and exploring integration with Python through Boost.Python+IPython+MPL. I enjoy working in Python, but I'm afraid of making a more consistent switch mainly for fear of losing the static type checking that C++ gives me. I have the horrifying feeling that if I were to write much code in Python I could break it in so many ways just because of this, and I'd have the constant perception of not having my back covered by the compiler, at least for this kind of errors.

It's true that probably I'd get the software up and running in less time with Python, but I think that I would spend much more time making sure it behaves as expected and "fortifying" it, so to speak. Am I totally offset here?

Francesco.

I suspect there is no answer to this fear except trying it.

If you want to hear your fear ridiculed, you can post this
query on comp.lang.python. If you want to hear your fear
lauded for its sensibility, post it to comp.lang.c++.

That said, note that Python supports properties (getters and
setters) that can do runtime checking.

Also Python 3 supports function annotations, which someone
will certainly exploit to provide type checking.
I guess you might find PEP 3119 (ABCs) relevant as well.

Cheers,
Alan Isaac

···

On Sat, 01 Mar 2008, Francesco Biscani apparently wrote:

I'm currently working mostly in C++ and exploring
integration with Python through Boost.Python+IPython+MPL.
I enjoy working in Python, but I'm afraid of making a more
consistent switch mainly for fear of losing the static
type checking that C++ gives me. I have the horrifying
feeling that if I were to write much code in Python
I could break it in so many ways just because of this, and
I'd have the constant perception of not having my back
covered by the compiler, at least for this kind of errors.

Dear Francesco,

I'm sorry --- it is hard not to read your message and laugh. You really think that the static type checking of C++ is protecting you? Well, it may be, but C++ is unsafe in so many other ways that you are not doing yourself a favor by working in it.

If you want to use a typesafe language, you really should be using Java or Python. Java will give you both static and dynamic type checking. Python will give you runtime type checking. C++ gives you a good feeling until something goes wrong and it crashes.

···

On Feb 29, 2008, at 5:29 PM, Francesco Biscani wrote:

Hi all,

Christopher Barker wrote:

"The only difference that my users see between an app written in Python
and C++ is that the Python one has more features...and fewer bugs."

I'm currently working mostly in C++ and exploring integration with
Python through Boost.Python+IPython+MPL. I enjoy working in Python, but
I'm afraid of making a more consistent switch mainly for fear of losing
the static type checking that C++ gives me. I have the horrifying
feeling that if I were to write much code in Python I could break it in
so many ways just because of this, and I'd have the constant perception
of not having my back covered by the compiler, at least for this kind of
errors.

It's true that probably I'd get the software up and running in less time
with Python, but I think that I would spend much more time making sure
it behaves as expected and "fortifying" it, so to speak. Am I totally
offset here?

Francesco.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Simson Garfinkel wrote:

Dear Francesco,

I'm sorry --- it is hard not to read your message and laugh. You really think that the static type checking of C++ is protecting you? Well, it may be, but C++ is unsafe in so many other ways that you are not doing yourself a favor by working in it.

If you want to use a typesafe language, you really should be using Java or Python. Java will give you both static and dynamic type checking. Python will give you runtime type checking. C++ gives you a good feeling until something goes wrong and it crashes.
  
It is certainly possible to shoot yourself in the foot with C++ if you use it like it were plain C (i.e., unsafe casts, casts to void *, pointers to functions, etc.). However the C++ programming style which is sometimes referred to as "modern" C++ (cfr. Alexandrescu's book), which makes heavy use of template (meta)programming facilities, shields you very effectively from such problems. For example, you can use functors in place of pointers to functions, and if you do something wrong the compiler will error out (in place of random crashes at runtime). If I write a generic template function which requires that its argument supports a certain method, and if I use it with an argument type that does not provide such method, a compilation error will be emitted. You can use the static_cast operator to make sure at compile time that you are not performing a "dangerous" cast. And so on...

Frankly, the only cases in which I usually have to resort to the pains of plain C programming are when fiddling with lower level stuff like memory allocators, SIMD programming, etc. But usually you just have to encapsulate a small amount of dangerous code into a class and provide some abstraction to interact with it and you are done.

I write mostly scientific software, so abandoning C++ tout-court is not an option.

Thanks to all who replied, and best regards.

  Francesco.

Sorry, this really is OT, but I've been doing some research on this issue, so I thought I see what folks here think:

Francesco Biscani wrote:

However the C++ programming style which is sometimes referred to as "modern" C++

OK, so I'll take it as a given for the moment that Modern C++ is typesafe, and, of course JAVA is. Those are the two primary languages that people seem to want to use rather than Python.

I recently had a Java vs. Python discussion at work, so I dug into it on the net once again -- My thesis is that aside from syntax, library support etc, etc, the difference is static vs. dynamic typing. Here's my quickie synopsis:

* Dynamic typing allows more flexibility and therefor greater productivity.

* Static typing provides more safety, and the ability to optimize compiled code.

Ignoring performance issues, that leaves: Productivity vs. type safety.

What I've found is that folks that are fans of statically typed languages really don't get how much productivity can increase. If you haven't really written code in a dynamic language (and I mean "really", if you write Fortran with Python syntax, that doesn't count), you tend to think that all you're saving is the typing involved in declaring types and interfaces, etc. That's simply not the case -- dynamically typed languages let you build far more flexible systems with far less code. This has been well documented, at least anecdotally.

So the question is: does the type safety you get out weigh the productivity gains? Some say not for quickie scripts, but yes to big systems, or particularly for "if it fails, someone can die" systems. I'm not so sure.

We all make type errors when writing code (forget to turn that string into a number before passing it off to the calculation code, or whatever), the fact that a static language's compiler catches a lot of errors like that doesn't mean at all that they wouldn't get caught quickly with a dynamic language. In fact, my personal experience is that those kind of errors get caught very quickly, usually the first test of the code in question. The point is that while the compiler can catch those bugs for you, those aren't the bugs I care about. In fact, in my reading, I haven't found a SINGLE anecdote by anyone about a deep, hard to find bug caused by a type error in a dynamic language, Not one.

Has anyone seen such an anecdote? Or better yet, a real study?

So why are people so concerned, and letting these issues drive their decisions? A couple reasons:

1) All they know is that their compiler is catching a lot of errors, so they can imagine that some of those errors would never be found if the compiler wasn't finding them -- you know that sense of relief when you finally get a bunch of code to compile! Even though it may not work right at all, there's still a sense of accomplishment.

2) When you've primarily worked with static languages, you really don't get how much less code you can write with a dynamically typed language -- you're so used to thinking that a given method is designed to work with a couple specific types and classes -- what's so hard about declaring them? I think folks see the gains from type checking, and really have no idea that there are significant costs. Here's a good essay about that:

http://www.artima.com/weblogs/viewpost.jsp?thread=4639

A quote from that: "So I tried writing some applications in Python, and then Ruby (well known dynamically typed languages). I was not entirely surprised when I found that type issues simply never arose."

3) A point made in that article: some folks have bad memories from C (or Fortran), with type issues. The problem is that they are mistaking weak typing (or no typing!), like you get when you cast a pointer to a new type, with dynamic typing, where the type is checked, just not 'till run time. I used to write Fortran code where you'd pass in references to a procedure that expected certain types, and the compiler wouldn't check anything, it would just merrily go along and use that memory address, which could be total garbage -- that did suck!

This is also a good article about the issue (from the Author of "Thinking in Java", no less):

http://mindview.net/WebLog/log-0066

Here's a choice quote from that one:
"""
you bring up an interesting question in suggesting that a dynamically-typed language may require more unit testing than a statically typed language. Of this I am not convinced; I suspect the amount may be roughly the same and if I am correct it implies that the extra effort required to jump through the static type-checking hoops may be less fruitful than we might believe.
"""

My way of phrasing that -- you're either testing a given code path or you're not -- if you are not, then you don't know if the code works. If you are, then you're testing the types and the results at the same time -- there's no extra testing required to test the typing.

Well, enough written about that! Sorry for the OT post.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...