Hacker News Reader

"multiple platforms" means "ten different types of gcc+POSIX+fork+pthreads"

This. Unfortunate, but some even seem to think C99 support automatically means POSIX and then start complaining a platform isn't compatible if it doesn't handle what they thought was portable code..

Why is it bad to expect a portable operating system interface? Almost all languages have been doing this over the last decade (C, C++, Java, Go, Python, Ruby, PHP, etc...).

I once had the pleasure of writing a game engine that ran on Windows, Xbox, Xbox360, PS2, PS3, GameCube and the Wii. The 3 Microsoft systems shared some very basic Win32-style system API, but the other 4 were completely unique. When I see people talk about "cross platform" code only to find they mean "Linux and OSX!" I chuckle a little.

I can only guess what the portable code for PS3 looked like :).

Here's a taste: https://www.reddit.com/r/gamedev/comments/xddlp/describe_wha...

That was some funny stuff and enlightening. I remember having the PS2 experience myself when studying its architecture: so many individual processors stitched together it was like re-inventing 60-80's computing experience lol. That said, I thought it was cool that they threw in some scratchpad. It's better than cache in many ways and so underutlized in special-purpose, performance designs. Helps with real-time, too, as it's predictable. PS2's mainly just helped with I/O hacks IIRC correctly, though.

Also interesting to contrast your description of PS3 with Naughty Dog comments. Seems like they got a lot more out of them but had to work hard to do it. Curious, there were products that auto-synthesized code for SPU's like RapidMind. I had planned on trying them had I used PS3's for acceleration. Did you or anyone in that industry try those tools to see if they delivered similar performance over hand-coded algorithms in gaming workloads?

http://www.theregister.co.uk/Print/2007/05/08/rapidmind_two/

The big difference between the project I was on vs Naughty Dog was that ND was 100% committed to the PS3 exclusively and eternally. If you know you can't escape then you are motivated to put in the effort to make it as good a fate as possible. The PS3 rewarded effort, but only on a very steep curve...

Meanwhile, my team was multiplatform. That meant most people could hide in the easy spaces on the PC or maybe the 360. We had a small group of Russians and Europeans who enjoyed the challenge of hand-optimizing the SPU. They would not have tolerated synthesized code ;)

That makes sense. The Russian angle, too: prior experience showed thdm to bd good at programming and optimization. One told me it's because access to good hardware was limited for many and so people got the most out of what they had. He said some even coded and debugged algorithms on paper before going to Internet cafes.

I'd probably try to get more in OSS projects but they can be a rowdy bunch. Gotta have manager or leader that can keep the egos and nationalism in check. ;)

you mean half of code compiled with __cdecl, other half __stdcall, some calls as pascal... oh, that's cute..

and 32/64bit..

Because C and C++ never really had one.

UNIX was seen as the C runtime. When the standard came ANSI C adopted what was considered the minimum portable bits one could use in non UNIX systems.

Then came POSIX, which isn't as portable as many think. It also enjoys some of the UB and implementation specific behavior of the C world.

C++ while trying to cater to C developers adopted the same attitude.

Thankfully the C++ committee is changing that with C++17.

It's a bit disappointing C seems to be getting left behind in some areas. It's simpler to compile, which in theory should mean that it's more portable.

No it is not.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

Many equate "C == what my compiler does", but just like any standardized technology with holes open to implementers to decide upon, portability isn't as people think.

I read Chris Lattner's posts. There are definitely things the standards don't specify that people take for granted (twos-complement for example). C is still an order of magnitude easier to parse than C++ though (especially modern). In theory, implementing and maintaining a compiler for it for a platform should be simpler.

Implementing an effective compiler is another concern entirely, but I would still argue that there tend to be more incompatibilities between C++ implementations than C.

Yes, parsing is way harder because C++ requires the context aware grammar.

However many C++ incompatibilities are actually caused by C compatibility and the goal of having higher constructs that are copy paste compatible with C but with additional semantics, e.g. structs.

So in both cases, to achieve your portability goal the languages would have to be fully specified.

C and C++ are admittedly different languages, but I would think more than less of the code for compiling both languages should be the same. I personally can't see how one language would impede the other.

As a C/C++ user, I'm honestly still not sure why a number of C features have yet to be formalized in C++ (e.g. restrict).

> Thankfully the C++ committee is changing that with C++17.

Which C++17 feature are you referring to? Modules?

The work being done by the SG

https://isocpp.org/std/status

Filesystems, networking, concurrency, ....

Sadly databases died out apparently.

Looks like they're doing what they should've done some time ago and what helped many competing languages get ahead. Between that and recent standards, C++ programming might get really interesting again. Even I might take a stab at it eventually.

Even though I hardly use it at work (JVM/.NET), it was my to go to language after Turbo Pascal. So I still enjoy following and dabbling with it.

Some of the issues C++ had were:

- C compilers were still catching up with ANSI C89 and it was a mess

- C++ being in the process of becoming standardise was even worse. It was quite hard to find out what were the working common features between compiler vendors, specially in terms of semantics

- The C culture that prevented many nice frameworks to succeed, because they were too high level, hence why MFC is such a thin wrapper over Win32.

- Lack of standard ABI in an age people only shared binary libraries.

