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

Jan 08 2001

"Edward F. Sowell" <sowelled home.com> writes:

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

Jan 08 2001

Jan Knepper <jan smartsoft.cc> writes:

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

Jan 08 2001

Damian Dixon <damian.dixon tenetdefence.com> writes:

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

"Edward F. Sowell" <sowelled home.com> writes:

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

Jan 09 2001

Jan Knepper <jan smartsoft.cc> writes:

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

Jan 09 2001

"Edward F. Sowell" <sowelled home.com> writes:

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:

Jan 10 2001

Jan Knepper <jan smartsoft.cc> writes:

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:

Jan 11 2001

"Edward F. Sowell" <sowelled home.com> writes:

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

Jan 11 2001

Jan Knepper <jan smartsoft.cc> writes:

"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

Jan 11 2001

"Edward F. Sowell" <sowelled home.com> writes:

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

Jan 11 2001

Jan Knepper <jan smartsoft.cc> writes:

"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

Jan 11 2001

Damian Dixon <damian.dixon tenetdefence.com> writes:

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
 


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:

Jan 11 2001

Jan Knepper <jan smartsoft.cc> writes:

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

Jan 11 2001

Damian Dixon <damian.dixon tenetdefence.com> writes:

On Thu, 11 Jan 2001 13:11:43 -0500, Jan Knepper <jan smartsoft.cc> wrote:
 Damian Dixon wrote:
 
 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?!
 


was going on. The only benefit we had was performance, but we also got code
bloat!

So for sanity and for porting we removed the code.

Regards,
Damian

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

Damian Dixon wrote:

 On Thu, 11 Jan 2001 13:11:43 -0500, Jan Knepper <jan smartsoft.cc> wrote:
 Damian Dixon wrote:

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


 was going on.


Know exactly what you mean...
Although, my customers NEVER look into my code.

 The only benefit we had was performance, but we also got code bloat!


Hmmm.

 So for sanity and for porting we removed the code.


For this reason I never use any STL template directly, but always derive a
protected class and implement
an interface. This way, if I ever go out of luck on a platform or compiler I
will have to implement the
class myself without the template, but it will work.

Jan

Jan 12 2001

"Walter" <walter digitalmars.com> writes:

Jan Knepper wrote in message <3A5F347E.2DDE0BE6 smartsoft.cc>...
Know exactly what you mean...
Although, my customers NEVER look into my code.




I've warned people that if they looked at my code, they'd need new glasses,
lose their hair, and probably require psychoanalysis.

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

Lost most of my hear already at age of 33...
Used to have glasses, but got LASIK surgery a couple of months ago to correct a
+4.5 on both eyes, so glasses are out I guess.
I still might need the psychoanalysis though...



Walter wrote:

 Jan Knepper wrote in message <3A5F347E.2DDE0BE6 smartsoft.cc>...
Know exactly what you mean...
Although, my customers NEVER look into my code.


 I've warned people that if they looked at my code, they'd need new glasses,
 lose their hair, and probably require psychoanalysis.

Jan 12 2001

"Walter" <walter digitalmars.com> writes:

I considered the laser surgery, but due to my advancing age I would need
reading glasses anyway so I thought why bother. I also want the UV blocking
I can get with glasses, since I'm at risk for macular degeneration, and
lifetime UV dosage is a risk for that.


Jan Knepper wrote in message <3A5F5942.D6E8B121 smartsoft.cc>...
Lost most of my hear already at age of 33...
Used to have glasses, but got LASIK surgery a couple of months ago to


+4.5 on both eyes, so glasses are out I guess.
I still might need the psychoanalysis though...



Walter wrote:

 Jan Knepper wrote in message <3A5F347E.2DDE0BE6 smartsoft.cc>...
Know exactly what you mean...
Although, my customers NEVER look into my code.


 I've warned people that if they looked at my code, they'd need new




 lose their hair, and probably require psychoanalysis.

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

That's true... The information on LASIK I read was quite honest about the fact
that it the results are not nearly as good once you hit 40 or older. As I have
no idea what you 'advancing age' is, but just guess that you're at least 5 to
10 years older than I am going for LASIK might give more trouble than good.

Hmmm, how do they know you're at risk for macular degeneration?
I guess UV blocking is important, also I always wonder how much slips by with
glasses. With every kind I've had I've always looked at the frame or outside
the frame at times.



Walter wrote:

 I considered the laser surgery, but due to my advancing age I would need
 reading glasses anyway so I thought why bother. I also want the UV blocking
 I can get with glasses, since I'm at risk for macular degeneration, and
 lifetime UV dosage is a risk for that.

Jan 12 2001

"Walter" <walter digitalmars.com> writes:

Jan Knepper wrote in message <3A5FA30B.2050748B smartsoft.cc>...
That's true... The information on LASIK I read was quite honest about the


that it the results are not nearly as good once you hit 40 or older. As I


no idea what you 'advancing age' is, but just guess that you're at least 5


10 years older than I am going for LASIK might give more trouble than good.

Hmmm, how do they know you're at risk for macular degeneration?
I guess UV blocking is important, also I always wonder how much slips by


glasses. With every kind I've had I've always looked at the frame or


the frame at times.



I'm 41. I don't need reading glasses yet, but I will within 5 years, as I'm
borderline for them now. My father & grandfather both suffer from macular
degeneration. Genetics are a risk factor, but also both of them had careers
that involved excessive exposure to UV light, so who knows? The glasses I
have have a UV blocking coating added on. Ordinary window glass will
naturally block UV light to some extent, but my lenses are plastic. I also
have blue eyes, which block less UV light than brown.

