Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Should this compile?

1 view
Skip to first unread message

meeroh

unread,
May 6, 2001, 3:56:48 PM5/6/01
to
Should this compile?

class foo {
foo ();
};

void foo (void);

class bar {
bar& operator = (const foo&);
};

meeroh
--
To get random signatures put text files into a folder called "Random Signatures" into your Preferences folder.

Greg Weston

unread,
May 6, 2001, 5:55:34 PM5/6/01
to
[[ This message was both posted and mailed: see
the "To," "Cc," and "Newsgroups" headers for details. ]]

In article <macdev-1A9C8C....@senator-bedfellow.mit.edu>,
meeroh <mac...@meeroh.org> wrote:

> Should this compile?
>
> class foo {
> foo ();
> };
>
> void foo (void);
>
> class bar {
> bar& operator = (const foo&);
> };


I don't have a compiler or a copy of the spec handy but I see a couple
of things that raise my eyebrows:

1) Objects of type foo can't be created because the only constructor
overrides the default and is private. That shouldn't interfere with the
function in bar, but it does kind of make the snippet pointless.

2) Not sure about the issue of having a type and a function with the
same name. Although they don't really, I guess, given name-mangling.

What are you seeing?

G

Howard Hinnant

unread,
May 6, 2001, 7:58:09 PM5/6/01
to
[[ This message was both posted and mailed: see
the "To," "Cc," and "Newsgroups" headers for details. ]]

| Should this compile?
|
| class foo {
| foo ();
| };
|
| void foo (void);
|
| class bar {
| bar& operator = (const foo&);
| };

At the risk of playing language lawyer (which I most definitely am
not), have a look at 3.3/4:

| -4- Given a set of declarations in a single declarative region, each of
| which specifies the same unqualified name,
|
|
| * they shall all refer to the same entity, or all refer to functions
| and function templates; or
|
| * exactly one declaration shall declare a class name or enumeration
| name that is not a typedef name and the other declarations shall all
| refer to the same object or enumerator, or all refer to functions and
| function templates; in this case the class name or enumeration name is
| hidden (basic.scope.hiding). [Note: a namespace name or a class
| template name must be unique in its declarative region
| (namespace.alias, clause temp). ]

The second bullet seems to say that the function foo hides the class
foo, and so the error message is correct.

--
Howard Hinnant
Metrowerks

meeroh

unread,
May 6, 2001, 8:46:01 PM5/6/01
to
In article <060520012000070073%hin...@antispam.metrowerks.com>,
Howard Hinnant <hin...@antispam.metrowerks.com> wrote:

>[[ This message was both posted and mailed: see
> the "To," "Cc," and "Newsgroups" headers for details. ]]
>

>| * exactly one declaration shall declare a class name or enumeration
>| name that is not a typedef name and the other declarations shall all
>| refer to the same object or enumerator, or all refer to functions and
>| function templates; in this case the class name or enumeration name is
>| hidden (basic.scope.hiding). [Note: a namespace name or a class
>| template name must be unique in its declarative region
>| (namespace.alias, clause temp). ]
>
>The second bullet seems to say that the function foo hides the class
>foo, and so the error message is correct.

Excellent, thanks :-)

meeroh
--
The contents of text files in a folder called "Random Signatures" in your Preferences folder are used as random signatures.

Ron Hunsinger

unread,
May 7, 2001, 7:38:09 AM5/7/01
to

> In article <macdev-1A9C8C....@senator-bedfellow.mit.edu>,
> meeroh <mac...@meeroh.org> wrote:
>
> | Should this compile?
> |
> | class foo {
> | foo ();
> | };
> |
> | void foo (void);
> |
> | class bar {
> | bar& operator = (const foo&);
> | };
>
> At the risk of playing language lawyer (which I most definitely am
> not), have a look at 3.3/4:
>
> | -4- Given a set of declarations in a single declarative region, each of
> | which specifies the same unqualified name,
> |
> |
> | * they shall all refer to the same entity, or all refer to functions
> | and function templates; or
> |
> | * exactly one declaration shall declare a class name or enumeration
> | name that is not a typedef name and the other declarations shall all
> | refer to the same object or enumerator, or all refer to functions and
> | function templates; in this case the class name or enumeration name is
> | hidden (basic.scope.hiding). [Note: a namespace name or a class
> | template name must be unique in its declarative region
> | (namespace.alias, clause temp). ]
>
> The second bullet seems to say that the function foo hides the class
> foo, and so the error message is correct.

However, the hidden class name can still be unhidden by using an elaborated
name. See 3.4.4/1:

An elaborated-type-specifier may be used to refer to a previously
declared class-name or enum-name even though the name has been
hidden by a non-type declaration (3.3.7). The class-name or
enum-name in the elaborated-type-specifier may either be a simple
identifer or be a qualified-id.

That is, you could still declare bar::operator= the way you want, by writing:

class bar {
bar& operator= (const class foo&);
};

This is the rationale for letting the non-type name hide the type name;
since it's easy to unhide the type name by elaborating it (adding "struct"
or "class"), but not so easy to unhide the non-type name, it's better to
hide the name that can be easily unhidden.

-Ron Hunsinger

Howard Hinnant

unread,
May 7, 2001, 7:48:36 AM5/7/01
to
In article <hnsngr-ya0231800...@news.pacbell.net>, Ron
Hunsinger <hns...@sirius.com> wrote:

| However, the hidden class name can still be unhidden by using an elaborated
| name. See 3.4.4/1:
|
| An elaborated-type-specifier may be used to refer to a previously
| declared class-name or enum-name even though the name has been
| hidden by a non-type declaration (3.3.7). The class-name or
| enum-name in the elaborated-type-specifier may either be a simple
| identifer or be a qualified-id.
|
| That is, you could still declare bar::operator= the way you want, by writing:
|
| class bar {
| bar& operator= (const class foo&);
| };
|
| This is the rationale for letting the non-type name hide the type name;
| since it's easy to unhide the type name by elaborating it (adding "struct"
| or "class"), but not so easy to unhide the non-type name, it's better to
| hide the name that can be easily unhidden.

You learn something every day! Thanks for the education. I guess
there's still hope I may pass the language lawyer bar some day. :-)

-Howard

--
Howard Hinnant
Metrowerks

meeroh

unread,
May 7, 2001, 9:56:09 AM5/7/01
to
In article <070520010750315634%hin...@antispam.metrowerks.com>,
Howard Hinnant <hin...@antispam.metrowerks.com> wrote:

>| However, the hidden class name can still be unhidden by using an elaborated
>| name. See 3.4.4/1:

Ah, yeha, thanks, I figured that our by experimentation, but I wasn't
sure that the error was supposed to be there in the first place. thanks

meeroh

unread,
May 7, 2001, 9:56:28 AM5/7/01
to
In article <070520010750315634%hin...@antispam.metrowerks.com>,
Howard Hinnant <hin...@antispam.metrowerks.com> wrote:

>| However, the hidden class name can still be unhidden by using an elaborated
>| name. See 3.4.4/1:

Ah, yeah, I figured that our by experimentation, but I wasn't
sure that the error was supposed to be there in the first place. Thanks
:-)

meeroh
--
Using random signatures is as simple as putting text files into a folder called "Random Signatures" in your Preferences folder.

0 new messages