bill@amber.ssd.csd.harris.com (Bill Leonard) wrote:

>> The real goal, of course, is to attain something intermediate between a
>> real standard (which takes considerable time and effort), and just
>> random extensions.
>
>Is that really the goal?  Non-standard extensions cause lots of problems
>for both users and vendors.  Users get mad when they find out they depend
>on an extension that isn't universally provided.  Vendors get upset because
>users blame them for lulling them into using the extensions in the first
>place.
>
>If you want portability, you want strict standard conformance, period.

The problem is not nearly so severe with class libraries as it is with
language extensions, since (especially with namespaces) a non-standard
class library can be used indefinitely, even if superceded by a standard
class library. I imagine that a large part of this almost-standard
repository will be libraries.

My first nominees for such a repository are:

1. auto_array_ptr<>
2. conversion_cast<> (a.k.a. implicit_cast<>)
3. hash_set<>, hash_multiset<>, hash_map<> & hash_multimap<>

I can personally contribute function adaptors that work with pointers:
dereference_arg(), dereference_1st(), dereference_2nd(),
dereference_both().
-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <rf5680ima12.fsf@vx.cit.alcatel.fr>, James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
> Ted Clancy <s341282@student.uq.edu.au> writes:
>
> |>  James Kanze wrote:
> |>  > late" was a lot earlier.)  I would like to propose that we establish
> |>  > some sort of "almost-standard" somewhere, so that implementors who wish
> |>  > to add such extensions will do so in a compatible manner.  This also has
> |>  > the advantage that in the next round, we will have existing practice.
>
> I don't think it subverts the standardization committee.  I think it
> would be more of a resource.

This can be a two-edged sword.  For example: Early in the standardization
of Fortran 90 (when it was still called Fortran 8x :-), the standards
committee had a proposal all worked out for adding structured types to
Fortran.  DEC decided to implement that "almost standard" in their Fortran
compiler.  DEC machines and DEC Fortran was so popular, many other Fortran
vendors also implemented it.

Unfortunately, the standards committee eventually decided to reject the
syntax and semantics in that proposal and implement a completely different
structured types mechanism!  Consequently, many vendors and users were
stuck with a non-standard extension that was very difficult to reconcile
with the eventual standard.  This caused both vendors and users lots of
headaches.

I think the C++ vendors have generally been great about implementing
features in the developing standard, and I'm sure it has helped the
standards committee a lot.  However, in most cases the vendors have been
reasonably sure that the standardization of those features was relatively
close at hand, and the features have already had lots of work by the
committee before implementation.  Even so, there have been some significant
changes required that made for problems for the users.

> The real goal, of course, is to attain something intermediate between a
> real standard (which takes considerable time and effort), and just
> random extensions.

Is that really the goal?  Non-standard extensions cause lots of problems
for both users and vendors.  Users get mad when they find out they depend
on an extension that isn't universally provided.  Vendors get upset because
users blame them for lulling them into using the extensions in the first
place.

If you want portability, you want strict standard conformance, period.

--
Bill Leonard
Concurrent Computer Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.ccur.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Concurrent Computer Corporation.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

bill@amber.ssd.csd.harris.com (Bill Leonard) writes:

|>  In article <rf5680ima12.fsf@vx.cit.alcatel.fr>, James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
|>  > Ted Clancy <s341282@student.uq.edu.au> writes:
|>  >
|>  > |>  James Kanze wrote:
|>  > |>  > late" was a lot earlier.)  I would like to propose that we establish
|>  > |>  > some sort of "almost-standard" somewhere, so that implementors who wish
|>  > |>  > to add such extensions will do so in a compatible manner.  This also has
|>  > |>  > the advantage that in the next round, we will have existing practice.
|>  >
|>  > I don't think it subverts the standardization committee.  I think it
|>  > would be more of a resource.
|>
|>  This can be a two-edged sword.  For example: Early in the standardization
|>  of Fortran 90 (when it was still called Fortran 8x :-), the standards
|>  committee had a proposal all worked out for adding structured types to
|>  Fortran.  DEC decided to implement that "almost standard" in their Fortran
|>  compiler.  DEC machines and DEC Fortran was so popular, many other Fortran
|>  vendors also implemented it.

|>  Unfortunately, the standards committee eventually decided to reject the
|>  syntax and semantics in that proposal and implement a completely different
|>  structured types mechanism!  Consequently, many vendors and users were
|>  stuck with a non-standard extension that was very difficult to reconcile
|>  with the eventual standard.  This caused both vendors and users lots of
|>  headaches.

I'm aware of the risk.  Like most things, it isn't a perfect solution,
and has some drawbacks.

The problem is, that C++ is (still) a growing language.  In order to get
a standard anytime soon, the committee had to set a cut-off, and declare
"no more extensions".  There are, however, extensions which, except for
this, the committee would have certainly considered.  (The STL hash
tables, and the Detleff/Ellis garbage collection come to mind.)  The
idea is to "prepare" these proposals for the next round; particularly,
to give them some sort of "existing practice".

Of course, to be useful, such a site couldn't just accept anything
someone wanted to add.  It would have to be a full and detailed
proposal, well thought out.  (Again, I think that both the Detleff/Ellis
proposal and the STL hash tables fill this condition.  There are, at
present, very few others.)  I'm not sure what sort of critera should be
applied for acceptance, other than this.

|>  I think the C++ vendors have generally been great about implementing
|>  features in the developing standard, and I'm sure it has helped the
|>  standards committee a lot.  However, in most cases the vendors have been
|>  reasonably sure that the standardization of those features was relatively
|>  close at hand, and the features have already had lots of work by the
|>  committee before implementation.  Even so, there have been some significant
|>  changes required that made for problems for the users.