The ironic thing is my eye doctor suggested I avoid sunglasses. He says that
with sunglasses, your pupils expand letting in even more UV. In any case,
never even consider using sunglasses that are not UV blocking.

Besides, I've worn glasses essentially my whole life. I've accepted my fate
<g>.

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

 I'm 41. I don't need reading glasses yet, but I will within 5 years, as I'm
 borderline for them now.


Well, I needed glasses ever since I was 8 years old... Could not read without
them. I used to be very far sighted.
Right now after the LASIK surgery it's pretty funny, but I think I am a little
over corrected. Also, my right eye's sigmatism has been corrected, so my brain
still tells me that my left eye is the best while my right eye is right now.
Basically, my vision, expecially for reading jumps around a little. However,
it's always good at nights when I get relaxed and tired.

 My father & grandfather both suffer from macular degeneration. Genetics are a
 risk factor, but also both of them had careers that involved excessive
 exposure to UV light, so who knows?


Well, I would not... I am certainly no specialist in that area.
It's good to count with those factors though, but they do not always work.
My father has had back problems as long as I can remember, and so do I. However
it turns out that my lowest back bone exists in two halfs instead of one whole.
Next to that my body seems to be in survival position because of some kind of
trauma which makes it worse. I am planning on going to a clinic in Springfield
for a week to get it fixed. (Non-surgery!) My fathers back problem is quite
different as far as I know.

 The glasses I have have a UV blocking coating added on. Ordinary window glass
 will naturally block UV light to some extent, but my lenses are plastic. I
 also have blue eyes, which block less UV light than brown.


Hmmm, did know about glass blocking UV light as I got welding lessons when I was
younger and had to go through quite some theory before I was allowed to actually
weld. I never heard of that difference between blue and brown eyes though.

 The ironic thing is my eye doctor suggested I avoid sunglasses. He says that
 with sunglasses, your pupils expand letting in even more UV. In any case,
 never even consider using sunglasses that are not UV blocking.


I don't. I don't like sunglasses to begin with.
I've got a pair of Ray Ban I got 10 years ago in New Orleans, still have them,
hardly ever use them.

 Besides, I've worn glasses essentially my whole life. I've accepted my fate
 <g>.


So have I, or at least for a long time. It was amazing to be able to forget
about them though.

Jan 12 2001

"Edward F. Sowell" <sowelled home.com> writes:

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

Jan 11 2001

Damian Dixon <damian.dixon tenetdefence.com> writes:

On Thu, 11 Jan 2001 14:26:48 -0800, "Edward F. Sowell" <sowelled home.com>
wrote:
 
 
 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

Jan 12 2001

"Walter" <walter digitalmars.com> writes:

Damian Dixon wrote in message <1107_979228530 dilbert>...
Jan, Walter, When do you plan to improve the template support in the




I do hear and understand the problems you're having with templates and
namespaces.

The template support in the compiler is one of the trickiest and most
complex pieces of code in it (aside from multiple inheritance!). A quick
hack isn't going to do the job and will likely make things worse - not only
that, doing it right may require some significant work on the linker.

My main focus for the near term is to get the whole package into a usable
form (there's some legal footwork to be done, too), so the template support
will not likely change in the near future.

I'm also facing the reality that it's just myself & Pat working on this, so
we'll have to be a bit ruthless in narrowing the scope of the project. We'll
likely not be making any changes at all to the IDE nor the 16 bit support,
and will focus on the command line tools and win32 support.

I appreciate all the work everyone here in the newsgroup is doing to produce
workarounds for the template issues.

Jan 11 2001

"Edward F. Sowell" <sowelled home.com> writes:

Wise.

Ed

Jan 11 2001

"Walter" <walter digitalmars.com> writes:

As Clint Eastwood put it, "a man's got to know his limitations!" <grins>


Edward F. Sowell wrote in message <3A5E8175.5BA87BB9 home.com>...
Wise.

Ed

Jan 11 2001

Damian Dixon <damian.dixon tenetdefence.com> writes:

On Thu, 11 Jan 2001 18:49:57 -0800, "Walter" <walter digitalmars.com> wrote:
 
 Damian Dixon wrote in message <1107_979228530 dilbert>...
Jan, Walter, When do you plan to improve the template support in the


 
 
 I do hear and understand the problems you're having with templates and
 namespaces.
 
 The template support in the compiler is one of the trickiest and most
 complex pieces of code in it (aside from multiple inheritance!). A quick
 hack isn't going to do the job and will likely make things worse - not only
 that, doing it right may require some significant work on the linker.
 


I understand. I had looked at doing a pre-process jog on templates into a
supported
form for partial specialisation etc.... but decided for the moment it was too
large
a job given my other commitments :(

 My main focus for the near term is to get the whole package into a usable
 form (there's some legal footwork to be done, too), so the template support
 will not likely change in the near future.
 


Thanks understandable.

 I'm also facing the reality that it's just myself & Pat working on this, so
 we'll have to be a bit ruthless in narrowing the scope of the project. We'll
 likely not be making any changes at all to the IDE nor the 16 bit support,
 and will focus on the command line tools and win32 support.
 


win32 is probably the thing to concentrate on. I can live with IDE and 16 bit
support as they are.

 I appreciate all the work everyone here in the newsgroup is doing to produce
 workarounds for the template issues.
 


Is there anything the rest of us could do to help?

Jan 12 2001

"Walter" <walter digitalmars.com> writes:

Damian Dixon wrote in message <1109_979295385 dilbert>...
 I appreciate all the work everyone here in the newsgroup is doing to




 workarounds for the template issues.





Certainly, the work going on here to get a version of STL to work is great.

A (rather dull) job I need to do is to get the manuals converted into usable
html format, since my intention is to have all the manuals online instead of
published. To do that, I ran all the .pdf files through adobe's pdf->html
translator. Unfortunately, their software did a terrible job - the text is
all there, but the formatting is a mess. All the html files need to  be gone
through line by line and the formatting corrected by hand. Ugh. I could just
say "use the .pdf files", but I don't like using them and I doubt other net
people do either.

The printf and scanf functions need to be upgraded to support 80 bit long
doubles and hex floats. Any library changes need to be accompanied with test
programs to verify that they work.

I want to sort out and reorganize the library source tree so the old cruft
is shunted aside and just the win32 stuff remains, and make it easier to
build the library.

Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues with
SMAKE).

At issue also would be the compensation for any work people do that is on
proprietary stuff. Due to licensing issues, I can't make it open source, nor
can I transfer copyrights.

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

Walter wrote:

 Certainly, the work going on here to get a version of STL to work is great.


Thanks!

 A (rather dull) job I need to do is to get the manuals converted into usable
 html format, since my intention is to have all the manuals online instead of
 published. To do that, I ran all the .pdf files through adobe's pdf->html
 translator. Unfortunately, their software did a terrible job - the text is
 all there, but the formatting is a mess. All the html files need to  be gone
 through line by line and the formatting corrected by hand. Ugh. I could just
 say "use the .pdf files", but I don't like using them and I doubt other net
 people do either.


Well, for now we could publish them as they are. A lot of company's seem to use
.PDF files online and with the plugin's it isn't really a problem.

 The printf and scanf functions need to be upgraded to support 80 bit long
 doubles and hex floats. Any library changes need to be accompanied with test
 programs to verify that they work.


Cool! Any description available?

 I want to sort out and reorganize the library source tree so the old cruft
 is shunted aside and just the win32 stuff remains, and make it easier to
 build the library.


Good idea!

 Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues with
 SMAKE).


Hmmm, there is no way of getting it from "Innovative Data Concepts
Incorporated"?

 At issue also would be the compensation for any work people do that is on
 proprietary stuff. Due to licensing issues, I can't make it open source, nor
 can I transfer copyrights.


That would be great and also a very good motivator to do more, at least for me
as I am independent, but still need to work for my bread (and expenses)...

Jan

Jan 12 2001

"Walter" <walter digitalmars.com> writes:

Jan Knepper wrote in message <3A5F5EAF.9FE11F4A smartsoft.cc>...
Walter wrote:
 Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues




 SMAKE).


Incorporated"?



I can't find them <g>. Who actually has the IP rights to SMAKE I have not
been able to determine, nor can I locate the source to it. It doesn't seem
worth the bother to deal with since I have unquestioned IP rights to MAKE
and the source for it.

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

Hmmm, did I ever forward you the page I found on the web with their name,
address and phone number? Than again, you might have found them yourself that
way and learned that they are no longer there.

Anyways, if you have MAKE and the sources for MAKE and it is as good, why
bother...



Walter wrote:

 Jan Knepper wrote in message <3A5F5EAF.9FE11F4A smartsoft.cc>...
Walter wrote:
 Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues




 SMAKE).


Incorporated"?


 I can't find them <g>. Who actually has the IP rights to SMAKE I have not
 been able to determine, nor can I locate the source to it. It doesn't seem
 worth the bother to deal with since I have unquestioned IP rights to MAKE
 and the source for it.

Jan 12 2001

"Walter" <walter digitalmars.com> writes:

If you did, I have forgotten, for which I apologize.

Jan Knepper wrote in message <3A5FA396.576125D4 smartsoft.cc>...
Hmmm, did I ever forward you the page I found on the web with their name,
address and phone number? Than again, you might have found them yourself


way and learned that they are no longer there.

Anyways, if you have MAKE and the sources for MAKE and it is as good, why
bother...



Walter wrote:

 Jan Knepper wrote in message <3A5F5EAF.9FE11F4A smartsoft.cc>...
Walter wrote:
 Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues




 SMAKE).


Incorporated"?


 I can't find them <g>. Who actually has the IP rights to SMAKE I have not
 been able to determine, nor can I locate the source to it. It doesn't




 worth the bother to deal with since I have unquestioned IP rights to MAKE
 and the source for it.

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

Don't worry.
It was a matter of typing "Innovative Data Concepts" into altavista...
I sent it to you already.

Jan



Walter wrote:

 If you did, I have forgotten, for which I apologize.

 Jan Knepper wrote in message <3A5FA396.576125D4 smartsoft.cc>...
Hmmm, did I ever forward you the page I found on the web with their name,
address and phone number? Than again, you might have found them yourself


way and learned that they are no longer there.

Anyways, if you have MAKE and the sources for MAKE and it is as good, why
bother...



Walter wrote:

 Jan Knepper wrote in message <3A5F5EAF.9FE11F4A smartsoft.cc>...
Walter wrote:
 Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues




 SMAKE).


Incorporated"?


 I can't find them <g>. Who actually has the IP rights to SMAKE I have not
 been able to determine, nor can I locate the source to it. It doesn't




 worth the bother to deal with since I have unquestioned IP rights to MAKE
 and the source for it.

Jan 12 2001

