johnchx2@yahoo.com wrote:

> what would be an example of a piece of
> code that has well-defined behavior under the current standard, but
> would have undefined behavior if the fifth bullet of 3.10/15 were
> deleted from the standard?

struct a { int i; };
struct b { int j; };

void* vp = malloc(sizeof(a));
if(vp)
{
a* ap = (a*) vp;
b* bp = (b*) bp;
(*ap).i = 0;
(*bp).j = 1;
1/(*ap).i;
}

This code accesses the same object through l-values of type a (*ap),
and type b (*bp).  3.10/15 bullet 5 says this is legal, and the
behavior is well defined.  Without that particular bullet, the compiler
would, IMO, be given license to assume that no object of type b may
alias an object of type a (meaning also that no member of 'b' may alias
a member of 'a').  Without that bullet, the code produces UB.  Change
the code so that 'a' and 'b' are not aggregates (perhaps have them both
derive from an empty base class) and even with the current standard the
code produces UB.

I don't think the standard does a very good job of talking about this
C-compatibility stuff.  OTOH, I don't have a suggestion for better
wording, so I shouldn't complain.

What is the "actual" type of the memory pointed at by vp?  It behaves
much like a union of every POD or scalar that fits, but without the
last-member-accessed restriction.  3.8 says that the lifetime of a POD
object begins when storage with the proper alignment and size is
obtained, and that storage was obtained before the body of the 'if' was
entered.  So in some sense, there is a 'float' object there (assuming
sizeo(float) is not too big) as well as an int, an 'a', an array of
char, ... .  As a result of code like this, compilers would need to
assume that almost every lvalue could alias the same object, preventing
most "register" optimizations.  IMO, 3.10/15 says that if two lvalue
types are sufficiently different the compiler may assume (the program
must ensure) that the objects are not aliased.

Clearly, once the compiler deduces that two objects are not aliased, it
may also deduce that their members are not aliased.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

kuyper@wizard.net wrote:

> whyglinux wrote:
> .
> > the standard, it's better that A, B in "A or B" are distinct and thus
> > the "or" should be used restrictively.
>
> Why? All that such a requirement would do is require that sets which
> can be easily described as unions of overlapping sets would have to be
> described in a more complicated fashion as the union of non-overlapping
> sets. The more complicated description would, in general, be harder to
> understand than the original.

The reason is obvious: when they are overlapped, they must come from
*different* category of groups. Usually it's bad to describe something
based on two or above categorical rules. It will lead to confusion and
thus should be avoided.

For example, when people say "white or Persian cats", do you have a
clear impression what they refer to? Probably not (and may feel
uncomfortable), because here "white cats" and "Persian cats" come from
2 categories of groups separately and thus may not be distinct between
them, which can prevent from understanding.

But when it is "white or black cats", we can grasp the meaning easily
because they are classified according to the same categorical rule,
colors, and distinct.

Therefore, the essence is that the underneath categorical rules are
unified.

(Thanks the discussion, it made me realize what I really wanted to
express.)

> Taking the case that is the topic of this
> thread. It will make the problem clearer if I prohibit you from
> inventing new terminology. Using only existing terminology, there are
> several ways that it could be re-written to express the intent in terms
> of non-overlapping sets. You could say "non-aggregate union or
> aggregate", or you could  say "non-union aggreggate or union". If the
> assymettry bothers you , you describe it as the union of three
> non-overlapping sets: "non-union aggregate or union aggreggate  or
> non-aggregate union". Would you argue that any one of these is easier
> to correctly understand than "aggregate or union"?

Even in "non-union aggregate or union" or "non-union aggregate,
aggregate union or non-aggregate union" the sub-sets are distinct, but
since "aggregate" and "union" in C++ are classified based on different
rules, neither is good, the same as "aggregate or union".

And I won't say "non-aggregate union or aggregate" or "non-union
aggregate
or union aggreggate or non-aggregate union" as you suggested. The
reason is the same as above. Furthermore, the sub-sets are still
overlapped.

The best way I think to express the contents of "aggregate or union"
is, as written earlier, "aggregate class, aggregate struct or union" if
here "aggregate class" means only those defined with the class-key
class. However, in C++ standard, "aggregate class" is different from
what I want it to be. For that reason, if only using the terms provided
in C++ standard, it is not possible to express "aggregate or union" by
selecting terms that come only from the same categories, and perhaps
the "aggregate or union" is the best if you insist on describing such a
target and not inventing new terms.

I think the current C++ standard is not ready to express "aggregate or
union", as I stated eralier, because there is hardly a situation that
needs to describe the target as "aggregate or union". Can you find
another one except the current debated?

> If there was an existing convention that "or" requires non-overlapping
> categories, writing things in an unnecessarily complicated way to
> adhere to that convention might be the price we would have to pay in
> order to avoid confusion - but I'm aware of no such convention.

When a writer writes something, it's more important to make readers
understand easily, rather than write in an easy way.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

