USL v.s. STL

S

Steve

Hi,

We have software built on USL and are migrating to IBM VisualAge STL.
Can someone tell me the major difference between the two? Is the "Block" in
USL the same as "vector" in STL?

Thanks,
Steve
 
M

Mike Wahler

Steve said:
Hi,

We have software built on USL and are migrating to IBM VisualAge STL.
Can someone tell me the major difference between the two? Is the "Block" in
USL the same as "vector" in STL?

The difference is that 'USL' is not part of standard C++
and 'STL' is a (informal) term used to refer to the
contanier/iterator/algorithm parts of the C++ standard
library. 'STL' issues are topical here, 'USL' issues are
not.

-Mike
P.S. To me, the acronym 'USL' only means "University
of Southwest Louisiana" at Lafayette (although the
school has since been renamed). :)
 
J

Julie

Mike said:
The difference is that 'USL' is not part of standard C++
and 'STL' is a (informal) term used to refer to the
contanier/iterator/algorithm parts of the C++ standard
library. 'STL' issues are topical here, 'USL' issues are
not.

Questions about a comparison between STL and some other similar library _are_
appropriate.
 
M

Mike Wahler

Julie said:
Questions about a comparison between STL and some other similar library _are_
appropriate.

I disagree. Anyone participating here is assumed to know
or ask about C++, of which what is informally called 'STL' is a
part. No other assumptions can be made about any third-party
libraries or tools, etc. E.g. I have no idea what OP meant by
'USL'. To some, it might mean one thing, to others some other
thing(s). I've already cited the only meaning 'USL' has to me,
and it's certainly not C++-oriented.

IMO this is a good example of why restricting topicality of a
discussion forum is a Good Thing(tm).

-Mike
 
B

Bob Bell

Hi,

We have software built on USL and are migrating to IBM VisualAge STL.
Can someone tell me the major difference between the two? Is the "Block" in
USL the same as "vector" in STL?

Thanks,
Steve

What the heck is USL?
 
S

Steve

Julie said:
Questions about a comparison between STL and some other similar library _are_
appropriate.

USL has Set_of_p, Set_of_piter, List_of_p, List_of_piter. Does anyone
know if STL has those classes too?
 
J

John Harrison

Questions about a comparison between STL and some other similar library
_are_
USL has Set_of_p, Set_of_piter, List_of_p, List_of_piter. Does anyone
know if STL has those classes too?

I think its clear that no-one here knows what USL is, perhaps you could
provide a reference.

However STL has set and list classes plus iterators for those classes. How
close they are to what you are familiar with in USL I have no idea.

john
 
C

Claudio Puviani

Steve said:
USL has Set_of_p, Set_of_piter, List_of_p, List_of_piter.
Does anyone know if STL has those classes too?

The Standard Library has std::set<> and std::list<> which are more generalized
than USL's Setxxx and Listxxx. They're also more efficient because they can store
the target objects in-place. The iterators are classes inside their respective
container namespaces, such as std::set<>::iterator.

For those who don't know USL, you can find some docs at:
http://www.desy.de/user/projects/C++/products/usl.html.

Anyone who has used USL (I only had to port programs away from it, thank
goodness) will have all the more reason to be grateful for the C++ Standard
Library.

And I definitely think that USL is about as topical as Rogue Wave Tools.h++ or
the old Borland container hierarchy.

Claudio Puviani
 
F

Frederic Banaszak

What the heck is USL?

United Soccer Leagues
Ultra Stereo Labs, Inc.
United Skirmish League
United Security Life Insurance Co.
Unix System Laboratories
University of Southwestern Louisiana (now known as the University of
Louisiana at Lafayette)
 
S

Steve

Claudio Puviani said:
The Standard Library has std::set<> and std::list<> which are more generalized
than USL's Setxxx and Listxxx. They're also more efficient because they can store
the target objects in-place. The iterators are classes inside their respective
container namespaces, such as std::set<>::iterator.

For those who don't know USL, you can find some docs at:
http://www.desy.de/user/projects/C++/products/usl.html.

Anyone who has used USL (I only had to port programs away from it, thank
goodness) will have all the more reason to be grateful for the C++ Standard
Library.

And I definitely think that USL is about as topical as Rogue Wave Tools.h++ or
the old Borland container hierarchy.

Claudio Puviani

Claudio,
Thanks for clarification. I am also porting programs away from USL.
In USL, Set_of_p<> has member functions: contains(), select(), next().
There are no exactly same functions in std::set<>. I need to provide
wraper functions for those. Am I right?
 
D

David

Hi,

We have software built on USL and are migrating to IBM VisualAge STL.
Can someone tell me the major difference between the two? Is the "Block" in
USL the same as "vector" in STL?

Thanks,
Steve

<Ears perked up>

Did I hear you mention IBM VisualAge? Its nice to hear someone else
has used some of their stuff. I had to read the posts on USL to find out
what it was.

David
-- still using IBM VisualAge C++ and other VA tools --
 
C

Claudio Puviani

Steve said:
Claudio,
Thanks for clarification. I am also porting programs away from USL.
In USL, Set_of_p<> has member functions: contains(), select(), next().
There are no exactly same functions in std::set<>.

The functions won't be named the same or work exactly in the same way, but you do
have the same functionality.
'count()' and 'find()' will do the work of 'contains()' and 'select()', while
operator++ will do the work of 'next()'.
I need to provide wraper functions for those. Am I right?

I certainly wouldn't wrap them. I'd much rather modify the code in such a way
that it uses the Standard Library in a way that's natural for the container in
question. It might hurt up front, but the effort will pay for itself in the long
run.

Claudio Puviani
 
S

Steve

Claudio Puviani said:
The functions won't be named the same or work exactly in the same way, but you do
have the same functionality.
'count()' and 'find()' will do the work of 'contains()' and 'select()', while
operator++ will do the work of 'next()'.


I certainly wouldn't wrap them. I'd much rather modify the code in such a way
that it uses the Standard Library in a way that's natural for the container in
question. It might hurt up front, but the effort will pay for itself in the long
run.

Claudio Puviani

The code used USL List operator[]. It does not seem easily to get away
from it. Is there a way to use STL list performing operator[] without
writing operator[] for STL list?
 
C

Claudio Puviani

Steve said:
The code used USL List operator[]. It does not seem easily to
get away from it. Is there a way to use STL list performing
operator[] without writing operator[] for STL list?

If you need direct/random access, simply use an std::vector instead of and
std::list. Indexing into a list is abominably inefficient and the C++ standard
library reflects that fact by not giving you a shortcut to do it. The performance
gain you'll likely get by switching to a vector, by itself, will probably justify
your move to the standard containers. :)

Claudio Puviani
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,169
Messages
2,570,919
Members
47,460
Latest member
eibafima

Latest Threads

Top