Overloading short-circuit

Pages: 1234
Well, it was you who claimed it can be done. Now you say it cannot be done.
I said it was possible to have short-circuit semantics with overloaded operators. I never said it was going to be transparent.

If C++ was able to express appropriate implicit conversion, it would work.
Let me know when you can describe a sensible conversion method.

EDIT: (I just noticed xorebxebx edited his post.)
But if C++ supports the && operator that does short-circuit and also supports operator overloading, you should be able to overload the && operator without changing its semantics or you should not be able to overload it at all.
I might agree with this. After all, this is why ?: can't be overloaded (I think).
But what's done is done. It can't be fixed now without breaking code, so let's make the most of it.
Can we add short-circuit to these operators?
Yes.
Is it safe?
Yes. You won't accidentally get unexpected semantics without also getting a compiler error.
Is it nice?
That depends on what you want to do, but it's nice for most cases.
Is it exactly like the built-in operators?
No, but it's pretty close.
Last edited on
On ?: overloading:

Stroustrup wrote:
There is no fundamental reason to disallow overloading of ?:. I just didn't see the need to introduce the special case of overloading a ternary operator. Note that a function overloading expr1?expr2:expr3 would not be able to guarantee that only one of expr2 and expr3 was executed.


Anyway:
But if C++ supports the && operator that does short-circuit and also supports operator overloading, you should be able to overload the && operator without changing its semantics or you should not be able to overload it at all.


I could agree with this, but I don't know how you would be able to check at compile time whether or not a particular overloading of the operator would break its semantics.
closed account (EzwRko23)

I could agree with this, but I don't know how you would be able to check at compile time whether or not a particular overloading of the operator would break its semantics.


This is a different thing. The language should **provide** ways to achieve correct semantics, not **enforce** it. I don't think enforcing it is possible, until compilers that read your thoughts are invented.
closed account (iw0XoG1T)
To me this seems like an academic argument--similar to how many angels can sit on the head of a pin. What type of effect will the difficultly of this one type of operator overloading have on any real problem? Could someone give me a practical reason why this ability is needed?
I chose to learn C++ because there are plenty of good books out their teaching how to program that use C++--show me a good book for learning the basics of programing using Scala?
Last edited on
What type of effect will the difficultly of this one type of operator overloading have on any real problem? Could someone give me a practical reason why this ability is needed?
This very particular type of operator overloading has relatively few applications, but using a similar method (that is, constructing ASTs from static code), you can implement complex semantics with other operators, such as a lazy evaluation, which is suitable for certain types of computation.

In any case, this topic has gotten way out of hand. I just had an idea in the time between waking up and getting out of bed and thought I'd post it because other people might find it interesting. I didn't expect (or want) it to get into a debate about whether or not C++ should allow overloading && and ||. It was just an unusual way of using the compiler.
closed account (EzwRko23)
C++--show me a good book for learning the basics of programing using Scala?


http://www.scala-lang.org/node/959

And C++ is definitely not a language for beginners in programming. But this is another topic.


What type of effect will the difficultly of this one type of operator overloading have on any real problem?


Things should work consistently. If && short-circuits, every usage of && should short-circuit. Otherwise, whenever I see an && in the program I have to check if this is on builtin type or on a user type - this deteriorates readability of code. This is a minor issue of course, but when lots of such issues gather together (and there are lots of them in C++), programming in such a language becomes quite an unpleasant task.

Indeed:
"C++ is a horrible language"
-- Linus Torvalds
So umm, xorebxebx, what degree is it that you have that qualifies you to declare a language as inferior again?
closed account (iw0XoG1T)
@xorebxebx:
C++ has real practical advantages for beginners, one being that it is a mature language with lots of people using it. If C++ died today and there was no longer any new development there would still be a need for C++ programmers for the next 20 years just to maintain legacy code.
Scala has only been around since 2003 and there is not a lot of chatter about it so what makes you think that it will be around for the long haul?
And more importantly what are your credentials? Most of the people who you are arguing with on this site post code regularly. Why don't you post something for code review so we can see if you can program. Show us some code prove your opinion is worth respect.
I have a few questions, xorblahblah: Do you read or write C++? If so, why? If not, what are you complaining about?

