headers
Gavin Collings | 1 Apr 2000 13:15
Picon

Re: array-wrapper or vector with static size (was

> >Darin Adler wrote:
> >THIS is an important design issue. Unless somebody has a solution to
> >fit
> >both needs, we have to decide between what I would call an
> > - array wrapper and
> > - an STL container  similar to vector with static size.
> >Or may be we introduce both.
> >
> >However, if we introduce both, then we need a name for both
> >(I' suggest array for the array wrapper and ???vector for the
> latter).
> >
> >Opinions, please!
> 
> Ouch!  Let's avoid two if we possibly can.  Sounds like the problem
> needs better definition.

As I see it, the language prevents reconciling the two, and both are useful.  I
don't like "vector", as it's too different to std::vector and it sort of implies
variable size.  It could be done as a specialisation (template <typename T,
std::size_t n, bool Initialisable = false> class array {...}), but I prefer
something like naked_array for the former (it reminds the user that it is
potentially uninitialized) and array for the latter.

Gavin

--
Gavin Collings
gcollings <at> sperry-sun.co.uk
(Continue reading)

Permalink | Reply | 0 comments |
headers
Beman Dawes | 2 Apr 2000 18:02

Re: CopyPtr & ClonePtr ?

At 08:21 AM 3/24/00 -0500, Kevin Atkinson wrote:

>...  Also please forgive the
>wonderful typos that constantly appear in my emails.

Your "typos" often make me smile!

But note that English is a second language for many boost members.
Word plays can be confusing to non-native speakers.

--Beman
Permalink | Reply | 1 comment |
headers
Kevin Atkinson | 2 Apr 2000 21:43
Picon

Re: CopyPtr & ClonePtr ?

On Sun, 2 Apr 2000, Beman Dawes wrote:

> At 08:21 AM 3/24/00 -0500, Kevin Atkinson wrote:
> 
> >...  Also please forgive the
> >wonderful typos that constantly appear in my emails.
> 
> Your "typos" often make me smile!
> 
> But note that English is a second language for many boost members.
> Word plays can be confusing to non-native speakers.

It not like I mean to do it.  I am just very prone to misspelling
things....

---
Kevin Atkinson
kevinatk <at> home.com
http://metalab.unc.edu/kevina/
Permalink | Reply | 0 comments |
headers
Tomasz Kowalczyk | 4 Apr 2000 14:09

SUBMISSION: Signal/slot library

Dear Boost Members,

I have written a library which deals with so-called signal/slot
connections. I would like to ask you for review and comments. Since
boost libraries contain lots of beautiful work, I thought it would be
the best place to have my own code criticized.

The source can be found in:
http://www2.gol.com/users/tomek/signals.tar.gz

and a short introduction:
http://www2.gol.com/users/tomek/signals.html

Although the library is far from complete, I decided to post it because
I believe the techniques employed are very powerful and extremely
useful, especially in event-driven environments (such as most GUI
toolkits). I hope to find here new ideas, advice, and maybe gain some
interest in the further development.

The library you can find in the above URL was a side product of an
OpenGL-based viewer for 3D geometry. That's why the abstractions may not
be as general as they could be (this is especially true for slots and
and connection predicates).

Please let me explain in a few words what the whole signal idea is
about, as I can see it now.

Say you have an class template called signal. For example:

signal<A,B> sig;  // equivalent to a function  void sig(A,B)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Borgerding, Mark A. | 4 Apr 2000 15:52

RE: SUBMISSION: Signal/slot library

Sorry, I don't have many comments on the code itself, mainly on the concepts
and presentation.

Let me start off by showing my ignorance.  I am not really familiar with the
concept of signal and slot.

I found the Qt documentation about it and it sheds a little more light.
http://doc.trolltech.com/signalsandslots.html

It would help clarify your explanation if you noted the strengths and
inadequacies of the Qt approach (like the fact that it seems to need a
special compiler is a *major* drawback).  And then comment on how your
approach builds on the strengths and addresses the inadequacies.

I have a hard time thinking up some good examples.  Some code and narrative
explanation might help to clarify.  

It may just be my unfamiliarity with signals and slots, but I question
whether something that is based on callbacks is the right idiom to promote
for C++.  

By the way, I think that (Qt's) choice of the term "signal" was a poor one.

- Mark

> -----Original Message-----
> From: tomasz <at> smtp03.mail.gol.com [mailto:tomasz <at> smtp03.mail.gol.com]On
> Behalf Of Tomasz Kowalczyk
> Sent: Tuesday, April 04, 2000 8:09 AM
> To: boost <at> egroups.com
(Continue reading)

Permalink | Reply | 19 comments |
headers
Hibbs, Philip | 4 Apr 2000 16:01
Picon

RE: SUBMISSION: Signal/slot library

>the fact that it seems to need a
>special compiler is a *major* drawback

Actually all it seems to need is a special preprocessor. It generates regular
C++ code, so I suppose you could write it all by hand, but it looks like a lot
of work.

Philip Hibbs http://www.snark.freeserve.co.uk/
Opinions expressed may not even be my own, let 
alone those of any organisations, nations, species, 
or schools of thought to which I may be affiliated.
Permalink | Reply | 0 comments |
headers
Tomasz Kowalczyk | 5 Apr 2000 16:45

Re: SUBMISSION: Signal/slot library

"Borgerding, Mark A." wrote:
> 
> Sorry, I don't have many comments on the code itself, mainly on the concepts
> and presentation.
> 
> Let me start off by showing my ignorance.  I am not really familiar with the
> concept of signal and slot.
> 
> I found the Qt documentation about it and it sheds a little more light.
> http://doc.trolltech.com/signalsandslots.html

If you need explanation of the concepts, you should have a look in
http://libsigc.sourceforge.net. It is a similar library for Gtk-- (Gtk+
wrapper in C++). They use more modern C++ and have nice narrative
explanations on their site. They have done a pretty good work and
libsigc was my main inspiration. 

I left that references on purpose. They restrict you to think in terms
of GUI and GUI notifications. In my opinion a proper way of thinking
about this mechanism is about storing arbitrary code for later
execution.

> 
> It would help clarify your explanation if you noted the strengths and
> inadequacies of the Qt approach (like the fact that it seems to need a
> special compiler is a *major* drawback). And then comment on how your
> approach builds on the strengths and addresses the inadequacies.
> 
> I have a hard time thinking up some good examples.  Some code and narrative
> explanation might help to clarify.
(Continue reading)

Permalink | Reply | 18 comments |
headers
Borgerding, Mark A. | 5 Apr 2000 17:52

shared_ptr runtime gotcha with MSVC

I found another bug with MSVC that rears its ugly head with a (patched)
shared_ptr.

Beman, 
The patches I sent you on 3/22 unearth some funky problems in an unrelated
part of the class.  I suggest we shelve the patches for now and still
consider MSVC to be completely broken wrt template members.

I am sending this to the list to fully describe the problem.

Here is the problem:

The following code should not compile ( by the shared_ptr definition ).
   {
      boost::shared_ptr<int> spI;
      spI = new int(5); // <= this should give an error
      *spI = 12;
   }

It should not compile because:
-- There is no shared_ptr::operator=(T*)
-- The shared_ptr constructor is explicit, so the new int* cannot be
converted to a temporary.

MSVC lets the above fly without even a warning, even at level 4.

At runtime the second statement doesn't do *anything*. It's like it's not
there. This causes the third statement to puke, because spI is still NULL.

It seems to have something to do with the template member operator=.  I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Matelich | 6 Apr 2000 00:15
Picon

Re: SUBMISSION: Signal/slot library

Tomasz Kowalczyk wrote:

> If you need explanation of the concepts, you should have a look in
> http://libsigc.sourceforge.net. It is a similar library for Gtk-- (Gtk+
> wrapper in C++). They use more modern C++ and have nice narrative
> explanations on their site. They have done a pretty good work and
> libsigc was my main inspiration.

I'm not being confrontational, just curious.  Could you tell me why I would use
your library and not libsigc?

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sosedada <at> usa.net
tmatelich <at> zetec.com
Permalink | Reply | 16 comments |
headers
Mario Contestabile | 6 Apr 2000 01:49
Picon
Favicon

Fw: shared_ptr runtime gotcha with MSVC

> > I found another bug with MSVC that rears its ugly head with a
> (patched)
> > shared_ptr.
>

 Microsoft isn't the only compiler complaining. Intel's C++ compiler trips
up
trying to compile directory.cpp, whereas MSVC does not.
Attachment: application/x-ygp-stripped, 152 bytes
Permalink | Reply | 2 comments |

Gmane