Why :: ? Why not : ? Why not . ? <- less clutter ?!?

[Skybuck Flying]

Hello,

Why does C++ use :: for members/methods why not just : ?

For example:

long Test::TimesOne() const { return mVal; }

Alternative:

long Test:TimesOne() const { return mVal; }

Why use : at all ? Why not stick to . ?

long Test.TimesOne() const { return mVal; }

^^^ Less clutter ^^^

Bye,
Skybuck.

 

[Victor Bazarov]

Why does C++ use :: for members/methods why not just : ?

For example:

long Test::TimesOne() const { return mVal; }

Alternative:

long Test:TimesOne() const { return mVal; }

Why use : at all ? Why not stick to . ?

long Test.TimesOne() const { return mVal; }

^^^ Less clutter ^^^

Less clutter does not mean more clarity. Programming is not
photography.

Analogy: I believe that if you make all road signs round,
they will be more difficult to read than with their current,
several distinct shapes.

I lost the link to this wonderful essay on the complexity of
English and proposals to reduce it. It starts, as I recall
with the proposal to replace 'c' with 'k' and 's' to reflect
the sounds it makes. Then it goes on to propose replacing
some diphthongs with single vowels or 'th' with 'z', and so
forth. Hillarious! Anyone knows where to find it?..

I googled for it, and I found one. Check it out:
www.polishnews.com/text/humor/european_comission_english.html

V

 

[Skybuck Flying]

Making road signs round or square or triangular does not add or reduce
clutter.

The unnecessary :: () makes it definetly more harder to understand, write
and read it.

A good test would be:

Ask someone who is dislexies which one he prefers:

long Test::TimesOne()

or

long Test.TimesOne

Another example of C++ clutter is operator overloading <- horrible clutter.

Just remembering what clutter is needed to make it compile requires an
elephant's memory.

Bye,
Skybuck.

 

[Alf P. Steinbach]

* Skybuck Flying:

Hello,

Why does C++ use :: for members/methods why not just : ?

For example:

long Test::TimesOne() const { return mVal; }

Alternative:

long Test:TimesOne() const { return mVal; }

Why use : at all ? Why not stick to . ?

long Test.TimesOne() const { return mVal; }

^^^ Less clutter ^^^

This choice is probably covered in Bjarne Stroustrup's "Design and
Evolution"-book.

But the short of it is that

.

is performed at run time, whereas

::

is evaluated (if that word can be said to apply) only at compile time.

It was found to be useful to distinguish these cases syntactically, so
that the effect of the code is reflected directly in the syntax.

Regarding ":" instead of "::", that would introduce additional possible
ambiguity for the parser, e.g. an expression such as

(condition?Foo:Barther)

The problem here being that ":" is already an operator that is evaluated
at run time, in a context where also the "::" can appear.

Also, ":" as a scope resolution operator would interfere with ":"
denoting inheritance, like in

class Humptyumpty:Alice {};

Is this a class Humpty inheriting from Dumpty:Alice, or a class
Humptyumpty inheriting from Alice, or a class Humptyumpty:Alice?

However, none of the above would be a problem with ".", and Java and C#
manage just fine using ".". And as I recall, but I'm not sure, "." was
used this way in early pre-standard C++. However, already by 1987 the
"::" as scope resolution operator had been adopted, so presumably, if
"." was ever used, it turned out to have some problems in C++.

Cheers, & hth.,

- Af

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-08-24 06:09, Skybuck Flying wrote:

Please quote the text you are replying to.

Making road signs round or square or triangular does not add or reduce
clutter.

The unnecessary :: () makes it definetly more harder to understand, write
and read it.

A good test would be:

Ask someone who is dislexies which one he prefers:

long Test::TimesOne()

or

long Test.TimesOne

Another example of C++ clutter is operator overloading <- horrible clutter.

Just remembering what clutter is needed to make it compile requires an
elephant's memory.

Yes, C++ might be a bit cluttered and a bit hard to read, but as Alf
explained there is an obvious reason for most of it. If you want an
language that is easier to read and understand there are many of those,
BASIC comes to mind. But then again, few of these simpler languages are
even close to C++ in popularity, or as powerful as C++.

It's true that most people probably never will get more than a basic
understanding of C++, and if you are dyslectic you'll have more problems
than most. But then again most people will never be fit enough to
participate in the Summer Olympics.

By the way, how do you mean that operator overloading increase the
clutter? I'd argue that it does exactly the reverse. Consider the
following two examples:

a = b * (c - d * e);

or

a = b.multiply(c.minus(d.multiply(e)));

The second example is what you get without operator overloading. I
remember when back in school I was implementing DSA using Java's
BigInteger (a class that can store arbitrary large integers). The
mathematical operations went over two lines and I'd was forced to spend
a lot of time to figure out why it didn't work (was a miss-placed
bracket). All the time I was wishing I was using C++ with overloaded
operators instead.

 

[Victor Bazarov]

[... Aw... C++ has so much "clutter" ...]

Just remembering what clutter is needed to make it compile requires an
elephant's memory.

I have worked on CAD programs most of my career so far. They usually
have more functionality than an individual would ever need. Some of
them require structured learning (while simpler ones you may be able
to pick up just by using), which reflects their complexity. I've seen
clients complain about that, mostly wanting to get through a casual
encounter with the program without paying too much attention. "Just
make it so it does what I want", is the recurring theme with those
folks. "Why do we need twenty ways to draw a friggin circle?", "All
those toolbars with all those buttons make my eyes and my head hurt!".

