Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:how does this compare to D? (Score 1) 188

Didn't C++ gratuitously invent new syntax, too? Regardless, syntax is not all there is to a language. There even used to be a very snarky empiric observation/law regarding the relative frequency of topics in programming language discussions, with less meaningful things like syntax being discussed more frequently, although I don't recall the exact formulation of the observation.

Comment Re:More features. (Score 1) 246

In 1997, std::vector was not legal syntax.

1997 was prior to C++ becoming standardised, so there was no standard library. The vector from vector.h in SGI's STL was similar to the standard library vector, but it was not part of the standard library. The STL was also still available for a good decade or so after it was deprecated in favour of the C++ standard library.

Another change that happened involved the meaning of delete with respect to arrays. Old code would introduce bugs if compiled with new compilers and new code would leak memory if compiled with old compilers. That fits your time window.

Only if your compiler is buggy. Arrays have required deletion with delete[], not delete, for as long as the language has had a standard.

Comment Re:C# vs Swift (Score 3, Interesting) 66

1. While you're completely correct in theory, if all of the mainstream implementations currently work in the assumed fashion then his point is still reasonably valid.

The mainstream implementations optimise for a particular point in the tradeoff space because they're mainstream (i.e. intended to be used in that space). GCs designed for mobile and embedded systems work differently.

2. ARC is designed to minimise the refcount editing / false sharing

I've worked on the ARC optimisations a little bit. They're very primitive and the design means that you often can't elide the count manipulations. The optimisations are really there to simplify the front end, not to make the code better. When compiling Objective-C, clang is free to emit a retain for the object that's being stored and a release for the object that's being replaced. It doesn't need to try to be efficient, because the optimisers have knowledge of data and control flow that the front end lacks and so it makes sense to emit redundant operations in the front end and delete them in the middle. Swift does this subtly differently by having its own high-level IR that tracks dataflow, so the front end can feed cleaner IR into LLVM.

The design of ARC does nothing to reduce false sharing. Until 64-bit iOS, Apple was storing the refcount in a look-aside table (GNUstep put it in the object header about 20 years before Apple). This meant that you were acquiring a lock on a C++ map structure for each refcount manipulation, which made it incredibly expensive (roughly an order of magnitude more expensive than the GNUstep implementation).

Oh, and making the same optimisations work with C++ shared_ptr would be pretty straightforward, but it's mostly not needed because the refcount manipulations are inlined and simple arithmetic optimisations elide the redundant ones.

Comment Re:Deliberately missing the forest for the trees (Score 2) 357

My only hope is that Trump kicks California out of the union for having the most unbalanced budget of any state

Not sure if it's still true, but the last time I looked California would be running a net surplus if it cut its contribution to the Federal budget in half, so I guess that's one way of solving the problem. Kicking out Texas and a few other states that are significant net contributors would help even more...

Comment Re: Deliberately missing the forest for the trees (Score 2) 357

The bulk of immigrants from Eastern Europe do not even compete with the regular native as they tend to be better educated and work at a higher level

Which actually is the problem, and it's a social one not an economic one. Picture this:

You're a British citizen. You grew up in a poor town and went to a crappy comprehensive school. You had no expectations of getting a good job, because there aren't very many in your area. You see immigrants coming in and living in your poor communities and by and large they're not a problem because they're suffering the same problems as you. After you get over the novelty, they just other poor people like you. Fast forward a few years and they've now manage to get qualifications that are recognised here and now they're suddenly getting better jobs than you'd ever qualify for. Their house now has a better car in front of it than yours. They're wearing more expensive clothes than you. You're seeing that social mobility is a real thing - just not for people like you. How does that make you feel?

Sure, the economy as a whole is doing better, but that's not really a great consolation to the long-term unemployed.

Comment Re:how about modules? (Score 1) 246

You can't really have a clean separation between interface and implementation in C++ without radically redesigning the compiler model. Class and function interfaces are simple, but when you throw in templates then you need to be able to have access to all of the code needed to construct a new instance of the template. The original 4Front C++ compiler did this by a horrible dance of trying to compile the code, catching the linker errors, generating code for the missing symbols, and repeating. Modern C++ compilers just generate a copy of every template that a compilation unit needs and expecting the linker to throw away the duplicates (which is why something like LLVM ends up with over a gigabyte of .o files for a 10MB binary). A lot of newer languages get around this by simply not supporting shared libraries, so you can ship the code (or some IR) along with the interface files and your compiler can generate specialised versions at static link time, or by including a big VM so that everything is distributed as some form of IR and you compile on demand.

Comment Re:Another SLOW Language (Score 1) 246

That's not necessarily true. Smalltalk VMs have been written in a subset of Smalltalk that is statically compiled for a while, and these days the JIT parts are written in the full language. In the case of Java, the sun.misc.Unsafe package include pretty much everything that the JVM needs to be able to do in terms of bypassing its own safety guarantees to be able to self host. In Jikes, the JIT and GC are written in Java. The main reason that JVMs are written in C/C++ is that you don't get much benefit from writing the bit of code that is explicitly allowed to violate a language's invariants in that language (and it makes bootstrapping harder).

Comment Re:C++ is due for deletion ... (Score 2) 246

When a "high" level language require half a dozen or so ways to implement a cast, it's time to go.

Of all of the criticisms of C++, this one makes the least sense. Different casts in C++ have very different semantics and one of the worst things that a programming language can do (and which C++ does in many places) is give you the same syntax for different semantics. Are you taking the same set of bits and interpreting them as a different type (typesafe languages don't need this because they don't permit it)? Are you explicitly removing a const qualifier and thus declaring that you know what you're doing when you do something that might break the invariants of an interface (similarly, not permitted in typesafe languages)? Are you saying create a new instance of the target type initialised from this one?

Remember when a programming language was truly object-oriented?

I still use some that are, but C++ is not one of them. If you try to write Smalltalk-like code in C++, you will write almost as bad code as if you try to write C-like code in C++.

Slashdot Top Deals

Nothing ever becomes real until it is experienced. - John Keats