STL-compatible iterator for csArray<>

[res]

The attached patch adds an STL-compatible iterator for csArray<>. This enables certain STL functionality to be used with it.

[sunshine]

This patch adds an STL dependency to all of CS. Unless I am mistaken, we are still trying to keep CS STL-free (except in special cases, such as AWS2, where its use is highly localized and does not pollute client code).

A slight improvement would be to protect this inside an #ifdef, but that has the problem of making the csutil/array.h include polymorphic. Much better would be to extract this STL iterator out to its own header file which clients can #include on-demand when they need STL iterator functionality.

(The new header also will need to be filtered out of the "master headers" just like the other specialized headers which have external dependencies. Finally, it will be the client's responsibility to add an 'ExternalLibs foo : STL ;' invocation in Jam and an STL check to their local configure. We might want to extract CS's STL configure check into a separate .m4 file so that it is reusable.)

[res]

Replying to sunshine:

This patch adds an STL dependency to all of CS. Unless I am mistaken, we are still trying to keep CS STL-free (except in special cases, such as AWS2, where its use is highly localized and does not pollute client code).

Hmm... what was the original reason for that?

STL has some useful parts, and notable client code is probably more likely to use STL (relatively well-known) than perhaps CS' containers (only known when using CS). Carefully adding STL support here and there may make it easier for ST-using clients to interface between CS' own helper classes and the STL classes they support; in CS itself it opens the opportunity to utilize some STL features (e.g. algorithm header).

[sunshine]

Replying to res:

Hmm... what was the original reason for that?

Historically, the complaints against STL have been (1) dramatic increase in compilation time, (2) severe bloat of object files/executables, (3) poor run-time performance in certain areas, (4) lack of availability or uniformity of STL implementations in the "old days".

Most likely, #3 is not so much of an issue these days, and #4 is probably of no concern any longer.

STL has some useful parts, and notable client code is probably more likely to use STL (relatively well-known) than perhaps CS' containers (only known when using CS).

Personally, I like the idea of standardized, generalized utilities in favor of the highly custom and sometimes special-purpose utilities in CS. I wouldn't mind seeing the custom CS utilities deprecated and ultimately retired in favor of the standardized ones. However, historically, there has been a significant amount of bias among developers against STL, exceptions, RTTI, etc.

Carefully adding STL support here and there may make it easier for ST-using clients to interface between CS' own helper classes and the STL classes they support; in CS itself it opens the opportunity to utilize some STL features (e.g. algorithm header).

Agreed. Still, this can be done in the way suggested above where these "helpers" are place in headers kept distinct from the "standard" CS headers to avoid global pollution. We can even have an STL "master header" which pulls in all of these STL helper headers.

[genjix]

What about boost? Things like the regex implementation and such are unnecessary when boost provides these things and much more.

[Oktal]

It is possible to implement an STL-compatible iterator (a class which can be used anywhere where an STL iterator is expected) without linking with STL or #include'ing STL headers.

The only STL symbol used in this patch is std::random_access_iterator_tag, and AFAIK it should be okay to forward-declare it, as it's only used in a typedef. Then any application developer who wants to, can link with STL, #include <iterator> and use the csArray iterator in STL functions.

[genjix]

STL isn't any slower than cs utility types I don't think, and nearly every platform now has it.