//The Strong-typedef means implementation not "is-a",
//but inherit all interfaces.
strong-typedef B A;
//means:
class A: private B  {
 public: B::all_public_members_of_B;
 protected: B::all_protected_members_of_B;
}

Jonathan H Lundquist and Bolog Pal put forward several more appropriate scenario.

John Nagle <nagle@animats.com> wrote in message news:<3BAB6A41.F5D4C56@animats.com>...
> If you want a new type, you can write
>
>  class A: public B {};
>
> Admittedly you can't subclass the built-in types, something
> Java and Smalltalk allow but C++ does not.
>
>      John Nagle
>      Animats
>

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

Sat, 22 Sep 2001 21:38:18 GMT, Tinct <tinct@163.com> pisze:

> //The Strong-typedef means implementation not "is-a",
> //but inherit all interfaces.
> strong-typedef B A;
> //means:
> class A: private B  {
>  public: B::all_public_members_of_B;
>  protected: B::all_protected_members_of_B;
> }

So it distinguishes between operator+ implemented as a member function
and operator+ implemented externally? IMHO this is strange.

Not to mention that the other argument of operator+ as a member
function is probably wrong anyway.

It's not so well defined concept to "inherit all interfaces".
Not everything can be meaningfully inherited.

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

"Tinct" <tinct@163.com> wrote in message
news:5450facb.0109211848.192b704f@posting.google.com...
> //The Strong-typedef means implementation not "is-a",
> //but inherit all interfaces.
> strong-typedef B A;
> //means:
> class A: private B  {
>  public: B::all_public_members_of_B;
>  protected: B::all_protected_members_of_B;
> }
>

   Then how do B objects interact with A objects?
In the above class, suppose we had
A A::operator+(const A&) const;

A a;
B b;
a + b;

Would a + b be an object of type A, an object of type B, or a compile error?
For that matter, what would the type of b + b be?

Joe Gottman


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

Christopher Eltschka <celtschk@web.de> wrote:

> "Jonathan H Lundquist" <jhl@sssonline.com> writes:
>=20
> > I certainly wish for the behaviour the original post is suggesting.  =
I don't
> > wish it for typedef, I think that is useful as-is.  And I don't think=
 the
> > keyword for it should be 'strong-typedef', how about 'typefrom'.

> What about using a combination of existing keywords instead?
>=20
> explicit typedef size_t bit_count;

I generally agree, though I think

  typedef new size_t bit_count;

would be even nicer. :-)

J=F6rg

--=20
J=F6rg Barfurth                         joerg.barfurth@attglobal.net
<<<<<<<<<<<<< using std::disclaimer;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Software Developer                    http://www.OpenOffice.org
StarOffice Configuration              http://www.sun.com/staroffice

---
[ 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:
> Sat, 22 Sep 2001 21:38:18 GMT, Tinct <tinct@163.com> pisze:
>
>> //The Strong-typedef means implementation not "is-a",
>> //but inherit all interfaces.
>> strong-typedef B A;
>> //means:
>> class A: private B  {
>>  public: B::all_public_members_of_B;
>>  protected: B::all_protected_members_of_B;
>> }
>
> So it distinguishes between operator+ implemented as a member function
> and operator+ implemented externally? IMHO this is strange.

Something that doesn't make sens is strange indeed.

> Not to mention that the other argument of operator+ as a member
> function is probably wrong anyway.
>
> It's not so well defined concept to "inherit all interfaces".

Yes it is very well defined.

It means "be exactly the same as". In other words,
strong-typed is the same as typedef.

> Not everything can be meaningfully inherited.

The proposed extention is semantically empty.

I don't see the point of discussing it.

  --   VB

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

"Jonathan H Lundquist" <jhl@sssonline.com> writes:

> I haven't thought through a formal set of 'rules' for it, just thinking
> about what would be nice... I would want explicit conversion between any two
> types which were 'typefrom' the same source type to be explicitly
> convertible, but not implicitly.

I believe something like this can be achieved whiting a
[policy-driven] template class, sort of

template <typename base_class [, ... policies ...] >
class make_type :
{
  base_class base;
...
};

typedef make_type<original_type [, ...]> my_type;

It would be a nice exercise.

--
Vadim

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

>
>    Then how do B objects interact with A objects?
> In the above class, suppose we had
> A A::operator+(const A&) const;
>
> A a;
> B b;
> a + b;
>
> Would a + b be an object of type A, an object of type B, or a compile error?
> For that matter, what would the type of b + b be?
>
> Joe Gottman

Thanks. Really I was puzzled by "inherit" of strong-typedef these
days. In C++ The solution should be "is-the-implementation-of".
Strong-typedef is obscure and ambiguous.

In C++ "class" is wroten in an absolute way, i.e. the name of class A
is the property of A. In the defination of A, method operator+(const
A&) uses A as a parameter. It says that an object of A can be added to
"me" NOT an object of self-type can be added to "me". The latter is in
a relative way.
I try to describe the relative way as below.

///////////////////////////////////////////
template < class T, class MY_NAME>
class C {
 T i;
public:
 C operator+(const C &x) { ... }
};

class some_name_1; typedef C<int,some_name_1> intA;
class some_name_2; typedef C<int,some_name_2> intB;

// or say it similarly as
// class intA : public C<int, intA> { };
// class intB : public C<int, intB> { };

void main()
{
 intA a;
 intB b;
 a + b; //compiler error
 a + a; //ok
 b + b; //ok
}

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

In article <5450facb.0109201746.1391a702@posting.google.com>, Tinct says...

[ on typedef names ]

>I mean that in compile or debug time, computer complain typedef name
>rather than long-name. It will be more clear.

What's in a warning or error is up to the compiler vendor, not the
standard. So you should direct your request not to comp.std.c++, but
e.g one of the MS or GNU groups.

But I agree that is is a good thing; it would make many
std::map<std::string,T> related errors more readable.

Regards,
Michiel Salters

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

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

I certainly wish for the behaviour the original post is suggesting.  I don't
wish it for typedef, I think that is useful as-is.  And I don't think the
keyword for it should be 'strong-typedef', how about 'typefrom'.

The primary use I would have for it is in low-level code which uses counts
in different incompatible ways.  For instance, a compressed bitvector class
with a public interface which requires both bit-counts and byte-counts.

Wouldn't it be nice to be able to say (within a proper namespace/scope of
course :-):
typefrom size_t bit_count;
typefrom size_t byte_count;

and then have bit_count and byte_count behave as a size_t synonyms *except*
that they participate in overloading as unique types and bit_count does not
implicitly convert to byte_count.

Of course if this were the only use, I admit upfront we don't need it... But
I'm just thinking this is a trivial motivating example, far from the only
use.

"Tinct" <tinct@163.com> wrote in message
news:5450facb.0109191909.54a3a638@posting.google.com...
> ...
> Considering new type from "typedef", called "strong-typedef", I think
> at least  two benefits from "strong-typedef":
> 1. meaningful type name
> 2. strong type-check
> ...


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

"Tinct" <tinct@163.com> wrote in message news:5450facb.0109191909.54a3a638@posting.google.com...

> In Pascal/ADA, "TYPE B is A" generates a new type B, the behavior of A
> and B are the identical. But B is not A. That is,

IMHO C++ would need both the existing and the strong typedef.

The old one is needed to keep compatibility.

The missing strong one would be extremely useful to resolve overload problems, like:

typedef int tHandleA; //

typedef int tHandleB; // completely unrelated thing, implementation happened to pick int

void foo(tHandleA);
void foo(tHandleB);  // Should be a distinct function but both being int fails to compile!

