On Wed, 10 Jan 2001 14:14:37 -0800, "Edward F. Sowell" <sowelled@home.com> wrote:
> 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
> 

As long as you stick to Win32 interface and don't use something specific to win98 or nt you should be ok.

Others look on this would probably know better then me, as I tend to use the OS that I am targeting to build on.

> 
> 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
> 

On Wed, 10 Jan 2001 14:25:58 -0800, "Edward F. Sowell" <sowelled@home.com> 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
> 
Sticking to the C++ standard can cause you a lot of problems. While it is ideal it is not always possible.

Where I work we have the policy of what we call the lowest common denominator. So if some thing is not
supported with a compiler then we don't use it with the other compilers we have to support until
it is supported.

So far we are using: VC++ v5, v6, .NET (laugh), aCC (HP-UX), SGI C++, Solaris CC (v4.02 , v5, v6),
g++, DMC++, C++ (True64), GreenHill (I've probably missed something).

With all these compilers we have found that template support varies greatly to such an
extent that something that worked with VC++ v6 failed on nearly all the Unix platforms we need to
support, so we have had to re-write a large chuck of code (template meta programming). So we now
keep our templates fairly simple.


Jan, Walter, When do you plan to improve the template support in the compiler?



> 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.

The only way I can get this to compile is the elimination of the browser typedef and commenting out of the use of browser, plus a few other things to do with cout.

Other problems are to do with using 'namespace std' and hence the 'std::' as STLport has not been
configured to support namespaces. In fact I have not tested the compiler to see if the support for
namespace is implemented. It should be noted that STLport has been configured to support only
the iostreams that comes with the original compiler, not the new standard iostreams because of
porting problems due to limitations of the template support. So you may also run into problems else
where with this.

The method '....::view(const size_t....' needs to have 'const' defined in the template class.

typename should really be defined to nothing. This is the common way in STLport for dealing with broken support for typename.

In vector.h header inclusion is as follows:

...
#else
#define typename
#include <stddef.h>
#include <iterator>
#include <strstrea.h>
#include <iostream.h>
#endif
...

In addition I needed to rename the file from vector.h to tvector.h and I needed to include vector.h when building against STLport (problem with including setup file for STLport).

> 
> What are you referring to specifficaly when you say "However, how many more of these constructions is
> 
> being used in the code?"

Is the browser type being used it a large number of places? or just a few? If in a few places then
replacing the use of browser should not be too difficult. It may be fairly simple to move the functionality of browser
into the TVector template, with minimal impact. I've done some modifications that eleminate the use of the
browser template, though I have not tested them to see if the functionality is the same.

Sorry I could not be of any more help. If you want the changes I made email me and I will send them to you.

Regards,
Damian

> 
> 
> 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:
> >
> 

Damian Dixon wrote:

> Sticking to the C++ standard can cause you a lot of problems. While it is ideal it is not always possible.
>
> Where I work we have the policy of what we call the lowest common denominator. So if some thing is not
> supported with a compiler then we don't use it with the other compilers we have to support until
> it is supported.

Same here.

> So far we are using: VC++ v5, v6, .NET (laugh), aCC (HP-UX), SGI C++, Solaris CC (v4.02 , v5, v6),
> g++, DMC++, C++ (True64), GreenHill (I've probably missed something).

We are using...
DMC++, Borland C++ Builder 5.0, VC-- 6.0. We also used to use Watcom C++, MetroWerks C++. We are getting into using more
g++, because of the BSD platforms. Since g++ is giving some problem with code being ported we are looking into using
KCC...

> With all these compilers we have found that template support varies greatly to such an
> extent that something that worked with VC++ v6 failed on nearly all the Unix platforms we need to
> support, so we have had to re-write a large chuck of code (template meta programming). So we now
> keep our templates fairly simple.

Cool huh?!

> Jan, Walter, When do you plan to improve the template support in the compiler?

That's up to Walter actually...
I don't write nor maintain the compiler. I just provide free support as much as I can.

> Is the browser type being used it a large number of places? or just a few? If in a few places then
> replacing the use of browser should not be too difficult. It may be fairly simple to move the functionality of browser
> into the TVector template, with minimal impact. I've done some modifications that eleminate the use of the
> browser template, though I have not tested them to see if the functionality is the same.

Exactly my thought.

Take care!
Jan

Damian Dixon wrote:

> > 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 :-) )
>
> As long as you stick to Win32 interface and don't use something specific to win98 or nt you should be ok.
>
> Others look on this would probably know better then me, as I tend to use the OS that I am targeting to build on.

Presumably yes, but we develop on Windows 2000 Professional at this moment and always check our executables on all other platforms...

I have seen quite a number or rarities over the last couple of years...

Jan

Hi Jan,

Thanks again. I will make the changes you suggest if you will guide me; of course I would be ore than grateful if you just made the changes for me! I believe this is the only place where we make use of templates.

Ed

Jan Knepper wrote:

> Ed,
>
>
> 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:

> Thanks again. I will make the changes you suggest if you will guide me; of course I would be ore than grateful if you just made the changes for me! I believe this is the only place where we make use of templates.

Ed, if the sources you sent me is the complete stuff I migth get to it later this week or may be during the
weekend...
I am under a lot of pressure though right now as I am facing a deadline of February 1st for my Time Log System.

Take care!
Jan

Hi Jan,

I really don't want to put pressure on you to solve my problems. Maybe if
you just gave me a direction I could do it with an occasional Q & A
with you. Perhaps you (and Damian) already have. I'll ask Damian to send me the
code he tweaked, and I'll try to take it from there.

Ed

Jan Knepper wrote:

> "Edward F. Sowell" wrote:
>
> > Thanks again. I will make the changes you suggest if you will guide me; of course I would be ore than grateful if you just made the changes for me! I believe this is the only place where we make use of templates.
>
> Ed, if the sources you sent me is the complete stuff I migth get to it later this week or may be during the
> weekend...
> I am under a lot of pressure though right now as I am facing a deadline of February 1st for my Time Log System.
>
> Take care!
> Jan
>

Damian Dixon wrote:

>
>
> Is the browser type being used it a large number of places?

No. Seems to be used only once!

> or just a few? If in a few places then
> replacing the use of browser should not be too difficult. It may be fairly simple to move the functionality of browser
> into the TVector template, with minimal impact. I've done some modifications that eleminate the use of the
> browser template, though I have not tested them to see if the functionality is the same.
>
> Sorry I could not be of any more help. If you want the changes I made email me and I will send them to you.

Yes, please send. I will try to continue the work and ask for help if needed.

Thanks.

Ed

"Edward F. Sowell" wrote:

> I really don't want to put pressure on you to solve my problems. Maybe if
> you just gave me a direction I could do it with an occasional Q & A
> with you. Perhaps you (and Damian) already have. I'll ask Damian to send me the
> code he tweaked, and I'll try to take it from there.

That would be a good start.
The basic problem is is that TVectorBrowser has been derived from TVector.
With a little bit of effort is should be possible to move up the one member variable that TVectorBrowser uses into
TVector and integrate the TVectorBrowser code into TVector.

Once that is done the major problem is over I suspect.

Jan

I've found it the most productive to develop under NT or 2000, and then port it to 98/95. The reason is that the former is a much more robust development environment (a lot fewer reboots needed).