how to recognize whether code is C or C++?

[Ian Collins]

That I'd regard as poor style (although of course that doesn't mean it
may not often occur).

Nonsense, why would you se anything else when there is nothing bu a
public interface?

 

[Phlip]

Nonsense, why would you se anything else when there is nothing bu a
public interface?

Because style guidelines often reserve 'struct' to mean "behaviorless data
bucket", where a pure virtual interface is the exact opposite - dataless behavior.

Put that guideline together with "all publics should appear at the top of a
class", and our industry is fated to forever write only class Foo{ public:...

 

[gw7rib]

If you are given a bunch of .c files, is there a way to recognize (by
just looking at them) whether the code in them is written in C or in C+
+?

What would you look for?

Other people have pointed out features that would show, or suggest,
that the code was C++.

By way of contrast, if you have conversions from void * - for example
using malloc without a cast, as recommended in comp.lang.c - this
would show the code was not C++.

 

[Noah Roberts]

Because style guidelines often reserve 'struct' to mean "behaviorless
data bucket", where a pure virtual interface is the exact opposite -
dataless behavior.

Can you state any technical reason for that guideline or is this yet
another irrational standard you like to harp on?

What happens when what used to be a "behaviorless data bucket" suddenly
gains behavior?

Is a "behaviorless data bucket" really an object that has enough
responsibility to survive?

Is a C language structure that has member function pointers a class or not?

Is this a class?

class X
{
int x;
friend ostream& operator<<(ostream&,X const&);
};

Is this less of a class?

struct X
{
int x;
};
ostream& operator<<(ostream&,X const&);

Is this a class?

class X
{
public:
int x;
X() : x(42) {}
};

Put that guideline together with "all publics should appear at the top
of a class", and our industry is fated to forever write only class Foo{
public:...

Why put it together with the former? There's no reason to use 'class'
over 'struct' since they mean the same thing. The only important thing
is to chose which you're going to use since finding the declaration of
the class to check if its declared as struct or class is annoying.
That's simply caused by a language deficiency.

Frankly, the idea of "class" as a cohesive entity in C++ is a misnomer.
Classes in C++ are compound data types that have zero or more of the
following:

* state
* member functions
* functions that accept the object as a parameter
* template traits utilities that provide information about the object

etc, etc...

As I learned the other day, even a union is a "class" in C++.

Since the only difference between 'struct' and 'class' in C++ is default
permission, and it is more common to inherit publicly and write public
members first, it is more efficient and sensible to use the 'struct'
keyword for everything. This does two things:

1. saves us from the pointless typing of 'public' everywhere.
2. Points out uncommon inheritance by using keywords for the uncommon
permission rather than the common one.

The standards committee could do us all a favor and get rid of the
'class' keyword all together.

 

[coal]

"More efficient and sensible" is overstating the case.  You're right
about publics coming first more often, but popularity doesn't make it a
good idea.  I always put private members first, with fields coming
before the functions that use them.  Nothing in my code ever refers to
anything that has not defined yet, except in specific situations on
large projects where there are build-related concerns.  I've been doing
this in earnest for about a year, and so far, I'm very happy with it.

I do the same thing in terms of ordering functions, but hadn't
thought about it terms of data members preceding functions.
That sounds like a good idea and I think I'll work on changing
to that tomorrow.

I'd have been happy with not introducing "class" in the first place, but
that genie's not going back in the bottle.

How about dropping the use of "struct" and using "class" instead?
The semantics of "class" could then be changed to those of "struct."
I'm talking ideally. I think "class" is a more helpful term.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Bart van Ingen Schenau]

Depends on the input set.

#include <stdio.h> /* C header
#include <iostream.h>

