views:

221

answers:

2

Having code:

struct B
{
    int* a;
    B(int value):a(new int(value))
    {   }
    B():a(nullptr){}
    B(const B&);
}

B::B(const B& pattern)
{

}

I'm getting err msg:
'Error 1 error C2533: 'B::{ctor}' : constructors not allowed a return type'

Any idea why?
P.S. I'm using VS 2010RC

+9  A: 

You're missing a semicolon after your struct definition.


The error is correct, constructors have no return type. Because you're missing a semicolon, that entire struct definition is seen as a return type for a function, as in:

// vvv return type vvv
struct { /* stuff */ } foo(void)
{
}

Add your semicolon:

struct B
{
    int* a;
    B(int value):a(new int(value))
    {   }
    B():a(nullptr){}
    B(const B&);
}; // end class definition

// ah, no return type
B::B(const B& pattern)
{

}
GMan
Thanks. BTW does anyone knows in c++0x there won't be need for that silly semicolon? When you think about this it's somewhat incosistent with other constructs in c++. Or am I missing something?
There is nothing we can do
It's kind of a c hangover, the declaration of a struct is the definition of a type, and the declaration of a class looks like a struct. ps VS2010 warns you about this!
Martin Beckett
@Martin: it's not just a "hangover" from C. Something like: `class { /* ...*/ } object;` is allowed, so the semicolon is *needed* to tell the compiler it's reached the end of the class definition.
Jerry Coffin
+6  A: 

You need a better compiler :-) With g++:

a.cpp:1: error: new types may not be defined in a return type
a.cpp:1: note: (perhaps a semicolon is missing after the definition of 'B')
a.cpp:5: error: return type specification for constructor invalid

The semicolon is needed because it terminates a possible list of instances of the struct:

struct B {
...
} x, y, z;

Creates three instances of B called x, y and z. This is part of C++'s C heritage, and will still be there in C++0x.

anon
+1 for rationale. :)
GMan
+1 for answer, -1 for rationale. It is relatively easy to implement(for pros) that if there is nothing after bracket thats the end of the decl.
There is nothing we can do
@atch You are an expert on parsing C++ now? The point is that there *is* something after the struct - your constructor.
anon
@atch: Have you ever written a compiler?
GMan
+1 for recommending g++. :)
missingfaktor
@GMan Or even just a parser. Its really easy to create ambiguous grammars that look correct, but have subtle problems.
KeithB
@Neil and GMan - As I've said it should be relatively easy to implement this functionality for pros. No I'm not a pro. Not I'm not expert on parsing C++ and no I've never written a compiler. I is irrelevant. The relevant thing is that this could/should be easily avoided (circumvent). And unfortunately I'm finding your comment Neil passively agressive.
There is nothing we can do
@atch: If you want whitespace to mean something, use python. In C++, end of line doesn't terminate anything (except comments, which are stripped out by the preprocessor before the actual compiler even sees the code).
Ben Voigt
And if you don't have to have semicolon after B::B(){} and so on and so forth. I'm not even going to start this discussion because I know how it will end up. I've personally tried to discuss various things on various forums and unfortunatelly it seems like you cannot critisize anything because people are thinking that you trying to start a raw. No thanks. 've been there, done that, got a t-shirt.
There is nothing we can do
@Ben so why after function definition you don't have to have semicolon? Just because somebody explains you something it doesn't nesecarilly mean that this explanaition makes sense. And in this case this is very lousy.
There is nothing we can do
Last comment in this topic I hope. And how many times anyone of you uses construct presented by Neil (I'm not saying that is there anything wrong with this construct I'm just wondering if it's something that exists in C++ but people rarely use it). As I'm just a student I really wonder.
There is nothing we can do
@atch: No, it *is* about you. "You" is absolutely relevant. Because you *aren't* a pro you're the last person who should be telling the pro's what they can do and what's possible. C++ is one of the hardest language to parse. You're saying "I'm not a pro, but I know (contradictory to the previous statement) they could do it, they should do it." The point is you're making claims ("It is relatively easy to implement(for pros) that if there is nothing after bracket thats the end of the decl.") that you have no basis to make. It's harder than it looks.
GMan
@GMan can't agree with you, this type of lousy explanaition (and I know this isn't yours or anyone's from this forum, you just quote somebody) reminds me explanation of why we did have have to write template<template<> >(space between). And you don't have to be an expert to feel that something isn't right and should be changed.
There is nothing we can do
@atch: Your logic is poor. "Feeling" something isn't right doesn't make it so. If you've never tried to parse something, you're going to make uninformed estimations on it's difficulty; why would you take that estimation as if it were accurate? An appeal to ridicule is a fallacy.
GMan
@GMan - But would you like to see this feature in next C++ standard? I'm sure it would make sense to have it. Saying that I know that I'm not experienced enough to argue so I'm quitting this discussion now.
There is nothing we can do
@atch: And that's okay. Don't mean to make anyone feel like they're stupid or their ideas are worthless. I just think it's best (in any aspect) that when someone doesn't know something very well, they shouldn't try to push their ideas to hard against those who do know something well. Better is to say "Hm, this must be harder than it seems, I'll just try to see what they have to say." I don't know parsing well at all, myself, but I've tried and it's bitching. I'm sure simplifying the syntax would be great, if possible, but you'd be introducing more context-sensitive parsing, the same thing...
GMan
@atch You say you found my comment "passively aggressive"? Well, I find yours actively aggressive, and ignorant to boot. If you had read my answer, you would have seen why the semicolon is required, and why it is not required after (for example) a function. But who needs this shit - I won't be answering any more of your questions.
anon
(continued) ...that makes parsing C++ as difficult as it is now. In honesty, it's not broken, so there isn't a need to fix it. I'm sure it's not as simple as it seems. :\
GMan
@Neil I'm sorry but could you kindly point it out to me the comment which according to you is actively agressive? I'm really looking forward to see that. And as for your last sentence in your last comment-pathetic and childish. It seems like you can't/don't want to discuss in civilized way without starting to swear and getting upset and jittery. You're right Neil though, until I didn't know your character I didn't mind your answers but knowing it, I don't want to be answered by little princess.
There is nothing we can do
@atch: since you asked "how many people ever use this" (meaning a declarator after the type definition, I looked through the public windows header files (windef.h and winbase.h actually) and couldn't find a single instance that didn't have a declarator. Sometimes it was a typedef (or four, for pointer variants), sometimes it was the name of a nested structure, but EVERY SINGLE struct declaration used a declarator.
Ben Voigt
@Ben To be precise I've asked how many of YOU use it not if it is used by people.
There is nothing we can do
@atch: I quote your exact words "(I'm not saying that is there anything wrong with this construct I'm just wondering if it's something that exists in C++ but people rarely use it)". But if you want to know if _I_ use it, the answer is YES. Not only do I `#include <windows.h>`, and therefore require a compiler that understands it, but I use declarators following struct and class in my own code. Since the code I write is not publicly available, and Microsoft's headers are, I thought they would make a better illustration.
Ben Voigt
@Ben Voigt I'll quote my exact words for you "And how many times anyone of you uses construct presented by Neil". What you're quoting referred to other things rarely used by other people.
There is nothing we can do