Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > A missing language feature?

Reply
Thread Tools

A missing language feature?

 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      09-01-2009
I think it's a language defect, or at least an inconsistency, that a definition
of F generally can't use the same type names as the earlier declaration of F.

The source of this problem is that by current rules the compiler evaluates the
routine result type declaration before knowing which routine it's compiling: the
result type, as opposed to argument types, is not evaluated in the routine's
declaration context.

It would IMHO be nice with consistent rules, the same rules, for arguments and
result types.


Cheers,

- Alf (grumbling)


PS: Of course, an even more missing language feature is some sort of module
support. The administrative overhead of using libraries in C++, specifying
header and library search paths, binary names etc., is O(n^2) where n is the
number of libraries that are being developed within a project. That's silly.
 
Reply With Quote
 
 
 
 
Saeed Amrollahi
Guest
Posts: n/a
 
      09-01-2009
On Sep 1, 5:26*am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> I think it's a language defect, or at least an inconsistency, that a definition
> of F generally can't use the same type names as the earlier declaration of F.
>
> The source of this problem is that by current rules the compiler evaluates the
> routine result type declaration before knowing which routine it's compiling: the
> result type, as opposed to argument types, is not evaluated in the routine's
> declaration context.
>
> It would IMHO be nice with consistent rules, the same rules, for arguments and
> result types.
>
> Cheers,
>
> - Alf (grumbling)
>
> PS: Of course, an even more missing language feature is some sort of module
> support. The administrative overhead of using libraries in C++, specifying
> header and library search paths, binary names etc., is O(n^2) where n is the
> number of libraries that are being developed within a project. That's silly.


Hi Alf

I can't understand what do you mean, Please throw the light
by an example.
Also, I definitely sure, you know the best place to discuss missing/
new/defect
feature is comp.std.c++.

AFAIK, There is some proposal for adding Module by Daveed Vandevoorde
in C++ standard committee. Of course it will be for TR2.

Regards,
-- Saeed Amrollahi

standard
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      09-01-2009
* Saeed Amrollahi:
> On Sep 1, 5:26 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
>> I think it's a language defect, or at least an inconsistency, that a definition
>> of F generally can't use the same type names as the earlier declaration of F.
>>
>> The source of this problem is that by current rules the compiler evaluates the
>> routine result type declaration before knowing which routine it's compiling: the
>> result type, as opposed to argument types, is not evaluated in the routine's
>> declaration context.
>>
>> It would IMHO be nice with consistent rules, the same rules, for arguments and
>> result types.
>>
>> Cheers,
>>
>> - Alf (grumbling)
>>
>> PS: Of course, an even more missing language feature is some sort of module
>> support. The administrative overhead of using libraries in C++, specifying
>> header and library search paths, binary names etc., is O(n^2) where n is the
>> number of libraries that are being developed within a project. That's silly.

>
> Hi Alf
>
> I can't understand what do you mean, Please throw the light
> by an example.


struct Foo
{
typedef Foo Outer;
enum E {};

struct Bar
{
Outer* F( E ) const;
};
};

