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

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

[OT] fortran lib which provide python like data type

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

Contents

  [OT] fortran lib which provide python like data type 1989lzhh <1989lzhh@gmail.com> - 2015-01-29 21:39 +0800
    Re: [OT] fortran lib which provide python like data type beliavsky@aol.com - 2015-01-29 14:39 -0800
      Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-29 17:40 -0800
        Re: [OT] fortran lib which provide python like data type Christian Gollwitzer <auriocus@gmx.de> - 2015-01-30 08:32 +0100
          Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-30 08:27 -0800
            Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 10:08 -0700
              Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-30 09:31 -0800
                RAII vs gc (was fortran lib which provide python like data type) Rustom Mody <rustompmody@gmail.com> - 2015-01-30 10:02 -0800
                  Re: RAII vs gc (was fortran lib which provide python like data type) Sturla Molden <sturla.molden@gmail.com> - 2015-01-30 21:28 +0000
                    Re: RAII vs gc (was fortran lib which provide python like data type) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-01 14:00 +1100
                      Re: RAII vs gc (was fortran lib which provide python like data type) Chris Angelico <rosuav@gmail.com> - 2015-02-01 14:21 +1100
                  Re: RAII vs gc (was fortran lib which provide python like data type) Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-31 19:27 -0800
                Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 11:15 -0700
                  Re: [OT] fortran lib which provide python like data type Paul Rubin <no.email@nospam.invalid> - 2015-01-30 10:23 -0800
                    Re: [OT] fortran lib which provide python like data type Christian Gollwitzer <auriocus@gmx.de> - 2015-01-31 09:27 +0100
                  Re: [OT] fortran lib which provide python like data type Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-31 11:51 +1300
                    Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 10:49 +1100
                    Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-01-31 14:22 +0200
                      Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-31 07:50 -0800
                        Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-01-31 19:43 +0200
                          Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-31 18:30 -0800
                            Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 09:38 +0200
                              Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 03:49 +1100
                                Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 20:57 +0200
                                  Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 12:59 +1100
                                    Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 13:05 +1100
                                      Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 10:51 +0200
                                    Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-02 13:04 +1100
                                      Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 18:01 +1100
                                      Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 10:52 +0200
                                        Re: [OT] fortran lib which provide python like data type Paul Rudin <paul.nospam@rudin.co.uk> - 2015-02-02 12:56 +0000
                                          Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 15:27 +0200
                                        Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 16:08 +0000
                                          Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-02-02 08:21 -0800
                                            Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 16:52 +0000
                                            Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-03 04:25 +1100
                                            Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 18:34 +0000
                                            Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-03 10:15 +1100
                                    Re: [OT] fortran lib which provide python like data type Matthew Barnett <auxlang@mrabarnett.plus.com> - 2015-02-02 02:35 +0000
                                    Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-02 13:45 +1100
                                      Re: [OT] fortran lib which provide python like data type Roy Smith <roy@panix.com> - 2015-02-01 23:12 -0500
                                    Re: [OT] fortran lib which provide python like data type Roy Smith <roy@panix.com> - 2015-02-01 23:14 -0500
                                      Re: [OT] fortran lib which provide python like data type Chris Angelico <rosuav@gmail.com> - 2015-02-02 15:47 +1100
                                      Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-02 16:06 +0000
                        Re: [OT] fortran lib which provide python like data type Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-31 17:59 +0000
                      Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-01 13:27 +1100
                      Re: [OT] fortran lib which provide python like data type Paul Rubin <no.email@nospam.invalid> - 2015-01-31 22:26 -0800
                        Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 09:58 +0200
                          Re: [OT] fortran lib which provide python like data type Christian Gollwitzer <auriocus@gmx.de> - 2015-02-01 09:14 +0100
                            Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-01 21:12 +0200
                              Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-01 17:50 -0700
                              Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-01 18:02 -0700
                                Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 09:39 +0200
                                  Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-02 09:25 -0700
                                    Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 19:57 +0200
                                      Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-02 11:23 -0700
                                        Re: [OT] fortran lib which provide python like data type Marko Rauhamaa <marko@pacujo.net> - 2015-02-02 20:54 +0200
                              Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-02-01 18:02 -0700
                    Re: [OT] fortran lib which provide python like data type beliavsky@aol.com - 2015-02-02 05:30 -0800
                  Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 10:50 +1100
                    Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 20:49 -0700
                      Re: [OT] fortran lib which provide python like data type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 22:04 +1100
                        Re: [OT] fortran lib which provide python like data type Rustom Mody <rustompmody@gmail.com> - 2015-01-31 08:18 -0800
            Re: [OT] fortran lib which provide python like data type Sturla Molden <sturla.molden@gmail.com> - 2015-01-30 23:12 +0000
            Re: [OT] fortran lib which provide python like data type Michael Torrie <torriem@gmail.com> - 2015-01-30 20:35 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#85046

