James said:
....
What does that have to do with the increment() function? You
seem to be mixing subthreads.
No, I was just trying (unsuccessfully) to return to the original topic
of passing by reference/value ambiguity and you were diverging by saying
that increment(), and even incrementPercentage() should actually be an
operator. I feel now we should have stayed with 'f()' because replacing
the majority of function names and purposes does not make sense (unless
you would state that relatively quite limited number of operators C++
has should be used to represent much bigger set of verbs and phrases
that function names can express) and I hoped to avoid discussion of
operators (simply because they would bring a whole new can of worms --
which they did
). I really dislike broad and generic discussions.
So, I just tried to discourage you from discussing operators by showing
how ambiguous their meaning could be but you saw it as a challenge and
decided to stay to it.
The "intuitively expected" answer will obviously depend on the
overall philosophy of the language:
No, for C++ programmer, it will depend on his/her background, including
other programming languages, broader professional/educational background
(see set example in another thread) and the purposes for which s/he
overloaded this operator in the past, if s/he did at all.
for untyped languages, such
as Perl, AWK, etc., the intuitively expected response is "36";
for typed languages, such as C++ and Java, the only intuitively
expected response is a compiler error. Which neither Java nor
C++ get right (for different reasons).
Let's admit there is no right/wrong here -- unless it is used in a sense
of more or less ambiguous and any C++ operator may mean the highest
number of different actions.
See, I can write:
// pgm.cpp
#include <iostream>
#include <string>
#include "myheader.h"
using namespace std;
int main() {
string s2 = "255" + 3;
string s1 = "255";
string s3 = s1 + 3;
cout << "s1=" << s1 << " s2=" << s2 << " s3=" << s3 << endl;
return 0;
}
// myheader.h or same code much deeper in included files
#include <sstream>
std::string operator+(const std::string &left, int right) {
std:
stringstream oss;
oss << left << right;
return oss.str();
}
And I would probably expect s1 equal to s3 as a result.
However, depending on how the + operator is defined, C++ can treat s3 as
in C, as in Java (as in the example), as in Perl or AWK or as in any
other way, some of them logical for different people and no writes or
wrongs -- at least for many definitions. And the best C++ programmer
will have no way to know until s/he reads the header file. And even
then, s/he needs to pickup the applicable definition -- which is
possible, but time consuming and requires lining up all included
overloads first. What's worse, the meaning may change after including
some other header file, directly or indirectly.
....
I'm afraid that I don't see any real difference between Java and
C++ here. Not that it's really relevant; neither language is
perfect, and no reasonable person would pretend the contrary.
Both have their flaws. The basic question concerns the
totality, which depends on the application domain, but
doubtlessly favors C++ over Java most of the time.
see the example above
And? Designing a good interface does require a bit of typing.
And I'm not sure that you'd need that many overloads for
percentage. Not every operation makes sense on a percentage.
No, but adding a percentage makes sense for a values of different types.
Think of BigDecimals etc you introduced to the dis?ussion earlier; with
a slightly different semantics (say, rounding) of addition, then think
of people who will want to have a conversion from BigDecimals to, say,
doubles (isn't it natural -- all of these are numbers, after all), and
then think which particular operator '+' will be called if you have few
of them defined.
Also you correctly mentioned that the definition of some
application-specific numeric types like Price or Quantity or Money may
migrate from BigDecimal to double.. under all these possibilities do you
still want to use an operator and uniform syntax?
No. You're confusing your personal experience in poorly run
shops (where any language would fail) with absolute truths.
Well, this does not stand my experience:
1. I am not familiar with a single absolute truth.
2. There was no / is no pure failure -- there are costs related with the
projects in different languages. What you are essentially saying -- "if
you have never worked in a shop where C++ projects could be as
successful as the projects in C / Java etc ("success" can be defined
quite unambiguously in terms of meeting requirements in time at lower
cost etc) -- then you did not work for a well-run shop". I should
probably agree to you then -- I have to really think if I worked for
one, but I might as well agree that I have never worked for such a shop;
the only thing is I do not agree to define "well-run" in terms of
suitability for C++ specifically.
Exactly. Why look further.
And then, when the returned value will be (or not be -- whatever is
contrary to your assumption) the increased argument, you will share the
responsibility for not really reviewing the code; in fact, you will
carry greater responsibility as you were supposed to be a gatekeeper.
I would assume that any code which passed code review was
conform to the conventions in use in the company.
No, the code has not been reviewed yet, you are reviewing it now. Will
you just assume the effect corresponds to the name or you will go seek
the applicable definition? And if you have to go see the definition,
won't your performance be impeded by this (as comparing to C, in which
case you will not have to go see definition if you see the argument is
passed by value).
Which is, after all, exactly what software engineering is all
about. If you don't do that, you might as well pack it up and
go home; no language is going to work for you.
The ability to say exactly what you want, clearly and concisely.
Does it include the ability of the reader to understand what you wanted
to say, clearly, easily and unambiguously? If not, I agree with all you
said about expressivity but do not think it is an advantage; if yes, I
disagree that C++ is more expressive than other languages; I would
rather argue it is one of the least expressive languages as the
understanding is most difficult and ambiguous although sometimes
deceptively clear.
My definition of "advantage" is, in the end, something that
reduces the cost of software development. Expressing exactly
what you want, clearly and concisely, definitely reduces the
cost of software development, and so is an advantage.
See my answer above
There are two things which make Java attractive to project
managers: the first is simply that it is more or less
"in"---it's not a good reason, but it's probably the most wide
spread one. The second is the support structure which is
available for certain types of applications.
There are many reasons, I agree, but low entry barrier and simple, less
error-prone syntax are clearly a big one.
Most algorithm courses changed their algorithm-teaching classes from
everything (Algol/Pascal/C++/MIX) to Java -- why if not for Java is
easier to learn and does not make a student to think too much on a
syntax, by that leaving more brain power to think on the problem). If
C++ were just "more expressive" but did not carry prohibitive costs with
it, they would be taught in C++.
(And no, it is not only because students can nicely present their
results as applets -- I am saying that because most assignments I saw on
the Internet ask to output the results on the console or file, probably
to spare them having to learn a lot of things irrelevant to the
algorithm course).
BTW, the fact that most students study Java as their first language has
some significance for the future of C++, too. I mean, to be popular with
Universities would definitely help a language to survive / prevail /
stay in wide use / grow -- the right verb depends on its current
standing in the industry.
Sure. It's Turing complete. You just can't express them as
clearly and concisely.
Again see the paragraph above about your definition of expressivity.
A structure doesn't necessarily have the semantics you want in
your pure value.
And that's simply wrong. A value is a value, and has entirely
different characteristics than an entity. Look at
java.lang.String, for example, for an example of a well designed
value in Java. (Note that it is final, has no mutable members
and... has overloaded operators.)
You are confusing me. I think you are introducing new concepts to the
discussion on purpose. Please defined them first. You complained that
with C you have to cross your fingers that nobody manipulates the fields
of the structures which you only wanted to be manipulated via functions.
I told you it can be assured by exposing forward declaration only and
hiding definition in the implementation files. How does such code change
make these structures entities from values in this sense in which you
started using them now (still not sure what it is, precisely)?
Also, why I cannot represent the analog to Java string in C if I hide
its declaration (but, I assume, I can do it if I do not hide it?)?
-Pavel