Tons of programs use such stuff, and are forced to use structure*s or some other off-the-road method in order to create distinct types. And most then must use all kinds of casts that leads to dangerous situation.


My other problem with current typedef is that I can't use it with forward-declaration. This is a growing pain as time flows. I have

class Foo;
... use Foo as incomplete type ... later
class Foo {};

Then later I generalize Foo, and it will become

template <class T> FooTempl {};
typedef FooTempl<int> Foo;

I'd expect that to pass transparently, but having the conflict with forwards I'll have to rearrange the whole project, or drop the idea of evolution. :-(((

Paul








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

Tinct <tinct@163.com> wrote:
> In Pascal/ADA, "TYPE B is A" generates a new type B, the behavior of A
> and B are the identical. But B is not A. That is, [...]
> In c++, "typedef A B" means that B is a replacer/abbreviation of A. No
> new type B is generated! [...]

Provided typedef modified to fit your vision, what would be the way
to create type alias, i.e. different name for existing type?

>  typedef string NAME;
>  typedef string ADDRESS;
>  typedef map<NAME,ADDRESS> ADDRESS_BOOK;
[...]
> Considering new type from "typedef", called "strong-typedef",
> I think at least  two benefits from "strong-typedef":
> 1. meaningful type name

You already have it with current typedef semantics.

> 2. strong type-check

Ugh? What type checking provided for case when someone writes following:
ADDRESS address ("John Welsh");
NAME name ("#33 Fifth Ave, Pretty Town, Nice Country");

What do all the string operations mean for address
and name correspondingly?

And what is the way to extract last name of the person whose
full name is stored as "Patangali Khan ibn Hottab"?

If you do want more type checking and more convinience you should
provide more meaningful interfaces for your ADDRESS and NAME types,
i.e. make them different classes.

> 3. simple type name, you know the real name for ADDRESS_BOOK in C++ is
> "class std::map<class std::basic_string<char,struct
> std::char_traits<char>,class std::allocator<char> >,class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> >,struct std::less<class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> > >,class std::allocator<class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> > > >"
> HOW LONG IS IT! Trivial and depending on implementation detail.

Well, who cares about "real name"? As far as I can see this is what you
get with typeid(ADDRESS_BOOK).name() or something. And how it would
become implementation independent if you make it "class ADDRESS_BOOK"?
Another implementation could make it "ADDRESS_BOOK"...

--
Pavel Kuznetsov

[ DON'T MAIL THE REPLY ADDRESS! THAT IS UNATTENDED MAILBOX.    ]
[ If you do want contact me in person, please use the address: ]
[ pavel <dot> kuznetsov <at> mail <dot> ru                     ]


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

"Tinct" <tinct@163.com> wrote in message
news:5450facb.0109191909.54a3a638@posting.google.com...
>  typedef string NAME;
>  typedef string ADDRESS;
>  typedef map<NAME,ADDRESS> ADDRESS_BOOK;
>  NAME n1 ("Tom");
>  ADDRESS a1("New York");
>  ADDRESS_BOOK book;
>  book[ n1 ] = a1;  // All above look nice
>  n1 = a1; // NAME is not ADDRESS! Complier should give out an error/a
> warning.
>
> Considering new type from "typedef", called "strong-typedef", I think
> at least  two benefits from "strong-typedef":
> 1. meaningful type name
> 2. strong type-check

You can always create a wrapper class around the map if that is what you
want.

class address_book
    : private std::map<std::string, std::string>
{
public:
    // code to forward all it's interface:
    using std::map<std::string, std::string>::begin;
    using std::map<std::string, std::string>::end;
    // ...
};

It would be nice if C0x were to allow you to just say using BASECLASS to
forward the whole interface.
Either that or to allow you to use public inheritance and to disable the
conversion to the base class with a private operator BASECLASS.  As this is
not the case in the current language, you have to either do something like
the above.


> 3. simple type name, you know the real name for ADDRESS_BOOK in C++ is
> "class std::map<class std::basic_string<char,struct
> std::char_traits<char>,class std::allocator<char> >,class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> >,struct std::less<class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> > >,class std::allocator<class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> > > >"
> HOW LONG IS IT!

So?  If your concerned about length of symbol names (which is the main
reason for concern that I can think of), some modern compilers use a
compressed name mangling scheme.  gcc-3, which uses Itanium ABI, mangles
this type to "St3mapISsSsSt4lessISsESaISt4pairIKSsSsEEE".  I don't think
this is particularly long.

--
Richard Smith


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

"Richard Smith" <richard@ex-parrot.com> wrote in message news:<1001000673.4107.0.nnrp-02.3e31d362@news.demon.co.uk>...
> You can always create a wrapper class around the map if that is what you
> want.
>
> class address_book
>     : private std::map<std::string, std::string>
> {
> public:
>     // code to forward all it's interface:
>     using std::map<std::string, std::string>::begin;
>     using std::map<std::string, std::string>::end;
>     // ...
> };

Take the example of size_t By Jonathan H Lundquist.
class bit_size: private size_t {...} // error
class byte_size: private size_t {...} // error

So, one can write:
class bit_size { size_t s; operator +/-/*/==/...()}
One can really use class to encapsulate these things. But, from the
semantic viewpoint, both the number of apples and the number of
bananas are integers. Oh, apples cannot be added to bananas. So, One
may simply implement both with "strong-typedef". It is a clear and
simple way.

About the keyword, I think:
typedef int int_num;  // Old-style typedef
typedef int class int_num;  // Strong typedef

It looks better.

>
> It would be nice if C0x were to allow you to just say using BASECLASS to
> forward the whole interface.
> Either that or to allow you to use public inheritance and to disable the
> conversion to the base class with a private operator BASECLASS.  As this is
> not the case in the current language, you have to either do something like
> the above.
>
>
> > 3. simple type name, you know the real name for ADDRESS_BOOK in C++ is
> > "class std::map<class std::basic_string<char,struct
> > std::char_traits<char>,class std::allocator<char> >,class
> > std::basic_string<char,struct std::char_traits<char>,class
> > std::allocator<char> >,struct std::less<class
> > std::basic_string<char,struct std::char_traits<char>,class
> > std::allocator<char> > >,class std::allocator<class
> > std::basic_string<char,struct std::char_traits<char>,class
> > std::allocator<char> > > >"
> > HOW LONG IS IT!
>
> So?  If your concerned about length of symbol names (which is the main
> reason for concern that I can think of), some modern compilers use a
> compressed name mangling scheme.  gcc-3, which uses Itanium ABI, mangles
> this type to "St3mapISsSsSt4lessISsESaISt4pairIKSsSsEEE".  I don't think
> this is particularly long.

I mean that in compile or debug time, computer complain typedef name
rather than long-name. It will be more clear.

Thanks to all.

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

    If you want a new type, you can write

 class A: public B {};

Admittedly you can't subclass the built-in types, something
Java and Smalltalk allow but C++ does not.

     John Nagle
     Animats

Tinct wrote:
>
> In Pascal/ADA, "TYPE B is A" generates a new type B, the behavior of A
> and B are the identical. But B is not A. That is,

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

"Jonathan H Lundquist" <jhl@sssonline.com> writes:

> I certainly wish for the behaviour the original post is suggesting.  I don't
> wish it for typedef, I think that is useful as-is.  And I don't think the
> keyword for it should be 'strong-typedef', how about 'typefrom'.
>
> The primary use I would have for it is in low-level code which uses counts
> in different incompatible ways.  For instance, a compressed bitvector class
> with a public interface which requires both bit-counts and byte-counts.
>
> Wouldn't it be nice to be able to say (within a proper namespace/scope of
> course :-):
> typefrom size_t bit_count;
> typefrom size_t byte_count;
>
> and then have bit_count and byte_count behave as a size_t synonyms *except*
> that they participate in overloading as unique types and bit_count does not
> implicitly convert to byte_count.
I'm just wondering, would smth like this be valid:
    bit_count c =  bit_count(1)*8;

And why/why not?

I mean that there are much more aspects of behavior beside the
implicit conversion that you eventually want to control.

--
Vadim

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

"Jonathan H Lundquist" <jhl@sssonline.com> writes:

> I certainly wish for the behaviour the original post is suggesting.  I don't
> wish it for typedef, I think that is useful as-is.  And I don't think the
> keyword for it should be 'strong-typedef', how about 'typefrom'.
>
> The primary use I would have for it is in low-level code which uses counts
> in different incompatible ways.  For instance, a compressed bitvector class
> with a public interface which requires both bit-counts and byte-counts.
>
> Wouldn't it be nice to be able to say (within a proper namespace/scope of
> course :-):
> typefrom size_t bit_count;
> typefrom size_t byte_count;

What about using a combination of existing keywords instead?

explicit typedef size_t bit_count;

[...]

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

John>     If you want a new type, you can write
John>  class A: public B {};

John> Admittedly you can't subclass the built-in types, something
John> Java and Smalltalk allow but C++ does not.

Java allows you to derive from int?  I think not.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

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

John Nagle wrote:
>
>     If you want a new type, you can write
>
>         class A: public B {};
>
> Admittedly you can't subclass the built-in types, something
> Java and Smalltalk allow but C++ does not.
>

Java does not allow subclassing built-in types. It provides wrapper
classes for each of the builtin types, and you can subclass those types.
C++ also allows this, but doesn't provide the wrapper classes for you.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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

I haven't thought through a formal set of 'rules' for it, just thinking
about what would be nice... I would want explicit conversion between any two
types which were 'typefrom' the same source type to be explicitly
convertible, but not implicitly.

"Vadim Egorov" <egorovv@uroam.com> wrote in message
news:8766ad9e7s.fsf@fingolfin.bogus.org...
> "Jonathan H Lundquist" <jhl@sssonline.com> writes:
>
> >
> > Wouldn't it be nice to be able to say (within a proper namespace/scope
of
> > course :-):
> > typefrom size_t bit_count;
> > typefrom size_t byte_count;
> >
> > and then have bit_count and byte_count behave as a size_t synonyms
*except*
> > that they participate in overloading as unique types and bit_count does
not
> > implicitly convert to byte_count.
>
> I'm just wondering, would smth like this be valid:
>     bit_count c =  bit_count(1)*8;
>
> And why/why not?
>
> I mean that there are much more aspects of behavior beside the
> implicit conversion that you eventually want to control.
>
> --
> Vadim
>


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

In Pascal/ADA, "TYPE B is A" generates a new type B, the behavior of A
and B are the identical. But B is not A. That is,

Var ax: A; Var bx: B;
Function f( b: B);
bx := ax; //Error!
f(ax);  // Error!
-------------------
In c++, "typedef A B" means that B is a replacer/abbreviation of A. No
new type B is generated!
For Example:

 typedef string NAME;
 typedef string ADDRESS;
 typedef map<NAME,ADDRESS> ADDRESS_BOOK;
 NAME n1 ("Tom");
 ADDRESS a1("New York");
 ADDRESS_BOOK book;
 book[ n1 ] = a1;  // All above look nice
 n1 = a1; // NAME is not ADDRESS! Complier should give out an error/a
warning.

Considering new type from "typedef", called "strong-typedef", I think
at least  two benefits from "strong-typedef":
1. meaningful type name
2. strong type-check
3. simple type name, you know the real name for ADDRESS_BOOK in C++ is
"class std::map<class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >,class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >,struct std::less<class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > >,class std::allocator<class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > > >"
HOW LONG IS IT! Trivial and depending on implementation detail.

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