http://www.cplusplus.com/forum/lounge/27451/page2.html#msg149446
I'm a counterweight for C++ fanboyism presented by some of the forum members
If you're trying to convince us that C++ sucks, I have some bad news for you. The people who come here come for a few reasons (sorted from most to least common):
1. They are learning/using C++ and need help with something in particular.
2. They want to cheat.
3. They are C++ badasses and want to help others with their problems and/or discuss C++ and/or general programming. This implies that they either enjoy writing in it or they've managed to endure it long enough to become proficient in it. You seem to belong to this last group.
4. They're spammers.
5. They are considering learning C++, either for some specific application, or just in general.
Of all these, #5 are the only ones you have any chance of convincing, but they're also the rarest.
#1 just want to get the job done. They probably can't or don't have the time to mess with a different language.
#2 just don't care.
#3 can't be given a strong enough argument to be dissuaded into changing their posture.

Now, do you really think it's worth it to waste yours and our time, including the time of the people who need help, trying to convince one or two people every six months (and that's being optimistic) that C++ sucks? Do you want to bitch about C++ and how much better Scala is? Go blog about it. There's hundreds upon hundreds of idiots with nothing better to do than spend all day reading blogs and writing comments on said blogs and blogging about the blogs they've read.
All you'll be met with here is resistance and, once the administrator gets tired of your shenanigans, another ban. Seriously, other than waste everyone's time, you're going to accomplish absolutely nothing, here.
closed account (EzwRko23)
@helios, I've already made someone at this forum take a closer look at Scala, so there **is** a point in posting critical posts on C++ on C++ forum.

@chwsks:
C++ has real practical advantages for beginners, one being that it is a mature language with lots of people using it.


True, but there are lots of better mature languages to start with. E.g. Python or Ruby are excellent.


If C++ died today and there was no longer any new development there would still be a need for C++ programmers for the next 20 years just to maintain legacy code.


This is what I said some time ago on this forum. If you like maintaining legacy code, then I have nothing to say, it is your choice.


Scala has only been around since 2003 and there is not a lot of chatter about it so what makes you think that it will be around for the long haul?


If you look at the sites that attract hackers community (e.g. lambda the ultimate, hacker news, reddit, etc.), Scala gained a lot of attention recently. Also some big-fish companies migrate(d) to Scala (Twitter, LinkedIn, Foursquare) and some seriously consider development in Scala for their mission critical software (NASA). I'm almost sure this will be one of the next big players in the programming languages market, even if it won't surpass C, Java or PHP in popularity - it is hard to do for any language.


And more importantly what are your credentials?


If you trust credentials more than logic, then good luck.
Last edited on
I'm almost sure this will be one of the next big players in the programming languages market, even if it won't surpass C, Java or PHP in popularity - it is hard to do for any language.

And more importantly what are your credentials?

If you trust credentials more than logic, then good luck.
You continuously say how much you like or dislike some language. But that's not really interesting.
I could say that Brainfuck is better than Scala because you need to remember only 8 operators
You say that Scala will pwn the world but even if you know that someone somewhere is looking something about it, who are you to say such things? Why should we care about which language you prefer?
closed account (EzwRko23)

You continuously say how much you like or dislike some language.


It is you who have said it.

I have said only that:
1. Many things in C++ design are flawed / redundant / inconsistent.
2. C++ lacks abstraction mechanisms compared to Scala (and Java, and Python, and Ruby, and OCaml, and Lisp, and many many more), thus provides less freedom in how you shape your programs. If you don't like comparisons to functional languages, then another such strong abstraction mechanism that C++ lacks is garbage collection.
3. C++ implements fully only one programming paradigm: structural imperative programming. Just like C and Pascal. The implementation of others is either flawed (OOP), cumbersome (generic) or almost-absent (declarative programming including FP, aspect oriented programming).

These are **not** opinions. These are facts.

4. C++ is a bad choice as the first programming language.

Ok, this is an opinion, but I can justify it easily (howewer, this is offtopic, so I won't).


Last edited on
I agree with your number 4, although it should be number 3 really.
closed account (EzwRko23)
Point 3. was broken and needed fixing ;)
Ok, fair enough.
1. Many things in C++ design are flawed / redundant / inconsistent.
That is an opinion
2. C++ lacks abstraction mechanisms compared to Scala (and Java, and Python, and Ruby, and OCaml, and Lisp, and many many more), thus provides less freedom in how you shape your programs. If you don't like comparisons to functional languages, then another such strong abstraction mechanism that C++ lacks is garbage collection.
IMO garbage collection is not an abstraction and C++ ( as C ) gives a lot of flexibility in pointer operations thus a garbage collector is not possible
The implementation of others is either flawed (OOP)
opinion
, cumbersome (generic)
opinion
closed account (iw0XoG1T)
@xorebxebx:
Anyone can talk --- show us some code. Prove yourself!!!!!!!!!!!!!!

C++ is a bad choice as the first programming language


"first programming language" is a meaningless statement--go ahead define "first programming language" and give it meaning. I guess you mean either the first language you learn or your first choice for a problem.

We don't know what you can do so why should we care what you prefer?

You might be some out-of-work language lawyer loser who has never solved a real problem.
Last edited on
"First programming language" means the first you learn and yes, C++ is a bad first programming language. I know, it was mine.

I got over it, though.
closed account (EzwRko23)

That is an opinion

Redundancy or inconsistency in language design are sharp, mathematic terms.
The behaviour of overloaded && has inconsistent semantics with behaviour of built-in &&.

Is ambiguous and non-LL(k) C++ grammar also an opinion?
Creating a standard compliant C++ compiler or code analyzer takes years. Creating a standard compliant Java compiler takes days or weeks. Therefore you can hardly find two compatible C++ compilers, but there are plenty of compatible Java ones.


IMO garbage collection is not an abstraction


It is. It abstracts out technical details of managing memory.

gives a lot of flexibility in pointer operations

Which is not needed except some extremely low-level stuff which is usually done in pure C anyway.

The implementation of others is either flawed (OOP)


A strong requirement for OOP is encapsulation of data and implementation. C++ violates encapsulation by exposing private parts of the class in the public interface of the class. Because of this flaw, an artificial PIMPL pattern has to be used. PIMPL existence is not an opinion. No other language needs this pattern.

Generic programming is not well intergrated - it was tackled on the core of the language by using textual substitution hacks (very similar to C macros). Which causes all those terrible error messages and requirements to use "template" and "typename" keywords in strange places just to instruct the compiler on the meaning of symbols.

@chwsks:

You might be some out-of-work language lawyer loser who has never solved a real problem.


By using this personal argument you have definitely lost the discussion. I won't answer any more of your posts.
Last edited on
The behaviour of overloaded && has inconsistent semantics with behaviour of built-in &&.
It's not, overloaded operators are meant to behave as functions
Is ambiguous and non-LL(k) C++ grammar also an opinion?
Almost no programming languages can be described by an unambiguos LL context-free grammar
Creating a standard compliant C++ compiler or code analyzer takes years.
So what?
Therefore you can hardly find two compatible C++ compilers, but there are plenty of compatible Java ones.
The two things are not related and 'compatible compilers' really means nothing, the produced object code may not be compatible but I can't see if this is an issue
It is. It abstracts out technical details of managing memory.
It doesn't abstract, it makes it automated
Pages: 1234