I am writing this sitting in a room at the Danish Standards in
Copenhagen listening to an evening presentation by Bjarne Stroustrup
launching his view of the next stage in the ongoing development of C++.
We have had a number of years (three or more) of stability with an ISO
Standard for C++ and failure to consider change will tend to move from
stability (good for many reasons) to stagnation (put your own spin on
that)

BS has just suggested that we should focus on a few major topics while
considering minor changes that will increase language and standard
library consistency.

He is floating the idea that the overall goals should include making C++
a better language for systems programming and library building. A second
major goal should be to make it easier to teach and learn (aside from me
-- we would still have the problem of getting those teaching to actually
know what they are doing)

Directions:

Minimise incompatibilities with C++98 but we should face reality and
accept that some changes will break exiting code (like the move form C
to C++)

Keep the zero overhead principle
Maintain or increase type safety

Avoid major extensions to the language
make rules more general and uniform
improve support for low level embedded programming (note BS explicitly
does not want to see C++ become an exclusively high level language)

Increase library support for platform independence
support distributed programming (actually, programming for distributed
systems)

He says that if we are ambitious in library development (something he is
advocating) we need to accept that some developments will not be
supportable on all platforms.

At this stage he is beginning to explore specific ideas for library
development. I will leave the specifics for later contributors to add.
The intention of this posting is to alert the serious C++ community to
the fact that the C++ standards committees are now willing to listen
(after a long day of working on defects in the current standard) to the
originator of C++ make suggestions for ways in which we might move
forward. You should not get the idea that we are about to launch a
basket of changes and destabilise what we have. What we are sitting on
is a watershed when we move from purely correcting and clarifying what
we have already done to considering how we might make the good even
better.

I am sure that BS's current presentation will be heard and refined many
times over the next few years. If you are responsible for organising
meetings, conferences or write for journals and magazines take the
opportunity to invite BS to contribute his vision of the future of C++.
But remember that this should be a shared vision. The readers of this
posting (here and copied to clc++m) are those that should be adding
clarity to the vision. We each have our own pet ideas, but we should
listen as well as talk. Change should come from a consensus of the C++
programming community in the large rather than just that of the
Standards Committees. That consensus requires an investment of time, any
time you find yourself muttering 'someone ought to do something about
that' remember that you are someone.

This writer can see a danger in some enthusiasts being so determined to
get their pet item into C++0x that they will be blind to the larger
picture.

I think that is enough for now apart from drawing your attention to the
fact that you read this here first and it was ACCU that brought it to
you attention.

Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

So, what do we want?

Let's start a list:

1. typeof()

2. using Base;
   Example:

     class Derived : private Base {
       public:
       using Base;  // expose the entire public interface of Base.
       // ...
     };

3. explicit operator.
   Example:

     class My_class {
       public:
       // ...
       // allow int(My_class()), but not int i = My_class();
       explicit operator int();  
     };

4. Zero sized objects.
   This would require lengthof() because the standard idiom would break:

      #define lengthof(x) (sizeof(x)/sizeof((x)[0]))

   On the other hand, who puts zero sized objects in an array?

5. Require the "empty base class optimization".

6. Abolish trigraphs,
   or at least depreciate trigraphs.

What else?

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  
http://table.jps.net/~vert/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

For the love of humanity, define the value of a "default" constructed builtin!

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Compilers are free to do so, if you choose the overhead.  Right
now they/you have the choice between safety and efficiency.  If
the Standard mandates safety, efficiency will be impossible.

-- James Dennett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

This is really clunky.   "using" brings names forward which have no
bearing on access control.  I'm at a loss as to what this does that
just inheriting Base publically doesn't.

Ugh...why not just add an explicit method.

I think it would break far more than ad-hoc size macros.  Why do you need
zero sized objects.

Why?

Why?  (and the word is deprecate).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <AcrV7JAEbv76E...@ntlworld.com>, Francis Glassborow

Amiss (even though mentioned below) in this general picture is support for
distributed programming.

