Hello

Its just about C++ generalization. Would it be useful to allow user to
add custom type qualifiers along with existing const & volatile ?

PS. Well, uhm, english is not my native language, rather it is C++.

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

Thu, 31 May 2001 15:55:39 GMT, sahn0 <superone@mail.ru> pisze:

> Its just about C++ generalization. Would it be useful to allow user to
> add custom type qualifiers along with existing const & volatile ?

What would they mean?

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

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

Marcin 'Qrczak' Kowalczyk wrote:
>
> Thu, 31 May 2001 15:55:39 GMT, sahn0 <superone@mail.ru> pisze:
>
> > Its just about C++ generalization. Would it be useful to allow user to
> > add custom type qualifiers along with existing const & volatile ?
>
> What would they mean?

Whatever the user wanted them to ;)

More seriously, their only meaning to the compiler would be
in type checking.  This would enable techniques such as
Andrei Alexandrescu's "volatile safety" to be implemented
without introducing flame wars because of misunderstandings:
Andrei's technique uses the properties of volatile only at
compile-time (within the type system) and actually finds the
run-time semantics inconvenient (having to play carefully
to avoid formally undefined behaviour).  If it was possible
to introduce a new property (say "synchronized") which had
compile-time analagous properties to const or volatile but
no run-time effects, the technique (and who knows how many
others) would become clean.  I can imagine similar techniques
being used to simulate Perl's "taint" feature at compile
time by tagging variables as "tainted" until operations are
performed on them to explicitly remove that taint.  (Just
an idea I've not thought through, btw.)

-- James Dennett

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

James Dennett wrote:
>
> Marcin 'Qrczak' Kowalczyk wrote:
> >
> > Thu, 31 May 2001 15:55:39 GMT, sahn0 <superone@mail.ru> pisze:
> >
> > > Its just about C++ generalization. Would it be useful to allow user to
> > > add custom type qualifiers along with existing const & volatile ?
> >
> > What would they mean?
>
> Whatever the user wanted them to ;)
>
> More seriously, their only meaning to the compiler would be
> in type checking.  This would enable techniques such as
> Andrei Alexandrescu's "volatile safety" to be implemented
> without introducing flame wars because of misunderstandings:
> Andrei's technique uses the properties of volatile only at
> compile-time (within the type system) and actually finds the
> run-time semantics inconvenient (having to play carefully
> to avoid formally undefined behaviour).  If it was possible
> to introduce a new property (say "synchronized") which had
> compile-time analagous properties to const or volatile but
> no run-time effects, the technique (and who knows how many
> others) would become clean.  I can imagine similar techniques
> being used to simulate Perl's "taint" feature at compile
> time by tagging variables as "tainted" until operations are
> performed on them to explicitly remove that taint.  (Just
> an idea I've not thought through, btw.)

We don't need a language extension for this. You can implement it in
current C++:


// Tip o' the hat to Andrei
template <bool Test> struct static_assert;
template <> struct static_assert<true> {};

// Valid only if there are no bits in Src that aren't in Dst
template <unsigned Src, unsigned Dst> struct convert_check:
  static_assert<((Src | Dst) == Dst)> {};

// Template for qualified types
// Each bit in Mask represents a type qualifier
template <typename T, unsigned Mask> class qualified {
  public:
    qualified(T t = T()):
      value_(t) {}
    operator T() const {
      static_assert<(Mask == 0)>();
      return value_;
    };
    template <typename T2, unsigned Mask2>
      qualified(qualified<T2, Mask2> src):
        value_(src.value_) {
          convert_check<Mask2, Mask>();
        }
    template <unsigned Mask2> friend qualified<T, Mask2>
      qualified_cast(qualified src) {
        return qualified<T, Mask2>(src.value_);
      }
  private:
    T value_;
};

// Define a couple of type qualifiers
const unsigned magic(1);
const unsigned tainted(2);

int main() {
  int i(42);                             // Plain int
  qualified<int, magic> m;               // Magic int
  qualified<int, (magic | tainted)> mt;  // Magic, tainted int
  mt = i;                                // OK
  // m = mt;                             // This won't compile
  m = qualified_cast<magic>(mt);         // But this will
  return 0;
}


(Tested on GCC 2.95.3)

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
        "Hungarian notation is the tactical nuclear weapon of
         source code obfuscation techniques." -- Roedy Green

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