vector as an argument

[oz10RXSz]

Could you give an example of a situation like that? I just want to see more clearly what the problem is.

Too much writing.
Read this:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

Besides shared state is not only a problem in multithreaded apps. It is also in large single-threaded ones for similar reasons.

You offer no support for this point. Thus, it is invalid.

1. No good optimizing compilers: C++ compilers do some dumb low-level optimizations like loop-unrolling or inlining. But many things are out of their reach: locks elision, inlining accross dynamic loadable modules, object inlining, common subexpression elimination, tail call optimization (except simple cases). Ever heard of pointer aliasing problem?

2. Semantic bugs in copying: deciding between shallow or deep copying members must be done at the level of each member, not a general smart pointer implementation. Thus, you still do need copying constructor written by yourself, or you get in trouble (in most cases).

[Galik]

@xoreaxeax

It seems to me that what you are saying is that C++ is a bad language for people who are not very good at programming. I think we can agree on that.

But what I would not do is take away C++ from those who are good programmers. And I would not argue that all programming languages should be used with the assumption that all programmers don't know what they are doing. Learning C++ requires learning about ownership, what should and should not hold references etc... You should not avoid teaching people those skills because that will make C++ programmers as bad as you presumed they were going to be. If you argue for your limitations then they become you.

So if you want to hire bad/cheap programmers, then use something slow and safe.

It sounds to me that you shouldn't be using C++ because it doesn't seem to do anything you want a language to do. Instead of using C++ the way that experts agree it should be used, you prefer to impose your own philosophy in order to make the same restrictions on the programmer as are built in to other languages.

I don't think you 'get' C++. I think you have a knowledge of language theory and an idealistic view that you seek to impose where it was never intended.

[oz10RXSz]

So if you want to hire bad/cheap programmers, then use something slow and safe.

No, you didn't understand. I'm still looking for the answer how you solve the problem with shared state I mentioned __IN C++__. I'm not saying that C++ is a bad language. It has some niche (like gamedev). I just say it does not scale up to large systems, where safety is needed, because it does not offer reasonable tool for dealing with shared state - even for the advanced programmers. Do you really think most of bugs in KDE are there because KDE is programmed by noobs?

And I do not need to use something slow and safe, because I can use something fast and safe. Python is not the only choice there - there are plenty of fast languages like Scala, Haskell or OCaml, which offer similar performance to that of C++. Anyway, this is a C++ forum, and we are talking on how to solve this issue in C++. Till now we have just 2 imperfect solutions:

1. keep good documentation and clear object ownerships (which is a limitation - there are lots of cases where objects do not have a natural owner - so you must bend your design to meet this goal)
2. avoid passing by ref if you can (slow).

[Galik]

The benchmarks here suggest Haskell is considerably slower than C++

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=gpp&lang2=ghc

Also http://www.haskell.org recommends writing code that needs to be fast in C:

http://www.haskell.org/haskellwiki/Why_Haskell_matters#The_speed_of_Haskell

EDIT: wrong link corrected

[oz10RXSz]

The first benchmark is flawed, because it compares hand-optimized C++ with machine-optimized Haskell. You see, C++ compilers are weak at optimizing code, but on the other side C++ allows programmers to optimize code by hand, just like in assebly. So this is unfair. No one writes code in such a way like in these benchmarks - maintainability is much more important than performance in most real projects. And in most projects you also have deadlines. By the time you finish basic functionality of your large project in C++, I will have been optimizing mine in (any HLL here) for 6 months. Most performance gain is from algorithms, not from low level optimizations. Which one will perform better?

But regardles, whether it is 4 times slower or not, things change quickly, because inmodern languages it is easier to parallelize code just because of lack of shared mutable state. So, on multicores, Haskell scales better and finally can outperform C++ (spending its time locking mutexes). The same can be said about Scala (wchich is less than 2x slower than C++ in most benchmarks, and in some it is even faster, so this is negligible) with its superior concurrency model. Why do you think Ericsson created Erlang? Because C++ scaled not enough for high performance telecommunication systems. We are entering multicore era, and C++ slept it over.

[Galik]

That's all very well but people need to know how to program C++ now, on architectures that that currently exist and that most people can afford. So they need to know good practice in C++, rather than how to mimic the strengths of other languages.

[oz10RXSz]

Agreed, but still what is wrong in passing by val?

[Galik]

If I have thousands of records in a list that I need to modify in several different ways by several different functions, I don't want to copy the list to every function that modifies it.

[oz10RXSz]

Ok, so the only reason is performance. So except in cases if the list is really large, there is no problem with this strategy.

[Galik]

Of course the only reasons are performance and memory consumption. What other reasons would there be?

[Galik]

xoreaxeax wrote:

So except in cases if the list is really large, there is no problem with this strategy.

Is the author of a function always going to know how large the list is that the caller is going to pass it?

[oz10RXSz]

How could he not know? He does have documentation which describes it in detail.

[Galik]

xoreaxeax wrote:

How could he not know? He does have documentation which describes it in detail.

What documentation tells the programmer how long a list is going to be? That's like knowing the length of a piece of string.

[Galik]

And its not just a function of the list's length. A shorter list being processed many times or a list that is passed through many depths of function calls all cause performance degradation and memory consumption.

[oz10RXSz]

Ok, ok, you are absolutely right. Passing by val is not a good default option. :)
There is no safe default.

[Galik]

Indeed.

In C++ nothing is truly safe. Security is largely down to design strategy. The learning curve for C++ is therefore quite steep compared with other languages. Language design (in general) follows the holy grail of safe-coding using different philosophies. One thing that appears to have remained consistent is the trade off between security and performance. C++ was designed to give as much safety as possible without yielding performance. So it has always tried to remain close to the hardware and give the programmer opportunities to be efficient. That is why good design methodology is crucial in C++ because it won't hold your hand or force you to program safely. Above all its a practical language, that lives in limited memory and runs on the smallest of processors.

[igouy]

xoreaxeax > So, on multicores, Haskell scales better and finally can outperform C++

The measurements Galik pointed to are on multicore - note the "≈ CPU Load" column

http://shootout.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=ghc#faster-programs-measurements

xoreaxeax > Why do you think Ericsson created Erlang?

For fault tolerance - not for performance!

Erlang FAQ - "The most common class of 'less suitable' problems is characterised by performance being a prime requirement and constant-factors having a large effect on performance."

http://www.erlang.org/faq/introduction.html#id50317

xoreaxeax > The first benchmark is flawed, because it compares hand-optimized C++ with machine-optimized Haskell.

Those Haskell programs have been heavily optimized in a collaborative effort by expert Haskell programmers.

http://www.haskell.org/haskellwiki/Great_language_shootout

[Kyon]

xoreaxeax wrote:

If you want to modify the passed arguments, you should pass by val. Functions modifying their arguments are poor design.

Whenever passing by value, you tell the computer to copy your input to be used in the function, this can take a very long time for large objects or structures. Don't think of functions like Mathemathical functions, think of them like Subroutines. You are free to change inputted arguments, just make sure that this is clear to the reader (by commenting, for example).