caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] stl?
Date: Tue, 3 Mar 2009 23:36:52 +0000	[thread overview]
Message-ID: <200903032336.53089.jon@ffconsultancy.com> (raw)
In-Reply-To: <87zlg2z19g.fsf@aryx.cs.uiuc.edu>

On Tuesday 03 March 2009 22:31:55 Yoann Padioleau wrote:
> I don't know what are the Stepanov requirements, but C++
> can do unboxed collections like  list<int>, which OCaml can
> not provide I think. a 'int list' has boxed integers in OCaml.

The currently OCaml implementation never boxes ints and the boxing of other 
types (like float) is an artefact of the current implementation not found in 
other language implementations like F# and my HLVM. Moreover, this is not 
even a visible difference.

> Also, a maybe good thing with STL is that you can write a single 'find'
> or 'sort' function that will work for every kind of collections
> (list, arrays, map, hash, etc) by using the
> indirect iterator idiom, without the penalty of dynamic dispatch
> solutions. I am not sure OCaml can do that too.

OCaml can do that too. Just wrap your code in a functor and parameterize it 
over the module implementing the data structure (e.g. List or Array). Modules 
and functors are second-class statically resolved constructs in OCaml so 
there is no dynamic dispatch.

> The question is do we really need those 2 things?

Parameterizing code using functors is extremely useful but it goes far beyond 
the usable capabilities of C++.

> I've worked a little bit with C++ using unboxed objects, that
> is without introducing pointers (similar to boxing) in templates,
> like list<figure> instead of list<figure*>, and passing them
> as value in parameters, or returning them,
> and it was far less efficient because there was lots of copy,
> and you could not use then virtual method on them. So in the
> end the C++ programmer I thing manually re-introduce boxing
> when using STL if he wants good performance, and he can not really
> rely either on the default copy/equal implementation provided
> by those templates. So, yes STL makes it possible to do things,
> but programmers don't want them, or only in very few cases where
> one need extreme performance.

The STL is extremely slow. If you want fast code in C++ then you drop to the C 
subset. Alex Stepanov tried and failed to implement efficient constructs in 
the STL. Furthermore, the memory consumption of his library is awful. OCaml's 
GC is far more efficient with memory whilst permitting easy sharing.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e


  parent reply	other threads:[~2009-03-03 23:31 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-03 21:40 stl? Raoul Duke
2009-03-03 22:31 ` [Caml-list] stl? Yoann Padioleau
2009-03-03 22:42   ` Till Varoquaux
2009-03-03 23:36   ` Jon Harrop [this message]
2009-03-04  0:13     ` Peng Zang
2009-03-04  0:58     ` Yoann Padioleau
2009-03-04  1:10       ` Raoul Duke
2009-03-04  1:19         ` Pal-Kristian Engstad
2009-03-04  1:21         ` Yoann Padioleau
2009-03-04  1:29       ` Jon Harrop
2009-03-04 14:26     ` Kuba Ober
2009-03-04 14:24   ` Kuba Ober
2009-03-03 23:42 ` Jon Harrop
2009-03-04  0:11   ` Brian Hurt
2009-03-04  1:05     ` Yoann Padioleau
2009-03-04  4:56       ` Brian Hurt
2009-03-04 20:11         ` Yoann Padioleau
2009-03-04 21:59           ` Brian Hurt
2009-03-04 22:42             ` Yoann Padioleau
2009-03-04 23:19               ` Jon Harrop
2009-03-04 23:03             ` Jon Harrop
2009-03-11  3:16               ` Brian Hurt
2009-03-11  5:57                 ` David Rajchenbach-Teller
2009-03-11  6:11                   ` David Rajchenbach-Teller
2009-03-04  1:59     ` Jon Harrop
2009-03-04  6:11       ` Brian Hurt
2009-03-04 14:08         ` Christophe TROESTLER
2009-03-04 14:19         ` Peng Zang
2009-03-04 16:14           ` Brian Hurt
2009-03-04 16:35             ` Andreas Rossberg
2009-03-04 16:40             ` Peng Zang
2009-03-04 21:43             ` Nicolas Pouillard
2009-03-05 11:24             ` Wolfgang Lux
2009-03-04 19:45         ` Jon Harrop
2009-03-04 21:23           ` Brian Hurt
2009-03-04 23:17             ` Jon Harrop
2009-03-05  2:26             ` stl? Stefan Monnier
2009-03-04  3:10     ` [Caml-list] stl? Martin Jambon
2009-03-04  6:18       ` Brian Hurt
2009-03-04 16:35 ` Mikkel Fahnøe Jørgensen
2009-03-04 16:48   ` Yoann Padioleau
2009-03-04 20:07     ` Jon Harrop
2009-03-04 20:31       ` Richard Jones
2009-03-04 20:49       ` Yoann Padioleau
2009-03-04 21:20         ` Andreas Rossberg
2009-03-04 21:51         ` Pal-Kristian Engstad
2009-03-04 22:50           ` Jon Harrop
2009-03-04 23:18             ` Pal-Kristian Engstad
2009-03-05  1:31               ` Jon Harrop
2009-03-05  2:15                 ` Pal-Kristian Engstad
2009-03-05  3:26                   ` Jon Harrop
2009-03-05  6:22                     ` yoann padioleau
2009-03-05  7:02                       ` Raoul Duke
2009-03-05  8:07                         ` Erick Tryzelaar
2009-03-05  9:06                       ` Richard Jones
2009-03-05  9:34                         ` malc
2009-03-05  9:56                           ` Richard Jones
2009-03-05 10:49                             ` malc
2009-03-05 11:16                               ` Richard Jones
2009-03-05 12:39                                 ` malc
2009-03-05 19:39                       ` Jon Harrop
2009-03-05 21:10                       ` Pal-Kristian Engstad
2009-03-05 22:41                         ` Richard Jones
2009-03-05 22:53                         ` malc
2009-03-05  8:59                   ` Richard Jones
2009-03-05 17:50                     ` Raoul Duke
2009-03-05  8:17             ` Kuba Ober
2009-03-05  1:06         ` Jon Harrop
2009-03-05  9:09           ` Richard Jones
2009-03-05 20:44             ` Jon Harrop
2009-03-05 20:50               ` Jake Donham
2009-03-05 21:28                 ` [Caml-list] OCaml's intermediate representations Jon Harrop

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200903032336.53089.jon@ffconsultancy.com \
    --to=jon@ffconsultancy.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).