In article <mailman.18388.1422845124.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Mon, Feb 2, 2015 at 1:35 PM, Matthew Barnett
> <auxlang@mrabarnett.plus.com> wrote:
> > And the plural of "virus" is "viruses", not "viri" (that's the plural of
> > "vir") or "virii" (that would be the plural of "virius", if it existed).
> 
> Yes indeed."Virii" and "octopi" are as wrong as "hice" for "houses"
> (paralleling mice).

And, of course, I die, but we dice.

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

#85047

In article <54ceda0b$0$12977$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> What is the plural of octopus?

It's a trick question.  Octopus is already plural.  Monopus is singular.

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

#85049

On Mon, Feb 2, 2015 at 3:14 PM, Roy Smith <roy@panix.com> wrote:
> In article <54ceda0b$0$12977$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
>> What is the plural of octopus?
>
> It's a trick question.  Octopus is already plural.  Monopus is singular.

People is already plural, too, but you can talk about all the peoples
of the world. Also, I can use "people" as the subject and "is" as the
verb, just to completely destroy any chance of a simple grammar parser
being able to cope with English.

ChrisA

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

#85088

On 02/02/2015 04:47, Chris Angelico wrote:
> On Mon, Feb 2, 2015 at 3:14 PM, Roy Smith <roy@panix.com> wrote:
>> In article <54ceda0b$0$12977$c3e8da3$5496439d@news.astraweb.com>,
>>   Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>>
>>> What is the plural of octopus?
>>
>> It's a trick question.  Octopus is already plural.  Monopus is singular.
>
> People is already plural, too, but you can talk about all the peoples
> of the world. Also, I can use "people" as the subject and "is" as the
> verb, just to completely destroy any chance of a simple grammar parser
> being able to cope with English.
>
> ChrisA
>

I'm simple and I cope (somehow) with English.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#84965

On 31/01/2015 15:50, Rustom Mody wrote:
> On Saturday, January 31, 2015 at 5:52:58 PM UTC+5:30, Marko Rauhamaa wrote:
>> Esthetically, I'm most impressed with Scheme. One day it might give
>> Python a run for its money.
>>
>>
>> Marko
>
> Aren't you getting this backwards?
>
> http://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python
>
> Dont get me wrong: Ive had more fun with scheme than any other language.
> [And APL for very different reasons]
> Its just that its 2015 now not 1985...
> People did not 'settle' the question: "How many angels can dance on the head
> of a pin". It just stopped being relevant.
>
> Likewise, which is the 'best' programming language is a question without the
> edge it had when I was a student
>

The answer is beautifully put here 
https://mail.python.org/pipermail/python-list/2002-November/154258.html 
so I have no hesitation in reposting for the umpteenth time.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#84969

Marko Rauhamaa wrote:

> I'm most impressed with Scheme. One day it might give
> Python a run for its money.

Scheme is forty years old, having come out in 1975. Python is 24 years old,
having come out in 1991. If Scheme hasn't caught up with Python by now, it
never will.



-- 
Steven

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

#84983

Marko Rauhamaa <marko@pacujo.net> writes:

> The guiding principle in C++ language development is to take static
> type safety to the extreme. 

Heh, try Ada.