Also amiss is support for dynamic programming, like support for the hooks
that enables the efficient implementation of a conservative GC (like a way
to get access to the root system.

One will need some such additions in order to be able to build good libraries.

As for the teaching aspect, I think this must be always secondary to the
aspect of C++ as a language designed to get things done. To me, it is OK
that C++ is a behemoth and an encyclopaedia one never bother learning in
its completeness: When one needs a feature.

If I should compare with Haskell, the standardization into a language
Haskell 98 which will never change was in itself enough for providing the
educational aspect.

One should warn against that looking too much on this educational aspect
one complicate the language: For example, the class std::list did not get
operator plus, because it was felt that less experienced programmers one
use that. Real programmers should use a profiler to determine what and how
to optimize. So in this case, the educational aspect made the language
more complicated and less based on general principles, the latter which
C++ is in the need of more.

In this support for distributed programming, there is hidden a C/C++
principle that one must depart from, namely that they are written so that
one from compiler to compiler never can specify the underlying binary
model: Even a byte, even though nowadays always a standard 8 bit, one
cannot rely on.

This problem shows up in other contexts: For example, if one tries to a
functional language style boxed/unboxed elements, that is screwed up by
the fact that when deriving one can never get ensurance where on the
object the class pointer is. Therefore, in principle, self-mutation of
unboxed elements into another type in the same memory location may screw
up.

The support for low level embedded programming is good: I expect embedded
programmers to be transformed into what is now regular C++ programmers as
the computers become more powerful. When this discussed in the C++
newsgroups, there was this joke about the bread machine with its own
WWW-site. But there is a fact that there is a standard to connect
household appliances to the Internet via the electrical cord. And if
memory doubles every year, then a bread machine that a few years had 50 kB
in its memory 10 years later will have 50 MB, and yet ten years later 50
GB, at which point it will be cheaper to let it have its own WWW site than
building a electro-mechanical interface on it.

Also, I think there is a connection between dynamic programming and low
level programming: In order to take an easy example, if one wants to build
a multi-precision number library, one needs to do a lot of low level
optimizations. As matters now stand, such things must be implemented
platform to platform in assembler. The implementation of functional
languages really need such low level optimizations in order to be
competitive with more static languages.

The more static C++ programmers of today will surely gradually become more
dynamic programmers when computers become more powerful, as dynamic
programming is requires less programming time. So for that reason, it will
be important to start to incorporate such features at this point in time.

So it would be great if such things could be done more directly in C++.
Perhaps ideas form a language like C-- should be integrated into C++.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.hab...@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I'm not even sure, if what you would get is safety. If you've
forgotten to initialize variables, why would zero be the _safe_
choice?

Most often I became aware of failure to set variables, in release
builds, when the compiler had omitted zero-initialization, and all
my programme's output was rubbish. Unfortunally there is a difference
between plausibility and correctness.

Just my 2 cents.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Thanks for bringing this up; you've touched on some excellent points. I'm
impressed with Bjarne's recent efforts.

A few preliminary thoughts...

First, we need to look at the current standard and refine it, *before*
adding new features. Certainly we need to address all defect reports -- but
we also need to consider inconsistencies. My recent topic about openmode is
an example: It should be possible to interrogate the state of that property
for a stream. Is that a defect? Probably not. Is such a feature simple and
useful, leading to more reliable code? Yes.

Second: The more hands we get into the process, the more difficult it will
be to find a consensus. I know, I've been part of standards processes
before... everyone has a pet feature they'd love to have in the language,
and we don't want to lose focus. C++ should *not* try to be everything to
everyone; that's Java's job :-). Instead of adding anything and everything
to the language, I'd rather see a few new, well-conceived features. I want
concurrency, for example -- but if we can't find a clean, logical way to
include it in C++, I'll live without it.

Third: I strongly urge that we move beyond a poorly-formatted rigid document
to a hyperlinked, well-formatted, easy-to-read publication. Contrast the C++
Standard with W3C documents, and you'll see what I mean. A lot of confusion
and frustration could be solved simply by organizing and formatting the
document better.

Fourth: While I understand how standards committees work, most programmers
don't. The Standards process would do well to use the web actively in
keeping the community well-informed as to its activities. If we're going to
ask people to participate, they need to feel included, even if they can't
afford to travel. That is the strength of the Internet -- bringing people
together. Let's do it.

As for *my* personal laundry list of goodies -- give me a day or two here...
:-)

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order & Chaos
http://www.coyotegulch.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

It doesn't make the program correct (unless 0 really was the right value), it makes the resulting disaster easier to reproduce.  That, in turn, makes the error easier to find.

I can't count the hours I've spent tracking down uninitialized variable bugs (sometimes even my own) of one form or another.

As for the choice between efficiency and safety, you could add syntax to say "don't initialize."

int a = uninitialized;

or

uninitialized int a;

So it's really a choice between adding syntax and unreproducible bugs.

The way it sits many of us are paying for a feature (efficiency) that we don't use.  

I bet instructors would like to get rid of the whole topic too, for that matter.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Safe as in reproducible, at least.  I'm not an advocate
of making this change globally, but I can understand those
who want something like it.

You can have 2 of mine to go with them.  I don't want to
globally mandate that

{
  int i;
  // ...

has the run-time overhead of initializing i.

-- James Dennett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

 >

[...good suggestions edited for brevity...]

Finally: I understand that some think that everyone everywhere should
always, without exception (pun intended), use "resource acquisition is
initialization". Personally, however, I like the fact that C++ is a
multiparadigm language, and there are times when I'd find a finally
block extremely useful.

How about being able to place some restrictions on a class that are
enforced by the compiler. Non-derivable classes. Classes that can't be
placed on the stack/heap. Etc. Sure, there are some idioms that allow
some of these things to be done within the existing language, but they
are often verbose, inelegant, or both. (I want to say what I mean,
rather than say something that coincidentally has the side effect of
what I mean.)

How about a way to say that all of a class's member functions (and all
of its subclasses' member functions) should be virtual by default.

How about a (good, simple, portable, safe, efficient) way to tell
whether an object was allocated with new and can be safely deleted? (In
other words, not one of the kludges that have been created using the
existing language.) Imagine objects that can actually tell whether it is
safe to delete themselves or not. This might be the one thing I'd most
like to see.

(Also, a way to tell whether you should use delete or delete[] might be
useful. How about a way to find the size of an array allocated by new[].
Presumably the runtime has to keep track of such information anyway so
that delete[] works properly.)

The honorable Mr. Stroustrup has mentioned eliminating the default copy
constructor and assignment operator for classes with destructors and
making base classes with virtual member functions have a virtual
destructor by default. These will be very welcome changes.

Any remaining fix necessary to ensure that smart pointers can be
completely safe needs to be made. (I know there used to be some issues
about this.)

I'd ask anyone who has implemented an automatic garbage collector for
C++ what could be done to make C++ more garbage collector friendly.
(Last I looked into it, there was an issue or two.) Even better, ensure
that the major automatic garbage collection techniques can be
implemented in pure, portable C++. (Of course, such garbage collectors
would only be expected to collect C++ objects.)

Am I the only one that hates the standard library? The blatant, violent
abuse of operator overloading by the I/O streams has kept me from EVER
using them. I respect and admire the STL classes, but I hate using them
for reasons I haven't quite completely identified yet. Sure, it's too
late to make any radical changes, but I'd sure like to see an
"alternative standard library".

I also applaud Mr. Stroustrup's thoughts that the standard library
should address such common modern issues as concurrency. (And any holes
in the language that might make addressing such issues difficult.)

--
Robert FISHER
rfis...@my-deja.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

What compiler are you using?
Have you turned on all of the warnings?

For this program:
===================
int main()
{
  int i;
  return i;

=================
MSVC++ 6.0 says:
  test.cpp(4) : warning C4700: local variable 'i' used without having
  been initialized

and gcc version 2.95.3 20010315/djgpp (release) says:
  test.cpp:3: warning: `int i' might be used uninitialized in this
  function

If you are using a compiler that cannot produce a warning for this,
I think you should change to a better compiler.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  
http://table.jps.net/~vert/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I agree with that.

I spent several hours a couple of weeks ago tracking down an
uninitialized pointer bug in some third-party code.  A waste
of time, but it probably would have been no easier (maybe
even less easy) if the pointer value was 0 rather than garbage.

That's a "quiet change" though, in the sense that

int a;

changes meaning to become less efficient, and so billions of
lines of existing code become less efficient.

I'd prefer something like a Standard pragma (though historically
pragmas have been a pain) such as

#pragram STDC++ always-initialize

And many of us don't want to pay for a feature (possibly more
easily reproducible bugs) that we don't use at the expense of
code which runs more slowly.

That may well be true.

-- James Dennett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

news:3AEF1353.87673842@jps.net...

For what benefit? I could imagine that disadvantages of it breaking code
outweighs any benefits.

Currently, I cannot find examples where "optimisations" are a requirement of
the standard. Another example might be the requirement for return value copy
constructor optimisations. I don't think the standard should set a precedent
for compiler vendors to meet "optimisations" however desireable they are.

Stephen Howe

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

My favorites, but unlikely to be implemented:

1.  Make arrays real types.
2.  Prohibit freebie const lossage on string literals.
3.  Initialize POD's consistantly.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Could you elaborate how exactly you think that zero-sized objects should
be implemented? In particular, what layout would an array of zero-sized
objects have, and how would pointers to zero-sized objects behave?

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

news:3AEF1353.87673842@jps.net...

- typeof

- some multithreading support (more order of evaluation garanties)

- final (disabling farther overriding of a virtual function)

- sized (int8 etc) or templated std::int<128> integers

- did I mention 'typeof'?

Radoslav Getov

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

No. An explicit method has a name like asXyz, toXyt, convertToXyZ,
conv2Xyz, as_xyz, to_xyz, convert_xyz and whatever comes to peoples
crazy minds. When working with templates, this is completely useless.
Also, asString() could return std::string, char*, RWCString or whatever
people think is *their* standard. We need explicit operators to allow
templates to use these functions. OTOH you cannot use cast-operators
without explicit because it's far too dangerous for most cases.

While we are at it, this could be used for other parameters too: void
hello( explicit const std::string& s ) could means: Don't convert
anything to string by creating a temporary object to call this function.
explicit for an operator is just like the explicit here but for '*this'.
Hope you get the idea, I'm not very good in expressing myself clearly in
english :)

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.f...@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

[...]

What are you looking for?
That is, how will you recognize it when you see it?
Is it just that the STL is too large?

The STL definitely has some warts.
Like, why does vector have all of:
size(), resize(), reserve(), and capacity()?

we could instead have:
  size_t size();
  void size( size_t);
  size_t capacity();
  void capacity( size_t);

And, to me, this would be easier to explain, learn, and remember.

But, I am not sure that it is worth changing at this stage.
But, then again, maybe it is.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  
http://table.jps.net/~vert/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <zXTH6.143994$fs3.22936...@typhoon.tampabay.rr.com>, "Scott

This is also one thing that I think should be named in the general
picture: Concurrency support, not only for locks, but also for atomic
code.

But perhaps, if one adds support for distributed programming, concurrency
support must be a part of that.

Actually, when I bought my copy I suggested the ANSI people just that. I
g´figure that this has something to do with the obsolete software used by
the ISO/ANSI staff, because hyperlinks ought to be automatic with the
right kind of authoring software.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.hab...@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

news:3AEF68FD.D09C520A@acm.org...

Efficiency is not always the enemy of safety. Imagine C++ had a keyword
'uninitialized' that you could use like so:

void Fun()
{
    int i = uninitialized;
    int j; // initialized with zero
    ...

There are multiple advantages to this approach - defaults to safe, and
allows you to optimize when you need.

Andrei

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Only if it is REQUIRED to be impelemented is this useful.  If it's
optional, the feature suddenly becomes VERY VERY DANGEROUS.   I suggest
that if we're going to have compile standardized compile controls that
they NOT be called PRAGMA.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

\
Because this is a trivial instantiation of the problem.

How about

        int* i = new i;

and

        struct x {
                int i;
        };

The compiler will warn you of neither of these, typically.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

What I don't understand is why it takes 6 years to make a change to a
programming language!! I am new to C++ so I don't want to open my mouth too
much, but as far as I know its been 3 years since the language settled, and
it looks like it will take 3 more to make changes. Then after the changes
had been decide on, we have to wait another year for the compiler people to
do their part and make it stable. In the mean time there are other
programming languages being created that are very innovating.

I don't mean to piss anybody off with this email; I just find it frustrating
to see technology advancing so fast and C++ just crawling.

Thank you.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Wed,  2 May 2001 20:25:33 GMT, Daniel Frey <daniel.f...@aixigo.de>
wrote:

Writing templates is no problem.  Note that the standard library did
not write an explicit cast in copy to allow conversions.  It wrote
transform to accept a named conversion.

Can you give a concrete example to support your claim?

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]