LWN: Comments on "A look at C++14, part 1"

Still no fixed template syntax

dgm — 2013-04-04T13:48:17+00:00

That's a bold proposal. Yes it is.

Still no fixed template syntax

dgm — 2013-04-04T13:45:05+00:00

Or you could glue two keys to the side of your keyboard, route the pins through the case to the PCI bus, write a custom kernel module, a driver for X, send patches to Qt and GTK+, and if you care, Microsoft.

Or you could just use < and >.

Still no fixed template syntax

hummassa — 2013-04-02T12:02:07+00:00

Backticks are the evilest ascii chars. :-D

Still no fixed template syntax

jezuch — 2013-04-02T08:53:55+00:00

Interestingly, early high-level programming languages separated the keyword and identifier namespaces by using e.g. bold or underline for keywords. This way the parser did not get a heart attack if you named your variable "if". (Some later languages dropped the inconvenience of special character attributes and made the keywords all-uppercase. And later still there was C.)

So, another way to fix the '<' ambiguity would be to make the template-initiating angle bracket bold ;)

A look at C++14, part 1

jwakely — 2013-04-02T08:25:17+00:00

> But back to pipelines in C++, surely the UNIX way would be to write some kind of general program which you could tell the system to take the output of one program and "pipe" it into another.

Shameless plug: http://pstreams.sourceforge.net/

A look at C++14, part 1

akeane — 2013-04-02T04:28:21+00:00

>What I am opposed to is multi threading!

Hooray, finally, a sane voice in the wilderness!

>the most misunderstood and _amused_ feature in programming.

This may be a typo, but yet it is brilliant somehow, I have always regarded pthreads as some evil entity laughing maliciously as some hapless programmer stumbles into it's wake...

If only I had a dollar for every sleep() I have seen to try to push that pesky race condition further into the sunset, and the amount of times I have seen assumptions being made about thread startup time and executions.

Or the nested locks, Oh God, the nested locks!

But back to pipelines in C++, surely the UNIX way would be to write some kind of general program which you could tell the system to take the output of one program and "pipe" it into another. I would call it:

/bin/M*A*S*H

Merry Easter

A look at C++14, part 1

nix — 2013-04-01T23:05:55+00:00

Before the newest C++ standeard the compiler didn't know about threading. That is it could optimize away as it wanted. Only the OS knew about threading. Now the compiler have to lay out code, which can work in a multi-threaded environment.

I commend to you Hans Boehm's Threads Cannot be Implemented as a Library.

A look at C++14, part 1

nix — 2013-04-01T23:03:28+00:00

Indeed. Unfortunately, a lot of programmers don't realize they can use pthread locking functions even without linking to libpthread, getting stubs unless something else has loaded libpthread. The total lack of glibc libpthread documentation might explain this :)

(actually, I can't remember if they're stubs or weak symbols. Stubs, I think, so you don't even need to wrap their uses in null checks.)

A look at C++14, part 1

mathstuf — 2013-04-01T20:49:46+00:00

> (developers test their own code in your reality, yes?)

Maybe[1] :) .

[1]http://www.r6.ca/blog/20120708T122219Z.html

A look at C++14, part 1

tjc — 2013-04-01T15:41:02+00:00

Thanks for starting the sub-thread on multithreading. I'm not sure if I agree with you or not--I have to think about this more--but it was very interesting.

A look at C++14, part 1

jwakely — 2013-04-01T11:43:27+00:00

> Before the newest C++ standeard the compiler didn't know about threading.

Nonsense, people have been using Pthreads with C++ for decades. The *standard* didn't mention threads, but compilers live in the real world and had to deal with what programmers actually do.

You're making a silly leap from "some people don't use threads correctly" to "I wish noone was allowed to use threads." Luckily you're not actually involved in the standardisation process, you're just whining on the internet.

> What we need in general (not only C++) is _not_ more support for threading, but non-blocking APIs and a good framework for writing applications using non-blocking IO.

There are proposals to add such things to the next C++ standard, because the committee realises not everyone programs the same way and that different tools are suitable for different tasks. Maybe you would benefit from the same realisation.

A look at C++14, part 1

simlo — 2013-03-31T21:08:01+00:00

Well, as I work with _real_ Java programs (written before select() came to Java), I know it is needed.

For instance: I have some data I have to send to different clients via TCP sockets. Naive solution: Loop through the clients and perform write() on each socket. Problem: If one client is not taking data the write() operation will block halting data for any other client as well.
Therefore I have to make a thread in which to execute write() for each client. And a message queue for each client to get data from the data producing thread(s) to the write thread.
Similarly, the read option is blocking so I have to have a receive thread per client.
And all this is hard to make work in all cases where clients can close the connection, the link is lost or what ever where the different thread are in different states.

On a proper OS (i.e. UNIX) in C++, I can use select() and therefore contain everything in one thread and have a clear picture of my possible states.

A look at C++14, part 1

simlo — 2013-03-31T20:58:02+00:00

Before the newest C++ standeard the compiler didn't know about threading. That is it could optimize away as it wanted. Only the OS knew about threading. Now the compiler have to lay out code, which can work in a multi-threaded environment. So unless, I use non-standeard options on the compiler I can't avoid it. Of course you can say the same for exceptions.

I am not against features in libraries: Those I can simply avoid.

