🚀 go-pugleaf

Bill Leonard (bill@amber.ssd.hcsc.com) wrote:
|> kanze@gabi-soft.fr (J. Kanze) writes:
|> > enseeg14@grenet.fr wrote:
|> > 
|> > |> > for (i = 0 ; i < n ; i++) {
|> > |> >    for (j = 0 ; j < n ; j++) {
|> > |> >       a[i][j] = b[i][j] * c[i] ;
|> > |> >    }
|> > |> > }
|> > 
|> > |> > do j = 1,m
|> > |> >   do i = 1, n
|> > |> >     a (i,j) = b(i,j) * c(i)
|> > |> >   enddo
|> > |> > enddo 
|> > 
|> > Const won't help, and the problem isn't typing, but potential aliasing.
|> > Fortran basically says that the results are undefined if aliasing is
|> > present, C/C++ doesn't.

    [...]

|> > There is a proposed extention to C which would do it, a sort of son of
|> > noalias.  I don't know any of the details, but I'm sure that a question
|> > in comp.std.c would reach people who did, or who could point you in the
|> > right direction.

|> I continue to think such extensions are a bad idea.  They basically force
|> the compiler to trust the programmer, and historically that is not a
|> reliable thing to do.  The original programmer may have been careful to
|> avoid aliasing, but what about the 50 other programmers who came later and
|> made modifications to the program?  Worse still, you may have a bug lurking
|> there for decades until you happen to compile with a compiler that takes
|> advantage of the noalias declaration *and* does it in such a way that the
|> illegal aliasing changes the behavior of the program.  Such bugs are
|> extremely difficult to track down.

I agree (although I'm not too familiar with the proposal, except for
knowing that it exists).  The real problem is that the declaration
affects the code generation in the function, but requires discipline on
the part of the callers.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]