Maybe something to consider.

[revelator]

OrangeC from ladsoft, uses clangs libc++.

If the compiler can at all handle C++11 ? it might be a good standard library to consider.
Also i think he might be able to give you some pointers on how to modify the build chain so that it works with watcom. DOS compiling also works with it so it would be ideal since its a complete standard library that handles c++89 to c++17.

Offcourse this means dropping watcoms stl, so it might be a sour note for the developer who maintained that.

[bmanga]

Unfortunately it doesn't support any standard at the moment. C++11 support is essentially non-existent.

[revelator]

Sorry for the late reply, kidney stones got me again...

What would it take to get support in ?, obviously the runtime libraries need an interface and the C++ compiler needs to have options added for supporting the various standards.

Would there be any other pitfalls besides the watcom specific calls that we need to consider ?.

[jmalak]

Main reason is that OW C++ compiler doesn't support many "new" features, mainly with templates.
It will need big rework of C++ compiler to be capable implement new features necessary for these new standards.

[revelator]

I was afraid of that :-/ C++ is hard work indeed.

[pchapin]

There is a possibility that I might have some time to work on OWSTL again in the next few months. I'm currently getting the build going again on my machine as a first step. I realize I've said something like this before, and I know it has been a while since I contributed anything meaningful to that effort, but...

Anyway, due to the lack of C++ 11 features, work on OWSTL mostly involves cherry picking the parts of the library that the current compiler can support and ignoring the rest. There are certainly plenty of things in the library that are missing; many (not all) of them await language upgrades.

[revelator]

would atleast be nice to have full std 89 support :) im not to well versed in C++ myself but ill help if i can.

[pchapin]

You probably mean C++ 98... even that requires language features the compiler does not yet implement. That said, there is certainly more that can be added that the compiler can handle.

[revelator]

Whoops didnt notice i mixed those up :S

Ok sounds like a good start, which parts of std 98 does the compiler not yet handle ?.

[bmanga]

One of the biggest problems is two-phase name lookup for templates. OW essentially treats templates as a token soup.

[revelator]

So the compiler does not really know which types or otherwise it handles ? ouch...
Ok i will see if there are any good implementations that can be used.

[pchapin]

As I recall there are four issues that are blocking some important library additions, all are related to templates:

1. The lack of lazy instantiation. The compiler instantiates all the members of a class template even if they are not used. This means certain types can't be used with STL containers as they should be. There are bugs reported on std::vector, for example, that are due to this.

2. The inability to cope with the syntax of out-of-line definitions of template members of class templates. Quite a few members of the library container templates are themselves templates. The compiler can handle that as long as the definitions of the member templates are inline. However, that creates other issues. I believe Christof once told me that the problem is only a syntax issue. The compiler can handle out-of-line member template definitions internally, but it doesn't recognize the way they are declared.

3. The inability to deal properly with explicit template arguments for functions. For example, you should be able to do:

   template< typename T >
   void f( );

and then call it like this: f<int>( ). The compiler currently requires that template parameters be in the function signature. This issue is blocking the development of a modern IOStreams library.

4. Inadequate name mangling. The name mangling algorithm used by Open Watcom is rather limited and can't handle extremely complicated template instantiations. For example, if you try to do things like std::map< std::string, std::set<std::string> >, the compiler is likely to abort (I'm not sure if that example will cause an abort or not, but examples like that will once they get complex enough). The way it mangles names needs to be changed to support these kinds of examples. The immediate issue is that std::map and std::set are implemented with an internal template for red-black trees, so the mangled names are even more complicated than they look.

I don't think the lack of two-phase lookup is particularly a problem. Situations where that matters are fairly rare. The lack of lazy instantiation is a much bigger issue (maybe that is what @bmanga is thinking about).

[jmalak]

Only technical note to mangling, another problem.
There is limitation in symbol length for OMF to 255 characters.
We could switch to COFF or ELF to get longer symbols, but standard COFF and ELF don't support 16-bit segmented architecture. I don't know if exist some implementation for COFF or ELF formats and 16-bit segmented architecture which we could use otherwise we will need to develop such implementation.

[revelator]

hmm i think digital mars supported 16 bit segmented, but it only does OMF...

[revelator]

So it does understand typenames atleast as you shown with the template< typename T >
void f( ); example.

Thats a world of relief since that means the parser is not a completely lost case.

[jmalak]

Digital Mars use the similar method as OW round symbol length to follow OMF limit and add hash of symbol rest to end of symbol.
It generate unique symbol, but can not fully demangle original prototype.

[revelator]

not sure how OrangeC does it, going to look into source to see if i can get a picture.
Maybe better to look at the older CC386 from the same developer, since that one used std 98 and not C++11.

OrangeC's linker is quite different though, so im not sure any parts from that would come in handy.

[pchapin]

@revelator I'm not sure I understand what you're asking. Are you asking if the compiler understands the typename reserved word? The answer to that is "yes." Although, as I'm writing this, I'm remembering that the support for all of typename's semantics might not be complete. I forget the details. It has been a while since I was actively working on this stuff!

[revelator]

Ment can it deduce T to the type of function it represents :)

[revelator]

Hmm the C++ compiler sources are rather complicated, but as far as i can see it uses a lexical parser.
In the process of hunting down the missing bits and pieces needed for what we want out of it.

The code for handling templates needs a workover from what i can see its a bit braindead,
name mangling not sure how to go about that one, but there has to be a way.

Rest looks pretty solid to me :)

[revelator]

old hp stl for watcom here ->

https://sourceforge.net/projects/cbadvanced/files/Tools/hp-stl.7z/download

works with watcom 10 and 11.

outdated as all hell but it might help in regards to workarounds for getting the std upto speed.

[bmanga]

@pchapin I meant that two-phase name lookup is the feature that would require one of the most drastic changes in the internal representation of OW. But of course you're right that it's not one of the most beneficial ones, your list is much better for that :)

[revelator]

Have to agree since you worked more than anyone else on this part of the watcom C++ compiler.
Still trying to make heads or tails out of the parser :), might learn a trick or two in the process.

[sskras]

I guess this topic could be renamed to something more particular:)

[revelator]

possible improvements to the C++ compiler interface maybe ?.