I suppose that out of the thousands of template types, these
are a distinct minority.  However, since I have to deal
regularly with the world outside of C/C++, I keep finding
the need to do things like the following:

1.  Represent IBM's decimal data formats.
2.  Represent various forms of fixed and variable string
  variables that do not follow the C format.  For instance,
  Turbo Pascal string variables (char length plus fixed data)
  and PL/I style fixed strings where the right thing to do is
  print everything, including all the nulls, if any.

There are probably other similar examples; maybe FORTRAN style
arrays?

The list might not be all that long, compared to some of the
more obvious template cases, but while the list may be short,
it also may represent a significant opportunity to extend C++
into other environments and so its needs ought not to be
summarily dismissed.

There's still a lot of data out there
that doesn't follow C/C++ conventions and it is sometimes nice
to process it in-place, with a simple cin.read or cin.getline
of the constituent parts and return the result in the "other"
data format.  It's even nicer to add to the usual suspects
and so be able to (e.g.) intermix integer and decimal
expressions, intermix the above strings and the usual String
C++ object, etc.  But, the key is the parent data types
are real data entities that are defined by either
operating systems or computer languages that don't follow
the C/C++ assumptions about how certain data aggregates work.

All of these cases implement most easily and directly as templates,
because it enables me to not just emulate them in some manner,
but to implement them as to-the-bit equivalent objects, which
matters to me in various data interchange scenarios.  In a
few cases, I even have the potential to intermix these old
fashioned data models via call/return to/from C++ and some old
language or other where the linker can pull them both together.
Of course, that's not always available, but, the file level
interchange is always possible.

A couple of problems:

1.  I understand it to be the case that the emerging standard
will ignore in-lining of template functions.  I suppose this war has
already been fought out a couple of times, but the decision is
particularly unfortunate here, because (e.g.) in the decimal
cases, the overloaded operators work very nicely if they can
make in-line calls to a selected suite of routines.  Not only
that, but the generated in-line code can make some checks for
special cases that boil down to constants that could be
optimized to call only one of three routines.  But, with the
standard's proposal, all that dreary code becomes instead a
small, useless little stub routine that just gets in the way.

I think a pragma is an ugly solution here, but will there be
some sort of standard way of saying "respect in-line" in the
cases where we are quite sure we want it?  Someone told me the
ARM specifically said that overriding templates was to be
the norm, here.

I don't necessarily ask to refight this war; I just want to
know if this scenario has been considered and can it be
accommodated.

2.  There is no way I know of in templates to raise a compiler
error.  This is a problem at present.

Example:  Turbo C++ does not allow <unsigned int> as a template
type.  So, there is at least the possibility of someone
passing in a negative number.  It would seem to pass siliness
that they would, but sometimes one likes a little paranoia.
A run time check is only 2nd best, because with C++'s rules,
the bad declare can be deep inside a routine that is executed
only every other century or so.

Of course, fixing the standard to explicitly allow signed/unsigned
fixes that.  But, what if you only want to allow odd integers?
Or, a limited list of types?  Or, disallow a certain combination
of types?  Be nice to blow it up at compile time.  None of the
C++ compilers I work with do that.  Will it be added to the
standard?  Something like a

   compiler_throw("explanation")

or some such?

--
   Larry W. Loen        |  My Opinions are decidedly my own, so please
                        |  do not attribute them to my employer

   email to:  lwloen@rchland.vnet.ibm.com

In article <2mde6q$16nv@locutus.rchland.ibm.com> lwloen@rchland.vnet.ibm.com writes:
>1.  I understand it to be the case that the emerging standard
>will ignore in-lining of template functions.

 I'm confused. What do you mean "ignore in-lining"?
A compiler can inline anything its wants to that its smart
enough to inline. It can inline non-inline code too.
It can do anything, provided the semantics are not changed.

>2.  There is no way I know of in templates to raise a compiler
>error.  This is a problem at present.

 Constraints on templates were considered.
They were not rejected, there were just other things to do
of higher priority.

>Of course, fixing the standard to explicitly allow signed/unsigned
>fixes that.

 The WP allows that, so does the ARM unless I'm
completely mistaken.

>But, what if you only want to allow odd integers?

 struct Odd {
  int j;
  Odd(int i) : j(i) { if (i%2==0) throw(error); }
 };

>Or, a limited list of types?

 Why?

>Or, disallow a certain combination
>of types?  Be nice to blow it up at compile time.  None of the
>C++ compilers I work with do that.  Will it be added to the
>standard?  Something like a
>
>   compiler_throw("explanation")
>
>or some such?

 Try assert() macro.

 The issue is not so much reporting constraint violations
as stating them. At present, there is no syntax for stating them.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA