Queue

Queue

[steve]

i have sent up a queue package using head and tail pointers, and have
procedures for adding, removing and nodes. But l am haveing trouble writing
a procedure for displaying the nodes. Can anyone send me a procedure where
you can display all the nodes.

Thanks in advance.

Steve

Re: Queue

[Jeffrey Carter]

steve wrote:
> 
> i have sent up a queue package using head and tail pointers, and have
> procedures for adding, removing and nodes. But l am haveing trouble writing
> a procedure for displaying the nodes. Can anyone send me a procedure where
> you can display all the nodes.

That's quite simple:

generic -- Display_Nodes
   with function End_Of_Nodes return Boolean;
   with function Get (Q : Queue) return Node;
   with procedure Next (Q : in out Queue);
   with procedure Display (N : in Node);
procedure Display_Nodes (Q : in out Queue);

procedure Display_Nodes (Q : in out Queue) is
   -- null;
begin -- Display_Nodes
   All_Nodes : loop
      exit All_Nodes when End_Of_Nodes (Q);

      Display (N => Get (Q) );
      Next (Q => Q);
   end loop All_Nodes;
end Display_Nodes;

Seriously, since we have no idea what your queue package looks like,
what a node looks like, or what you mean by "display", how can you
expect anyone here to be able to do this? If, as seems likely, this is a
homework assignment, no one here will do your homework for you. Your
first place to go for help should be your instructor. If you have
specific problems and your instructor can't help you, then we might be
able to help with a clearly stated and narrowly focused question.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail

Queue

[steve]

Which is the best way to make a queue using head and tail pointers

Many thanks

Re: Queue

[Larry Kilgallen]

In article <yUBM7.7695$4d6.1768979@news11-gui.server.ntli.net>, "steve" <steve_rm@ntlworld.com> writes:
> Which is the best way to make a queue using head and tail pointers

Start by defining your own idea of "best".

To get some hints, look at the last month's posts in this newsgroup
that have the string "List Container" in the title.  Many diverse
opinions have been advanced.

Re: Queue

[Ted Dennison]

In article <BWq3g0s2usk2@eisner.encompasserve.org>, Larry Kilgallen says...
>
>In article <yUBM7.7695$4d6.1768979@news11-gui.server.ntli.net>, "steve" <steve_rm@ntlworld.com> writes:
>> Which is the best way to make a queue using head and tail pointers
>
>Start by defining your own idea of "best".
>
>To get some hints, look at the last month's posts in this newsgroup
>that have the string "List Container" in the title.  Many diverse
>opinions have been advanced.

Yeah. If we knew the answer to that question unanamously, there would have been
about 150 less posts here in the last two weeks. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Queue

[Marin David Condic]

Or, if we had been able to settle on something and agree that it was going
to be The One, we could have said "Here's a link to the standard Ada data
structure library..." and forced professors everywhere to ban its use in
Data Structures courses. :-)

I'd still be willing to settle on the BC's with some enhancements and
extensions. Anybody else willing to go that route?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:%QRM7.39743$xS6.65958@www.newsranger.com...
>
> Yeah. If we knew the answer to that question unanamously, there would have
been
> about 150 less posts here in the last two weeks. :-)
>

Re: Queue

[Matthew Heaney]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9u0qhb$pq5$1@nh.pace.co.uk...
> I'd still be willing to settle on the BC's with some enhancements and
> extensions. Anybody else willing to go that route?

No.  The problem with the Booch Components is that they use inheritance,
which is completely unnecessary unless you require dynamic polymorphic
behavior.

The C++ STL doesn't use inheritance.  The use of iterators and algorithms
abstracts away the details of specific containers, and thus treats all
collections as a "sequence."  This is a form of static polymorphism.

If you do need a dynamically polymorphic container (a stack, say), then you
can implement that yourself using an Adapter pattern.

The standard library should provide only the most basic primitives, from
which higher-level abstractions can be constructed.

Re: Queue

[Marin David Condic]

Well, I guess the problem I see is that we could easily keep going back and
forth on what constitutes the best possible solution indefinitely. We'd be
far better off getting something as an answer - even if it is imperfect.