class xyz {

friend family relatives;
*/

int main()
{
printf("My C++ program \n");
return 0;
}

Now?

I like this one better:

#include <stdio.h>
char* string =
"#include <iostream>\n"
"using namespace std;\n"
"int main()\n"
"{\n"
" cout << \"Hello World\" << endl;\n"
"}\n";
int main()
{
printf("My C++ program: \n%s", string);
return 0;
}

I agree with Juha Nieminen. Thats the best.

How will one determain if a given text is English, French or a mix? We
keep looking for key words? No. Make an English read the text.

Bart v Ingen Schenau

 

[Christopher Dearlove]

In the fourth place, forward declarations smell bad.

If you're going to hold that opinion, despite the clear advantages
of forward declarations in saving compilation dependencies, there's
no point us discussing further.

 

[Christopher Dearlove]

I got it from Bjarne Stroustrup, in The C++ Programming Language.

We don't agree, so there's no point us arguing past each other. But I
would be interested in a page/section reference here (Third Edition
only, anything before that is obsoleted) as the obvious Section 12.3
that introduces abstract base classes uses class, not struct.

 

[Noah Roberts]

Developers should not be expected to convolute their code, just to
accommodate a single broken or misconfigured compiler that they aren't
even using.


He recommended it to decrease build times on very large projects.
Nowadays, we have good support for precompiled headers.

Precompiled headers are meant for extra-project dependencies, not
intra-project dependencies. You'll find that your build times are
greatly increased for almost all changes, no matter how small, if you
violate this.

 

[Noah Roberts]

"More efficient and sensible" is overstating the case. You're right
about publics coming first more often, but popularity doesn't make it a
good idea. I always put private members first, with fields coming
before the functions that use them. Nothing in my code ever refers to
anything that has not defined yet, except in specific situations on
large projects where there are build-related concerns. I've been doing
this in earnest for about a year, and so far, I'm very happy with it.

That's funny, because I generally do the same thing.

 

[Default User]

I'd have been happy with not introducing "class" in the first place,
but that genie's not going back in the bottle.

I'd have been happy to keep struct only for POD use, for C
compatibility. Different strokes and all that.





Brian

 

[Noah Roberts]

That is not the case.

Well, since you say it...I _must_ be wrong.

 

[Noah Roberts]

I'd have been happy to keep struct only for POD use, for C
compatibility. Different strokes and all that.

If that's the case then your structs can never contain std::string or
anything else that isn't also a POD. May as well not use them at all at
that point.

 

[Default User]

If that's the case then your structs can never contain std::string or
anything else that isn't also a POD. May as well not use them at all
at that point.

As I said, C compatibility. std::string is not compatible with C. They
would be used for common C/C++ libraries or ported code. So yes, not
used all that often.





Brian

 

[Noah Roberts]

We tune the contents of our precompiled headers to minimise build time.

Precompiled ones are processed much faster, but you end up with stuff in
the compilation unit that it doesn't need - which slows it down.

There's also the overhead of what happens when a file that is in your
precompiled header set changes - everything that uses the precompiled
header has to be rebuilt.

Which is why you want precompiled headers to contain references to
stable, extra-project dependencies and not intra-project dependencies
nor rarely used ones. Precompiled headers are NOT a replacement for
forward declarations.

 

[Phlip]

Precompiled ones are processed much faster, but you end up with stuff in
the compilation unit that it doesn't need - which slows it down.

To avoid runaway dependencies, you should not use the everything-in-one-header
system. You would like a (meaningful) error message if you type in an identifier
that the current module should not know about.

 

[Ian Collins]

"More efficient and sensible" is overstating the case. You're right
about publics coming first more often, but popularity doesn't make it a
good idea. I always put private members first, with fields coming
before the functions that use them. Nothing in my code ever refers to
anything that has not defined yet, except in specific situations on
large projects where there are build-related concerns. I've been doing
this in earnest for about a year, and so far, I'm very happy with it.

I've always written my classes that way. I find it much more natural to
look up the screen for declarations than down. We do this everywhere
else in our code, so why should class declarations be any different?

One could argue writing the public interface before the private data it
uses is akin to top posting.....

 

[Ian Collins]

But not necessarily C, as many people use compiler extensions or ignore
warnings from their C++ compiler.

Assigning the return of malloc (void*) to anything else is a error, not
a warning.

 

[Noah Roberts]

I've always written my classes that way. I find it much more natural to
look up the screen for declarations than down. We do this everywhere
else in our code, so why should class declarations be any different?

One could argue writing the public interface before the private data it
uses is akin to top posting.....

Writing the public interface first puts the most interesting and
important information about an interface as the first thing you see.
Implementation details, such as private member variables, rarely need to
be accessed or read. One would prefer they not be in the interface at
all, and you can use pimpl's to make that happen, but this is C++ so we
must make do. If you are using a pimpl then it makes even less sense to
have that as the top most item of importance in a class declaration
since it's completely meaningless to the interface.

The most important information should be the first information available
whenever possible. Since we normally read top to bottom, the most
important information should be at top. With regard to class
declarations, the most important information is almost always its public
interface.

One could argue anything one wants but comparing apples to oranges
(English prose to C++) is always going to be a fallacious argument
unless you can show reason for considering them the same.

 

[coal]

Writing the public interface first puts the most interesting and
important information about an interface as the first thing you see.
Implementation details, such as private member variables, rarely need to
be accessed or read.  One would prefer they not be in the interface at
all, and you can use pimpl's to make that happen, but this is C++ so we
must make do.  If you are using a pimpl then it makes even less sense to
have that as the top most item of importance in a class declaration
since it's completely meaningless to the interface.

The most important information should be the first information available
whenever possible.  Since we normally read top to bottom, the most
important information should be at top.  With regard to class
declarations, the most important information is almost always its public
interface.

One could argue anything one wants but comparing apples to oranges
(English prose to C++) is always going to be a fallacious argument
unless you can show reason for considering them the same.- Hide quoted text -

- Show quoted text -

I agree with some of that, but not really the conclusion. If you
put data members first, you'll get used to the public interfaces
following the data members. It may be a case of "Last, but not
least."

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net