Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
January 09, 2001 <iterator> | ||||
---|---|---|---|---|
| ||||
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 |
January 09, 2001 Re: <iterator> | ||||
---|---|---|---|---|
| ||||
Posted in reply to Edward F. 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 |
January 09, 2001 Re: <iterator> | ||||
---|---|---|---|---|
| ||||
Posted in reply to Edward F. 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 |
January 09, 2001 Re: <iterator> | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jan Knepper | 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 |
January 09, 2001 Re: <iterator> | ||||
---|---|---|---|---|
| ||||
Posted in reply to Damian Dixon | 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 |
January 10, 2001 Re: <iterator> | ||||
---|---|---|---|---|
| ||||
Posted in reply to Edward F. 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
|
January 10, 2001 Re: <iterator> | ||||
---|---|---|---|---|
| ||||
Posted in reply to Edward F. 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
>
|
January 10, 2001 Re: <iterator> | ||||
---|---|---|---|---|
| ||||
Posted in reply to Damian Dixon | 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
|
January 10, 2001 Re: <iterator> | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jan Knepper | 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:
>
|
January 11, 2001 Re: <iterator> | ||||
---|---|---|---|---|
| ||||
Posted in reply to Edward F. Sowell | 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:
> >
|
Copyright © 1999-2021 by the D Language Foundation