Thanks, Jan. It now seems that the code causing me the trouble is not
STL at
all.
One of the team members seems to have implemented his own container
class,
relying on things in the <iterator> header file. This apparently is part
of
the Standard C++ library. it is in MSVC, but apparently not DMC. (I
searched
the sc\include directory for "iterator" with no hits.) So it looks like
I'm stuck, unless I want to borrow <iterator> from Microsoft!

Any ideas would be appreciated.

Ed Sowell

Jan,

Thought I'd move the discussion over here. In your e-mail reply, you said
that iterators are in STL. I know there is an iterator.h file in STL, but
is it really the same thing? That is, there are iterators and there are
iterators.
At any rate, I tried to resolve the problem by pointing to the stl\include
directory.
Got errors there, so that's when I went back to VC and saw that #include
<iterator>
was referring to the Standard C++ library, which I understand is a different
animal
from STL. But, I'll yield to the experts, if you are sure, and try to figure
out
why STL doesn't work.

Ed

"Edward F. Sowell" wrote:

> Thanks, Jan. It now seems that the code causing me the trouble is not
> STL at
> all.
> One of the team members seems to have implemented his own container
> class,
> relying on things in the <iterator> header file. This apparently is part
> of
> the Standard C++ library. it is in MSVC, but apparently not DMC. (I
> searched
> the sc\include directory for "iterator" with no hits.) So it looks like
> I'm stuck, unless I want to borrow <iterator> from Microsoft!
>
> Any ideas would be appreciated.
>
> Ed Sowell

Hi Ed,

I do not know what exactly happened with STL and the Standard C++ Library.
SGI's STL seems to have a iterator and a iterator.h which both basically include
a set of the same header files.
So far I have never been in trouble using STL.
Is there any way you could post a small example here of what is being done so we
can take a look at the code and figure it out?

HTH
Jan

On Mon, 08 Jan 2001 23:53:48 -0500, Jan Knepper <jan@smartsoft.cc> wrote:
> Hi Ed,
> 
> I do not know what exactly happened with STL and the Standard C++ Library. SGI's STL seems to have a iterator and a iterator.h which both basically include a set of the same header files.

STL became a small but significant part of the Standard C++ library.

The files iterator and iterator.h should result in the same code being included regardless of which file is included. On all the platforms I use this is the method for handling the change from standard include files having a '.h' extension to having no extension as required by the ANSI standard (the '.h' versions are supplied to support legacy code).

Mixing the VC++ STL (http://www.dinkumware.com) and STLport is likly to give
you problems, while both are derived from the same source (HP's original STL), both
have diverged considerably.

> So far I have never been in trouble using STL.

dito. Most of my problems have been caused by my misuse of STL, hence my use of STLport
with this and other compilers (VC++, HP-UX, SGI, Solaris....) as a Debug STL is provided, which
can help you when things go wrong :>

> Is there any way you could post a small example here of what is being done so we can take a look at the code and figure it out?

Please do. The problem maybe because the STL supplied with VC++ is not as upto date
as the STLport version (There was a legal case that prevented M$ from supplying updates
and corrections until very recently). Then again the problem may be due to DMC though
I hope not :)

> 
> HTH
> Jan
> 
> 

Regards
Damian

Jan & Damian,

I am sending to both of you a zip file with a very short test driver using our vector class, along with our vector.h header.

It compiles, links and runs under MS VC 5.0 but not with DMC 8.0B2. If I point to STLPort, it tells me the compiler is not supported. If I point to the HP STL, it fails while trying to compile our vector class.



Ed Sowell

Ed,

I quickly looked at the example.
The first problem is that the keyword 'typename' is being used. DMC++ accepts it to a certain
level, but does not implement the semantics.
So what I did for starters... I replaced 'typename' with 'class' which created a much better
result. However it still does not compile.
After that, I took a closer look at the code and started wondering why the heck things have been
made as complex as they are.
I mean, TVectorBrowse hardly add any thing to TVector... So why has it been implemented
separately? Why not just integrate the code from TVectorBrowser into TVector and take it that
road.

Basically, you've run into the fact that DMC++ does not have the templates implemented as proposed in the latest standards. For this template construction I do see a very easy way around it that will get rid of a lot of confision IMHO. However, how many more of these constructions is being used in the code?

HTH

Jan



"Edward F. Sowell" wrote:

> Jan & Damian,
>
> I am sending to both of you a zip file with a very short test driver using our vector class, along with our vector.h header.
>
> It compiles, links and runs under MS VC 5.0 but not with DMC 8.0B2. If I point to STLPort, it tells me the compiler is not supported. If I point to the HP STL, it fails while trying to compile our vector class.
>
> Ed Sowell

On Tue, 09 Jan 2001 12:26:08 -0800, "Edward F. Sowell" <sowelled@home.com> wrote: Ed,

Sorry, I should have asked. What platform are you building for: DOSX, DOS, Windows NT, Windows 95?

One of the limitations with STLport for DMC 8.0 at the moment is that I have only tested it for Windows NT.

Regards,
Damian
> Jan & Damian,
> 
> I am sending to both of you a zip file with a very short test driver using our vector class, along with our vector.h header.
> 
> It compiles, links and runs under MS VC 5.0 but not with DMC 8.0B2. If I point to STLPort, it tells me the compiler is not supported. If I point to the HP STL, it fails while trying to compile our vector class.
> 
> 
> 
> Ed Sowell
> 

Damian,

I'm running Win98 at the moment. Presumably, our executibles thus generated
would also run under NT, right? (if they generated at all, of course :-) )