I do have as I mentioned above (https://lwn.net/Articles/545352/) a thing against multi threading in general. And now C++ tries to jump the wagon, too.

The good thing about C++ is that it doesn't do much opposite for instance Java. There is no standeard for GUI either. STL is a library of containers and types you can use anywhere on any OS and without an OS (except for file IO).

Of course, to make portable multi threaded programs, wrappers around the OS specific implementations where needed. But then why not wrappers for sockets, serial ports etc?
Or put it another way: Was POSIX not a good enough wrapper?

Before STL and C++ was really not about portability. There weren't even a standeard like int32_t in C++. With threading, atomic types, chrono etc. STL have been given the task of supplying portability.

The thing about threads:
People learn to use threads all over the place. The excuse these days are scale-ability. But very rarely your program can scale anyway. The core reason for using threads is "that is what I am used to" and due to not being used to work with non-blocking IO.

What we need in general (not only C++) is _not_ more support for threading, but non-blocking APIs and a good framework for writing applications using non-blocking IO.

A look at C++14, part 1

jwakely — 2013-03-31T18:46:58+00:00

> An awful lot of libraries pull in libpthread just in case they are used with threaded programs.

This is not the C++ runtime's fault though, libstdc++ goes to a lot of effort to avoid locking in non-threaded programs, but sufficiently motivated fools^Wprogrammers can defeat that effort.

If you really need to skin that cat you can build GCC with --disable-threads and use that libstdc++.so

A look at C++14, part 1

nix — 2013-03-31T14:08:01+00:00

That's a nice API. I'll definitely be using that, although its being GPLv3 (not even GPLv2+) greatly restricts the set of projects that can benefit from it...

A look at C++14, part 1

nix — 2013-03-31T14:06:24+00:00

So you like new stuff, but only the stuff you want, and you don't like anything else even if other people want it. Got it.

This should be called "the user's lament" or something: it is universal. Note that since users often don't know if they'll like something before they try it, predicting this reliably requires not only telepathy but also precognition.

A look at C++14, part 1

nix — 2013-03-31T14:04:58+00:00

Well, sort of. An awful lot of libraries pull in libpthread just in case they are used with threaded programs. Nonthreaded programs then pull in libpthread transitively, and suddenly get hit with pointless locking overhead even though they will never have more than one thread.

Hell, on my system even ls(1) is linked with libpthread (though that is via librt because of a use of clock_gettime() and will presumably go away when it is rebuilt against glibc 2.17+.)

A look at C++14, part 1

Cyberax — 2013-03-31T13:59:27+00:00

I haven't seen real Java apps using separate threads to receive and send data. That's simply stupid in most cases. However, I did see asynchronous servers die under a high load with all but one CPU completely idle.

Still no fixed template syntax

nix — 2013-03-31T13:57:59+00:00

I'm yet to see a font where “і” differs from “i”

FWIW, here, the former (CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I, according to uniname) is differently hinted, so appears slightly different (with more hinting blur) if the patented FreeType bytecode interpreter is turned on. (In my web browser, ｉ FULLWIDTH LATIN SMALL LETTER I is invisible: in my terminals, it's visible since they use a different font, it is visible but ⅰ SMALL ROMAN NUMERAL ONE and ⁱ SUPERSCRIPT LATIN SMALL LETTER I are square boxes. IMNSHO, anyone who uses any of these when programming is a maniac. Even using them in literal strings or translated output is questionable: font coverage for these letters is just too poor.)

A look at C++14, part 1

simlo — 2013-03-31T09:31:49+00:00

What I am opposed to is multi threading!

My experience have shown me that it is the most misunderstood and amused feature in programming. Everybody learn about it in school and think they have to use it and impose it on everybody else. Once a program, framework or API relies on multithreading it is impossible to avoid. But in 95% of the cases the multi threading was complete unneeded if just the API were available in non-blocking versions.

Take Java: when you implement a TCP protocol you have a thread for receive, a thread for transmit and a timer to detect inactivity. Using select() you can do this in one thread avoiding a lot potential race conditions. I have seen instabilities and odd problems popping up in old Java programs due to this.

When using this model in C++ you get into further problems due to missing garbage collector.

In the beginning UNIX user space did not have multi threading. It is mostly a bad habit coming from other OS'es lacking proper processes.

I am not totally against multi threading: realtime system and system with heavy scale able algorithms. But 95% of programs only becomes unstable and much harder to maintain due to threads.

A look at C++14, part 1

jwakely — 2013-03-30T17:55:00+00:00

> What I oppose to, is having a C++ runtime assuming it is multi threaded, having the runtime system using atomic operations, when I want to stick to single threaded programs.

Use a better C++ runtime implementation then, don't argue the rest of us should always have to do things your way.

GCC can be configure with --disable-threads in which case there are no atomic operations used in the runtime. When configured with --enable-threads=posix (on a supported OS) the runtime still doesn't use atomic operations unless the program is linked with libpthread.so so single-threaded programs don't use atomic operations. So I don't really see what you're opposed to.

A look at C++14, part 1

jwakely — 2013-03-30T17:46:00+00:00

So you like new stuff, but only the stuff you want, and you don't like anything else even if other people want it. Got it.

If you don't like the new threading features don't use them. Sounds like you have no need for them, so it shouldn't be a problem for you.

A look at C++14, part 1

jwakely — 2013-03-30T17:44:01+00:00

No, "according to the Standard" containers do not expect allocators to be stateless. The weasel words allowing them to assume allocators are equal were removed for C++11 and the new propagation traits and scoped allocator model make it well-defined what happens when two containers with non-equal allocators interact.

Still no fixed template syntax

khim — 2013-03-30T12:36:02+00:00

I never needed to do what you described, nor did 99.9% of developers.

Rilly? Let's exclude developers who never worked in the international teams and never had to deal with foreign scripts. Do you still claim 99% of these like Unicode?

Most style guides forbid anything besides US ASCII even in languages where no such limitation exist for a reason. You only need to edit one piece of Java code which has Japanese-specific pieces with names in kanji and Arabic-specific pieces with names in abjad to understand why unicode in programming languages is bad idea (tm). At least if foreign names are transliterated you can least type them (even if you can not always pronounce them), but to even distinguish names in some weird scripts like abjad you need some training.

Even without kanji or abjad it's easy to create extremely hard-to-edit pieces of code. Here is an example:
public class HelloWorld { public static void main(String[] args) { for (int ⅰ=1;ⅰ<=10;ⅰ++) { for (int і=1;і<=10;і++) System.out.printf("%4d", і*і); System.out.println(); } } }
It's realtively easy to spot the error (depending on the font in your editor, of course), but if you try to fix it… you'll probably need to use copy-paste and if your piece of code contains not just “ⅰ” and “і” but a straightforward “i” and less straightforward “ｉ” and also “ⁱ” and “ᵢ”, too… then you are in trouble. For java compiler all six are quite different but for programmer some of them may be hard to distinguish and some are impossible to distinguish at all (depending on font).

US Ascii also has couple of pieces where confusion is possible (think "O" vs "0" and "1" vs "l"), but these are well-known and fonts are often specifically designed to distinguish them. With unicode confusion is inevitable: I'm yet to see a font where “і” differs from “i” and often even “ⅰ” is indistinguishable from “і” or “i”.

The whole "let's argue about the taste of oysters with those who actually ate them" just make me sick. Sorry, but I've worked with programs which use Unicode and I most definitely don't want to repeat this experience. Unicode in comments is fine (even if you can not change them in a clean way you can always just replace them with some approximation and if code deal with a nuances of a foreign language then often you need to use a bit of unicode to explain what goes on there), but once Unicode reaches identifiers it becomes a disaster and I shudder to even think about them lever of mayhem when it'll reach the syntax of language itself.

A look at C++14, part 1

simlo — 2013-03-30T11:18:23+00:00

As I see it there are 3 levels of concurrency

1) Use of explicit locks (as in the Linux kernel)

2) Message queues between threads, where data structures are owned by one thread avoiding the need for locks.

