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]

Skybuck Flying wrote:

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:
http://www.polishnews.com/text/humor...n_english.html

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[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

[=?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.

--
Erik Wikström

[Victor Bazarov]

Skybuck Flying wrote:

[... 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[tragomaskhalos]

On Aug 24, 4:27 am, "Skybuck Flying" <[e-mail]:

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]

Skybuck Flying wrote:

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!

[werasm]

Skybuck Flying wrote:

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]

"tragomaskhalos" <da*************@logicacmg.comwrote in message
news:11**********************@e9g2000prf.googlegro ups.com...

On Aug 24, 4:27 am, "Skybuck Flying" <[e-mail]:

>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;

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.

--
Erik Wikström

[tragomaskhalos]

On 24 Aug, 22:09, "Skybuck Flying" <[e-mail]:

"tragomaskhalos" <[e-mail] in message

class A {
int x;
} A;

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

Exactly.

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

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.