Ed


Damian Dixon wrote:

> On Tue, 09 Jan 2001 12:26:08 -0800, "Edward F. Sowell" <sowelled@home.com> wrote: Ed,
>
> Sorry, I should have asked. What platform are you building for: DOSX, DOS, Windows NT, Windows 95?
>
> One of the limitations with STLport for DMC 8.0 at the moment is that I have only tested it for Windows NT.
>
> Regards,
> Damian

Jan,

As you  no doubt have experienced in team software development, one man's creation
of great beauty in another's ugliness personified! The general principle we are following
is adherence to the current C++ Standard. So I may have a hard time convincing the author
of this particular piece of code to change something that is Standard C++ and compiles
correctly on MS VC 5 (with Service pac 3) and 6, one of the Windows implementations of g++,
and a couple  differenct Sun-based compilers (so I'm told). Nonetheless, if there is some work-around

that is indeed Standard C++ and is arguably better than the current code, I might be able
to convince him to change it. The class vs. typedef may be something of that nature. However,
elimination of the browser and other structural changes will be tough going.

What are you referring to specifficaly when you say "However, how many more of these constructions is

being used in the code?"


Ed

Jan Knepper wrote:

> Ed,
>
> I quickly looked at the example.
> The first problem is that the keyword 'typename' is being used. DMC++ accepts it to a certain
> level, but does not implement the semantics.
> So what I did for starters... I replaced 'typename' with 'class' which created a much better
> result. However it still does not compile.
> After that, I took a closer look at the code and started wondering why the heck things have been
> made as complex as they are.
> I mean, TVectorBrowse hardly add any thing to TVector... So why has it been implemented
> separately? Why not just integrate the code from TVectorBrowser into TVector and take it that
> road.
>
> Basically, you've run into the fact that DMC++ does not have the templates implemented as proposed in the latest standards. For this template construction I do see a very easy way around it that will get rid of a lot of confision IMHO. However, how many more of these constructions is being used in the code?
>
> HTH
>
> Jan
>
> "Edward F. Sowell" wrote:
>

Ed,

Actually, I do have some experience with team work, not a lot. However in the latest team work I was
aways the senior SENIOR programmer and not only looked over the code being C++ standard, but also over
the design and usage. A construction like the one in the code you send would have been redesigned a
little.
I personally do not see the big win in the code you sent for the separate template that makes the brower,
especially because it is being base on a derivation of the class that uses the browser. There is one
member variable being added and a reimplementation of a few member functions. When the original template
would ne extemded a little (made a little more intelligent) it would be able to support the functions now
implemented via the template that creates the browser with less complexity and less code generation.

What I meant with "However, how many more of these constructions is being used in the code?" is:
Is this the only thing that keep you from compiling your project with DMC++ and is it the one major thing
the compiler is stuck with: Change it!
If there is more stuff like this that is major: You might want to reconsider compiling the code with
DMC++ as it might take a lot of efford to 'patch' the code.

Of course, that decision is yours to make. I personally would change the code and make sure it compiled with DMC++... But hey, that is me being a DMC++ addict.

HTH

Jan



"Edward F. Sowell" wrote:

> Jan,
>
> As you  no doubt have experienced in team software development, one man's creation
> of great beauty in another's ugliness personified! The general principle we are following
> is adherence to the current C++ Standard. So I may have a hard time convincing the author
> of this particular piece of code to change something that is Standard C++ and compiles
> correctly on MS VC 5 (with Service pac 3) and 6, one of the Windows implementations of g++,
> and a couple  differenct Sun-based compilers (so I'm told). Nonetheless, if there is some work-around
> that is indeed Standard C++ and is arguably better than the current code, I might be able
> to convince him to change it. The class vs. typedef may be something of that nature. However,
> elimination of the browser and other structural changes will be tough going.
>
> What are you referring to specifficaly when you say "However, how many more of these constructions is being used in the code?"
>
> Ed
>
> Jan Knepper wrote:
>
> > Ed,
> >
> > I quickly looked at the example.
> > The first problem is that the keyword 'typename' is being used. DMC++ accepts it to a certain
> > level, but does not implement the semantics.
> > So what I did for starters... I replaced 'typename' with 'class' which created a much better
> > result. However it still does not compile.
> > After that, I took a closer look at the code and started wondering why the heck things have been
> > made as complex as they are.
> > I mean, TVectorBrowse hardly add any thing to TVector... So why has it been implemented
> > separately? Why not just integrate the code from TVectorBrowser into TVector and take it that
> > road.
> >
> > Basically, you've run into the fact that DMC++ does not have the templates implemented as proposed in the latest standards. For this template construction I do see a very easy way around it that will get rid of a lot of confision IMHO. However, how many more of these constructions is being used in the code?
> >
> > HTH
> >
> > Jan
> >
> > "Edward F. Sowell" wrote:
> >