I was just reading about this: http://yosefk.com/c++fqa/web-vs-c++.html#misfeature-4
To sum up: it doesn’t.
Often though, doing that is a terrible idea and universally considered bad practice. A lot of bugs have been created by using non-literal format strings (bugs, and software exploits)
Objective(ly)-C(rap) compilers usually do a check for that and throw a warning on compile time if you are doing that. Like-wise, so do a lot of modern C++\C compilers.
I want a pink unicorn that can fly and make me breakfast in bed every morning.
Oh wait, I’m not getting that either.
This is the millionth thread I’ve seen where people day-dream about what they want in Java. Suck it up and/or learn a different for a change!
Well said.
Learn more than one language so that your choices are not limited.
But in the end, they are limited such as much.
By now, most people here have learned and chosen their main language and maybe a secondary one too. Those are the languages that are in use daily or semi-daily. This means, that the choice itself is already made. And since we are on Java boards, the choice is Java (or some other jvm language).
I want POP-11. With blackjack, and hookers.
Cas 
What good is blackjack and hookers without the booze?
Here’s the deal. Languages evolve or the die a slow death. The JVM must evolve or it heading towards being a FORTRAN or COBOL. I’ve actually been more optimistic about the JVM’s future since Orcale took over.
One thing that virtually everyone overlooks is ‘invokedynamic’. Sure people take about lamdba’s, but that’s just the tip of the iceberg. invokdynamic is huge…by far the biggest JVM change ever. It allows user & language definable endpoints which basically opens up some very important runtime compiler features. Stuff along this line would be (by far) the biggest bang-for-your-buck features. So structures open up huge possibilities (which has been talked about in various forms) and changing the transport IR (never talked about and is probably too much to hope for).
I don’t know if this was already said or not, but I’d like functions to pass as parameters. Python has this, and it’s useful.
You can get the same effect very easily by using the command pattern, and less easily (and much more messy) using reflection.
To me, passing a function as an argument would be pointless unless it used a well defined interface.
Isn’t this what lambda is all about?
Cas
I have no clue. 
Trying to find out only yielded insanely vague results, or jargon I’m unfamiliar with.
Pretty much, and thanks to VM changes Roquen talks about above, should be significantly better performing than command pattern or reflection.
Assuming you don’t mean changing out the infra-red parking sensor in your car 
I’m assuming you’re talking bytecode representation? :clue: If so, what you thinking?
Java bytecode isn’t particularly well suited to all sorts of high-level analysis and optimisations. Changing the bytecode format into various other things would open up a bunch of new possibilities. For example the Dalvik IR is specially designed to make it JIT compile easily and with high speed and less performance cost than ordinary Java bytecode.
Cas
[quote=“Mads,post:71,topic:44466”]
Read these two:
Boost can:
std::cout << boost::format("writing %1%, x=%2% : %3%-th try") % "toto" % 40.23 % 50;
I think this is in the newest version of C++:
std::cout << std::putf("this is a number: %d\n",i);
Nonetheless, he is missing the advantage to << and >>.
Ha, um NO. It’s called readability.
Let’s say I have an equation like so:
Vector v0, v1, Vt;
Vector V = ((v1 - v0) * time + v0) + (Vt * restitution)
Using methods, you get something like:
Vector Vtr = Vt.mul(restitution);
Vector V = v1.sub(v0).mul(time).add(v0).add(Vtr);
Now THAT’s ugly. AND, how do you decide when to return a new Vector and when to return this? With the above code it’s safe to say a new vector is returned each time, which is often unacceptable if this code is running many times.
Of course you could write code like this (which I do to get around lack of operator overloading and structs)
Vector V = v1.sub(v0).muli(time).addi(v0).addsi(Vt, restitution);
Where a method ending in i means “immediate” which applies the operation to this and returns this (opposed to applying the operator to a new vector and returning it - like sub in this example).
Because of the lack of operator overloading I have useless comments that merely state “Here’s the one line equation I’m trying to achieve incase anyone looks at this and goes WTH IS GOING ON”
That’s not what he meant by replacing << with method names. Something like this solves the issue for more or less everybody:
Vector v0, v1, Vt;
Vector V = ((v1 minus v0) mul time add v0) mul (Vt cross restitution)
especially with appropriate syntax colouring. The reuse of various ascii symbols to mean just about anything is what irks nearly everybody against operator overloading, but the fundamental concept of being able to define unary and binary operators in the language I don’t think anyone’s against as such.
Cas
Really? But all of my user-facing text is externalized. No idea how that’s typically done with C++, but how it’s done is irrelevant - format strings can vary in the location of their parameters from one language to the next. Of course the format strings aren’t going to be freeform, they’re known at build time, as they were given to you by localizers.
Good to see Boost and/or newer standards support this kind of thing though.
I am arguing against ascii art, not unary and binary operators as princes said. I am simply asking that you give them a name. For god’s sake, why would we use symbols to represent complex functions like read\write?
Overloading established operators to some twisted meaning on complex objects is a terrible idea.
Ahh okay. That’s a better idea than what Java currently has, although it requires you to put parenthesis around everything (because a lack of order of operations). You might as well jump right to operators!
Gotcha. IMO I don’t think read and write are complex… at first I HATED the << and >> symbols… so odd and stupid. But after using them extensively I’m comfortable with them. They’re just a feature of the language, you don’t have to use them.
When I say they are complex I mean the process not the usage.
Anyway, you’re argument for operator overloading was presented to James Gosling (they’re a feature, it isn’t the language designer’s jobs to decide if you can use it):
“Many C++ design decisions have their roots in my dislike for forcing people to do things in some particular way […] Often, I was tempted to outlaw a feature I personally disliked, I refrained from doing so because I did not think I had the right to force my views on others.” - Bjarne Stroustrup
Which was a response to James Gosling, who left operator overloading out of Java as a personal preference. If that was his justification, I disagree with his stance and tend more towards Bjarne’s.
Anyway, that’s enough on operator overloading.