// Outer* Foo::Bar::F( E ) const { return 0; } -- Nah, but E is OK.
Foo* Foo::Bar::F( E ) const { return 0; // -- Different, OK.

int main()
{}


> Also, I definitely sure, you know the best place to discuss missing/
> new/defect
> feature is comp.std.c++.


I'm just letting out steam.

There's no chance of any new feature in C++0x.

Nor, I think, in C++0x's successor, if any, which IMHO will be the last C++
standard.


> AFAIK, There is some proposal for adding Module by Daveed Vandevoorde
> in C++ standard committee. Of course it will be for TR2.


I'm not sure. There's always the 'export' issue standing in the way of anything
module-like. I think we'd need ABI standardization along with modules.


Cheers,

- Alf
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      09-01-2009
* Saeed Amrollahi:
> On Sep 1, 5:26 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
>> I think it's a language defect, or at least an inconsistency, that a definition
>> of F generally can't use the same type names as the earlier declaration of F.
>>
>> The source of this problem is that by current rules the compiler evaluates the
>> routine result type declaration before knowing which routine it's compiling: the
>> result type, as opposed to argument types, is not evaluated in the routine's
>> declaration context.
>>
>> It would IMHO be nice with consistent rules, the same rules, for arguments and
>> result types.
>>
>> Cheers,
>>
>> - Alf (grumbling)
>>
>> PS: Of course, an even more missing language feature is some sort of module
>> support. The administrative overhead of using libraries in C++, specifying
>> header and library search paths, binary names etc., is O(n^2) where n is the
>> number of libraries that are being developed within a project. That's silly.

>
> Hi Alf
>
> I can't understand what do you mean, Please throw the light
> by an example.


Here's a better (worse) example than the fictiuous one I presented else-thread:


class TextEdit
{
protected:
class ApiWindowFactory
{
public:
typedef api::windowStyle::InsetElement InsetElement;

virtual InsetElement::Enum insetElements() const;
};
};


With inline code the definition of that routine is clean, but with a separate
definition in an implementation file ...


TextEdit::ApiWindowFactory::InsetElement::Enum
TextEdit::ApiWindowFactory::insetElements() const
{
...
}


.... just the routine head, a routine with no arguments, is an ungrokkable 101
character line, with extreme redundancy.

Utterly disgusting!


Cheers,

- Alf
 
Reply With Quote
 
Michael Doubez
Guest
Posts: n/a
 
      09-01-2009
On 1 sep, 04:26, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> I think it's a language defect, or at least an inconsistency, that a definition
> of F generally can't use the same type names as the earlier declaration of F.
>
> The source of this problem is that by current rules the compiler evaluates the
> routine result type declaration before knowing which routine it's compiling: the
> result type, as opposed to argument types, is not evaluated in the routine's
> declaration context.
>
> It would IMHO be nice with consistent rules, the same rules, for arguments and
> result types.


But then, how would you address the problem of:

class Outer { ...} ;

struct Foo
{
Outer* bla();

typedef Foo Outer;
enum E {};

struct Bar
{
Outer* F( E ) const;
};
};

// Outer must be external outer
Outer* Foo::bla();

// Outer must be Foo::Outer
Outer* Foo::Bar::F( E ) const { return 0; }

int main()
{}

You would not be able to specify Foo::bla because then, it would
believe it to be
Foo::Outer* Foo::bla().

--
Michael
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      09-01-2009
* Michael Doubez:
> On 1 sep, 04:26, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
>> I think it's a language defect, or at least an inconsistency, that a definition
>> of F generally can't use the same type names as the earlier declaration of F.
>>
>> The source of this problem is that by current rules the compiler evaluates the
>> routine result type declaration before knowing which routine it's compiling: the
>> result type, as opposed to argument types, is not evaluated in the routine's
>> declaration context.
>>
>> It would IMHO be nice with consistent rules, the same rules, for arguments and
>> result types.

>
> But then, how would you address the problem of:
>
> class Outer { ...} ;
>
> struct Foo
> {
> Outer* bla();
>
> typedef Foo Outer;


Shouldn't do that for portable code (see below)...

> enum E {};
>
> struct Bar
> {
> Outer* F( E ) const;
> };
> };
>
> // Outer must be external outer
> Outer* Foo::bla();
>
> // Outer must be Foo::Outer
> Outer* Foo::Bar::F( E ) const { return 0; }
>
> int main()
> {}
>
> You would not be able to specify Foo::bla because then, it would
> believe it to be
> Foo::Outer* Foo::bla().


I'm saying ideally one should have the same rules for result type as for arguments.

Hence there's no problem for result type that isn't there already for arguments.

But you're pointing out a real problem for existing rules for argument types.


<code>
class Outer {} ;

struct Foo
{
void bla( Outer* );

typedef Foo Outer;
enum E {};

struct Bar
{
void F( E, Outer* ) const;
};
};

// Outer must be external outer
void Foo::bla( Outer* ) {}

// Outer must be Foo::Outer
void Foo::Bar::F( E, Outer* ) const {}

int main()
{}
</code>


<comeau>
Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions

"ComeauTest.c", line 17: error: declaration is incompatible with
"void Foo::bla(Outer *)" (declared at line 5)
void Foo::bla( Outer* ) {}
^

1 error detected in the compilation of "ComeauTest.c".
</comeau>


<mingw g++>
hm6.cpp:7: error: declaration of `typedef struct Foo Foo::Outer'
hm6.cpp:1: error: changes meaning of `Outer' from `class Outer'
hm6.cpp:17: error: prototype for `void Foo::bla(Foo*)' does not match any in
class `Foo'
hm6.cpp:5: error: candidate is: void Foo::bla(Outer*)
</mingw g++>


<msvc>
hm6.cpp(17) : error C2511: 'void Foo::bla(Foo::Outer *)' : overloaded member
function not found in 'Foo'
hm6.cpp(4) : see declaration of 'Foo'
</msvc>


It's a different problem.

Intuitively argument types should be looked up in the context of the original
declaration, but the problem is that which declaration that is may depend on the
argument types, which is a bit circular. So the problem you point out (for the
existing language rules) can't be solved in general that way. Some qualification
is simply required when one chooses to "overload" a type name.


Cheers,

- Alf
 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      09-03-2009

"Alf P. Steinbach" <(E-Mail Removed)>
> // Outer* Foo::Bar::F( E ) const { return 0; } -- Nah, but E is OK.
> Foo* Foo::Bar::F( E ) const { return 0; // -- Different, OK.
>
> int main()
> {}
>
>
>> Also, I definitely sure, you know the best place to discuss missing/
>> new/defect
>> feature is comp.std.c++.

>
> I'm just letting out steam.
>
> There's no chance of any new feature in C++0x.


But C++0x IIRC covers this problem (to some degree), if you use the new
function decl syntax, that paces the return type at tail.

something like
auto Foo::Bar::F( E ) const -> Outer*; // picks Outer in F's context

possibly there are other new ways too.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
writing a compiler for Monster language using C language Shravani C Programming 8 03-16-2008 09:36 PM
A language-agnostic language Ed Java 24 03-27-2006 08:19 PM
c is a low-level language or neither low level nor high level language pabbu C Programming 8 11-07-2005 03:05 PM
Using a Scripting Language as Your Scripting Language DaveInSidney Python 0 05-09-2005 03:13 AM
Python is the best and most popular general purpose scripting language; the universal scripting language Ron Stephens Python 23 04-12-2004 05:32 PM



Advertisments