Wherever you go, there you are

Q: Can I use C++'s syntax for ostreams: cout << x << y ... ?

You can. If you don't like writing ``print x, y'' then you can try this:
import sys

class ostream:
    def __init__(self, file):
        self.file = file
       
    def __lshift__(self, obj):
        self.file.write(str(obj));
        return self

cout = ostream(sys.stdout)
cerr = ostream(sys.stderr)
nl = '\n'

cout << x << " " << y << nl

This gives you a different syntax, but it doesn't give you a new convention for printing--it just packages up the str convention that already exists in Python. This is similar to the toString() convention in Java. C++ has a very different convention: instead of a canonical way to convert an object to a string, there is a canonical way to print an object to a stream (well, semi-canonical---a lot of C++ code still uses printf). The stream approach is more complicated, but it does have the advantage that if you need to print a really huge object you needn't create a really huge temporary string to do it.

It also has the disadvantage that it doesn't allow for easy translation of text into other languages.

>>2
This.  C++ ostream and Java's abuse of "+" are utter crap when it comes to internationalization.  Printf style formatting strings work much better, and things like Python's string formatting (string.format, not "%") are better still.

>>3
+ works that way in Java because of how Java handles Strings and String concatenation.  Unfortunately, also due to the way Java handles Strings, each time you do + you also create a new String object to push the resulting Strings into.  System.io.print and println should never be used for anything more than simple String output; falling back on it for all output is the hallmark of a university programmer.

Java does have an implementation of printf but I'm not certain whether it suffers from a similar String being an immutable object drawbacks.

>>4
In what way, exactly, are immutable strings a drawback?

std::cout << std::ENTERPRISE_STRING << std::endl;

Format strings are fugly, what you really want is format combinators

>>5
Because idiots are often tempted to do something as demonstrated in the following PyFIOC code snippet to, for example, read a file into a string:

buf = ""
while 1:
  s = f.read(1024)
  buf += s
  if not len(s):
    break

The issue could be fixed in the VM by not copying the strings and only keeping references to its originating parts and only creating an actual new string upon repeated indexed access on it (sort of a lazy evaluation) but, ironically, VM writers are often too lazy to do it :(..

>>8
Nice pun, asshole!

>>8
So, immutable strings are bad because implementers are lazy? By the same logic, mutable strings are bad because programmers are stupid.

>>8
Maybe they were just too busy creating syntax for list comprehension and forgot to actually make their language worth a shit.

>>12
!

The most simple solution to this concern is to have Java deprecate use of the + as String concatenation, forcing the programmer to accept that Strings are immutable.  This will probably not happen in practice for reasons cited as "convenience" and backwards compatibility.

>>14
Is + just sugar for another function call, or are you seriously suggesting that strings should never be concatenated in Java?

>>15
Since it is Java, it should be handled through a method in the String class; usage of the + symbol is a special case and gives the naive programmer a false impression of mutability when all it is really doing is allowing shortcuts at the cost of GC work.  Moreover, Java already contains two other intentionally mutable string-likes named StringBuffer and StringBuilder that do not create a new object whenever you do something to the text contents.

You know what I am proposing?  Java can return interface types as well as classes.  Because both mutable and immutable string objects both use the same interface, I propose Java replaces most String returns with CharSequence returns.  That way, we can decide whether or not the output is worth changing later.

>>16
sequence
I smell clojure lurking in the background.

YES LET'S ADD STRINGS TOGETHER

Golly, j is a Unicode String type, and multiplying a Unicode String by an integer is obviously a good abstraction for converting Traditional Chinese to Standard Chinese, right?

23 Name: Anonymous 2011-02-03 1:38

Don't change these.

Name:		Email:
Entire Thread Thread List

All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -