Export and STL

[Mybowlcut]

Hi. Not sure whether this belongs in general developer topics or here but...

In the future, when compilers support the "export" keyword, it will be possible to use only the template's declaration and leave the definition in a separate source file.

I was just wondering if this means that - upon export being "supported by compilers" - whoever manages the Standard Template Library will move template class definitions to .cpp files? I assume that no one who lurks CodeGuru's forums is an STL author, so opinions on this are what I'm looking for.

Cheers.

[laserlight]

I was just wondering if this means that - upon export being "supported by compilers" - whoever manages the Standard Template Library will move template class definitions to .cpp files?

The "Standard Template Library" has been integrated into the C++ standard library. Consequently, no one manages the Standard Template Library, but the C++ standard committee manages the specification of the C++ standard library including the parts that came from the original STL, and the various compiler vendors (and outfits like STLport) maintain their own implementations of the C++ standard library.

What this tip refers to is for your own use, independent of any C++ standard library implementation: when compilers support the export keyword (and from what I understand only one of them has such support), we will be able "to use only the template's declaration and leave the definition in a separate source file".

[Mybowlcut]

What this tip refers to is for your own use, independent of any C++ standard library implementation: when compilers support the export keyword (and from what I understand only one of them has such support), we will be able "to use only the template's declaration and leave the definition in a separate source file".

Hi laserlight.

I don't quite understand your answer. Who is we? I know that if your compiler has support for it, you can do it. What I was asking was, when more compilers support export, do you think all or at least some of the STL template classes will be moved to .cpp files?

[laserlight]

Who is we? I know that if your compiler has support for it, you can do it.

We as in you, me, and the rest of the C++ programmers alive.

What I was asking was, when more compilers support export, do you think all or at least some of the STL template classes will be moved to .cpp files?

The C++ Standard merely specifies the standard headers and what they should contain. The implementation details of the standard library is left to the implementor. So, if a compiler vendor implements a compiler that supports export, that vendor can very well provide a standard library implementation where the code that implements various templates is moved to .cpp source files.

[Mybowlcut]

Ahhh... what you were saying about the compiler vendors is starting to make more sense now. Does that mean that each compiler vendor has to implement their own STL? What about visual studio's default compiler? MSVC or ming32 or whatever?

[Paul McKenzie]

Ahhh... what you were saying about the compiler vendors is starting to make more sense now. Does that mean that each compiler vendor has to implement their own STL? What about visual studio's default compiler?

Two men by the names of P.J. Plauger and Pete Becker have developed the STL implementation for the Visual C++ compilers. They work for DinkumWare (www.dinkumware.com).

For other compilers, there is the STLPort implementation (www.stlport.org) used by the Borland (now Inprise) compilers. I believe that g++ maintains their own version, Sun compilers have their own, etc.

What matters is not what the internals of the STL are. What matters is whether the library

1) Has the same public interface as described by the ANSI standard, and

2) If the library behaves the same way when given data to work with (in other words, vector::at() throws an exception on an out-of-bounds index, push_back() actually adds an item to the back of a vector, list, or deque, etc.) and

3) The operations perform algorithmically in the within the timing constraints as specified by the standard. In other words, std::find() should be linear time complexity, not quadratic, std::sort() should perform in logarithmic time (i.e. you can't implement std::sort using a bubble sort), etc.

Regards,

Paul McKenzie

[Mybowlcut]

Two men by the names of P.J. Plauger and Pete Becker have developed the STL implementation for the Visual C++ compilers. They work for DinkumWare (www.dinkumware.com).

For other compilers, there is the STLPort implementation (www.stlport.org) used by the Borland (now Inprise) compilers. I believe that g++ maintains their own version, Sun compilers have their own, etc.

What matters is not what the internals of the STL are. What matters is whether the library

1) Has the same public interface as described by the ANSI standard, and

2) If the library behaves the same way when given data to work with (in other words, vector::at() throws an exception on an out-of-bounds index, push_back() actually adds an item to the back of a vector, list, or deque, etc.) and

3) The operations perform algorithmically in the within the timing constraints as specified by the standard. In other words, std::find() should be linear time complexity, not quadratic, std::sort() should perform in logarithmic time (i.e. you can't implement std::sort using a bubble sort), etc.

Regards,

Paul McKenzie

I never knew all this stuff. It's so strange... it'd make sense to have one STL written, but one for each compiler?

My question still remains , however, in a slightly different form in light of what you two have told me:

Do you guys think that when Visual Studio's (default) compiler supports export, the authors maintaining that STL implementation will separate the template classes into .h and .cpp files? As in, what do you think? Are there reasons why they might keep the implementation open to the public? Are there reasons why they'd want to hide it?

Cheers.

[laserlight]

Are there reasons why they might keep the implementation open to the public?

One possibility is that members of the public who already have copies of their implementation would already have access to the implementation internals.

Are there reasons why they'd want to hide it?

The same reason people rather not distribute sources: to try and keep their implementation from prying eyes.

[Mybowlcut]

One possibility is that members of the public who already have copies of their implementation would already have access to the implementation internals.


The same reason people rather not distribute sources: to try and keep their implementation from prying eyes.

That's exactly what I was thinking. So what do you think they'll do? Haha. I'm getting the impression that no one has an opinion on this?

[laserlight]

So what do you think they'll do? Haha. I'm getting the impression that no one has an opinion on this?

You are not offering a tangible reward for being correct, so I see no reason to make a pointless guess and risk being wrong

[Paul McKenzie]

That's exactly what I was thinking. So what do you think they'll do? Haha. I'm getting the impression that no one has an opinion on this?

I think it would be a disadvantage to close the source code. These libraries are highly sophisticated, but invariably bugs can occur. C++ is a complex language, and the authors are dealing with C++ at a very low level.

Many times, the authors of these libraries are only alerted to a bug when one of the many thousands of programmers using their STL implementation carefully goes through the source and confirm that a bug exists. This allows faster updates and fixes. Since it is imperitive that the STL implementation is essentially flawless, it just makes sense IMO to keep the source open, or at least available if you buy an STL implementation (i.e. DinkumWare).

Regards,

Paul McKenzie

[laserlight]

Many times, the authors of these libraries are only alerted to a bug when one of the many thousands of programmers using their STL implementation carefully goes through the source and confirm that a bug exists.

I do wonder if they actually get good feedback. dude_1967 discovered that their implementation of std::complex as included with Visual C++ 2005 differed from other popular compilers. I checked the C++ standard, and it turned out that their implementation was incorrect and easily fixed (even if export was used, if I understand it correctly). Yet this was not fixed in Visual C++ 2008, implying that either no one discovered the mistake, or it was simply not reported, or was reported and yet no action was taken despite the minimal fix needed. I would like to think that the last possibility was not the case.

[Paul McKenzie]

I do wonder if they actually get good feedback. dude_1967 discovered that their implementation of std::complex as included with Visual C++ 2005 differed from other popular compilers. I checked the C++ standard, and it turned out that their implementation was incorrect and easily fixed

There is a bug reporting site for Visual C++:

https://connect.microsoft.com/VisualStudio/Feedback

I've never submitted a bug, so I don't know how difficult or easy it is to submit one

Regards,

Paul McKenzie

[Mybowlcut]

You are not offering a tangible reward for being correct, so I see no reason to make a pointless guess and risk being wrong

Perhaps I'll email you a delicious pavlova? Haha.

I think it would be a disadvantage to close the source code. These libraries are highly sophisticated, but invariably bugs can occur. C++ is a complex language, and the authors are dealing with C++ at a very low level.

Many times, the authors of these libraries are only alerted to a bug when one of the many thousands of programmers using their STL implementation carefully goes through the source and confirm that a bug exists. This allows faster updates and fixes. Since it is imperitive that the STL implementation is essentially flawless, it just makes sense IMO to keep the source open, or at least available if you buy an STL implementation (i.e. DinkumWare).

A - hah! That's what I was after! Haha. I never thought about it like that. I guess that's why libraries like Boost are so popular because they're peer reviewed.

[laserlight]

A - hah! That's what I was after! Haha. I never thought about it like that. I guess that's why libraries like Boost are so popular because they're peer reviewed.

You're looking at one of the arguments for open source software, though in this case it is more like the source is merely available for those who have bought (or for the Express editions, downloaded) the IDE.