Well, yes, the more complex problems you want to solve, the more complex
your tools have to become. The more complexity there is in the tools,
the more time one has to spend becoming proficient in those. If you do
not want to spend all the time and the effort required to learn the tool
(or tools), that's fine. You won't be able to compete on the market
with those who did spend the time and effort, but then again, maybe you
don't want or don't need to. It is entirely your choice. Use some
other tools to solve your problem. There are plenty to choose from.

Just remember that a few millennia ago a man would have to run to move
faster. Now, unless one has the money to hire a chauffeur, one has to
deal with the automobile with all the clutter of controls in front of
him. Same goes with man's dwelling, a few millennia ago it was just
a cave with a hearth. Nowadays it's the clutter of furniture, not to
mention home appliances, different kinds of food in the refridgirator.
And don't get me started on the clothing we're wearing. I don't see
you complain about all THAT...

V

 

[tragomaskhalos]

Hello,

Why does C++ use :: for members/methods why not just : ?
For example:
long Test::TimesOne() const { return mVal; }
Alternative:
long Test:TimesOne() const { return mVal; }
Why use : at all ? Why not stick to . ?
long Test.TimesOne() const { return mVal; }
^^^ Less clutter ^^^

The : token marks case labels and access specifiers,
so it's out.

As regards :: vs ., you're presumably thinking of
the java/C# situation where . is indeed used, ie
MyClass.StaticFunc();

The reason this wouldn't work in C++ is because in
C++ (as opposed to Java/C#) you can do this:

class A {
int x;
} A;

Now if we used . in place of ::, A.x would be ambiguous.

 

[Skybuck Flying]

Using operators vs writing the operator overloaders.

To write an operator overload one has to use lot's of clutter.

Bye,
Skybuck.

 

[Skybuck Flying]

I have programmed overloaded operators in Delphi.

And Delphi uses a really simple way to overload operators.

Without too much clutter !

Delphi puts C++ to shame !

Bye,
Skybuck.

 

[Victor Bazarov]

I have programmed overloaded operators in Delphi.

And Delphi uses a really simple way to overload operators.

Without too much clutter !

Delphi puts C++ to shame !

Ah, that... Congratulations on your exceptional camouflage, troll.
You win this year's prize!

Bye,
Skybuck.

Bye, Sky#uck!

 

[Skybuck Flying]

Ok so you're saying C++ is a real mess because : is already an operator used
for inheritance and god knows what else... (compares/boolean (?))

Delphi simply uses

type
Tlalalal = class(Tlalal)

For inheritance.

Overloading () would be meaningless because it's not an operator.

So Delphi has no problems at all.. while C++ has again wacky problems.

I don't understand why '.' would not be a problem, but then you assume it
was a problem.

So in the end it seems you still unsure.

I love your sig though it's funny as hell:

Though I don't quite agree with it...

Sometimes I like to read the answer before I read the question.

Because answers can be much shorter and clearer then somebody's question !
LOL.

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Bye,
Skybuck.

 

[werasm]

I have programmed overloaded operators in Delphi.

And Delphi uses a really simple way to overload operators.

Without too much clutter !

Delphi puts C++ to shame !

Yawn...

 

[Skybuck Flying]

Oh and besides,

You're sig doesn't make logical sense.

I always start reading the first post, and then it doesn't matter if the
second post starts top or bottom.

Because I already read the previous text

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

^^^

Illogical bad example.

Better example:

A: Because it messes up the order in which people normally read text.

= last post

Bye,
Skybuck.

 

[Skybuck Flying]

The : token marks case labels and access specifiers,
so it's out.

As regards :: vs ., you're presumably thinking of
the java/C# situation where . is indeed used, ie
MyClass.StaticFunc();

The reason this wouldn't work in C++ is because in
C++ (as opposed to Java/C#) you can do this:

class A {
int x;
} A;

Not sure what this means, I have't programmed in C++ for a pretty long time,
so I'll assume it means:

The first A is the class name, X is the field, the second A is a variable.

Now if we used . in place of ::, A.x would be ambiguous.

Why would it be ambigous ?

A.x can only be the field ?

Since I assume if one meant static class A.x one would have to use special
keywords.

Bye,
Skybuck.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-08-24 22:56, Skybuck Flying wrote:

Please quote the text you are replying to.

Using operators vs writing the operator overloaders.

To write an operator overload one has to use lot's of clutter.

A small sacrifice to avoid the more clutter later on. And the amount of
clutter the operator overload generates is debatable.

 

[Jorgen Grahn]

A good test would be:

Ask someone who is dislexies which one he prefers:

I am not convinced that people with a cognitive disorder should get to
decide what a language's syntax should look like ...

(But I know at least one mildly dyslectic programmer who does fine in
C++.)

/Jorgen

 

[tragomaskhalos]

... I'll assume it means:
The first A is the class name, X is the field, the second A is a variable.
Exactly.

Why would it be ambigous ?
A.x can only be the field ?

No. in a ". for ::" world A.x could mean EITHER the int x
inside the A variable (ie the field as you denote it) OR
the int x inside the A class, ie the int x inside ANY
instance of the class A. You may think that the latter
interpretation is meaningless, but this is precisely what
is required when declaring a pointer to member.
See Design & Evolution of C++ pg 95.

Since I assume if one meant static class A.x one would have
to use special keywords.

Now you've lost me - static hasn't got anything to do with it.