My vendors have been very conservative in this respect.  Which
corresponds to what I want and need.  I have heard, however, that some
other vendors have had problems.  (I think, for example, that Borland
provided a "standard" string class which is incompatible with the
version finally adopted, although it was exactly the draft version at
some pointer.)

|>  > The real goal, of course, is to attain something intermediate between a
|>  > real standard (which takes considerable time and effort), and just
|>  > random extensions.
|>
|>  Is that really the goal?  Non-standard extensions cause lots of problems
|>  for both users and vendors.  Users get mad when they find out they depend
|>  on an extension that isn't universally provided.  Vendors get upset because
|>  users blame them for lulling them into using the extensions in the first
|>  place.

I think that there is one point here worth stressing: the default
behavior of any compiler should be strict standard compliance, period.
Anything else is doing the user a disservice.

On the other hand, I have nothing against extensions if they are
documented as such, and require a special option in the command line of
the compiler to invoke.  In fact, I've never used a compiler which
didn't have them.

|>  If you want portability, you want strict standard conformance, period.

It depends on the degree of portability.  In about 95% of my work, for
example, I can count on the POSIX standard as well as C++.  One of my
customers has made ILOG Views standard for window management.  This has
a definite portability cost; they can only use systems to which ILOG has
ported.  On the other hand, developing something similar themselves,
using strictly portable C++, would have cost at least a magnitude more,
and probably delayed the project to the point that it wouldn't have been
viable.  (In fact, portability is probably enhanced, since there is no
portable way to manage windows in C++.  By using ILOG Views, however,
this is ILOG's problem, and not my customer's.)

To return to the main point: my goal would be that such a depository
would be an additional pseudo-standard.  Not as standard as, say, POSIX,
but hopefully more than ILOG Views.  Each application would judge for
itself the pros and cons of using such a standard, much as they do
today.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze wrote:
>
> I'm not sure that it should be in a namespace.  I think, for example,
> that in the standard library, operator new and operator delete are not
> in namespace std; null should behave the same way.

Yeah, I think so too. I originally wanted this "null" to act like a new
pointer literal, like the new boolean "true" and "false" literals. I
only suggested namespace std because I had a feeling people would find
it less threatening there. The global namespace seems already polluted
with nils and nulls, and namespaces seem to be trendy right now ;-).

Just to be clear, we seem, after much discussion, to be looking at:

//null.h
const class {
public:
    template<class T> inline operator T*()const {return 0;}
    template<class C, class T> inline operator C::T*()const {return 0;}
private:
    void operator &()const;
} null;

with the only apprehensions being that some compilers don't give
sensible diagnostics for objects of anonymous classes (a compiler
problem IMO, and the current NULL doesn't have its own type either), and
that some compilers won't warn against passing a non-POD to a varargs
function (a trivial and ridiculous compiler problem IMO, and no worse
than the current NULL situation. Note that a private copy constructor
_won't_ help in the varargs case).

Is that right? or do we prefer
const class NullPointer{
public:
    template<class T> inline operator T*()const {return 0;}
    template<class C, class T> inline operator C::T*()const {return 0;}
private:
    NullPointer() {};
    NullPointer(const NullPointer &);
    void operator &()const;
    static const NullPointer null_pointer;
} NullPointer::null_pointer, &null=NullPointer::null_pointer;

>>[...]

> I think that we have a good solution.  I regret that this idea didn't
> come up earlier.  It is, however, far too late to consider an addition
> to the current standard.
>
> I can think of a couple of other "extensions" (garbage collection, hash
> tables) which were proposed too late for the current standard.  (In both
> cases, the relative complexity, compared to null, was such that "too
> late" was a lot earlier.)  I would like to propose that we establish
> some sort of "almost-standard" somewhere, so that implementors who wish
> to add such extensions will do so in a compatible manner.  This also has
> the advantage that in the next round, we will have existing practice.
>
>[...]

Hmmm... interesting idea. It somewhat subverts the proceedures of the
standardisation committees unfortunately, or on the other hand, the
standardisation committees could use it as a resource.

This newsgroup and its homepage would seem like the ideal place to
coordinate such an archive. I pity the moderator however :-). How many
newsgroup contributors/lurkers would be in favour of that? Would we need
a RFD and CFV?

> --
> James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
>                  office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
> GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
>             -- Conseils en informatique industrielle --
> ---

--
Ted Clancy
s341282@student.uq.edu.au
B Engineering, University of Queensland.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Ted Clancy <s341282@student.uq.edu.au> writes:

|>  James Kanze wrote:
|>  > I can think of a couple of other "extensions" (garbage collection, hash
|>  > tables) which were proposed too late for the current standard.  (In both
|>  > cases, the relative complexity, compared to null, was such that "too
|>  > late" was a lot earlier.)  I would like to propose that we establish
|>  > some sort of "almost-standard" somewhere, so that implementors who wish
|>  > to add such extensions will do so in a compatible manner.  This also has
|>  > the advantage that in the next round, we will have existing practice.
|>  >
|>  >[...]
|>
|>  Hmmm... interesting idea. It somewhat subverts the proceedures of the
|>  standardisation committees unfortunately, or on the other hand, the
|>  standardisation committees could use it as a resource.

I don't think it subverts the standardization committee.  I think it
would be more of a resource.

The real goal, of course, is to attain something intermediate between a
real standard (which takes considerable time and effort), and just
random extensions.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]