whyglinux wrote:
> kuyper@wizard.net wrote:
.
> The reason is obvious: when they are overlapped, they must come from
> *different* category of groups. Usually it's bad to describe something
> based on two or above categorical rules. It will lead to confusion and
> thus should be avoided.
>
> For example, when people say "white or Persian cats", do you have a
> clear impression what they refer to? Probably not (and may feel
> uncomfortable), because here "white cats" and "Persian cats" come from
> 2 categories of groups separately and thus may not be distinct between
> them, which can prevent from understanding.
>
> But when it is "white or black cats", we can grasp the meaning easily
> because they are classified according to the same categorical rule,
> colors, and distinct.
>
> Therefore, the essence is that the underneath categorical rules are
> unified.
>
> (Thanks the discussion, it made me realize what I really wanted to
> express.)

When there are two or more different reasons why the a given rule
should apply to something, I don't see any intrinsic reason why those
reasons might not apply simultaneously. Requiring that categorical
rules be "unified" in the sense you give above essentially implies that
no rule can ever have more than one basic reason for applying. I don't
think that's a reasonable requirement to impose on the standard.

.
> > If there was an existing convention that "or" requires non-overlapping
> > categories, writing things in an unnecessarily complicated way to
> > adhere to that convention might be the price we would have to pay in
> > order to avoid confusion - but I'm aware of no such convention.
>
> When a writer writes something, it's more important to make readers
> understand easily, rather than write in an easy way.

I agree. And in this case, the argument applies both to the writer and
the reader. It's both easier to write and easier to understand when the
categories are allowed to overlap. The unnecessary complication
required to remove overlaps makes it, if anything, even harder to read
and understand correctly than it is to write it correctly. I don't know
about you, but I found the non-overlapping versions that I wrote almost
incomprehensible, and I'm the one who wrote them.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <1150730025.750791.160450@c74g2000cwc.googlegroups.com>,
whyglinux <whyglinux@gmail.com> writes
>The best way I think to express the contents of "aggregate or union"
>is, as written earlier, "aggregate class, aggregate struct or union"
With respect, rubbish. You have now forgotten to include arrays. You see
how easy it is to get it wrong when you start word-smithing to attempt
to enforce your view of 'or'. The English language has always used 'or'
as non-exclusive though sometimes when we want to emphasize the
possibility of overlap we write 'and/or'. And when we (rarely) need the
exclusive version we write 'A or B but not both'

Yes, reading standardese can be a gruelling task but trying to change
the meanings of words does nothing to help. Of course when we need to
translate a Standard to a different language we have to be very careful
to translate logical operator words because other natural languages use
variant concepts. That is one reason that mechanical translation is
often suspect.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:

> With respect, rubbish. You have now forgotten to include arrays. You see
> how easy it is to get it wrong when you start word-smithing to attempt
> to enforce your view of 'or'.

Argument always makes me nervous. So if I forgot something, please
forgive me. Thank you for pointing out the error anyway.

> The English language has always used 'or'
> as non-exclusive though sometimes when we want to emphasize the
> possibility of overlap we write 'and/or'. And when we (rarely) need the
> exclusive version we write 'A or B but not both'
>
> Yes, reading standardese can be a gruelling task but trying to change
> the meanings of words does nothing to help.

Am I changing the meaning of the "or"? I don't think so. I only suggest
the terms connected with "or" be given the constraint that they should
come from the same category of groups and distinct from each other, as
I stated earlier.

You'd better read to understand before replying.

And please have a glance at the C++ standard and find some "or"
sentences to see the usage as what I suggested is "rare" or not.

And
> Then how about a struct with no virtual functions, no base classes, no
> static members, and no members that are references but with a
> user-declared constructor? Obviously such a struct is not aggregate and
> banned accordingly. Should the current standard be revised to accept
> suchlike structs?

This is a question I asked earlier and expected to get an answer (but
not yet) from those who believe the "aggregate or union" is NOT
redundant. What's your opinion?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

whyglinux wrote:
> Francis Glassborow wrote:
>
>> With respect, rubbish. You have now forgotten to include arrays. You see
>> how easy it is to get it wrong when you start word-smithing to attempt
>> to enforce your view of 'or'.
>
> Argument always makes me nervous. So if I forgot something, please
> forgive me. Thank you for pointing out the error anyway.
>
>> The English language has always used 'or'
>> as non-exclusive though sometimes when we want to emphasize the
>> possibility of overlap we write 'and/or'. And when we (rarely) need the
>> exclusive version we write 'A or B but not both'
>>
>> Yes, reading standardese can be a gruelling task but trying to change
>> the meanings of words does nothing to help.
>
> Am I changing the meaning of the "or"? I don't think so.

When one advocates an unconventional usage for the word, it
does appear to be "changing the meaning" of that word, for
what is meaning but acceptable usage?

> I only suggest
> the terms connected with "or" be given the constraint that they should
> come from the same category of groups and distinct from each other, as
> I stated earlier.

That certainly qualifies as attempting to change the meaning
of the word "or" in my book.  I see no merit in deviating from
the accepted technical use of "a or b" as implying only that
one or both of a and b applies, without any implication on
how those categories relate to each other.  In some cases it
may be clearer if they are disjoint, and if they are from the
same category -- but in other cases, such as that under
discussion here, that does not appear to be the case, and
this would be a consistency too far.

-- James

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