"Edward F. Sowell" <sowelled home.com> writes:

What is the heritage of the MAKE you refer to? The reason I ask is I have found
a lot of variations in make programs, causing me a lot of grief. My build
program

now works with nmake, smake, Borland's make, and gmake.

Ed Sowell

Jan Knepper wrote:

 Hmmm, did I ever forward you the page I found on the web with their name,
 address and phone number? Than again, you might have found them yourself that
 way and learned that they are no longer there.

 Anyways, if you have MAKE and the sources for MAKE and it is as good, why
 bother...

Jan 13 2001

"Walter" <walter digitalmars.com> writes:

MAKE is a relatively simple make program I wrote about 15 years ago. But
then, I'm philosophically opposed to huge complex makefiles <g>.


Edward F. Sowell wrote in message <3A608D1C.6BE80D60 home.com>...
What is the heritage of the MAKE you refer to? The reason I ask is I have


a lot of variations in make programs, causing me a lot of grief. My build


now works with nmake, smake, Borland's make, and gmake.

Ed Sowell

Jan Knepper wrote:

 Hmmm, did I ever forward you the page I found on the web with their name,
 address and phone number? Than again, you might have found them yourself




 way and learned that they are no longer there.

 Anyways, if you have MAKE and the sources for MAKE and it is as good, why
 bother...

Jan 13 2001

Heinz Saathoff <hsaat bre.ipnet.de> writes:

Walter wrote...

 Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues with
 SMAKE).


When looking at make can you also check how system-time and file-time 
are handled? With make on WinNT I get messages like this:

    File 'text.obj' is newer than system time.
    File time = 979805590, system time = 979801992
    File time = 'Thu Jan 18 09:13:10 2001
    '
    Sys  time = 'Thu Jan 18 08:13:12 2001
    '

I assume this has to do with the timezone (here it's GMT+1). I don't get 
this with smake.


	Heinz

Jan 18 2001

"Walter" <walter digitalmars.com> writes:

I get a message like this sometimes when I use multiple computers and they
don't have their clocks synchronized. The message is triggered when the time
stamp on a file is forward in time than what the computer's system clock
says.

Do a dir on the file and see if the time on it matches MAKE's claim for it,
and do a TIME on the command line and see if that matches too.

-Walter


Heinz Saathoff wrote in message ...
Walter wrote...

 Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues




 SMAKE).


When looking at make can you also check how system-time and file-time
are handled? With make on WinNT I get messages like this:

    File 'text.obj' is newer than system time.
    File time = 979805590, system time = 979801992
    File time = 'Thu Jan 18 09:13:10 2001
    '
    Sys  time = 'Thu Jan 18 08:13:12 2001
    '

I assume this has to do with the timezone (here it's GMT+1). I don't get
this with smake.


 Heinz

Jan 18 2001

Heinz Saathoff <hsaat bre.ipnet.de> writes:

Walter wrote ...
 I get a message like this sometimes when I use multiple computers and they
 don't have their clocks synchronized. The message is triggered when the time
 stamp on a file is forward in time than what the computer's system clock
 says.
 
 Do a dir on the file and see if the time on it matches MAKE's claim for it,
 and do a TIME on the command line and see if that matches too.
 
 -Walter
 
 
 Heinz Saathoff wrote in message ...
When looking at make can you also check how system-time and file-time
are handled? With make on WinNT I get messages like this:

    File 'text.obj' is newer than system time.
    File time = 979805590, system time = 979801992
    File time = 'Thu Jan 18 09:13:10 2001
    '
    Sys  time = 'Thu Jan 18 08:13:12 2001
    '

I assume this has to do with the timezone (here it's GMT+1). I don't get
this with smake.




This must have to do with the timezone. Now on Winter make claims that 
system time is 1 hour before file time. In summer we have daylight 
saving (GMT+2) and make claims it's 2 hours before file time. And on NT 
I get this message _always_! I don't get this on an old DOS machine, but 
DOS doesn't have timezone support.
BTW, I've had this discussion already on the old Symantec newsgroup. One 
answer was that this messages only appear on machines that have 
timezones GMT+n but nut with GMT-n. So in the US you won't get this 
message.

BTW1, it does not have any influence on the build process as only file 
times are compared against each other. So it's not a real bug in make. 
But still I find this messages disturbing and therfore use smake 
instead.

BTW2, I mostly use make in 4DOS-NT boxes and not in the IDE. My target 
platform is still DOSX! 


	Heinz

Jan 19 2001

"Walter" <walter digitalmars.com> writes:

Checking the code, it is most likely a bug in the time() runtime library
function. The check has no affect on the rest of MAKE's operation, I only
put it in because that was back in the bad old days where networks didn't
synchronize clocks on all the computers connected. Having the computers all
with different dates could produce some pretty wacky make results.

Try an experiment for me - write a little program to get the time via time()
and print it out with ctime(). See if it is also off by an hour.

-Walter

Jan 19 2001

Heinz Saathoff <hsaat bre.ipnet.de> writes:

Walter wrote ...
 Checking the code, it is most likely a bug in the time() runtime library
 function. The check has no affect on the rest of MAKE's operation, I only
 put it in because that was back in the bad old days where networks didn't
 synchronize clocks on all the computers connected. Having the computers all
 with different dates could produce some pretty wacky make results.
 
 Try an experiment for me - write a little program to get the time via time()
 and print it out with ctime(). See if it is also off by an hour.


Hi Walter,

I tried a short test program:

   #include <time.h>
   #include <stdio.h>

   int main()
   {  time_t  t;
      time(&t);
      const char *s_time = ctime(&t);
      printf("time=%ld , ctime=%s\n", t, s_time);
      tm  loc_time = *localtime(&t);
      tm  gm_time  = *gmtime(&t);
      printf("loc_time = %s\n", asctime(&loc_time));
      printf("gm_time  = %s\n", asctime(&gm_time));
      printf("mktime(loc) = %ld\n", mktime(&loc_time));
      printf("mktime(gmt) = %ld\n", mktime(&gm_time));
      return 0;
   }

The result on my NT system is:

   time=979999687 , ctime=Sat Jan 20 15:08:07 2001

   loc_time = Sat Jan 20 15:08:07 2001

   gm_time  = Sat Jan 20 14:08:07 2001

   mktime(loc) = 979999687
   mktime(gmt) = 979996087

I've run this program on my Linux system and got the same behaviour 
there. So it seems that the actual implementation of time() is correct. 
Maybe the make problem comes from a use of gmtime() and localtime()?


	Heinz

Jan 20 2001

"Walter" <walter digitalmars.com> writes:

This is a mystery, since this is what MAKE does:

----------------------------------------------------------------------
time_t getsystemtime()
{   time_t t;

    time(&t);

    /* FAT systems get their file times rounded up to a 2 second
       boundary. So we round up system time to match.
     */
    return (t + 2) & ~1;
}

time_t gettimex(name)
char *name;
{   time_t datetime;
    time_t systemtime;

    struct stat st;

    if (stat(name,&st) == -1)
        return 1L;
    datetime = st.st_mtime;
    systemtime = getsystemtime();
    if (datetime > systemtime)
    {
        printf("File '%s' is newer than system time.\n",name);
        printf("File time = %ld, system time = %ld\n",datetime,systemtime);
        printf("File time = '%s'\n",ctime(&datetime));
        printf("Sys  time = '%s'\n",ctime(&systemtime));
    }
    return datetime;
}

Jan 21 2001

Heinz Saathoff <hsaat bre.ipnet.de> writes:

Walter schrieb...
 This is a mystery, since this is what MAKE does:
 
 ----------------------------------------------------------------------
 time_t getsystemtime()
 {   time_t t;
 
     time(&t);
 
     /* FAT systems get their file times rounded up to a 2 second
        boundary. So we round up system time to match.
      */
     return (t + 2) & ~1;
 }
 
 time_t gettimex(name)
 char *name;
 {   time_t datetime;
     time_t systemtime;
 
     struct stat st;
 
     if (stat(name,&st) == -1)
         return 1L;
     datetime = st.st_mtime;
     systemtime = getsystemtime();
     if (datetime > systemtime)
     {
         printf("File '%s' is newer than system time.\n",name);
         printf("File time = %ld, system time = %ld\n",datetime,systemtime);
         printf("File time = '%s'\n",ctime(&datetime));
         printf("Sys  time = '%s'\n",ctime(&systemtime));
     }
     return datetime;
 }


Tried this code with a small test environment. It works! Compiled it 
with sc -mn ftest.cpp and sc -mx ftest.cpp.
So could it be that make was compiled with an older library version 
which had a bug? 
Is it possible to recompile make and send be the recompiled version for 
test?


	Heinz

Jan 22 2001

"Walter" <walter digitalmars.com> writes:

There was one included in the DMC++ compiler update, and you can download
one from www.digitalmars.com. Before you overwrite the one you have, see if
it is the same or not. -Walter


Heinz Saathoff wrote in message ...
Walter schrieb...
 This is a mystery, since this is what MAKE does:

 ----------------------------------------------------------------------
 time_t getsystemtime()
 {   time_t t;

     time(&t);

     /* FAT systems get their file times rounded up to a 2 second
        boundary. So we round up system time to match.
      */
     return (t + 2) & ~1;
 }

 time_t gettimex(name)
 char *name;
 {   time_t datetime;
     time_t systemtime;

     struct stat st;

     if (stat(name,&st) == -1)
         return 1L;
     datetime = st.st_mtime;
     systemtime = getsystemtime();
     if (datetime > systemtime)
     {
         printf("File '%s' is newer than system time.\n",name);
         printf("File time = %ld, system time =




         printf("File time = '%s'\n",ctime(&datetime));
         printf("Sys  time = '%s'\n",ctime(&systemtime));
     }
     return datetime;
 }


Tried this code with a small test environment. It works! Compiled it
with sc -mn ftest.cpp and sc -mx ftest.cpp.
So could it be that make was compiled with an older library version
which had a bug?
Is it possible to recompile make and send be the recompiled version for
test?


 Heinz

Jan 22 2001

Heinz Saathoff <hsaat bre.ipnet.de> writes:

Walter wrote...
 There was one included in the DMC++ compiler update, and you can download
 one from www.digitalmars.com. Before you overwrite the one you have, see if
 it is the same or not. -Walter


Downloaded that version, works!

This is what Dir showed on the old make:
  D:\sc\bin\make.exe
  10.01.97   6:50          65.024  make.exe

For the new make Dir shows
  E:\USERS\hsaat\make.exe
  23.01.01  10:56          51.200  make.exe

The new make is also significantly smaller than the older one. It must 
have come with one of the last Symantec C++ 7.50 CD. All other updates 
have been on the compiler and not make I think.

What I found out is that the old version of make also runs on a pure 
DOS-system whereas the new one requires 32-bit windows. Maybe that has 
caused the problem?


	Heinz

Jan 24 2001

"Walter" <walter digitalmars.com> writes:

The old MAKE was a dual DOS/Win32 executable, in that an actual DOS MAKE was
linked in as the "stub executable". So there were essentially two different
programs merged into one file. (Doing that is a neat trick I discovered!)

The size dropped because I no longer included the old DOS MAKE as the stub
executable.

But in any case, with the old MAKE, it still should have run the Win32
native version on a Win32 system.

At least it is working for you now <g>.


Heinz Saathoff wrote in message ...
Walter wrote...
 There was one included in the DMC++ compiler update, and you can download
 one from www.digitalmars.com. Before you overwrite the one you have, see




 it is the same or not. -Walter


Downloaded that version, works!

This is what Dir showed on the old make:
  D:\sc\bin\make.exe
  10.01.97   6:50          65.024  make.exe

For the new make Dir shows
  E:\USERS\hsaat\make.exe
  23.01.01  10:56          51.200  make.exe

The new make is also significantly smaller than the older one. It must
have come with one of the last Symantec C++ 7.50 CD. All other updates
have been on the compiler and not make I think.

What I found out is that the old version of make also runs on a pure
DOS-system whereas the new one requires 32-bit windows. Maybe that has
caused the problem?


 Heinz

Jan 24 2001

Damian Dixon <damian.dixon tenetdefence.com> writes:

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

Jan 10 2001

Damian Dixon <damian.dixon tenetdefence.com> writes:

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

Jan 11 2001

Jan Knepper <jan smartsoft.cc> writes:

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

Jan 11 2001

"Walter" <walter digitalmars.com> writes:

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

Jan 11 2001

Jan Knepper <jan smartsoft.cc> writes:

Walter wrote:

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


Isn't it amazing!
I *never* reboot Unix (actually FreeBSD) on which I also do development by the
way. (Check the system status at http://www.digitaldaemon.com/)
But I agree, Windows NT or 2000 is a huge improvement over 95 or even 98. I
never changed to 95 or 98 since I was running NT before that. Never regret it
for one second...

Jan

Jan 11 2001

"Walter" <walter digitalmars.com> writes:

Jan Knepper wrote in message <3A5E83CA.1EEFD54B smartsoft.cc>...
Walter wrote:

 I've found it the most productive to develop under NT or 2000, and then




 it to 98/95. The reason is that the former is a much more robust




 environment (a lot fewer reboots needed).


Isn't it amazing!
I *never* reboot Unix (actually FreeBSD) on which I also do development by


way. (Check the system status at http://www.digitaldaemon.com/)
But I agree, Windows NT or 2000 is a huge improvement over 95 or even 98. I
never changed to 95 or 98 since I was running NT before that. Never regret


for one second...

Jan



I've had to reboot my linux box a few times, but the people in the linux
newsgroups called me a liar because linux *never* freezes up <g>.

Jan 11 2001

Jan Knepper <jan smartsoft.cc> writes:

Walter wrote:

 I've had to reboot my linux box a few times, but the people in the linux
 newsgroups called me a liar because linux *never* freezes up <g>.


<grin>
The truth is, as far as I know, that Linux is more on the bleeding edge of
technology than BSD. Drivers for new hardware are mostly implemented in Linux
first and than (quite) a bit later BSD follows.

I would not say that I would not know how to crash BSD, but it has been proven
that BSD is more stable, secure and has a more crash proof file system. BSD
seems to have the fastest TCP stack which is great with all the current DoS
attact that happen on the Internet these days.
I could show you some log files. You would be amazed how many port scans and
other things happen. One of the cutest is IP packages comming in via the
external interface that claim to come from 192.168.0.0/16, 172.16.0.0/12 or
10.0.0.0/8... These addresses are for private networks defined so by RFC 1918,
which means they legally NEVER can come from the Internet and thus never should
come in via the external interface of the system.

Jan

Jan 12 2001

"Walter" <walter digitalmars.com> writes:

I use a firewall implemented as a separate piece of hardware. So far, so
good. I also like it because the front panel lights blink on it - after all,
what's a computer without das blinkenlights? Now if they'd only make a
router with nixie tubes on it, I'm sold!

Jan Knepper wrote in message <3A5F3738.8FCE7687 smartsoft.cc>...
Walter wrote:

 I've had to reboot my linux box a few times, but the people in the linux
 newsgroups called me a liar because linux *never* freezes up <g>.


<grin>
The truth is, as far as I know, that Linux is more on the bleeding edge of
technology than BSD. Drivers for new hardware are mostly implemented in


first and than (quite) a bit later BSD follows.

I would not say that I would not know how to crash BSD, but it has been


that BSD is more stable, secure and has a more crash proof file system. BSD
seems to have the fastest TCP stack which is great with all the current DoS
attact that happen on the Internet these days.
I could show you some log files. You would be amazed how many port scans


other things happen. One of the cutest is IP packages comming in via the
external interface that claim to come from 192.168.0.0/16, 172.16.0.0/12 or
10.0.0.0/8... These addresses are for private networks defined so by RFC


which means they legally NEVER can come from the Internet and thus never


come in via the external interface of the system.

Jan

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

Walter wrote:

 I use a firewall implemented as a separate piece of hardware. So far, so
 good. I also like it because the front panel lights blink on it - after all,
 what's a computer without das blinkenlights? Now if they'd only make a
 router with nixie tubes on it, I'm sold!


I used to do that too!
I actually had a Ascend Pipeline 75 which I really liked during the time I was
connected via ISDN...

Currently I am connected via the Internet host machine (which has two network
interfaces) one goes to the internal network and one to the external network, in
other words, the Internet. Both interfaces are connected to 100-TX hubs which
connect to the Cisco Router in case of the external interface. Can tell you...
I've got a lot of "knipper-lichten"

Here comes the dumb question:
What is a Nixie Tube???

Jan 12 2001

"Walter" <walter digitalmars.com> writes:

Jan Knepper wrote in message <3A5F5B32.A06DFBFB smartsoft.cc>...
Here comes the dumb question:
What is a Nixie Tube???



A nixie tube is a vacuum tube with 10 elements in it, each of which is bent
into the shape of a single digit. By applying power to the right pin, the
corresponding digit would light up like an orange neon light. Nixie tubes
were used for digital numeric displays before LEDs were perfected. The first
digital desk calculator I saw used nixie tubes. You can still see them if
you look carefully on sci fi movies done before 1975 or so.

Back in 1977 or so I visited an electronic surplus store in Pasadena, and
they had some real live core memory modules for sale (with the toroidal
magnets carefully threaded through the wires, etc.). I wish I'd bought one,
it would make a great desk ornament today.

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

OK, I know what you are talking about now...
I actually liked those tubes too. From what you write I get the impression that
you like to keep certain things around.
I actually still have my first PC I ever bought. (Had to go to the bank to get a
loan). Because I moved to the USA that thing is still in the Netherlands, but it
is at a safe place with very good friends. It's amazing. I think it over 10
years old and still works!

Back in 1977 I was in elementary school, but you might have figured that from
reading my resume at janknepper.com. I first got into the computing stuff just
before the Commodore 64 and Sinclair ZX Spectrum became famous. At the time I
started with those when I was 16 I also was allowed to use a Philips P880 that
we had stowed in a special class room in school. This machine had 64 K RAM, but
the memory was "ring kern" (magnetic memory). To start it you had to manualy
punch in a boots trap...
For some time I even had a huge rack at home. My parent couldn't really
appreciate it because it was HUGE...



Walter wrote:

 Jan Knepper wrote in message <3A5F5B32.A06DFBFB smartsoft.cc>...
Here comes the dumb question:
What is a Nixie Tube???


 A nixie tube is a vacuum tube with 10 elements in it, each of which is bent
 into the shape of a single digit. By applying power to the right pin, the
 corresponding digit would light up like an orange neon light. Nixie tubes
 were used for digital numeric displays before LEDs were perfected. The first
 digital desk calculator I saw used nixie tubes. You can still see them if
 you look carefully on sci fi movies done before 1975 or so.

 Back in 1977 or so I visited an electronic surplus store in Pasadena, and
 they had some real live core memory modules for sale (with the toroidal
 magnets carefully threaded through the wires, etc.). I wish I'd bought one,
 it would make a great desk ornament today.

Jan 12 2001

"Walter" <walter digitalmars.com> writes:

My first computer was a Heathkit H11. It's gone now, I gave it away. The
second one I bought was an IBM PC type 2, which is in the garage moldering
away. Last time I checked it the hard disk was kaput, but it would still
come up in rom basic. I got rid of my dad's trash-80 too, though I regret
that now. It will be a fine collector's item!

That old IBM PC still has the zortech BBS software on its disk <g>. It was a
good old workhorse, it would run that BBS for literally six months at a
stretch without requiring a reboot.

This newsgroup is a lot better than the BBS!

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

Walter wrote:

 My first computer was a Heathkit H11. It's gone now, I gave it away. The
 second one I bought was an IBM PC type 2, which is in the garage moldering
 away. Last time I checked it the hard disk was kaput, but it would still
 come up in rom basic. I got rid of my dad's trash-80 too, though I regret
 that now. It will be a fine collector's item!


The first computer I bought was a 386... 16 Mhz zero wait state... 640 Kb Base
and 1 Mb Ext, 40 MB HD...
I replaced the mother board with a 486, 25Mhz (one of the first that was
available in the Netherlands) and 8 Mb RAM...
Replaced the HD with 100 MB SCSI, than 340 MB SCSI and finally 1 GB SCSI which
is still in there and running.

The machine has run at lot, from different version of DOS, Windows, SCO Xenix,
SCO Unix, Interactive Unix, OS/2, CMOS, QNX to FreeBSD and Windows NT...

 That old IBM PC still has the zortech BBS software on its disk <g>. It was a
 good old workhorse, it would run that BBS for literally six months at a
 stretch without requiring a reboot.


Cool!
I used to write production data registration systems that run on DOS+Novell.
They used to do that. i.e. Run for 6 or more months without a reboot.
I really wonder why it is so hard for NT or 2000...

 This newsgroup is a lot better than the BBS!


Thanks!
It's was first time I setup a newsgroup... Only took a couple of hours. The most
difficult thing was finding the right port from the collection...

It's kinda different though...
Connection is 24/7. Speed is incomparable.
Machine it runs on is a PIII with enough memory and disk space.

Jan 12 2001

"Edward F. Sowell" <sowelled home.com> writes:

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

"Edward F. Sowell" <sowelled home.com> writes:




Well, I can't get Damian's mods to my test code to compile, even though it
comiples for him.
I have set an include path to STLPort. If I try to use the DMC 8 download
it tells me that the compiler version is not registered (or to that effect).
I have reverted
back to earlier compilers, back to 7.6, getting failures in internal .h
files, like rel_ops,
saying "function expected."

Damian, what compiler version are you using?

Jan, since Damian has probably retired for the weekend, do you have any
ideas?

Ed Sowell

Jan 12 2001

Jan Knepper <jan smartsoft.cc> writes:

Did you get the standard STLport or did you get the new .tar.gz file which
should include all the latest modification Damian made?

When you use that version you should be able to use compiler version 8.0

Jan



"Edward F. Sowell" wrote:



 Well, I can't get Damian's mods to my test code to compile, even though it
 comiples for him.
 I have set an include path to STLPort. If I try to use the DMC 8 download
 it tells me that the compiler version is not registered (or to that effect).
 I have reverted
 back to earlier compilers, back to 7.6, getting failures in internal .h
 files, like rel_ops,
 saying "function expected."

 Damian, what compiler version are you using?

 Jan, since Damian has probably retired for the weekend, do you have any
 ideas?

 Ed Sowell

Jan 12 2001

"Damian Dixon" <damian.dixon virgin.net> writes:

Jan Knepper <jan smartsoft.cc> wrote in message
news:3A5F8B66.7DE4F9F smartsoft.cc...
 Did you get the standard STLport or did you get the new .tar.gz file which
 should include all the latest modification Damian made?

 When you use that version you should be able to use compiler version 8.0


Let us know how you get on.

Regards
Damian (from home)
 Jan



 "Edward F. Sowell" wrote:



 Well, I can't get Damian's mods to my test code to compile, even though




 comiples for him.
 I have set an include path to STLPort. If I try to use the DMC 8




 it tells me that the compiler version is not registered (or to that




 I have reverted
 back to earlier compilers, back to 7.6, getting failures in internal .h
 files, like rel_ops,
 saying "function expected."

 Damian, what compiler version are you using?

 Jan, since Damian has probably retired for the weekend, do you have any
 ideas?

 Ed Sowell

Jan 13 2001

"Damian Dixon" <damian.dixon virgin.net> writes:

Edward F. Sowell <sowelled home.com> wrote in message
news:3A5F81E5.89E2A1C4 home.com...


 Well, I can't get Damian's mods to my test code to compile, even though it
 comiples for him.
 I have set an include path to STLPort. If I try to use the DMC 8 download
 it tells me that the compiler version is not registered (or to that


 I have reverted
 back to earlier compilers, back to 7.6, getting failures in internal .h
 files, like rel_ops,
 saying "function expected."

 Damian, what compiler version are you using?


Version 8.0 of the compiler. Not quite the latest one. I've downloaded it
but not yet installed it (time is a problem).

If you want I can send the complete project on Monday.

Regards
Damian (from home)
 Jan, since Damian has probably retired for the weekend, do you have any
 ideas?

 Ed Sowell

Jan 13 2001

"Edward F. Sowell" <sowelled home.com> writes:

Hi Damian,

Thanks for your weekend work!

I grabbed  8.0 and the tar of STLport. I have installed 8.0, but not
the STLport yet because I am a bit confused about where to put it.
In one of the installation notes it says NOT to overwrite existing compiler
headers. In the STLPort non-tar version, the included paths show
things in  STLPort, presumably a subdirectory of  \sc. So when I installed
it, I just extracted the whole zip file into my compiler dir, called DMC++,.
However, the tar version seems to put them into \sc\stl\stlport. Before messing
up
my compiler dir, I thought I'd ask for more specific instructions on where to
put things.

Ed


 Version 8.0 of the compiler. Not quite the latest one. I've downloaded it
 but not yet installed it (time is a problem).

 If you want I can send the complete project on Monday.

 Regards
 Damian (from home)

Jan 13 2001

Damian Dixon <damian.dixon tenetdefence.com> writes:

Content-Type: text/plain; charset="us-ascii"

On Sat, 13 Jan 2001 11:23:05 -0800, "Edward F. Sowell" <sowelled home.com>
wrote:
 Hi Damian,
 
 Thanks for your weekend work!
 
 I grabbed  8.0 and the tar of STLport. I have installed 8.0, but not
 the STLport yet because I am a bit confused about where to put it.
 In one of the installation notes it says NOT to overwrite existing compiler
 headers. In the STLPort non-tar version, the included paths show
 things in  STLPort, presumably a subdirectory of  \sc. So when I installed
 it, I just extracted the whole zip file into my compiler dir, called DMC++,.
 However, the tar version seems to put them into \sc\stl\stlport. Before messing
 up
 my compiler dir, I thought I'd ask for more specific instructions on where to
 put things.
 
 Ed
 



I've actually stored STLport in the following place:
 
  M:\cvs\dmc\STL\port

primarily because I am using CVS.

Essentailly you can put it anywhere you want, except over writing the includes
that
came with the original Symantec compiler.

Before Jan made CVS available for development I used to store STLport in

  D:\SC\STLport  (where I have installed my Symantec compiler)

I have attached the project (without the .BRO, hopefully this is not required)
file.

Note that I have had to use the compiler flag '-Ab' to enable bool keyword. If
you
have problems check the file:

  port\stlport\config\stl_digital_mars.h

and uncomment '__STL_NO_BOOL' and remove '-Ab' from the compiler settings.

I think I need to update by readme file or at least check it.

Regards,
Damian


 
 Version 8.0 of the compiler. Not quite the latest one. I've downloaded it
 but not yet installed it (time is a problem).

 If you want I can send the complete project on Monday.

 Regards
 Damian (from home)

Jan 15 2001

D Programming

C/C++ Programming

Other

c++ - <iterator>