Mycroft Holmes wrote:
> Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote in message
> 3A276CB0.C9629788@physik.tu-muenchen.de...
>

[...]

> > I don't understand this one.
> > Do you mean that the layout of (int, double, char) should be the same as
> > the layout of struct foo { int a; double b; char c; } ?
>
> yes, exactly. the point is that the (int, double, char) is anonymous and you
> needn't define explicitly the struct.
>
> > > 5) the composite object is automatically replaced by an array, whenever
> all
> > > atoms are of the very same type. When this happens, you may use anything
> in
> > > square brackets for addressing objects. example:
> > >
> > > {
> > >     (int,int,int) a = {3,4,5};        // complier replaces with a[3] =
> > > {3,4,5}
> > >
> > >     int i;
> > >     a[i];        // allowed!
> > >
> > > }
> >
> > I don't like this one.
>
> this is a corollary of (3): internally an (int,int,int) would be identical
> to int[3], so there's no reason to restrict to constant indices.

No, according to 3, it would be the same layout as

  struct { int a; int b; int c; } foo;

which istn't guaranteed to be the same as the layout of

  int foo[3];

(though I don't think that there's even one implementation where it
isn't).

I wouldn't mind if the layout equivalence would be fixed, and I wouldn't
mind if an explicit cast would be allowed; I even could live with an
implicit conversion (like that of array->pointer to first element).
However
I _would_ object to the implicit rewrite you suggest. The type of
(int; int; int) should be (int; int; int), not int[3].
Note that if all you want is to write a[i] with variable i, then all
you need is to have an automatic decay of (int; int; int) to int*, just
as you have for arrays.

Another rule I'd like is to have an automatic conversion to every POD
struct which has the same structure, e.g.

  struct foo { int i, j; double k; } a;
  (int; int; double) b;
  a = b;

This would especially be interesting with temporaries:

  void f(foo);

  f((1; 2; 3.5))

[... additional "argument list decay" suggestion ...]

> well done ;-)

Thanks.
Note that this would not work if (int; int; int) were the same as
int[3].
Of course, it _would_ work with an implicit conversion.

I'm for a while thinking about a new language (but only as a quite low
priority task), and in that language, such "type combining" is indeed
one of the fundamental principles (that's also the reason why I
immediatly got your idea). Indeed, in that (not yet completely designed)
language, functions don't really take argument lists; they take just one
argument, which may consist of a combined type. The mechanism I
described
above is in my language a special case of "typer flattening": If you
have
a combined type, where one of the types itself is a combined type,
there's
an implicit conversion to the "flattened" type which you get by
replacing
the combined type by it's type list, e.g. (with C++ member types):

(int; (int; double; int); double) -> (int; int; double; int; double)

I never thought about adding combined types to C++. However, I like
that idea.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

--
 The set of solutions is never empty.
 Two solutions together form a new problem.
-- Mycroft Holmes

Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote in message
3A276CB0.C9629788@physik.tu-muenchen.de...

> This would break the current comma operator.

yep, I know. However you got the very meaning of the idea.


>
> Otherwise, it's IMHO a good idea.

thanks.


> > 3) the compiler ensires that the composite object is assembled from left
to
> > right (read the following example)
> >
> > {
> >    (int,double,char) obj1 = ( 3, -27.7, 'X' ) ;
> >   int* c = (int*) &obj1;
> >
> > // now *c == 3
> >
> >  double* d =  (char*)c+sizeof(int);    // now *d == -27.7        and so
on
> > }
>
> I don't understand this one.
> Do you mean that the layout of (int, double, char) should be the same as
> the layout of struct foo { int a; double b; char c; } ?

yes, exactly. the point is that the (int, double, char) is anonymous and you
needn't define explicitly the struct.

> > 5) the composite object is automatically replaced by an array, whenever
all
> > atoms are of the very same type. When this happens, you may use anything
in
> > square brackets for addressing objects. example:
> >
> > {
> >     (int,int,int) a = {3,4,5};        // complier replaces with a[3] =
> > {3,4,5}
> >
> >     int i;
> >     a[i];        // allowed!
> >
> > }
>
> I don't like this one.

this is a corollary of (3): internally an (int,int,int) would be identical
to int[3], so there's no reason to restrict to constant indices.

>
> Another suggestion:
>
> Automatic "decay" in argument lists:
>
> Assuming that you have a function
>
>   (int; double) foo();
>
> and you have a function
>
>   void bar(int, int, double);
>
> but no function
>
>   void bar(int, (int; double));
>
> then it should be allowed to write
>
>   bar(5, foo());
>
> which shall be equivalent to
>
>   {
>     (int; double) tmp = foo();
>     bar(5, tmp[1], tmp[2]);
>   }
>
> This would especially be useful for STL::

well done ;-)




---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]