wade@stoner.com wrote:
> johnchx2@yahoo.com wrote:
> > what would be an example of a situation in which the
> > "aggregate-ness" of a class affects the defined-ness of program
> > behavior under the terms of 3.10/15 bullet 5?

[snip]

> This code fragment is well defined in C89
>
>   struct a { int i; };
>   struct b { int j; };
>
>   struct a a_ = { 1 };
>   struct b *bp_ = (b*) &a_;  /* A C "reinterpret cast " */
>   bp_->j = 2;
>   printf("%d", a_.i);

I stil don't see what this has to do with 3.10/15 bullet #5.

3.10/15 is concerned with programs which access the stored value of an
object of some type, T1, through an lvalue of some (possibly other)
type T2.  So the first thing to understand is what does such an access
look like.  Consider the following code:

  typedef T1* T2;
  T1 x;
  T2 px = & t1;
  T1 y = *px;

Now, the expression "px" is an lvalue with type T2.  So: does the code
above access the value of an object of type T1 "through" an lvalue of
type T2?  If so, it yields undefined behavior under 3.10/15, since none
of the bullets apply.  But, of course, nobody believes this is true.
We are accessing the value of the object through the expression "*px",
which is an lvalue of type T1.  It makes no difference at all that some
sub-expression of that expression has type T2.

It seems clear that the expression type refered to in 3.10/15 is the
type of the expression which actually designates the object in
question, not the type of any sub-expression of that expression.

If we re-write the second to last line of your example from this:

  bp_->j = 2;

to this

  (*bp_).j = 2;

it's clear that two things are going on.  First, we are referring to an
object of type a through an lvalue of type b ("*bp_").  It's not clear
to me whether applying the member access operation to this lvaue counts
as accessing the stored value of the object for 3.10/15 purposes or
not.  If it does, the behavior is undefined, because no bullet in
3.10/15 applies.  If it doesn't (and for POD types I can see an
arguement that it doesn't), then 3.10/15 doesn't apply at all.

Second, we store a value of type int to an object of type int
designated by the lvalue "(*bp_).j", which has type int.  Assuming (as
I'm inclined to) that storing a new value entails access to the stored
value, the first bullet of 3.10/15 applies (the expression and the
object are of the same dynamic type).

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> wade@stoner.com wrote:
> > johnchx2@yahoo.com wrote:
> > > what would be an example of a situation in which the
> > > "aggregate-ness" of a class affects the defined-ness of program
> > > behavior under the terms of 3.10/15 bullet 5?
>
> [snip]
>
> > This code fragment is well defined in C89
> >
> >   struct a { int i; };
> >   struct b { int j; };
> >
> >   struct a a_ = { 1 };
> >   struct b *bp_ = (b*) &a_;  /* A C "reinterpret cast " */
> >   bp_->j = 2;
> >   printf("%d", a_.i);
>
> I stil don't see what this has to do with 3.10/15 bullet #5.
>
> 3.10/15 is concerned with programs which access the stored value of an
> object of some type, T1, through an lvalue of some (possibly other)
> type T2.  So the first thing to understand is what does such an access
> look like.

In C, both a_.i and bp_.j are at the same location, and the compiler
must assume that they may be aliased with each other.  The printf()
must print 2 (the last value assigned to that location).  In C++, using
the cast as shown is, strictly speaking, UB.  However, I believe the
intent of the standard is that the C++ code behave the same as C code.
OTOH, if either a or b were not aggregates, the intent of the C++
standard is that the compiler is allowed to assume that a_ (and its
members) are not aliased with (*bp_).

>  Consider the following code:
>
>   typedef T1* T2;
>   T1 x;
>   T2 px = & t1;
>   T1 y = *px;
>
> Now, the expression "px" is an lvalue with type T2.

No, typedef does not define a new type.  It defines a new name for an
existing type.  "T2" is just a shorthand for "T1*".

>  So: does the code
> above access the value of an object of type T1 "through" an lvalue of
> type T2?

No.  There is no type T2.


My interpretation of 3.10/15, in the context of these examples, in some
context, a compiler holds a bunch of lvalues, and can't be sure which
might be aliases.

struct nonaggregate1{ virtual ~nonaggregate1(){}; int i; };
struct nonaggregate2{ virtual ~nonaggregate2(){}; int i; };
struct aggregate{ int i,j,k; };

extern nonaggregate1& n1;
extern nonaggregate1 const & c1;
extern nonaggregate2& n2;
extern aggregate& a;
extern int& i;
extern int[3]& ar;
extern float& f;
extern char& c;
extern unsigned int& u;

What can n1.i be aliased with?  I believe it can be aliased with c1.i,
a.i, i, ar[k], c, u.  It cannot be aliased with n2 or f.  Both C and
C++ say that if you write to a float, the compiler may assume that
there is no int at the same location.  C++ has the additional rule that
objects of different (also not base/derived) non-aggregate types, don't
overlap.

Part of the rational for this belief is that non-aggregates must be
constructed before use.  For C compatibility, aggregates do not need to
be constructed before use (of course values need to be initialized
before they are read).

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

wade@stoner.com wrote:
> johnchx2@yahoo.com wrote:
> >  Consider the following code:
> >
> >   typedef T1* T2;
> >   T1 x;
> >   T2 px = & t1;
> >   T1 y = *px;
> >
> > Now, the expression "px" is an lvalue with type T2.
>
> No, typedef does not define a new type.  It defines a new name for an
> existing type.  "T2" is just a shorthand for "T1*".
>

True but entirely irrelevant.

> >  So: does the code
> > above access the value of an object of type T1 "through" an lvalue of
> > type T2?
>
> No.  There is no type T2.

On the assumption that you genuinely don't understand the point of the
question, I'll rephrase it:  "Does the code above access the value of
an object of type T1 'through' an lvalue of type T1*?"

Nothing changes.  The conclusion remains: if the answer to the question
is yes, then any access to an object through a pointer engenders UB
under 3.10/15.  Since nobody believes this, this cannot possibly be the
correct way to interpret 3.10/15.  The types of sub-expressions don't
matter; what matters is the type of the expression which actually
designates the object.

Let me try posing the question a different way.  The underlying concern
in this thread is whether or not 3.10/15 bullet #5 should include
lvalues of non-aggregate union type (it *does*, but the question is
whether it *should*).  Before forming an opinion on that, I'd like to
have a very precise understanding of what 3.10/15 bullet #5 actually
means.

So let's approach it this way:  what would be an example of a piece of
code that has well-defined behavior under the current standard, but
would have undefined behavior if the fifth bullet of 3.10/15 were
deleted from the standard?

The following is obviously *not* such an example:

  struct foo { int i; };
  foo f;
  f.i = 0;  // line A

becaue line A does *not* access the value of an object of type int
through an lvalue of type foo.  Nor would any other code using the
member access operator in a similar fashion.

So that's my question:  what currently well-defined code would have UB
if bullet #5 were deleted?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

kuyper@wizard.net wrote:
> johnchx2@yahoo.com wrote:
> > Greg Herlihy wrote:
> > > Francis Glassborow wrote:
> > > > Sorry but I find that self contradictory. If a union is and aggregate
> > > > type how can some unions not be aggregates?
> > >
> > > Any union (or other class type) that has a user-declared constructor is
> > > not an aggregate. (see    8.5.1).
> > >
> >
> > Right...which means that the language in 3.10/15 is NOT redundant,
> > contradicting the OP's claim.
>
> Thus, as currently written, 3.10/15 applies even to union types which
> are not aggregates; the proposed revision would make it apply only to
> union types which are also aggregates.

3.10/15 is meant to apply to all unions - even those unions that are
not aggregates. So the current language is not redundant - nor is it
incorrect. The only effect of making this change then would be to
transform a well-defined operation into one that would be undefined -
an outcome that seems neither desirable nor to make much sense.

Greg


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
>   ... but if we want
> to write about properties of all unions and aggregates in C++ we still
> need to write 'aggregate or union'.

johnchx2@yahoo.com wrote:
> ...which means that the language in 3.10/15 is NOT redundant,
> contradicting the OP's claim.

In C++, Aggregate or union = arrays + aggregate class + aggregate
struct + aggregate union + non-aggregate union. It seems that there is
hardly such a situation that needs to use 'aggregate or union'.

When "or" is used to connect 2 nouns, for example, A and B, the
standard should follows that either A and B are synonymous or A is
distinct from B. Since the intersection of aggregate and union is
aggregate union, not empty, in spite of the context concerned,
"aggregate or union" itself is a defect.

Greg Herlihy wrote:
> 3.10/15 is meant to apply to all unions - even those unions that are
> not aggregates. So the current language is not redundant - nor is it
> incorrect. The only effect of making this change then would be to
> transform a well-defined operation into one that would be undefined -
> an outcome that seems neither desirable nor to make much sense.

Compared with struct and class, the union characteristic is that at
most one of the data members can be active at any time (9.5-1).
However, the number of data members is irrelevant in the context, only
one of members is "one of the aforementioned types" is concerned.

Furthermore, if as you said that all (aggregate or non-aggregate)
unions are applied, then why not all (aggregate or non-aggregate)
structs? And we should say "aggregate, struct or union". Similarly, why
not all (aggregate or non-aggregate) classes? This time, it should be
"array, class, struct or union" or "array or class" simply, in which
aggregate is included.

Could "aggregate or union type" be replaced with "array or class type"
in the cited sentence? This produces another new, much deeper subject
needing to be discussed.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

whyglinux wrote:
> Francis Glassborow wrote:
> >   ... but if we want
> > to write about properties of all unions and aggregates in C++ we still
> > need to write 'aggregate or union'.
>
> johnchx2@yahoo.com wrote:
> > ...which means that the language in 3.10/15 is NOT redundant,
> > contradicting the OP's claim.
>
> In C++, Aggregate or union = arrays + aggregate class + aggregate
> struct + aggregate union + non-aggregate union. It seems that there is
> hardly such a situation that needs to use 'aggregate or union'.
>
> When "or" is used to connect 2 nouns, for example, A and B, the
> standard should follows that either A and B are synonymous or A is
> distinct from B. Since the intersection of aggregate and union is
> aggregate union, not empty, in spite of the context concerned,
> "aggregate or union" itself is a defect.

Unions and aggregates overlap in their membership - but they are
nonetheless distinct sets. The "or" in the sentence simply enumerates a
pair of unrelated conditions - any one (or both) of which has to be
matched for the condition to be met. There is no implication that the
two conditions are exclusive. An "either... or" pairing would be needed
(at the very least) to denote conditions that are meant to be exclusive
of one another.

> Greg Herlihy wrote:
> > 3.10/15 is meant to apply to all unions - even those unions that are
> > not aggregates. So the current language is not redundant - nor is it
> > incorrect. The only effect of making this change then would be to
> > transform a well-defined operation into one that would be undefined -
> > an outcome that seems neither desirable nor to make much sense.
>
> Compared with struct and class, the union characteristic is that at
> most one of the data members can be active at any time (9.5-1).
> However, the number of data members is irrelevant in the context, only
> one of members is "one of the aforementioned types" is concerned.

No, a union has other limitations compared with a class or a struct: a
union may have no virtual functions, no base classes, no static
members, and no members that are references.

> Furthermore, if as you said that all (aggregate or non-aggregate)
> unions are applied, then why not all (aggregate or non-aggregate)
> structs? And we should say "aggregate, struct or union". Similarly, why
> not all (aggregate or non-aggregate) classes? This time, it should be
> "array, class, struct or union" or "array or class" simply, in which
> aggregate is included.
>
> Could "aggregate or union type" be replaced with "array or class type"
> in the cited sentence? This produces another new, much deeper subject
> needing to be discussed.

No, the language is correct as is. A union is close enough to being an
aggegate to qualify for the purposes of 3.10, while a class or struct
can differ from an aggregate to such an extent that they are excluded
from the conditions set in 3.10/15.

Greg

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

whyglinux wrote:
> Francis Glassborow wrote:
> >   ... but if we want
> > to write about properties of all unions and aggregates in C++ we still
> > need to write 'aggregate or union'.
>
> johnchx2@yahoo.com wrote:
> > ...which means that the language in 3.10/15 is NOT redundant,
> > contradicting the OP's claim.
>
> In C++, Aggregate or union = arrays + aggregate class + aggregate
> struct + aggregate union + non-aggregate union. It seems that there is
> hardly such a situation that needs to use 'aggregate or union'.
>
> When "or" is used to connect 2 nouns, for example, A and B, the
> standard should follows that either A and B are synonymous or A is
> distinct from B. Since the intersection of aggregate and union is
> aggregate union, not empty, in spite of the context concerned,
> "aggregate or union" itself is a defect.

I don't believe that there's any such formal requirement, and would not
approve of imposing it if it were proposed. Ordinary English usage is
ambiguous on this point. If, for instance, a law says that  you're
entitled to a given tax break if you are a student or a teacher, the
fact that some students are also teachers doesn't mean that the law was
written incorrectly. Conventional use of "or" in programming contexts
is in conflict with your rule; xor is the operator that corresponds to
your rule.

If the 3.10/15 was intended (as seems to be the case) to apply to all
aggregates and all unions, including all aggregates that happen to be
unions, how would you suggest that it should be re-written?

.
> Furthermore, if as you said that all (aggregate or non-aggregate)
> unions are applied, then why not all (aggregate or non-aggregate)
> structs?

Because non-aggregate structs present problems that non-aggregate
unions don't, mainly because of the special limitations on unions.

> Could "aggregate or union type" be replaced with "array or class type"
> in the cited sentence?

No, because class types include the non-aggregate struct types for
which providing such a promise would be difficult, bordering on
impossible, for some implementations.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy wrote:

> No, the language is correct as is. A union is close enough to being an
> aggegate to qualify for the purposes of 3.10, while a class or struct
> can differ from an aggregate to such an extent that they are excluded
> from the conditions set in 3.10/15.

I actually find the intent of the provision a bit puzzling.

As I understand it, the purpose of 3.10/15 is to allow the compiler to
perform type-based alias analysis -- that is, to determine whether two
lvalues might denote the same object based on their types.

Given:

   struct A { int i; };       // aggregate
   struct B: public A {};     // non-aggregate

   void f( int& lhs, A& rhs );
   void g( int& lhs, B& rhs );

When compiling the body of f(), the compiler must assume that lhs and
rhs might denote the same object, as could happen if f() were called
like this:

   A a;
   f( a.i, a );

However, within g(), the compiler is allowed to assume that lhs and rhs
designate distinct objects, implying e.g. that writes through one don't
affect reads through the other.  So the following:

   B b;
   g( b.i, b );

could yield unexpected results.

Why does the "aggregateness" of A and B have this effect?  Or am I just
reading 3.10/15 wrong?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy wrote:

> No, a union has other limitations compared with a class or a struct: a
> union may have no virtual functions, no base classes, no static
> members, and no members that are references.

> No, the language is correct as is. A union is close enough to being an
> aggegate to qualify for the purposes of 3.10, while a class or struct
> can differ from an aggregate to such an extent that they are excluded
> from the conditions set in 3.10/15.

You believe all unions are applied in 3.10/15 condition, of course
including unions with user-declared constructors, don't you?

Then how about a struct with no virtual functions, no base classes, no
static members, and no members that are references but with a
user-declared constructor? Obviously such a struct is not aggregate and
banned accordingly. Should the current standard be revised to accept
suchlike structs?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> As I understand it, the purpose of 3.10/15 is to allow the compiler to
> perform type-based alias analysis -- that is, to determine whether two
> lvalues might denote the same object based on their types.

I think you are right.

> Given:
>
>    struct A { int i; };       // aggregate
>    struct B: public A {};     // non-aggregate
>    void g( int& lhs, B& rhs );
>
> Within g(), the compiler is allowed to assume that lhs and rhs
> designate distinct objects, implying e.g. that writes through one don't
> affect reads through the other.  So the following:
>
>    B b;
>    g( b.i, b );
>
> could yield unexpected results.

No.  Assuming g accesses rhs.i at some point, both access to b.i
occured through the dynamic type of the b object.  Since you can write
this code this way, the compiler must assume that lhs and rhs.i may
refer to the same object.

> Why does the "aggregateness" of A and B have this effect?  Or am I just
> reading 3.10/15 wrong?

I think you are reading it wrong.  The compiler can assume that writes
to floats do not modify ints.  Likewise for independent non-aggregate
structs (even if their layouts appear similar.).

struct b {};
struct d1: b { int i; };
struct d2: b { int i; };

In a context where the compiler holds a reference to a d1, and a
reference to a d2, it may assume that writes to one of the objects do
not affect the other.  If d1 and d2 were aggregates (no base class),
the compiler would not be able to make that assumption, because they
would be "layout compatible."

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

kuyper@wizard.net wrote:

> whyglinux wrote:.
> > In C++, Aggregate or union = arrays + aggregate class + aggregate
> > struct + aggregate union + non-aggregate union. It seems that there is
> > hardly such a situation that needs to use 'aggregate or union'.
> >
> > When "or" is used to connect 2 nouns, for example, A and B, the
> > standard should follows that either A and B are synonymous or A is
> > distinct from B. Since the intersection of aggregate and union is
> > aggregate union, not empty, in spite of the context concerned,
> > "aggregate or union" itself is a defect.

I will give A and B a much stricter limit: when they are terms defined
in the standard, then the above "A or B" rule works much better.

> I don't believe that there's any such formal requirement, and would not
> approve of imposing it if it were proposed.

Such requirement is formal or not I don't know, only I think it is
better to follow it. In the standard, the "or" is used *almost* in such
ways.

> Ordinary English usage is
> ambiguous on this point. If, for instance, a law says that  you're
> entitled to a given tax break if you are a student or a teacher, the
> fact that some students are also teachers doesn't mean that the law was
> written incorrectly. Conventional use of "or" in programming contexts
> is in conflict with your rule; xor is the operator that corresponds to
> your rule.

In reality, ambiguity may not be avoided. For your example, a student
is also a teacher, and vice versa. But in a well-prepared computer
language standard, a virtual world, ambiguity is not welcome and
expected to be banished. Terms are carefully chosen and defined to
represent concepts so as to aviod ambiguity.

> If the 3.10/15 was intended (as seems to be the case) to apply to all
> aggregates and all unions, including all aggregates that happen to be
> unions, how would you suggest that it should be re-written?

First of all, "aggregate or union" should be kicked out since the
intersection of aggregate and union is not empty as I said before.

It could be written as "array, aggregate class, aggregate struct, or
union". Or if the concept is needed elsewhere, it's better to define a
unique term to express it and then use the defined term when necessary.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

wade@stoner.com wrote:
> johnchx2@yahoo.com wrote:
> > Given:
> >
> >    struct A { int i; };       // aggregate
> >    struct B: public A {};     // non-aggregate
> >    void g( int& lhs, B& rhs );
> >
> > Within g(), the compiler is allowed to assume that lhs and rhs
> > designate distinct objects, implying e.g. that writes through one don't
> > affect reads through the other.  So the following:
> >
> >    B b;
> >    g( b.i, b );
> >
> > could yield unexpected results.
>
> No.  Assuming g accesses rhs.i at some point, both access to b.i
> occured through the dynamic type of the b object.  Since you can write
> this code this way, the compiler must assume that lhs and rhs.i may
> refer to the same object.

Yes, but the expression "rhs.i" is an lvalue of type int, which could
denote the same object as any other lvalue of type int.  So explicit
use of "rhs.i" doesn't involve the "fifth bullet" of 3.10/15, which is
the provision I'm trying to understand.

Perhaps another way to phrase the question is, "How exactly does one
access a value 'through' an lvalue of a 'containing' aggregate or union
type?"

Here's an example which *might* invovle the fifth bullet:

   struct A { int i; }
   struct B: A {};

   int f( int& lhs, A& rhs )
   {
      ++lhs;            // 1: access through int lvalue
      A a2 (rhs);       // 2: access through A lvalue
      return a2.i;
   }

   int g( int& lhs, B& rhs )
   {
      ++lhs;            // 3: access through int lvalue
      B b2 (rhs);       // 4: access through B lvalue
      return b2.i;
   }

   int main()
   {
      A a = {0};
      B b;
      b.i = 0;
      int j = f( a.i, a );
      int k = g( b.i, b );
   }


My questions: is line 2 the sort of access that bullet 5 is meant to
encompass?  If so, does that mean that the compiler is prohibited from
executing lines 1 and 2 in reverse order, but is permitted to reverse
the orders of lines 3 and 4?

If not, what would be an example of a situation in which the
"aggregate-ness" of a class affects the defined-ness of program
behavior under the terms of 3.10/15 bullet 5?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

whyglinux wrote:
> kuyper@wizard.net wrote:
.
> > Ordinary English usage is
> > ambiguous on this point. If, for instance, a law says that  you're
> > entitled to a given tax break if you are a student or a teacher, the
> > fact that some students are also teachers doesn't mean that the law was
> > written incorrectly. Conventional use of "or" in programming contexts
> > is in conflict with your rule; xor is the operator that corresponds to
> > your rule.
>
> In reality, ambiguity may not be avoided. For your example, a student
> is also a teacher, and vice versa. But in a well-prepared computer
> language standard, a virtual world, ambiguity is not welcome and
> expected to be banished. Terms are carefully chosen and defined to
> represent concepts so as to aviod ambiguity.

If you want to the standard use a term that is restricted in that
manner, then "or" seems a poor choice, since this is more restrictive
than conventional english usage of "or", and in conflict with
math/computer science usage of "or". Use "xor" instead - that will make
the unconventional restrictions less surprising.

.
> It could be written as "array, aggregate class, aggregate struct, or
> union". Or if the concept is needed elsewhere, it's better to define a
> unique term to express it and then use the defined term when necessary.

I don't see how that counts as an improvement, even in your terms. As
C++ defines it, a struct and a union are both special types of classes,
so "aggregate class", "aggregate struct", and "union" are still
overlapping categories. This might give you a hint as to why
prohibition of overlaps in "or"s is a bad idea. When you want to do a
conventional "or" of, for instance, a half-dozen complexly overlapping
categories, the re-wording needed to split them into non-overlapping
categories could take several paragraphs, and would be much harder to
understand than when written with overlapping categories.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <1150464441.212863.93900@i40g2000cwc.googlegroups.com>,
whyglinux <whyglinux@gmail.com> writes
>Such requirement is formal or not I don't know, only I think it is
>better to follow it. In the standard, the "or" is used *almost* in such
>ways.
The logical operators in natural languages are great sources of
difficulty. However the English default is NOT the exclusive or but the
inclusive version which is also the boolean or. i.e A or B == not(not A
and not B)

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> what would be an example of a situation in which the
> "aggregate-ness" of a class affects the defined-ness of program
> behavior under the terms of 3.10/15 bullet 5?

C++ is somewhat schizoid.  Some goals:

  1) Strongly typed.
  2) Legal C code that is syntactically correct C++ should have the
same meaning in C++.

Of course neither goal is met entirely, but it tries.

This code fragment is well defined in C89

  struct a { int i; };
  struct b { int j; };

  struct a a_ = { 1 };
  struct b *bp_ = (b*) &a_;  /* A C "reinterpret cast " */
  bp_->j = 2;
  printf("%d", a_.i);

In informal terms:

The C++ guys don't want you playing with the reinterpret cast that way,
on the other hand they didn't want to break existing C code.  As long
as 'a' and 'b' are aggregates, the code is intended to be legal C++
(I'm not sure that's exactly what the standard says, but it seems to be
the intent).  If 'a' or 'b' is not an aggregate, this isn't C code (all
C89 structs are C++ aggregates), so the compiler is given the C++
license to assume that programmers are playing by stronger typing
rules.

Look at C++, Annex C.1.2/5 (also labelled 3.9), "C allows compatible
types ... C++ does not  ... those problems not found by typesafe
linkage will continue to function properly ... "

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

kuyper@wizard.net wrote:

> If you want to the standard use a term that is restricted in that
> manner, then "or" seems a poor choice, since this is more restrictive
> than conventional english usage of "or",

Perhaps the standard has tried to do so and it's reasonable to use "or"
in a more restrictive manner in the standard than normal if both A and
B in "A or B" refer to defined terms.

> and in conflict with
> math/computer science usage of "or". Use "xor" instead - that will make
> the unconventional restrictions less surprising.

No, the "or" has the same meaning as that of math/computer and others,
which is a method that usually produces a "bigger" set. Thus the
*results* of "or" are the same. The difference lies that whether the
"operands" of "or" should be restricted or not. Normally not, but in
the standard, it's better that A, B in "A or B" are distinct and thus
the "or" should be used restrictively.

As to "xor", yes, if A and B are distinct, "A or B" equals "A xor B"
and so whichever to be used is no matter.

> whyglinux wrote:
> .
> > It could be written as "array, aggregate class, aggregate struct, or
> > union". Or if the concept is needed elsewhere, it's better to define a
> > unique term to express it and then use the defined term when necessary.
>
> I don't see how that counts as an improvement, even in your terms. As
> C++ defines it, a struct and a union are both special types of classes,
> so "aggregate class", "aggregate struct", and "union" are still
> overlapping categories.

Sorry, it's my fault to make you think so as I can hardly find suitable
terms in the standard. I meant "aggregate class", "aggregate struct"
and "union" are distinct from each other of course as I suggested
before, i.e. "aggregate class" here only refers to those defined with
the class-key class(, which is different from the "aggregate class" in
the standard, my fault).

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

whyglinux wrote:
.
> the standard, it's better that A, B in "A or B" are distinct and thus
> the "or" should be used restrictively.

Why? All that such a requirement would do is require that sets which
can be easily described as unions of overlapping sets would have to be
described in a more complicated fashion as the union of non-overlapping
sets. The more complicated description would, in general, be harder to
understand than the original. Taking the case that is the topic of this
thread. It will make the problem clearer if I prohibit you from
inventing new terminology. Using only existing terminology, there are
several ways that it could be re-written to express the intent in terms
of non-overlapping sets. You could say "non-aggregate union or
aggregate", or you could  say "non-union aggreggate or union". If the
assymettry bothers you , you describe it as the union of three
non-overlapping sets: "non-union aggregate or union aggreggate  or
non-aggregate union". Would you argue that any one of these is easier
to correctly understand than "aggregate or union"?

If there was an existing convention that "or" requires non-overlapping
categories, writing things in an unnecessarily complicated way to
adhere to that convention might be the price we would have to pay in
order to avoid confusion - but I'm aware of no such convention.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:

Forwarded to C++ Committee


===================================== END OF MODERATOR'S COMMENT
The C++ standard says in Section 3.10, in paragraph 15:

"an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union)"

Note that it is a literal copy from the C standard, but this is of
course not the problem.

In C, union is not defined as an aggregate type. Therefore it is
appropriate to say "aggregate or union". But things changed in C++:
aggregate type includes union type now (though not all unions are
aggregates), and it becomes clear that the "union" in "aggregate or
union" is redundant and should be deleted.

The above cited paragraph could be changed to:

an aggregate type that includes one of the aforementioned types among
its members (including, recursively, a member of a subaggregate)

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <1149921986.823720.116630@m38g2000cwc.googlegroups.com>,
whyglinux <whyglinux@gmail.com> writes
>In C, union is not defined as an aggregate type. Therefore it is
>appropriate to say "aggregate or union". But things changed in C++:
>aggregate type includes union type now (though not all unions are
>aggregates),
Sorry but I find that self contradictory. If a union is and aggregate
type how can some unions not be aggregates?

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
> In article <1149921986.823720.116630@m38g2000cwc.googlegroups.com>,
> whyglinux <whyglinux@gmail.com> writes
> >In C, union is not defined as an aggregate type. Therefore it is
> >appropriate to say "aggregate or union". But things changed in C++:
> >aggregate type includes union type now (though not all unions are
> >aggregates),
> Sorry but I find that self contradictory. If a union is and aggregate
> type how can some unions not be aggregates?

Any union (or other class type) that has a user-declared constructor is
not an aggregate. (see    8.5.1).

Greg


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

In article <1150231525.813284.25710@f6g2000cwb.googlegroups.com>, Greg=20
Herlihy <greghe@pacbell.net> writes
>
>Francis Glassborow wrote:
>> In article <1149921986.823720.116630@m38g2000cwc.googlegroups.com>,
>> whyglinux <whyglinux@gmail.com> writes
>> >In C, union is not defined as an aggregate type. Therefore it is
>> >appropriate to say "aggregate or union". But things changed in C++:
>> >aggregate type includes union type now (though not all unions are
>> >aggregates),
>> Sorry but I find that self contradictory. If a union is and aggregate
>> type how can some unions not be aggregates?
>
>Any union (or other class type) that has a user-declared constructor is
>not an aggregate. (see =A78.5.1).
>
  But that means that the term 'aggregate' in C++ is not equivalent to=20
'aggregate or union'. It seems that the term 'aggregate in C++ is=20
synonymous with the expression 'aggregate or union' in C but if we want=20
to write about properties of all unions and aggregates in C++ we still=20
need to write 'aggregate or union'.

--=20
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/pr=
ojects

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy wrote:
> Francis Glassborow wrote:
> > Sorry but I find that self contradictory. If a union is and aggregate
> > type how can some unions not be aggregates?
>
> Any union (or other class type) that has a user-declared constructor is
> not an aggregate. (see    8.5.1).
>

Right...which means that the language in 3.10/15 is NOT redundant,
contradicting the OP's claim.


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> Greg Herlihy wrote:
> > Francis Glassborow wrote:
> > > Sorry but I find that self contradictory. If a union is and aggregate
> > > type how can some unions not be aggregates?
> >
> > Any union (or other class type) that has a user-declared constructor is
> > not an aggregate. (see    8.5.1).
> >
>
> Right...which means that the language in 3.10/15 is NOT redundant,
> contradicting the OP's claim.

Thus, as currently written, 3.10/15 applies even to union types which
are not aggregates; the proposed revision would make it apply only to
union types which are also aggregates.


---
[ 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.comeaucomputing.com/csc/faq.html                      ]