C++14 and C++17 look really nice, but I doubt C++ will recover its place at the enterprise, beyond performance critical libraries/modules.

Expecting it isn't bad, blindly assuming POSIX is available everywhere is bad, as in calling your code cross-platform because it uses just C99 and POSIX for instance

The majority of the time it's a safe assumption though, so I'm not sure developers can really be considered to blame.

The reality is, without it, developing software for a platform takes more effort which I think is one of the reasons languages have taken on the initiative of building portable interfaces. Even C11 has added threads.h.

> But I've noticed a tendency for people to sometimes assume that "multiple platforms" means "ten different types of gcc+POSIX+fork+pthreads".

Having done multiple platform C development across Aix, HP-UX, Solaris, GNU/Linux and Windows in the first .com wave, as well as, having some embedded knowledge, it is always interesting that for some people only gcc and now clang exist.

As for C99, Microsoft is pretty clear that are only supporting what is required by the C++ standard.

I believe they have started explicitly targeting C99 support in more recent versions in order to make it easier to port C code developed against gcc or clang.

Here's an older article - http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar...

(I've seen more recent ones, but I can't find an example to hand)

Given that the video was already a bit old, this is the latest official statement I could find, from 29 Apr 2015.

http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17...

"Q. What about the C99 Core Language, or the C11 Core Language and Standard Library?

A. Our top priority is C++ conformance. We've implemented the C99 Standard Library because C++11 incorporated it by reference. C++ (up to the current Working Paper) hasn't incorporated the C99 Core Language in its entirety (only a handful of features, listed above), nor is it ever likely to. It may incorporate the C11 Standard Library at some point in the future, but that hasn't happened yet.

In VS 2013, the compiler team implemented some C99 Core Language features in C mode (e.g. designated initializers, see MSDN for the full list), in order to support some popular libraries. "

No they were pretty clear that it is only what is required by C++ standard, and some high profile customers.

There was a C9 interview about it, need to search for it.

Could not find the interview video, but this was another one I remembered have watched:

https://channel9.msdn.com/Events/Visual-Studio/Launch-2013/V...

Starting at 00:18:40, note the "not an intent to conform to C99/C11".

FFMpeg was one of the customers

Out of curiosity, who are MSVCs high profile customers?

They didn't mentioned on the interview.

If I recall correctly it was at a Visual Studio event last year, on those floor interviews they publish with the teams on C9.

Adobe is almost certainly one:

https://helpx.adobe.com/creative-suite/kb/microsoft-visual-c...

There's probably quite a few internal-only users of Visual C++ too.

EDIT: Well, they're a high-profile user of Visual C++, I have no idea if they require C99 support but they ship a Mac version so it's possible.

One of them was FFMpeg, from the video I digged out.

When I was in that situation (maybe ten years ago), we ran gcc on Aix, HP-UX, Solaris, Linux, Tru64, SGI, and maybe a couple of others. Then of course there was Windows, which used the Microsoft compiler. But using only two compilers made the ten or so platforms easier to deal with. (There still was a bunch of code that was "#ifdef SGI/#else/#endif", and similarly for other platforms, but at least the compilers behaved the same.)

We had to use the vendor compilers, so no fun.

This was the only time period I used C instead of C++ at work.

However I do confess, the situation for C++ support was even worse, so although I am not fan of C, the decision made sense from business point of view.

How long ago was your experience? Was gcc an option at that time? Or did management require you to use the vendor compiler?

What we did was, we used the vendor compilers to compile gcc for a platform (or maybe used gcc to cross-compile itself, I forget). Then we used that gcc to compile gcc for that platform. Then we used the new gcc to compile gcc for that platform, and made sure that it was the same as the previous gcc. This wasn't easy - we had one guy that this is pretty much all he did for months. But it got us to a place where we were free from the vendor compilers.

> How long ago was your experience?

It was back in the first .com wave, so 1999 - 2002.

> Was gcc an option at that time? Or did management require you to use the vendor compiler?

Customers did. Our software needed to integrate with their existing toolchains.

At least for our customers gcc was not a serious compiler, given the license and being that funny open source thingy.

FYI, C99 printf including 'z' for size_t was fully implemented in VS 2015.

Most likely you are not allowed to comment on it, but has the official position from the last C9 VS team interviews changed?

I believe we're hoping that Clang/C2 will satisfy those who want to build C99 TUs on Windows. Personally, I have absolutely no interest in C99 (I wasted a year and a half of my life learning C before C++).

Thanks for replying. I had a similar experience back in the MS-DOS days still, and share the same opinion.

Turbo Pascal -> C (meh) -> C++ (great back in business!)

Even though I mostly do JVM and .NET nowadays, still enjoy playing with C++ on the side, specially for mobile OS coding.

I see dropping C support on Windows as a means to force developers to migrate to more secure languages, but of course Microsoft should do what makes business sense.

correct.

Thanks for the note. Switching to VS2015 just worked its way up my to do list.

You'll want to read these changelogs for the CRT and the STL: http://blogs.msdn.com/b/vcblog/archive/2014/06/18/crt-featur... , http://blogs.msdn.com/b/vcblog/archive/2014/06/06/c-14-stl-f... , and http://blogs.msdn.com/b/vcblog/archive/2015/07/14/stl-fixes-... .