headers
Jesse Jones | 1 Dec 2000 01:04
Picon
Favicon

Re: Re: Callbacks Again

>> The view/controller needs three things from the model: 1)
>> notfication of changes so that it can invalidate itself 2) access
>> to the data so that it can render something for the user to see
>> 3) mutators so that the user can change the model. Notification can
>> be handled nicely via callbacks. I can imagine using some some sort
>> of callback architecture to handle the other two but it's not a
>> natural solution and it really seems like overkill when most views
>> will never be reused in other contexts.
>
>Just to illustrate the setup:
>
>--Record.h:
>
>class Record {
>	...
>};
>
>--Model.h:
>
>#include "signal.h"
>#include "record.h"
>class Model {
>public:
>	signal<void, Record> sendUpdateToViews;
>	void receiveUpdateFromView(Record r) {
>		change model to reflect r
>		sendUpdateToViews(r);
>	}
>};
>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Kevlin Henney | 1 Dec 2000 01:00

Re: Re: New New Callbacks Uploaded

In message <906epr+6d3a <at> eGroups.com>, William Kempf <sirwillard <at> my-
deja.com> writes
>Sorry, but "main part" and "a major part" are quite different 
>concepts (you did say "the major part" which could be equivalent 
>to "main part" but that argument is pointless so I assumed you 
>meant "a major part").  

As best I understand it, main part and major part are effectively
synonymous.

>I don't care if 75% of the usage fits your 
>other categories, if 25% fits the third category it MUST be addressed 
>accordingly in the implementation.  

I think again you are misunderstanding where I'm coming from on this. I
am not dismissing them (anything but), I am simply saying that where
function objects are concerned the case you are describing is not the
majority, in other words it is a minority. It is a point of fact not a
point for debate. I merely made the point to support another point!

>And frankly, I think we've made a 
>case that for many of us it's at least close to this, if not 
>exceeding it.  For STL algorithm usage I might reduce this to your 
>point of view, but, frankly, the concept being discussed here is 
>needed precisely because we're using it in places and for uses other 
>than STL algorithms.  

I think a broader view on function objects and their applications would
give a different perspective. Function objects can be used in many more
ways than you are suggesting -- this is on a par with limiting templates
(Continue reading)

Permalink | Reply | 29 comments |
headers
Kevlin Henney | 1 Dec 2000 01:01

Re: Problem with cast.zip

In message <B64C1805.3F0%darylew <at> mac.com>, Daryle Walker
<darylew <at> mac.com> writes
>The file "lexical_cast.htm" in "cast.zip" still has references to a
>'lexical_context,' which has been long dead.  

Oops, editor asleep on the job.

>Can these be removed?

Most certainly!

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  +44 117 942 2990
  Curbralan Limited               mobile: +44 7801 073 508
  mailto:kevlin <at> curbralan.com     fax:    +44 870 052 2289
  http://www.curbralan.com
____________________________________________________________
Permalink | Reply | 0 comments |
headers
Jeremy Siek | 1 Dec 2000 02:20
Picon

Re: Re: A class template for an N-dimensional generic resizable array

Hi Giovanni,

Hmm, my intuition is that when dereferencing the Array<int,2>::iterator
and Array<int,3>::iterator I should get a subarray, not an element. I
would rather have to explicitly request a "flattened" view to get what you
have here.

Also, have you though about adding access to arbitrary sub arrays, and
other kinds of slicing ala Blitz++?

Cheers,
Jeremy

On Wed, 29 Nov 2000, Giovanni Bavestrelli wrote:
> This kind of iteration is already possible in my Array as it is, 
> since each SubArray has iterators, with their begin and end member 
> functions. So, if you have a 3 dimensional array, you can traverse 
> dimensions like this:
> 
> 
> Array<int,3> A3(ArraySizes(10)(20)(30)); // 3D Array of ints
> 
> // Traverse through a monodimensional slice within the 3D array
> for (Array<int,1>::iterator i=A3[0][1].begin(),z=A3[0][1].end();i!
> =z;i++)
>        *i=1;
> 
> // Traverse through a bidimensional slice within the 3D array
> for (Array<int,2>::iterator i=A3[0].begin(), z=A3[0].end();i!=z;i++)
>        *i=1;
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jeremy Siek | 1 Dec 2000 04:36
Picon

Re: TypeLISP


Just want to note that a cons-list is conceptually similar to the tuple
of the LL, so we probably don't need multiple versions of "cons" in boost,
but it certainly would be good to have the list manipulation operations
shown here. Also, some STL algorithms would be appropriate to rewrite
in terms of these lists.

Cheers,
Jeremy

On Thu, 30 Nov 2000 netterdag <at> hotmail.com wrote:

> 
> Hi
> 
> Recently I made a *very* experimental typelist implementation
> with some "LISP"-like functionality. Is something like this of
> interest? Anyway, here it is... (Sorry if I've managed to break any 
> Boost posting rule with this one.)
> 
> Note for those trying to compile this:
> I've tested it using GCC-2.95.2 (Mingw32) with STLport 4.0.
> You probably need to increase the template depth of GCC
> (I've used -ftemplate-depth-30)
> 
> --
> Regards
> Gabriel
> 
> //--- begin
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Abrahams | 1 Dec 2000 05:16
Picon

Re: py_cpp and vector<..>::const_iterator

Ullrich,

the cursor stuff looks good, but it leaves me wondering why your interface
provides:

    y = l.cursor()[3]
    for x in l.cursor():

but not:

    y = l[3]
    for x in l:

which would seem more natural.

----- Original Message -----
From: "Ullrich Koethe" <koethe <at> informatik.uni-hamburg.de>
To: <boost <at> egroups.com>
Sent: Thursday, November 30, 2000 11:49 AM
Subject: Re: [boost] py_cpp and vector<..>::const_iterator

OK, I put the cursor into branch "cursor", and the build system into
branch "build_system". Both include updated documentation. Please test
these extensions and, if OK, integrate them into the main branch.

Regards
Ulli

David Abrahams wrote:
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Anton Gluck | 1 Dec 2000 06:36

Re: py_cpp: isinstance with extension classes

Dave,

> I suggest writing isinstance() in Python something like this.
> 
> # untested! (not needed For Python 2.0)
> def _is_subclass(t1, t2):
>     for b in getattr(t1. '__bases__', ()):
>         if b is t2 or _is_subclass(b, t2):
>             return 1
>     return 0
> 
> # untested! For Python 1.5 or 2.0
> def is_instance(obj, type):
>     return isinstance(obj, type) or _is_subclass(getattr(obj, '__class__',
> None), type)

I've tried to implement an isinstance() for Python 1.5.2 that would work
with extension classes following your suggestion. However, on closer look,
the above code will create the same problem as the original 
isinstance(obj, type) since this is what it calls too. You might remember
that the error with isinstance() is "second argument must be a class". 

This here worked for me, but I don't know how generally applicable it
would be:

def _is_instance(obj, type):
    if obj.__class__ == type:
	return 1
    else:
	return 0
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevlin Henney | 1 Dec 2000 11:12

Re: Re: New New Callbacks Uploaded

In message <v03110702b64c92d38729 <at> [153.32.222.4]>, Jesse Jones
<jejones <at> adobe.com> writes
>Callback doesn't mean event notification to me or, I think, many people. It
>means deferred function call which is exactly exactly the concept we're
>addressing.

Yes, the meaning of deferred call is the original one, but I have
noticed a slow shift towards more specialised use in recent years, eg

http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=callback

I don't know how much of the specialisation in vocab is related to the
rise of event-driven architectures, but in common use it is no longer as
general or unambiguous as it used to be. For STL function objects, I
note that many users do not immediately think of them as callbacks
although, strictly speaking, they are.

So, I think that the use of the term callback is not as clear as you
might have hoped, and we should -- as library authors -- be aware of and
sensitive to that.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  +44 117 942 2990
  Curbralan Limited               mobile: +44 7801 073 508
  mailto:kevlin <at> curbralan.com     fax:    +44 870 052 2289
  http://www.curbralan.com
____________________________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Scherer | 1 Dec 2000 11:27
Picon

MSVC section in <boost/config.hpp>

One of the recent updates of <boost/config.hpp> introduced the line

   #define NOMINMAX

in the compiler-section for MSVC.  Although this may be convenient
for most of the users most of the time, I would like to ask that
this be replaced by the more conservative version

   #ifndef NOMINMAX
   #define NOMINMAX
   #endif

Technical reasons (aka compiler deficiencies) force us to define
NOMINMAX in some of our own project files, and with the current
settings of <boost/config.hpp>, MSVC issues a warning about the
redefinition.  (It's more or less undefined, which headers might
come first, ours or <boost/config.hpp>.)

Thanks,
Andreas
Permalink | Reply | 1 comment |
headers
Kevlin Henney | 1 Dec 2000 12:09

Re: Re: New New Callbacks Uploaded

In message <906dmn+bo7q <at> eGroups.com>, William Kempf <sirwillard <at> my-
deja.com> writes
>> As an aside, if you take this from a function object perspective 
>then
>> proper copying semantics are the ones that make immediate sense. The
>> question of reference counting for sharing semantics becomes 
>unasked.
>
>I'm not sure I follow this.  Taken at face value here I'd have to 
>disagree with you because this is a very specific class of function 
>objects, aka a polymorphic function object used to wrap generic 
>function objects for use in code that can't be rely on template 
>typing.  As such I don't know if ref-counting semantics aren't 
>appropriate.

Ah, but I _do_ know they aren't appropriate ;->

The design principles involved are cohesion, orthogonality and cohesion,
and we can come at this from three different perspectives:

(1) A polymorphic function object that wraps generic function objects
does not imply sharing. By its very description it is intended to be
like a function object. These things don't share (or appear to share)
their representation unless they are explicitly written to do so. That
is the function object authors responsibility, not the default library
abstraction's.

(2) There is a misconception that we are wrapping a given instance of a
function or function object, which is not the case. We are encapsulating
a copy. Given that reference counting is used for one of two reasons --
(Continue reading)

Permalink | Reply | 2 comments |

Gmane