3) Messages queues in the form of pipes and sockets between processes.

1) is clearly the hardest to code. In principle it scales well of an unlimited amount of CPUs but it will often it ends up in lock congestion, where every thread waits for a specific resource. There is also a huge runtime overhead in managing the locks and logic around it.

2) and 3) are almost the same. 3) has the downside as you say that everything has to be serialized, which is a (huge) overhead. The upside is that individual processes can crash independently making it a lot easier to debug. You can also use sockets as a debug output, such the system can be inspected while running. 3) also have the possibility to move some of the system to a another machine.

But with a well written framework, where the communication channels are abstracted, 3) can be made into 2) without changing the core application code. No matter if you use 2) or 3), you have to use the same state machines in the application to handle the concurrency problems.

But once the application is written with explicit locks as under 1), there is no way back.

My advice is thus: Start by using 3). With templates and well a well written framework it is really not that hard to avoid threads. Then if the overhead of serialization is too high, merge the processes as in 2).

What I oppose to, is having a C++ runtime assuming it is multi threaded, having the runtime system using atomic operations, when I want to stick to single threaded programs. And what I argue for, is that most people ought to stick to single threaded programs anyway!

A look at C++14, part 1

simlo — 2013-03-30T10:38:50+00:00

Most likely the program is not waiting to get CPU - it is waiting for blocking IO. If you have 8 cores, the OS will schedule the other programs to the other CPUs.
Threading is most of the time a hack around blocking API calls. It is very rare that a normal desktop program actually have CPU work for more than one CPU.
And then you forget the cost in programming time and runtime of locking overhead: A single threaded program does not need atomic operations, which can be quite expensive on a multi cored platform. If, for instance, a program uses reference counting (std::shared_ptr), these operations have to be atomic. If you know the program is single threaded, that overhead is not needed. That kind of overhead might make the single threaded program run faster than the multi threaded, which very often can not use all 8 CPUs anyway due to lock contention.

A look at C++14, part 1

alankila — 2013-03-30T08:44:40+00:00

I suggest that you can't somehow smuggle in multiprocessing without encountering at least some of the hardships you suggest are exclusive to using threads. For instance, if you want to do multiprocessing and communicate using sockets or pipes, you could just as well use a producer-consumer pattern with threads and maintain the level of discipline in your threads that you know they don't need locking because all the resources they need for their work are local to the thread or just immutable.

Multiprocessing has one giant downside that always hits me in practice: the need to serialize and unserialize the datastructures that represent the work items and the results. This is pure overhead. In general the fact that threads can communicate with each other directly is their blessing and curse, but so far the blessings have been much larger to me, so I prefer code based on threads over the other means of achieving concurrency.