> Stroustrup apparently has never had to deal with callbacks; his thick
> books never made a mention of them last time I checked.

C++ has function pointers just like C, but more idiomatically you'd pass
a class instance and the library would invoke some method on it.  There
is also Boost::Coroutine which can get rid of the need for callbacks in
some situations.

> Esthetically, I'm most impressed with Scheme. One day it might give
> Python a run for its money.

It's in a small and shrinking niche, unfortunately.

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

#84988

Paul Rubin <no.email@nospam.invalid>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> Stroustrup apparently has never had to deal with callbacks; his thick
>> books never made a mention of them last time I checked.
>
> C++ has function pointers just like C,

Et tu, Brute!

C's callbacks always use a void pointer for the "self reference." In C,
I can use void pointers and type casts idiomatically. In C++, type casts
are apostasy.

Qt gave up on C++ when it comes to callbacks ("signals") and went for an
apocryphal metacompiler.

> but more idiomatically you'd pass a class instance and the library
> would invoke some method on it.

Yes, that's what I ended up doing, defining a class for each callback
type:

   struct ButtonPushListener {
       virtual void buttonPush(int x, int y) = 0;
   };

(Yes, "struct" and not "class"! Why?)

Typing all of that in was quite a chore. All because Stroustrup didn't
think of delegates (Delphi, C#, Python). C++'s method pointers are
ridiculous and useless, they should have been defined as delegates.

> There is also Boost::Coroutine which can get rid of the need for
> callbacks in some situations.

Boost is the world's biggest fig leaf.


Marko

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

#84989

Am 01.02.15 um 08:58 schrieb Marko Rauhamaa:
> Paul Rubin <no.email@nospam.invalid>:
> 
>> Marko Rauhamaa <marko@pacujo.net> writes:
>>> Stroustrup apparently has never had to deal with callbacks; his thick
>>> books never made a mention of them last time I checked.
>>
>> C++ has function pointers just like C,
> 
> Et tu, Brute!
> 
> C's callbacks always use a void pointer for the "self reference." In C,
> I can use void pointers and type casts idiomatically. In C++, type casts
> are apostasy.
> 
> Qt gave up on C++ when it comes to callbacks ("signals") and went for an
> apocryphal metacompiler.

Yes, but only because C++ compilers were not good enough when QT came
out, and later is was too late to change it to a templated system.
Lookup libsigc++ http://libsigc.sourceforge.net/ which does the same
using standard C++ and http://qt-project.org/doc/qt-4.8/templates.html
for a reasoning of QT.

In C++11 (supported by MSVC, g++, clang) there re also lambda expressions

	Christian

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

#85021

Christian Gollwitzer <auriocus@gmx.de>:

> Am 01.02.15 um 08:58 schrieb Marko Rauhamaa:
>> Qt gave up on C++ when it comes to callbacks ("signals") and went for
>> an apocryphal metacompiler.
>
> Yes, but only because C++ compilers were not good enough when QT came
> out, and later is was too late to change it to a templated system.
> Lookup libsigc++ http://libsigc.sourceforge.net/ which does the same
> using standard C++ and http://qt-project.org/doc/qt-4.8/templates.html
> for a reasoning of QT.
>
> In C++11 (supported by MSVC, g++, clang) there re also lambda expressions

So please implement this small piece of Python code in C++ so we can
compare the idioms:

    import sys, time

    class MyLogger:
        def __init__(self, write):
            self.write = sys.stderr.write

        def register_writer(self, write):
            self.write = write

        def log(self, text):
            self.write("{} {}\n".format(time.time(), text))

    class MyApp:
        def __init__(self, logger):
            self.logf = open("thelog.log", "a")
            logger.register_writer(self.log_write)

        def log_write(self, text):
            self.logf.write(text)
            self.logf.flush()


Marko

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

#85035

On 02/01/2015 12:12 PM, Marko Rauhamaa wrote:
> Christian Gollwitzer <auriocus@gmx.de>:
> 
>> Am 01.02.15 um 08:58 schrieb Marko Rauhamaa:
>>> Qt gave up on C++ when it comes to callbacks ("signals") and went for
>>> an apocryphal metacompiler.
>>
>> Yes, but only because C++ compilers were not good enough when QT came
>> out, and later is was too late to change it to a templated system.
>> Lookup libsigc++ http://libsigc.sourceforge.net/ which does the same
>> using standard C++ and http://qt-project.org/doc/qt-4.8/templates.html
>> for a reasoning of QT.
>>
>> In C++11 (supported by MSVC, g++, clang) there re also lambda expressions
> 
> So please implement this small piece of Python code in C++ so we can
> compare the idioms:

Honestly with the C++ standard library implementing std::function and
std::bind macros, idiomatically it would look very much similar to the
Python code you showed.

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

#85036

On 02/01/2015 12:12 PM, Marko Rauhamaa wrote:
> So please implement this small piece of Python code in C++ so we can
> compare the idioms:

So I though I might just for kicks code up a C++ version.  In doing so,
I realized that idomatically, this particular example would not really
use callbacks in real life, but rather stream objects.  Would look
nearly the same but be more idiomatic C++.

However, C++ function pointers are actually pretty slick in C++11. See
the example near the bottom of the page:

http://en.cppreference.com/w/cpp/utility/functional/function

Thus if we were to shoehorn your example into C++, the result would be
idiomatically very similar to what you have in your Python code.

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

#85063

Michael Torrie <torriem@gmail.com>:

> http://en.cppreference.com/w/cpp/utility/functional/function
>
> Thus if we were to shoehorn your example into C++, the result would be
> idiomatically very similar to what you have in your Python code.

I can understand why you wouldn't write out my example in C++:

   using std::placeholders::_1;

   std::function<void(int)> f_add_display2 =
        std::bind( &Foo::print_add, foo, _1 );

vs

   f_add_display2 = foo.print_add

The cherry on top: "_1"! The C++ compiler figures out template types
heroically but can't wrap its head around the arity of the method.


Marko

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

#85093

On 02/02/2015 12:39 AM, Marko Rauhamaa wrote:
> Michael Torrie <torriem@gmail.com>:
> 
>> http://en.cppreference.com/w/cpp/utility/functional/function
>>
>> Thus if we were to shoehorn your example into C++, the result would be
>> idiomatically very similar to what you have in your Python code.
> 
> I can understand why you wouldn't write out my example in C++:

I wouldn't write it out because it's a contrived example, and why should
I waste my time? You have no intention of being impressed with C++, let
alone simply learn about it.

> 
>    using std::placeholders::_1;
> 
>    std::function<void(int)> f_add_display2 =
>         std::bind( &Foo::print_add, foo, _1 );

Looks okay to me.  That's normal C++ that would be clear to any C++
programmer.  And for a statically compiled language, that's incredibly
powerful while providing for a measure of safety.  You may shudder, but
it's a really good statically compiled solution, given the constraints
of C++ and its compiler.

But like I said, idiomatically in C++, this isn't normally what you'd do
anyway.  You'd store a std::ostream object.

> vs
> 
>    f_add_display2 = foo.print_add
> 
> The cherry on top: "_1"! The C++ compiler figures out template types
> heroically but can't wrap its head around the arity of the method.

std::bind is a generic function that works with undecorated function
pointers.  There's no possible way for the compiler to know the arity of
the function without you telling it (how else would you do it? I
honestly want to know.).  That you would find this fact to be
incredulous suggests that you have very little understanding of
compilers in general.  Python being a dynamic, interpreted language can
examine a function at runtime.

Python is a very expressive language compared to C++ that can do things
at runtime that C++ cannot.  It's also an interpreted, dynamically-typed
language, whereas C++ is a statically-typed language that is clearly
faster at many things than Python is.  It's a matter of different tools
for different jobs.  For most of my jobs Python is the right tool.  But
I can see why people would still want to pick a compiled language, and I
can understand why some people still use C++.  It's a very powerful
language.

I'm a little unclear as to why you're even bringing up the comparison
with C++.  What's your point?  To feel superior?

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

#85097

Michael Torrie <torriem@gmail.com>:

> You have no intention of being impressed with C++, let alone simply
> learn about it.

I am fully open to being impressed. I have more than a decade of C++
programming under my belt, although not much for the past few years.

> There's no possible way for the compiler to know the arity of
> the function without you telling it (how else would you do it?

Somehow, C# manages it just fine.

> I honestly want to know.).

See

  <URL: https://msdn.microsoft.com/en-us/library/aa288459%28v=vs.71%29.aspx>

> That you would find this fact to be incredulous suggests that you have
> very little understanding of compilers in general. Python being a
> dynamic, interpreted language can examine a function at runtime.

C# does it at compile-time. C++ could have and should have introduced
delegates early on. The method pointer syntax was screaming for delegate
semantics. Too bad that didn't occur to Stroustrup until it was too
late.

> I'm a little unclear as to why you're even bringing up the comparison
> with C++. What's your point? To feel superior?

I really don't understand why you are taking all of this so personally.
We are just discussing different aspects of different programming
languages.


Marko

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

#85098

On 02/02/2015 10:57 AM, Marko Rauhamaa wrote:
> I really don't understand why you are taking all of this so personally.
> We are just discussing different aspects of different programming
> languages.

Fair enough. You raise good points.  I am not taking it personally; your
emails, lacking emotional context, just seemed a bit unnecessarily
argumentative. For example, "The cherry on top: "_1"! The C++ compiler
figures out template types heroically but can't wrap its head around the
arity of the method".

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

#85103

Michael Torrie <torriem@gmail.com>:

> Fair enough. You raise good points.  I am not taking it personally; your
> emails, lacking emotional context, just seemed a bit unnecessarily
> argumentative. For example, "The cherry on top: "_1"! The C++ compiler
> figures out template types heroically but can't wrap its head around the
> arity of the method".

I feel programming languages, being inanimate abstractions, can take my
abuse.


Marko

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

#85037

On 02/01/2015 05:50 PM, Michael Torrie wrote:
> Honestly with the C++ standard library implementing std::function and
> std::bind macros, idiomatically it would look very much similar to the
> Python code you showed.

Make that templates, not macros.

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

#85081

On Friday, January 30, 2015 at 5:51:38 PM UTC-5, Gregory Ewing wrote:
> Michael Torrie wrote:
> > On 01/30/2015 10:31 AM, Rustom Mody wrote:
> > 
> >>And what about the grey area between lightweight and heavyweight?
> > 
> > That's what the smart pointers are for.
> 
> I'd say it's what higher-level languages are for. :-)
> 
> I'm completely convinced nowadays that there is
> *no* use case for C++. If you need to program the
> bare metal, use C. For anything more complicated,
> use a language that has proper memory-management
> abstractions built in.

Lots of people are using C++ to build packages for statistical programming language R, using the package Rcpp. It has been possible to build such packages for R and S using Fortran and C since the beginning, and many have done so, but the wide usage of Rcpp suggests that there are advantages to using C++. C++ is still the primary language used by financial derivatives quants.

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

#84926

Michael Torrie wrote:

> If that happened, then it's because you the programmer wanted it to
> happen.  It's not just going to happen all by itself.  Yes anytime
> pointers are allowed, things are potentially unsafe in the hands of a
> programmer.  I'm just saying it's not nearly so bad as you make it out
> to be.  Follow basic rules and 99% of segfaults will never happen and
> the majority of leaks will not happen either.


Oh great. So if the average application creates a hundred thousand pointers
of the course of a session, you'll only have a thousand or so seg faults
and leaks.

Well, that certainly explains this:

https://access.redhat.com/articles/1332213

Manual low-level pointer manipulation is an anti-pattern. What you glibly
describe as programmers following "basic rules" has proven to be beyond the
ability of the programming community as a whole.



-- 
Steven

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web