Maybe its hopeless? Is it a little too much like asking "What's the best
kind of car to drive?" or "What's the best shotgun to have?" - Too many
potential uses and personal preferences to come up with a "best" answer and
nobody wants to settle for a sub-optimal answer. Maybe we'd end up with
Lists and Maps if the next standard just has them show up in a sneak attack,
but it seems that this process is not likely to get a consensus strong
enough to get a result.

I think that Ted proposed a package that would make a good start. But that
rather quickly shot off in a few dozen directions with objections on all
sorts of fronts - and it was only one little lonely list package.  I could
still imagine taking it pretty much "as is" and adding to it a map package
that looked similar and declaring that "Version 1.0". Any chance that
proposal would gain any support? Anybody else have a proposed answer?

I think if we don't commit to some direction pretty soon, the stagnation and
deadlock will result in a lack of interest and this will wither on the vine.
Too bad. Its a good idea and a noble goal.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Matthew Heaney" <mheaney@on2.com> wrote in message
news:u07tltbt28eq1d@corp.supernews.com...
>
> No.  The problem with the Booch Components is that they use inheritance,
> which is completely unnecessary unless you require dynamic polymorphic
> behavior.
>
> The C++ STL doesn't use inheritance.  The use of iterators and algorithms
> abstracts away the details of specific containers, and thus treats all
> collections as a "sequence."  This is a form of static polymorphism.
>
> If you do need a dynamically polymorphic container (a stack, say), then
you
> can implement that yourself using an Adapter pattern.
>
> The standard library should provide only the most basic primitives, from
> which higher-level abstractions can be constructed.
>
>
>
>
>

Re: Queue

[Ehud Lamm]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9u0ujd$rhg$1@nh.pace.co.uk...
> I think if we don't commit to some direction pretty soon, the stagnation
and
> deadlock will result in a lack of interest and this will wither on the
vine.
> Too bad. Its a good idea and a noble goal.

Exactly.
That's why I wanted the central repository to be on AdaPower, and the
discussion to be here.
It all started falling apart when people started posting their favorite
ideas on their own web pages. This is exactly the situation we started with.
We are now trying to work on consolidation, not to show our creativity (not
that I have anything against all the itneresting suggestions, I just don't
think they advance the cause...)

Ehud

Re: Queue

[Marin David Condic]

Well, people posting a variety of ideas is not all bad - but at some point
this has to narrow down to a set of optional courses of action and a
decision needs to be taken as to which option to persue. If a set of three
or four options were posted on AdaPower & a vote taken, we could probably
all ralley around the flag and start arguing about how to
enhance/improve/extend the chosen course of development.

If this were a corporate endeavor - or sponsored by a corporate endeavor,
the product owner/boss would have declared an autocratic and arbitrary
course of action and we'd have all been told to sit down, shut up and get to
work making the game plan successful. :-) I'm sure that once a decision is
taken on this, most of us would be willing to pull together and get some
version of it working. The problem is that this is barely a democracy - if
even close to that. Any one or more of us can pick up our marbles and go
home at any time and if enough of us do that, the whole effort collapses.

IMHO, if we're serious about wanting this, we ought to agree on some set of
choices/design directions/whatever and toss a coin to select a winner. From
there, I'm sure we could collaborate to get any enhancements, extensions or
implementation done.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:9u10bt$ake$1@news.huji.ac.il...
>
> Exactly.
> That's why I wanted the central repository to be on AdaPower, and the
> discussion to be here.
> It all started falling apart when people started posting their favorite
> ideas on their own web pages. This is exactly the situation we started
with.
> We are now trying to work on consolidation, not to show our creativity
(not
> that I have anything against all the itneresting suggestions, I just don't
> think they advance the cause...)
>

Re: Queue

[Ehud Lamm]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9u136q$aa$1@nh.pace.co.uk...
> Well, people posting a variety of ideas is not all bad - but at some point
> this has to narrow down to a set of optional courses of action and a
> decision needs to be taken as to which option to persue. If a set of three
> or four options were posted on AdaPower & a vote taken, we could probably
> all ralley around the flag and start arguing about how to
> enhance/improve/extend the chosen course of development.

I think this is what I suggested a while back, but I am not sure this is
what you advocate, if I understand the rest of your message. Are you in
favor of this approach?

>  The problem is that this is barely a democracy - if
> even close to that. Any one or more of us can pick up our marbles and go
> home at any time and if enough of us do that, the whole effort collapses.
>

That's good, in my book. I don't think this is likely to happen, and if it
does it means there are better alternatives - which is good in and of
itself.

> IMHO, if we're serious about wanting this, we ought to agree on some set
of
> choices/design directions/whatever and toss a coin to select a winner.
From
> there, I'm sure we could collaborate to get any enhancements, extensions
or
> implementation done.

This is what I started with. My original message on this was a list of goals
and design criteria. Most poster thought it is better to start with
something more concrete like Ted's strawman. In retrospect I think this was
indeed very useful, and indeed essential. But perhaps the time has come to
revisit the list of goal and try to produce a more polished version.

Ehud

Re: Queue

[Marin David Condic]

I'm in favor of any approach that gets a concensus going about what to
select as a component library for Ada. The danger here is debating the issue
for too long and ending up with *no* component library as a result.

AFAIK, there have been a handful of proposed directions - such as BC's+mods,
PragmAda+mods, Ted's list package strawman, etc. So far, there seems to be
some motion in the direction of building something from scratch based on
Ted's strawman. It seems that this was getting bogged down in a variety of
debates about iterators, sorts, library-level instantiations, etc. I don't
know if we want to take some kind of vote on it or not - but it seems like
it could be a viable direction if we can keep it from getting stalled. I
could get behind Ted's package and would be willing to help get it
implemented if needed - maybe others would do so as well?

Or are there still strong feelings about wanting to make fundamental changes
to Ted's strawman that would preclude using it as-is for a start?
(Superficial changes that can be added or tweaked later are O.K. in my
mind - is the spec good enough that if it were implemented, we'd have an
acceptable approach that might get extended/enhanced at a later point?) Or
is there still some interest in debating alternative approaches?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:9u14o2$d61$1@news.huji.ac.il...
>
> I think this is what I suggested a while back, but I am not sure this is
> what you advocate, if I understand the rest of your message. Are you in
> favor of this approach?
>

Re: Queue

[Brian Rogoff]

On Tue, 27 Nov 2001, Matthew Heaney wrote:
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9u0qhb$pq5$1@nh.pace.co.uk...
> > I'd still be willing to settle on the BC's with some enhancements and
> > extensions. Anybody else willing to go that route?
> 
> No.  The problem with the Booch Components is that they use inheritance,
> which is completely unnecessary unless you require dynamic polymorphic
> behavior.
> 
> The C++ STL doesn't use inheritance.  The use of iterators and algorithms
> abstracts away the details of specific containers, and thus treats all
> collections as a "sequence."  This is a form of static polymorphism.

Interestingly enough, there was a proposal to do something like this
(very much like the C++ STL) in Ada circa 1990. I mentioned it loooong 
ago, maybe in 1997 when there was some discussion of the STL here. I
forget the author's name, but she was a prof at some South African
university. What's interesting to me is that this was completely
independent of the STL line of work. I can dig up the ref if anyone is
interested. 

Doing an STL like library in Ada is certainly possible, but it will never
fit as snugly with Ada as the STL does with C++, for a number of reasons. 

> The standard library should provide only the most basic primitives, from
> which higher-level abstractions can be constructed.

I agree completely. To do otherwise would be an abstraction inversion. You 
can build a safe library on top of a fast one, but not vice-versa. 

-- Brian

Re: Queue

[Mats Karlssohn]

Brian Rogoff wrote:
%<
> Interestingly enough, there was a proposal to do something like this
> (very much like the C++ STL) in Ada circa 1990. I mentioned it loooong
> ago, maybe in 1997 when there was some discussion of the STL here. I
> forget the author's name, but she was a prof at some South African
> university. What's interesting to me is that this was completely
> independent of the STL line of work. I can dig up the ref if anyone is
> interested.

Please do! I'd like to read that.

> Doing an STL like library in Ada is certainly possible, but it will never
> fit as snugly with Ada as the STL does with C++, for a number of reasons.

I haven't really dug into this subject, would you care to expand on
this issue and perhaps suggest ways to make it fit better with Ada.


-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Queue

[Brian Rogoff]

I thought I replied, but my reply didn't even show up on Google groups.
&@#$ing computers!

On Wed, 28 Nov 2001, Mats Karlssohn wrote:
> Brian Rogoff wrote:
> %<
> > Interestingly enough, there was a proposal to do something like this
> > (very much like the C++ STL) in Ada circa 1990. I mentioned it loooong
> > ago, maybe in 1997 when there was some discussion of the STL here. I
> > forget the author's name, but she was a prof at some South African
> > university. What's interesting to me is that this was completely
> > independent of the STL line of work. I can dig up the ref if anyone is
> > interested.
>
> Please do! I'd like to read that.


@article{ bishop90effect,
    author = "J. M. Bishop",
    title = "The Effect of Data Abstraction on Loop Programming
Techniques",
    journal = "IEEE Transactions on Software Engineering",
    volume = "16",
    number = "4",
    publisher = "IEEE Computer Society",
    address = "Washington, DC",
    pages = "389--402",
    year = "1990"
}

> > Doing an STL like library in Ada is certainly possible, but it will never
> > fit as snugly with Ada as the STL does with C++, for a number of reasons.
>
> I haven't really dug into this subject, would you care to expand on
> this issue and perhaps suggest ways to make it fit better with Ada.

Well, for one thing pointer traversal using ++, --, etc is a common idiom
in C and C++, and since those operators, and [], are overloadable in C++,
STL code for traversing an ADT looks like low level pointer bumbing code.
C also has that ability to refer just beyond the end of an array and that
notion maps well to the one off the end iterator value.

The excessive instantiations that you need in an Ada version of the STL
become ponderous IMO. I believe this is a fundamental problem with Ada
generics, and perhaps even a fundamental issue in statically typed
languages, namely, when do we prefer explicit (manifest?) types and when
do we prefer implicit types. My own opinion is that I'd like a language
with both. Ada has only the first, and while modern high level languages
(think ML and Haskell here) provide both I'm a bit unsatisfied with the
way it all fits together (not to drift too far, but I'd like something
like Haskell's type classes and not just ML's universal style of
polymorphism, *and* I want a decent module system). I guess I'm not meant
to be happy with any programming language :-).

One of the things that annoys me about Ada is the fact that there is a lot
of nice notation that I, the programmer, can't change. It would be nice if
there were a more generalized notion of 'First and 'Last, since that's
what Ada programmers would like to use in an Ada "STL". If you just map
the STL concepts onto Ada directly, using, say, Incr, Decr, Pred, Succ
Get_Value, Set_Value, etc., instead of the C shorthand, Ada programmers
will still complain that the resulting library doesn't "look like" Ada.
Sorry, nothing can be done about that.

