STL.NET news

  • Thread starter Thread starter Andrew Roberts
  • Start date Start date
Andrew Roberts said:
Any more info on this? Anyone know when it will be released?
Click to expand...

Stay tuned - there is some news, but we're waiting for feedback from the
VC++ team as to what can be said publicly.

-cd
 
Andrew Roberts said:
Any more info on this? Anyone know when it will be released?
Click to expand...


Looks to me like it's dead in the water. No hint of a release date. The
dreadful version accidently included in beta 2 pointed to some serious
issues. Tis a pity because C++ is next to useless without it's standard
library.



-Liam
 
|
| | > Any more info on this? Anyone know when it will be released?
| >
|
|
| Looks to me like it's dead in the water. No hint of a release date. The
| dreadful version accidently included in beta 2 pointed to some serious
| issues. Tis a pity because C++ is next to useless without it's standard
| library.
|
|

This has nothing to do with STL and C++, it's about STL/CLR and C++/CLI.

Willy.
 
Willy Denoyette said:
|
| | > Any more info on this? Anyone know when it will be released?
| >
|
|
| Looks to me like it's dead in the water. No hint of a release date. The
| dreadful version accidently included in beta 2 pointed to some serious
| issues. Tis a pity because C++ is next to useless without it's standard
| library.
|
|

This has nothing to do with STL and C++, it's about STL/CLR and C++/CLI.

Willy.
Click to expand...

Sorry Willy I'll rephase. Tis a pity because because C++/CLI is next to
useless without the ability to use managed types with the standard library.

-Liam
 
|
| | >
| > | > |
| > | | > | > Any more info on this? Anyone know when it will be released?
| > | >
| > |
| > |
| > | Looks to me like it's dead in the water. No hint of a release date.
The
| > | dreadful version accidently included in beta 2 pointed to some serious
| > | issues. Tis a pity because C++ is next to useless without it's
standard
| > | library.
| > |
| > |
| >
| > This has nothing to do with STL and C++, it's about STL/CLR and C++/CLI.
| >
| > Willy.
| >
| >
| >
|
| Sorry Willy I'll rephase. Tis a pity because because C++/CLI is next to
| useless without the ability to use managed types with the standard
library.
|
| -Liam
|
|

Why? they are just wrappers around the managed containers available in the
framework. IMO they offer little added value.

Willy.
 
|
| Sorry Willy I'll rephase. Tis a pity because because C++/CLI is next to
| useless without the ability to use managed types with the standard
library.
|
| -Liam
|
|

Why? they are just wrappers around the managed containers available in the
framework. IMO they offer little added value.

Willy.
Click to expand...


Oh I don't know. Just say you're a C++ programmer. Which means you make
extensive use of the standard library. Say you'd like use a fairly standard
container, probably the most common after vector - the set. Yeah, say you'd
like to have a set of strings. Is there a set in the
System.Collections.Generic namespace? Nope.

-Liam
 
Willy said:
Why? they are just wrappers around the managed containers available
in the framework. IMO they offer little added value.
Click to expand...

No, they're not. The STL/CLR containers are managed implementations of the
STL containers and are not wrappers over List<T> or any other framework
class. They do support many of the framework interfaces (IEnumerable<T>,
etc) to make interoperation easier, but they're definitely not wrappers.

The reason why they're desirable is for use with the rest of the C++
standard library. In my own work, I particularly miss having well defined
complexity guarantees (that STL provides, but the BCL is very sketchy
about), and the ability to mix and match algorithms and containers. After
using STL containers and algorithms, the BCL classes are a like taking a 10
year step backwards - they're representative of state of the art C++
practice in the early to mid 90's.

Even something as simple as upper_bound/lower_bound is missing from the BCL
classes. Yes, List<T> does provide BinarySearch, but it's a wierd
implementation that usually requires some tweaking of the return value
before use (e.g. binary complement, test/increment, test/decrement). If
they'd simply provided lower_bound and upper_bound it'd be much easier to
use.

-cd
 
| |
| > | Sorry Willy I'll rephase. Tis a pity because because C++/CLI is next
to
| > | useless without the ability to use managed types with the standard
| > library.
| > |
| > | -Liam
| > |
| > |
| >
| > Why? they are just wrappers around the managed containers available in
the
| > framework. IMO they offer little added value.
| >
| > Willy.
| >
|
|
| Oh I don't know. Just say you're a C++ programmer. Which means you make
| extensive use of the standard library. Say you'd like use a fairly
standard
| container, probably the most common after vector - the set. Yeah, say
you'd
| like to have a set of strings. Is there a set in the
| System.Collections.Generic namespace? Nope.
|
| -Liam
|
|

That's right, they are not (yet) in the BCL, just like STL/CLR is not yet
part of .NET either, but that doesn't mean there are no implementations
available. Take a look at :

http://www.wintellect.com/powercollections

or (better) http://www.itu.dk/research/c5/

my guess is that we will see some of this added to the BCL in the Orcas time
frame.

Willy.
 
That's right, they are not (yet) in the BCL, just like STL/CLR is not yet
part of .NET either, but that doesn't mean there are no implementations
available. Take a look at :

http://www.wintellect.com/powercollections

or (better) http://www.itu.dk/research/c5/

my guess is that we will see some of this added to the BCL in the Orcas
time
frame.

Willy.
Click to expand...

Yep, I've been using these for co# only work. They're fine for what they
are - basic collection classes. The standard library is however much more
powerful - the powercollections ordered set type has to implement it's own
set difference, set intersection logic! The standard library with its
algorithm/container split is much adaptable, and expandable. Still, they're
a richer set of containers than the current somewhat limited BCL offerings.

The problem remains that

1. The fast majority (all?) of C++ developers use the standard library. It
is the standard after all.

2. Managed types are basically incompatible with the standard library.
(alright there's the gcroot gludge, and workarounds, but that's what they
are cludge and workarounds)

-Liam
 
|
| > That's right, they are not (yet) in the BCL, just like STL/CLR is not
yet
| > part of .NET either, but that doesn't mean there are no implementations
| > available. Take a look at :
| >
| > http://www.wintellect.com/powercollections
| >
| > or (better) http://www.itu.dk/research/c5/
| >
| > my guess is that we will see some of this added to the BCL in the Orcas
| > time
| > frame.
| >
| > Willy.
| >
| >
|
| Yep, I've been using these for co# only work. They're fine for what they
| are - basic collection classes. The standard library is however much more
| powerful - the powercollections ordered set type has to implement it's own
| set difference, set intersection logic! The standard library with its
| algorithm/container split is much adaptable, and expandable. Still,
they're
| a richer set of containers than the current somewhat limited BCL
offerings.
|

No one said they where an implementation of the STL, the C5 'Set'
collections offer functions not available in STL, that's why I said the
second offering (C5) is more powerfull, so what? They aren't designed to
mimic STL. Anyway, they are cross-language, they are available now, while
STL/CLR is not.


| The problem remains that
|
| 1. The fast majority (all?) of C++ developers use the standard library. It
| is the standard after all.
|

And how many (of the vast majority) will never embrace C++/CLI? Do you think
they will do when STL/CLR becomes available?


| 2. Managed types are basically incompatible with the standard library.
| (alright there's the gcroot gludge, and workarounds, but that's what they
| are cludge and workarounds)
|

Not sure what you mean here, why do you compare "managed types (or CLI types
to be exact) to a library like the STL?

Willy.
 
And how many (of the vast majority) will never embrace C++/CLI? Do you
think
they will do when STL/CLR becomes available?
Click to expand...


Well, presumably Microsoft's goal is to get the vast majority of C++
programmers on the PC compiling to C++/CLI at some stage.


| 2. Managed types are basically incompatible with the standard library.
| (alright there's the gcroot gludge, and workarounds, but that's what
they
| are cludge and workarounds)
|

Not sure what you mean here, why do you compare "managed types (or CLI
types
to be exact) to a library like the STL?
Click to expand...


I'm not comparing managed types with the STL. I'm saying managed types are
incompatible with the standard library. The STL is the largest part of the
standard library, therefore managed types are incompatible with the standard
library. From your previous posts I presume you are not a C++ programmer as
your exposure to the standard library appears to be somewhat limited,
however, one example of this incompatibility is the inability to use managed
types in the standard containers.



-Liam
 
IMO they don't care, C++ ISO, C++/CLI, C#, VB.NET you name it, as long as
they use one of their products.

Willy.

| >
| > And how many (of the vast majority) will never embrace C++/CLI? Do you
| > think
| > they will do when STL/CLR becomes available?
| >
|
|
| Well, presumably Microsoft's goal is to get the vast majority of C++
| programmers on the PC compiling to C++/CLI at some stage.
|
|
|
| >
| > | 2. Managed types are basically incompatible with the standard library.
| > | (alright there's the gcroot gludge, and workarounds, but that's what
| > they
| > | are cludge and workarounds)
| > |
| >
| > Not sure what you mean here, why do you compare "managed types (or CLI
| > types
| > to be exact) to a library like the STL?
| >
|
|
| I'm not comparing managed types with the STL. I'm saying managed types are
| incompatible with the standard library. The STL is the largest part of the
| standard library, therefore managed types are incompatible with the
standard
| library. From your previous posts I presume you are not a C++ programmer
as
| your exposure to the standard library appears to be somewhat limited,
| however, one example of this incompatibility is the inability to use
managed
| types in the standard containers.
|
|
|
| -Liam
|
|
 
Willy,

I can understand where you are coming from but I think you don't appreciate
the importance of this because you don't understand the STL (once you've
looked at that take a good look at Boost too). Any C++ programmer who keeps
their skills reasonably up to date will have come to rely on the STL to some
extent (the same as any .NET developer relies on the BCL, imagine if a new
..NET language was created but you only got half the BCL...).

There are a large number of highly talented C++ developers out there who are
not using C++ for their .NET development, or maybe not doing .NET
development at all, because they do not have access to their full set of
standard libraries. The point is there is no equivilant of the STL in the
BCL, the Collections.Generic namespace provides a very basic set of classes,
a very small subset of what the STL does.

Last but not least this is a very very hard problem to solve, largely due to
type identity issues, and consequently the STL/CLR was almost dropped. The
reason this decision has been reversed is due to the huge demand for it from
the community, so even though its a serious piece of engineering on
Microsofts part to achieve it is being done (as much as can be implemented).
Now if that doesn't contradict your statement that developers don't care
about it I don't know what does.

Andrew
 
Andrew said:
Last but not least this is a very very hard problem to solve, largely due to
type identity issues, and consequently the STL/CLR was almost dropped.
Click to expand...

Can you explain what these issues were? Can you not just port the STL
code in a simple minded way, adding ^ etc. as required (bearing in mind
I don't know much about C++/CLI)?

Tom
 
Andrew,

See inline.

Willy.

| Willy,
|
| I can understand where you are coming from but I think you don't
appreciate
| the importance of this because you don't understand the STL (once you've
| looked at that take a good look at Boost too). Any C++ programmer who
keeps
| their skills reasonably up to date will have come to rely on the STL to
some
| extent (the same as any .NET developer relies on the BCL, imagine if a new
| .NET language was created but you only got half the BCL...).
|

I don't think you know where I'm comming from, so let me explain first, I
started back in '78 (until I left the dev. busines a few years ago) to use
C/C++ as my primary language, my main task over the years was
designing/writing/porting low level stuff at DEC for VAX VMS/OVMS,
Ultrix/Unix & NT4/W2K on Alpha AXP in ASM, C and later C++, later I've done
some application level development, and I learned to use and apriciate the
STL (and other template based libraries), I'm not an expert, but I know
quite well what the STL means to the C++ community, now they have a
conformant STL in VC8 so what's the problem?
C++/CLI is a .NET language, and, as you said above, the key class library
for all .NET languages to rely upon is the Framework Class Library. Now, the
FCL is certainly lacking some features, and it's good to see some third
parties releasing rich container classes libraries, but that's not good
enough, what we need is some basic stuff added to the FCL. But, does that
mean that C++/CLI languages becomes "next to useless without" a "managed"
version of the STL (as was said by rellik)? I don't think so.
Now, when we look at the STL/CLR, AFAIK this is gonna be a C++/CLI only
library, it's a template library, not an MSIL library. This may be great to
have for the C++ community (at least for those who are willing to embrace
C++/CLI), but it lacks cross-(.NET)language support, that means it can't be
used (directly) from the other languages, so IMO it's not a first class
citizen in .NET

| There are a large number of highly talented C++ developers out there who
are
| not using C++ for their .NET development, or maybe not doing .NET
| development at all, because they do not have access to their full set of
| standard libraries.


I know a number of C++ devs. some don't need .NET at all, because their
problem domains don't need it (device driver & high perf. stuff).
But there are others, who aren't willing to touch .NET at all, believe me,
not because they are missing their favorite libraries. One of my jobs of the
last two years was trying to make them change their minds, quite a tough
job, but we are moving forward.

The point is there is no equivilant of the STL in the
| BCL, the Collections.Generic namespace provides a very basic set of
classes,
| a very small subset of what the STL does.
|
| Last but not least this is a very very hard problem to solve, largely due
to
| type identity issues, and consequently the STL/CLR was almost dropped.
The
| reason this decision has been reversed is due to the huge demand for it
from
| the community, so even though its a serious piece of engineering on
| Microsofts part to achieve it is being done (as much as can be
implemented).
| Now if that doesn't contradict your statement that developers don't care
| about it I don't know what does.
|
Sorry, You must have mis-understood my statement, what I meant to say was
"Microsoft doesn't care whether the vast majority of the C++ developers
embraced C++/CLI" as long as they use one of their products...
I can't comment on the rest of this paragraph, you seem to have other
information than I have.

Willy.

| Andrew
|
|
| | > IMO they don't care, C++ ISO, C++/CLI, C#, VB.NET you name it, as long
as
| > they use one of their products.
| >
| > Willy.
| >
| > | > | >
| > | > And how many (of the vast majority) will never embrace C++/CLI? Do
you
| > | > think
| > | > they will do when STL/CLR becomes available?
| > | >
| > |
| > |
| > | Well, presumably Microsoft's goal is to get the vast majority of C++
| > | programmers on the PC compiling to C++/CLI at some stage.
| > |
| > |
| > |
| > | >
| > | > | 2. Managed types are basically incompatible with the standard
| > library.
| > | > | (alright there's the gcroot gludge, and workarounds, but that's
what
| > | > they
| > | > | are cludge and workarounds)
| > | > |
| > | >
| > | > Not sure what you mean here, why do you compare "managed types (or
CLI
| > | > types
| > | > to be exact) to a library like the STL?
| > | >
| > |
| > |
| > | I'm not comparing managed types with the STL. I'm saying managed types
| > are
| > | incompatible with the standard library. The STL is the largest part of
| > the
| > | standard library, therefore managed types are incompatible with the
| > standard
| > | library. From your previous posts I presume you are not a C++
programmer
| > as
| > | your exposure to the standard library appears to be somewhat limited,
| > | however, one example of this incompatibility is the inability to use
| > managed
| > | types in the standard containers.
| > |
| > |
| > |
| > | -Liam
| > |
| > |
| >
| >
|
|
 
Regarding the type identity problem it is something like the following.

Assembly A you have a class with a method

template <typename T>
public ref class SomeTemplate
{
public:
void DoSomething() { }
};

public ref class GiveMeSomething
{
public:
SomeTemplate<System::String> ^GetSomething(); // I've chosen
System::String for no particular reason
};

Now in assembly B you do the following to call it

GiveMeSomething ^giveme = gcnew GiveMeSomething();
SomeTemplate<System::String> ^something = giveme->GetSomething();
something->DoSomething();


BUT this won't compile because SomeTemplate<System::String> is compiled into
each assembly and therefore are different types. They are generated at
compile time, not at runtime like generics.

The way around it is to provide an equivilant interface using generics and
expose that instead.

public interface class ISomeTemplate<T>
{
void DoSomething();
};

template <typename T>
public ref class SomeTemplate : ISomeTemplate<T>
{
public:
void DoSomething() { }
};

public ref class GiveMeSomething
{
public:
ISomeTemplate<System::String> ^GetSomething(); // return the generic
interface
};

This is all well and good but because of the limitations of generics it
limits what you can expose across assembly boundaries.
 
Andrew said:
Regarding the type identity problem it is something like the following.

Assembly A you have a class with a method

template <typename T>
public ref class SomeTemplate
{
public:
void DoSomething() { }
};

public ref class GiveMeSomething
{
public:
SomeTemplate<System::String> ^GetSomething(); // I've chosen
System::String for no particular reason
};

Now in assembly B you do the following to call it

GiveMeSomething ^giveme = gcnew GiveMeSomething();
SomeTemplate<System::String> ^something = giveme->GetSomething();
something->DoSomething();


BUT this won't compile because SomeTemplate<System::String> is compiled into
each assembly and therefore are different types. They are generated at
compile time, not at runtime like generics.
Click to expand...

Could another way around it not be to have the
SomeTemplate<System::String> be the same type in each assembly? You'd
just need a well defined name mangling scheme, wouldn't you?

Tom
 
Back
Top