A look at C++14, part 1

elanthis — 2013-03-30T03:36:47+00:00

Threads - when invisible - are super important. No, most programs don't _need_ them, but I rather enjoy when the program I'm running on my modern 8-core desktop does its operations nearly instantly rather than making me wait because at most it's using ~12% of my CPU.

A look at C++14, part 1

Cyberax — 2013-03-30T00:43:49+00:00

That's one thing that's long overdue. Allocators are really badly designed - containers among other things expect allocators to be stateless, so swapping two strings in different shared memory segments is impossible to do correctly, according to the Standard.

A look at C++14, part 1

cry_regarder — 2013-03-29T23:43:17+00:00

The Polymorphic Allocators one has me excited. It is frustrating that I can't assign a string to a string defined with an allocator. This makes it somewhat unnatural working with items stored in boost::interprocess segments.

Cry

Still no fixed template syntax

HelloWorld — 2013-03-29T23:08:48+00:00

> Fixing non-ASCII code presents several additional and absolutely unnecessary problems.
Readability matters, and having keywords in crazy places for reasons that most C++ programmers don't understand doesn't help readability at all.

> I don't know if you ever had a pleasure of editing code written in an unfamiliar script, but I had. Cut&pasting identifiers can only get you so far before you start crying.
You must be really desperate if you need to come up with crazy use cases like that. I never needed to do what you described, nor did 99.9% of developers. Optimising a language for something like that would be insane.

Still no fixed template syntax

Cyberax — 2013-03-29T22:18:29+00:00

The problem is - I can fix screwups in ASCII.

Fixing non-ASCII code presents several additional and absolutely unnecessary problems. I don't know if you ever had a pleasure of editing code written in an unfamiliar script, but I had. Cut&pasting identifiers can only get you so far before you start crying.

Still no fixed template syntax

HelloWorld — 2013-03-29T22:15:21+00:00

> And that's exactly why one should stick to ASCII.
Uh, so one should stick to ASCII because one can screw up with or without unicode characters? Yeah right, that makes sense.

Still no fixed template syntax

tjc — 2013-03-29T21:03:31+00:00

Keep all code within ASCII!

I think I could get used to this:

template `(typename T)
std::enable_if `(T::template foo `(42) ::value, T) ::type bla();

Still no fixed template syntax

Cyberax — 2013-03-29T21:02:48+00:00

And that's exactly why one should stick to ASCII.

>Otoh, being able to write code in their native language with the proper alphabet is certainly a boon for slav developers.
No it isn't. Code in Russian looks very weird for Russian developers. Besides, Russian is a language with grammar cases and case-neutral identifiers are often very clumsy.

Still no fixed template syntax

tjc — 2013-03-29T20:21:12+00:00

Otoh, being able to write code in their native language with the proper alphabet is certainly a boon for slav developers.

Well, maybe not:

http://www.codinghorror.com/blog/2009/03/the-ugly-american-programmer.html

A look at C++14, part 1

danieldk — 2013-03-29T19:23:58+00:00

In fact, Java 8 has streams, which are fairly similar:

http://cr.openjdk.java.net/~briangoetz/lambda/collections...

Of course, conduits/pipes/... in Haskell are still more elegant ;).

A look at C++14, part 1

guillemj — 2013-03-29T18:49:17+00:00

Also for C, there's <http://libpipeline.nongnu.org/>.

Still no fixed template syntax

HelloWorld — 2013-03-29T18:10:24+00:00

What's that supposed to demonstrate? Sure, I have no idea what that code is about. But I wouldn't know what, say, code written in czech is about either, so how does that make things worse for me? Otoh, being able to write code in their native language with the proper alphabet is certainly a boon for slav developers.

Still no fixed template syntax

Cyberax — 2013-03-29T17:29:48+00:00

My system can handle UTF just fine. It's _me_ that can't handle the full UTF character set.