Valentin Bonnard wrote:
>
> >
> > Borland's approach is completely standard.
>
> Not IMO. The code x = ..., is clearly ill-formed, but
> will get compiled without diagnostics, which is (should
> be) non standard.

I just tried it with BC++ 5.02, and the compiler said that it was
invalid syntax.
 -- Pete
---
[ 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
]

Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  Hyman Rosen <jyacc!hymie@uunet.uu.net> writes:
|>
|>  > Tomas Rylek <rylek@cslab.felk.cvut.cz> writes:
|>  > > Borland made a beautiful conservative language extension: inside
|>  > > functions, you can use the triple dot ... in expression, where the
|>  > > compiler supplies a void* to the variable arguments. So Borland's
|>  > > va_start doesn't even need to know about the last variable: #define
|>  > > va_start(set, last) set = ...  I would like to note that Borland's
|>  > > approach, while maybe not according to the standard, has a few nice
|>  > > points:
|>  >
|>  > Borland's approach is completely standard.
|>
|>  Not IMO. The code x = ..., is clearly ill-formed, but
|>  will get compiled without diagnostics, which is (should
|>  be) non standard.

The approach of giving ... an address, and using this in the
va_... macros, is completely legal.  Which doesn't mean that they didn't
make an error in implementing it; it isn't legal to make the
... available in user code.  (If I were writing a compiler, all of the
va_... functions would resolve to custom compiler builtins.  The
builtin's would, at least for most platforms, take the Borland
approach; requiring the name of the last argument is a hack.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ 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                             ]