Just so I don't sound entirely negative, generic formal package
parameters, and the signature trick, really make something like the STL,
or Bishop's approach, a lot cleaner in Ada 95 than was possible in Ada 83.
It also makes the STL easier to understand, since you can express the
notion of "iterator category" (I think that's what Alex Stepanov called
it, I can't remember since it was a few years ago) pretty directly with
a few signatures (Forward_Iterator_Sig, Bidirectional_Iterator_Sig, etc.).

Sorry for rambling, I guess I'll ramble off now...

-- Brian

Re: Queue

[Ted Dennison]

In article <Pine.BSF.4.40.0111300447310.89131-100000@bpr.best.vwh.net>, Brian
Rogoff says...
>One of the things that annoys me about Ada is the fact that there is a lot
>of nice notation that I, the programmer, can't change. It would be nice if
>there were a more generalized notion of 'First and 'Last, since that's
>what Ada programmers would like to use in an Ada "STL". If you just map
>the STL concepts onto Ada directly, using, say, Incr, Decr, Pred, Succ
>Get_Value, Set_Value, etc., instead of the C shorthand, Ada programmers
>will still complain that the resulting library doesn't "look like" Ada.
>Sorry, nothing can be done about that.

I like that idea. Hopefully redefining of more attributes will make its way into
Ada 20XX. I'd add 'Image to the list.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Queue

[Ehud Lamm]

Ted Dennison <dennison@telepath.com> wrote in message
news:LCNN7.43879$xS6.73853@www.newsranger.com...

> I like that idea. Hopefully redefining of more attributes will make its
way into
> Ada 20XX. I'd add 'Image to the list.
>


I remember being so sure this must be possible, I spent tons of time trying
and looking in the RM for the way to overload (common) attributes. After
that I made rationalization about why this is not possible in most cases...

Ehud

Re: Queue

[Ehud Lamm]

Brian Rogoff <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0111300447310.89131-100000@bpr.best.vwh.net...
>
> The excessive instantiations that you need in an Ada version of the STL
> become ponderous IMO. I believe this is a fundamental problem with Ada
> generics, and perhaps even a fundamental issue in statically typed
> languages, namely, when do we prefer explicit (manifest?) types and when
> do we prefer implicit types. My own opinion is that I'd like a language
> with both. Ada has only the first, and while modern high level languages
> (think ML and Haskell here) provide both I'm a bit unsatisfied with the
> way it all fits together (not to drift too far, but I'd like something
> like Haskell's type classes and not just ML's universal style of
> polymorphism, *and* I want a decent module system). I guess I'm not meant
> to be happy with any programming language :-).
>

I am with you on this.
In a sense this is a language engineering issue. We want to safety brought
by explicit instanations etc., but we don't want to have to use it all the
time.
I am still not sure what's the best way of combining these features, but it
seems to me there shouldn't be a theoretical problem here, just a need for
smart language design.

> Just so I don't sound entirely negative, generic formal package
> parameters, and the signature trick, really make something like the STL,
> or Bishop's approach, a lot cleaner in Ada 95 than was possible in Ada 83.
> It also makes the STL easier to understand, since you can express the
> notion of "iterator category" (I think that's what Alex Stepanov called
> it, I can't remember since it was a few years ago) pretty directly with
> a few signatures (Forward_Iterator_Sig, Bidirectional_Iterator_Sig, etc.).
>

Signature packages are a very important concept, and add expressive power
that I like.
Indeed, formal packages were a great addition to the language. But they can
be improved upon (for example, I'd like to be able to elegantly require that
 two formal packages share some parameters, etc.)

Ehud

Re: Queue

[Thomas Wolf]

Brian Rogoff wrote:

> Interestingly enough, there was a proposal to do something like this
> (very much like the C++ STL) in Ada circa 1990. I mentioned it loooong
> ago, maybe in 1997 when there was some discussion of the STL here. I
> forget the author's name, but she was a prof at some South African
> university. What's interesting to me is that this was completely
> independent of the STL line of work. I can dig up the ref if anyone is
> interested.
> 
> Doing an STL like library in Ada is certainly possible, but it will never
> fit as snugly with Ada as the STL does with C++, for a number of reasons.

Don't know if this has already been mentioned or is generally known.
But...

The C++ STL started out as an Ada 83 generic library. Only in 1990 the
authors changed from Ada 83 to C++ as their implementation language.

There is an Ada 95 version of the STL called SGL done by Dave Musser and
Alexander Konstantinou available at the URL
<http://www.cs.rpi.edu/pub/stl/SGL-2.0a3.tar.gz>.

--
---------------------------------------------------------------------
Dr. Thomas Wolf                          e-mail: t_wolf@angelfire.com

Re: Queue

[Ted Dennison]

In article <Pine.BSF.4.10.10111272129470.93360-100000@bpr.best.vwh.net>, Brian
Rogoff says...
>
>Doing an STL like library in Ada is certainly possible, but it will never
>fit as snugly with Ada as the STL does with C++, for a number of reasons. 

I was actually hoping to end up with something like that. Not an Ada version of
the STL, but rather something on the STL's level of ease of use and power, but
fitting in "snugly" with Ada and its libraries. That's why I kept pointing back
to the STL as a point of comarison in the discussions.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Queue

[Ehud Lamm]

Ted Dennison <dennison@telepath.com> wrote in message
news:u89N7.40977$xS6.68933@www.newsranger.com...
> I was actually hoping to end up with something like that. Not an Ada
version of
> the STL, but rather something on the STL's level of ease of use and power,
but
> fitting in "snugly" with Ada and its libraries. That's why I kept pointing
back
> to the STL as a point of comarison in the discussions.
>

I think it is fair to ask whether Ada makes this goal too hard to achieve.
I think some things we came across (like the need of nested instnatiations,
when using an OO design; or the library level instnation needed if we want
to use Controlled) can't be solved nicely with Ada95. Maybe this can guide
some language changes.
In fact, the STL influenced the C++ design process too.

Ehud

Re: Queue

[Mats Karlssohn]

Matthew Heaney wrote:
> 
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:9u0qhb$pq5$1@nh.pace.co.uk...
> > I'd still be willing to settle on the BC's with some enhancements and
> > extensions. Anybody else willing to go that route?
> 
> No.  The problem with the Booch Components is that they use inheritance,
> which is completely unnecessary unless you require dynamic polymorphic
> behavior.

I have vorried about this and actually I think it is this property that I
like most (dislike least ? :-) about STL. I havn't actually had any
problems arising from BC's using inheritance during my (admittedly small)
use of them.

%<
> The standard library should provide only the most basic primitives, from
> which higher-level abstractions can be constructed.

Yes, AND much of the 'standard' higher-level stuff should probably be
availible in standard add-on pakages (at least after version 1.1).


-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Queue

[Mats Karlssohn]

Marin David Condic wrote:
%<
> I'd still be willing to settle on the BC's with some enhancements and
> extensions. Anybody else willing to go that route?

Yes, I'd be willing to support the BC's. They DO exist and they have
worked quite fine in the projects where I have used them. Although
I have to admit that I have not made any esoteric use of them. I also
find them somewhat bulky, but I can't say that I've made any real
measurements on neither code size nor execution time, so that may
just be my imagination.

What enhancements (spl ?) are we talking about ?

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: Queue

[Marin David Condic]

The weaknesses of the BC's have been discussed in other threads here quite a
bit. My personal favorite is that they don't have persistence & would need
some version of 'Read and 'Write implemented for them so that structures
could be loaded/stored from/to files/streams. The other objections seem to
center around the excessive complexity of the BC's making them too hard to
use for more simple situations. No real fix for that except to add on some
extension to the library that provides for the more simple cases in a manner
that wouldn't be at all in keeping with the flavor of the BC's. Hence, there
is resistance to the idea of using the BC's as the basis and possibly more
support for the idea of building a library from the ground up.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Mats Karlssohn" <mats@mida.se> wrote in message
news:3C0496B9.813D5667@mida.se...
>
> What enhancements (spl ?) are we talking about ?
>

Re: Queue

[Mats Karlssohn]

Marin David Condic wrote:
> 
> The weaknesses of the BC's have been discussed in other threads here quite a
> bit. My personal favorite is that they don't have persistence & would need
> some version of 'Read and 'Write implemented for them so that structures
> could be loaded/stored from/to files/streams. The other objections seem to
> center around the excessive complexity of the BC's making them too hard to
> use for more simple situations. No real fix for that except to add on some
> extension to the library that provides for the more simple cases in a manner
> that wouldn't be at all in keeping with the flavor of the BC's. Hence, there
> is resistance to the idea of using the BC's as the basis and possibly more
> support for the idea of building a library from the ground up.

OK, I'm back on track...
The persistance/streams stuff havn't really been a concern of mine, so
I will not comment on that.
As for the instansiation complexity, Yes, it can be complex, but
somehow I've always managed. I guess that it took an hour or so the
first time with a lot of digging around in the source. But once one
get the feel for it the biggest problem is IMHO to com up with
sensible names for the 'intermediate' packages/types. Sometimes I
really whish that Ada would provide anonymous types.

*smacks my fingers with the ruler and tell myself to stop ranting*

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809