[ANN] macstl -- new C++ source library for the Macintosh

  • Pixelglow Software is proud to announce the immediate availability of macstl 0.1.1 -- a
    new C++ source library designed to bring the Macintosh into the world of modern
    generic programming. macstl gives you the elegance and efficiency of programming
    with templates. macstl is distinctly mac as well -- you program with Mac OS X concepts
    and technologies using a cutting-edge interface.

    macstl offers a new implementation of std::valarray optimized for the Altivec. It runs
    inline arithmetic 7.76x faster than gcc 3.1 and inline transcendentals 14.21x faster than
    gcc 3.1. Even with Altivec optimizations off, it is almost 2x faster than gcc, due to the
    ruthless weeding out of redundant loads and stores.

    The Mach copy-on-write vector is a partial specialization of std::vector for the Mach
    allocator. It neatly uses the OS vm_copy facility to "get around" thread safety issues
    when doing copy-on-write and reference counting. As a result, std::vector can be
    copied, passed back by value and enlarged without the same overheads.

    http://www.pixelglow.com/macstl/

    Cheers, Glen Low
    Pixelglow Software
    http://www.pixelglow.com/
  • On Thursday, August 7, 2003, at 10:12 PM, No Spam wrote:

    > Pixelglow Software is proud to announce the immediate availability of
    > macstl 0.1.1 -- a
    > new C++ source library designed to bring the Macintosh into the world
    > of modern
    > generic programming.

    Forgive me for chuckling, but Mac (Cocoa and predecessors)) programmers
    have been in the world of modern generic programming since around 1985
    and are waiting for most of the rest of the world (C++) to catch up.

    (I know this macstl is probably a great thing for C++ programmers and
    wish it good luck -- I just thought the generic programming bit was
    funny)

    best regards
    Chad
  • On Friday, August 8, 2003, at 12:16  AM, Chad Leigh -- ObjectWerks Inc.
    wrote:

    > On Thursday, August 7, 2003, at 10:12 PM, No Spam wrote:
    >
    >> Pixelglow Software is proud to announce the immediate availability of
    >> macstl 0.1.1 -- a
    >> new C++ source library designed to bring the Macintosh into the world
    >> of modern
    >> generic programming.
    >
    > Forgive me for chuckling, but Mac (Cocoa and predecessors))
    > programmers have been in the world of modern generic programming since
    > around 1985 and are waiting for most of the rest of the world (C++) to
    > catch up.

    Heck, leaving aside the NeXT heritage, where I agree, I remember a time
    when Metrowerks had the most compliant STL library around for Classic
    Mac OS.  Has it fallen behind lately, or is this just marketing-speak?

    -Patrick
  • Chad,

    I would fire my PR manager for that humorous email, but unfortunately
    he is me, and then I would be out of a job :-)

    On a more serious note, "generic programming" does mean some specific
    in the context of C++ (and languages like Java and um, C#). It allows
    containers to return fully-typed objects, for example, but also forces
    them to always contain that sort of object.

    For example, in Cocoa:

    NSMutablearray *array;
    array = [[NSMutableArray alloc] init];
    X *x;
    [array addObject:x];
    Y *y;
    y = [array objectAtIndex;0];

    If X and Y are incompatible e.g. they are not related by inheritance,
    this will result in a runtime error.

    However in C++:

    vector <X> array ();
    X x;
    array.push_back (x);
    Y y = array [0];

    Now if X and Y are incompatible, this will be caught at compile time.

    Note that that locks you into storing only X in the vector<X> so that
    is less flexible. But as a practical point, I needed generic
    programming to get the speed and performance I wanted out of Altivec
    optimization.

    libstdc++ ships with the gcc 3.1 that comes with Mac OS X 10.2
    Developer Tools, and is a complete and up-to-date implementation of
    STL. I mainly wrote macstl for specifically Mac things, to complement
    the Standard Library: CFPlugIn, Mach allocator, Altivec.

    Cheers, Glen Low

    ---
    pixelglow software | simply brilliant stuff
    www.pixelglow.com
  • As far as I can tell, it still is more ANSI C++ compliant than GCC 3.3.
    In fact I'm hard-pressed to find a part of the standard that MW doesn't
    do as of 8.3 (must be some obscure thing around there, plus there are a
    couple places where the compiler can get confused, but other than that
    it's there).

    That's coming from one who can't compile his C++ code in GCC 3.3
    because it won't do covariant return types where there are public
    virtual classes.

    Hope that helps.

    On Friday, 8 August 2003, at 6:21 AM, Patrick Coskren wrote:

    > On Friday, August 8, 2003, at 12:16  AM, Chad Leigh -- ObjectWerks
    > Inc. wrote:
    >
    >> On Thursday, August 7, 2003, at 10:12 PM, No Spam wrote:
    >>
    >>> Pixelglow Software is proud to announce the immediate availability
    >>> of macstl 0.1.1 -- a
    >>> new C++ source library designed to bring the Macintosh into the
    >>> world of modern
    >>> generic programming.
    >>
    >> Forgive me for chuckling, but Mac (Cocoa and predecessors))
    >> programmers have been in the world of modern generic programming
    >> since around 1985 and are waiting for most of the rest of the world
    >> (C++) to catch up.
    >
    > Heck, leaving aside the NeXT heritage, where I agree, I remember a
    > time when Metrowerks had the most compliant STL library around for
    > Classic Mac OS.  Has it fallen behind lately, or is this just
    > marketing-speak?
    >
    > -Patrick
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
    >
    >

    /*
    Oscar Morales Vivó

    Eternal Computer Science Student. Master of C++ Templates. Cocoa Nut.
    Computer Graphics Scientiam Lumina. UI Guru in Training. Dabbler in all
    things CS and most which are not.

    Web stuff: http://homepage.mac.com/oscarmv/index.html
    */
  • On Friday, Aug 8, 2003, at 08:28 Europe/London, Glen Low wrote:

    > On a more serious note, "generic programming" does mean some specific
    > in the context of C++ (and languages like Java and um, C#). It allows
    > containers to return fully-typed objects, for example, but also forces
    > them to always contain that sort of object.

    Yes, this is a restriction on a fully polymorphic container, which can
    potentially be a useful optimization.  However, like all optimizations
    it should only be applied after profiling has identified a hot-spot in
    the final application.  Applying the restriction beforehand is
    premature optimization.

    > For example, in Cocoa:
    >
    > NSMutablearray *array;
    > array = [[NSMutableArray alloc] init];
    > X *x;
    > [array addObject:x];
    > Y *y;
    > y = [array objectAtIndex;0];
    >
    > If X and Y are incompatible e.g. they are not related by inheritance,
    > this will result in a runtime error.

    Actually, it will not.  First, just getting the object and (for
    example) passing it along or storing it somewhere else won't result in
    a runtime error, no matter what.  That allows you to write truly
    generic code.  Secondly, two objects need not be related by inheritance
    to be compatible in Objective-C, they just need to respond to the same
    (subset of) protocol required in a particular circumstance.  The
    restriction to an inheritance-relationship is specific to C++.

    Marcel

    --
    Marcel Weiher                Metaobject Software Technologies
    <marcel...>        www.metaobject.com
    Metaprogramming for the Graphic Arts.  HOM, IDEAs, MetaAd etc.
      1d480c25f397c4786386135f8e8938e4
  • On Fri, Aug 08, 2003 at 10:56:24AM +0100, Marcel Weiher wrote:
    }
    } On Friday, Aug 8, 2003, at 08:28 Europe/London, Glen Low wrote:
    }
    } >On a more serious note, "generic programming" does mean some specific
    } >in the context of C++ (and languages like Java and um, C#). It allows
    } >containers to return fully-typed objects, for example, but also forces
    } >them to always contain that sort of object.
    }
    } Yes, this is a restriction on a fully polymorphic container, which can
    } potentially be a useful optimization.  However, like all optimizations
    } it should only be applied after profiling has identified a hot-spot in
    } the final application.  Applying the restriction beforehand is
    } premature optimization.

    Actually, the value isn't in runtime speed but in development/testing
    speed. Static typing of this sort (and much more complicated constructions)
    make it possible to catch a lot of potential errors at compile time rather
    than runtime. The advantage of more static analysis is that errors need not
    fall on a commonly used (and thus likely to be tested) code path to be
    found since the compiler will complain about them before one even has a
    chance to run the program. I find that for large systems (I'm writing one
    for work) I simply can't do without that static analysis, even though I
    like feel of Objective-C better.

    [...]
    } >If X and Y are incompatible e.g. they are not related by inheritance,
    } >this will result in a runtime error.
    }
    } Actually, it will not.  First, just getting the object and (for
    } example) passing it along or storing it somewhere else won't result in
    } a runtime error, no matter what.  That allows you to write truly
    } generic code.  Secondly, two objects need not be related by inheritance
    } to be compatible in Objective-C, they just need to respond to the same
    } (subset of) protocol required in a particular circumstance.  The
    } restriction to an inheritance-relationship is specific to C++.

    While this can make some constructions much easier to express, a lot of it
    can be written in such a way that the compiler does some debugging for you
    if one uses C++ templates. Honestly, my experience has been if I can make
    the compiler do work I would otherwise have to do, it's a win.

    } Marcel
    --Greg
  • Marcel:

    >> For example, in Cocoa:
    >>
    >> NSMutablearray *array;
    >> array = [[NSMutableArray alloc] init];
    >> X *x;
    >> [array addObject:x];
    >> Y *y;
    >> y = [array objectAtIndex;0];
    >>
    >> If X and Y are incompatible e.g. they are not related by inheritance,
    >> this will result in a runtime error.
    >
    > Actually, it will not.  First, just getting the object and (for
    > example) passing it along or storing it somewhere else won't result in
    > a runtime error, no matter what.  That allows you to write truly
    > generic code.  Secondly, two objects need not be related by
    > inheritance to be compatible in Objective-C, they just need to respond
    > to the same (subset of) protocol required in a particular
    > circumstance.  The restriction to an inheritance-relationship is
    > specific to C++.

    Apologies, as Chad first and rightly pointed out to me in a private
    reply, it does not result in a runtime error. However if you send a
    message that Y understands but X does not, then if you send it to y in
    the program, it will abort with a "selector not found" error. In this
    sense Objective-C is generic, like Smalltalk and C++ templates are, in
    that an object can respond to an arbitrary message. not just one from
    an inheritance relationship -- the importance difference is: in C++,
    this is checked at compile time.

    Cheers, Glen Low

    ---
    pixelglow software | simply brilliant stuff
    www.pixelglow.com
  • I my experience with 14 years of C++ programming as C++ has evolved and
    gained more features as well as more baggage, the static analysis that
    you praise is largely useless for finding bugs at compile time and can
    radically reduce the productivity of programmers.  Obviously, a lot
    depends on the type of application being written and the subset
    ANSI/ISO C++ being used (no one uses all of if because there is no
    compiler in the world that supports all of it today).  I still use C++
    everyday, but I wish I didn't have to.

    1) No amount of static compile-time analysis assures that there are no
    bugs in a program.  Therefore, the program must be rigorously tested.
    Given the existence of rigorous tests, it doesn't really matter if bugs
    are found at compile time or run time because the only place they need
    to be found is test time.

    2) The amazing productivity benefits of a simpler and more dynamic
    language like Objective-C means that for the same development cost, the
    Objective-C programmer can optimize and test much more than the C++
    programmer.

    The test driven development people are starting to see the light:
    http://www.artima.com/weblogs/viewpost.jsp?thread=4639
    http://mindview.net/WebLog/log-0025

    On Friday, August 8, 2003, at 07:09 AM, Gregory Seidman wrote:

    > On Fri, Aug 08, 2003 at 10:56:24AM +0100, Marcel Weiher wrote:
    > }
    > } On Friday, Aug 8, 2003, at 08:28 Europe/London, Glen Low wrote:
    > }
    > } >On a more serious note, "generic programming" does mean some
    > specific
    > } >in the context of C++ (and languages like Java and um, C#). It
    > allows
    > } >containers to return fully-typed objects, for example, but also
    > forces
    > } >them to always contain that sort of object.
    > }
    > } Yes, this is a restriction on a fully polymorphic container, which
    > can
    > } potentially be a useful optimization.  However, like all
    > optimizations
    > } it should only be applied after profiling has identified a hot-spot
    > in
    > } the final application.  Applying the restriction beforehand is
    > } premature optimization.
    >
    > Actually, the value isn't in runtime speed but in development/testing
    > speed. Static typing of this sort (and much more complicated
    > constructions)
    > make it possible to catch a lot of potential errors at compile time
    > rather
    > than runtime. The advantage of more static analysis is that errors
    > need not
    > fall on a commonly used (and thus likely to be tested) code path to be
    > found since the compiler will complain about them before one even has a
    > chance to run the program. I find that for large systems (I'm writing
    > one
    > for work) I simply can't do without that static analysis, even though I
    > like feel of Objective-C better.
    >
    > [...]
    > } >If X and Y are incompatible e.g. they are not related by
    > inheritance,
    > } >this will result in a runtime error.
    > }
    > } Actually, it will not.  First, just getting the object and (for
    > } example) passing it along or storing it somewhere else won't result
    > in
    > } a runtime error, no matter what.  That allows you to write truly
    > } generic code.  Secondly, two objects need not be related by
    > inheritance
    > } to be compatible in Objective-C, they just need to respond to the
    > same
    > } (subset of) protocol required in a particular circumstance.  The
    > } restriction to an inheritance-relationship is specific to C++.
    >
    > While this can make some constructions much easier to express, a lot
    > of it
    > can be written in such a way that the compiler does some debugging for
    > you
    > if one uses C++ templates. Honestly, my experience has been if I can
    > make
    > the compiler do work I would otherwise have to do, it's a win.
    >
    > } Marcel
    > --Greg
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
    >
previous month august 2003 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Go to today