Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

open-std.org

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#11

Post by _yosefk »

jwatte wrote: post #4

Still no support for static compile and runtime introspection. That could be easily and cheaply implemented, at least for POD and aggregates thereof. If I have to build one more system that requires either a custom parser or repeating the names of all members, I think I will cry. The compiler ALREADY KNOWS!

One (longish) shortcut is getting the info from the debugger which already knows. That is, in the build system, compiling a file #including what you want, firing a debugger, printing out the necessary type information, generating code, building that code with the rest of your system.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#12

Post by EpicEng »

doctorpangloss wrote: post #3

It's actually kind of fascinating that the HN shortened title omits "games," which is really what this document focuses on. Specifically the document investigates "EASTL", i.e. the Electronic Arts STL, and how its learnings can be applied to the common STL. The actual title: "Towards improved support for games, graphics, real-time, low latency, embedded systems." These little pieces of censorship—that's not a sign th…

>It's certainly what most software people are working on, and it is probably where the plurality of the money is made.

Not sure where you got those ideas, but they're not even remotely true. Enterprise, while boring as all hell, is _huge_. The largest software vendors are (consistently) Microsoft, Oracle, IBM, and SAP[1]. According to Gartner, software was a $407.3B industry in 2013, and enterprise driven companies accounted for nearly half[2]. The video game industry pulled in $887M in 2014[3]. Not even close at .21%.

[1]: http://en.wikipedia.org/wiki/Software_industry#Size_of_the_i...

[2]: http://www.gartner.com/newsroom/id/2696317

[3]: http://www.statista.com/statistics/201093/revenue-of-the-us-...

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#13

Post by dang »

doctorpangloss wrote: post #3

It's actually kind of fascinating that the HN shortened title omits "games," which is really what this document focuses on. Specifically the document investigates "EASTL", i.e. the Electronic Arts STL, and how its learnings can be applied to the common STL. The actual title: "Towards improved support for games, graphics, real-time, low latency, embedded systems." These little pieces of censorship—that's not a sign th…

I think a moderator restored the original title as we usually do, but thought there wasn't enough room for the word "games" (there actually was, because we don't count " [pdf]" against the 80 char limit, but that isn't obvious). Invoking "censorship" here seems a bit over the top. Besides, games and games development stories are all over HN!

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#14

Post by shin_lao »

jwatte wrote: post #4

Still no support for static compile and runtime introspection. That could be easily and cheaply implemented, at least for POD and aggregates thereof. If I have to build one more system that requires either a custom parser or repeating the names of all members, I think I will cry. The compiler ALREADY KNOWS!

Static introspection is available via third party libraries such as Boost.Fusion.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#15

Post by fit2rule »

doctorpangloss wrote: post #3

It's actually kind of fascinating that the HN shortened title omits "games," which is really what this document focuses on. Specifically the document investigates "EASTL", i.e. the Electronic Arts STL, and how its learnings can be applied to the common STL. The actual title: "Towards improved support for games, graphics, real-time, low latency, embedded systems." These little pieces of censorship—that's not a sign th…

> censorship

It is censorship in the sense that the original authors' intention is modified to exclude the 'game' factor, but then .. why is this happening in the first place? Why do you think the editing-OP decided to omit this aspect?

> "pushed out of gaming"

There are a couple of schools of thought about 'games programmers' and 'game systems' which can be plotted with wide variance, yet have some interesting points of intersection. For example, the 'factoid' that games developers have a high turn-over/rockstar-phase/kidzone aspect, unless your game is making millions, in which case its serious business and only big boys need apply. So 'game ideology' as an industrious, conscious body of knowledge, has the punk-rock factor, wearing a 2000 dollar suit.

>> we really don't like to talk about games.

Game development as a software ethos, either from consumer or developer side in my opinion, is an interesting quandry.

Many times the notion that you are not making a game if you're making, instead, a business app, or a web scraper, or an OS kernel, and so on .. But actually the notion of game is key to all computing. From a technological perspective, we're all just playing games. Even Oracle has its event and frame "inner loop".

So I think there's an ugly truth about why we "don't like o talk about games", and it is that there is a zen to the subject. The zen is profitable, and it is also deadly.

Keep playing games - no matter where you go and what you do there. Keep making games, too.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#16

Post by chipsy »

doctorpangloss wrote: post #3

It's actually kind of fascinating that the HN shortened title omits "games," which is really what this document focuses on. Specifically the document investigates "EASTL", i.e. the Electronic Arts STL, and how its learnings can be applied to the common STL. The actual title: "Towards improved support for games, graphics, real-time, low latency, embedded systems." These little pieces of censorship—that's not a sign th…

You're getting it backwards. Games are prominent because it's in their modus operandi. Their relationship with tech remains symbiotic only as long as they can act as a flashy demo. This is a thing that occurs only some of the time, and more often than not, one of the two is compromised.

The other side of it, that a lot of games are made, is mostly reflective of the wishful thinking everyone has about games as a business. There are far more modified WordPress blogs out there than games, and they're probably more successful from a value standpoint.

Still, we discuss games often enough because they have that tendency to keep floating into the consumer space of tech.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#17

Post by panic »

chipsy wrote: post #16
doctorpangloss wrote: post #3

It's actually kind of fascinating that the HN shortened title omits "games," which is really what this document focuses on. Specifically the document investigates "EASTL", i.e. the Electronic Arts STL, and how its learnings can be applied to the common STL. The actual title: "Towards improved support for games, graphics, real-time, low latency, embedded systems." These little pieces of censorship—that's not a sign th…

You're getting it backwards. Games are prominent because it's in their modus operandi. Their relationship with tech remains symbiotic only as long as they can act as a flashy demo. This is a thing that occurs only some of the time, and more often than not, one of the two is compromised. The other side of it, that a lot of games are made, is mostly reflective of the wishful thinking everyone has about games as a busin…

Games have been a huge driving force behind tech from the beginning. For example, Unix only exists because Ken Thompson wanted to port his game Space Travel to the PDP-7.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#18

Post by Paul_S »

yoklov wrote: post #8

The allocator support in C++11 and, from what I've seen, the proposed allocator support in C++1y/z/whatever still leaves a massive amount to be desired. Polymorphic allocators solve what's basically a non-problem for games (ABI boundary problems) while introducing huge other issues. Alignment is a PITA but not really a pressing IMO. The real issue is stuff like rebind and the requirements to call destructors (which d…

There are no gamdevs on the c++ committee, probably because games companies are cheap bastards and don't want to expend resources on something that will affect them 10 years down the line (or even 2). Join the committee.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#19

Post by pavlov »

C++ has left the horrors of the '90s largely behind it, and I'm rather liking it these days... But every time I work on a C++ project, I soon get "array angst" -- a feeling of profound incompetence because I feel uncertain about basic array operations.

Seems like every project has its own take on array classes and their ownership semantics. Std::vector appears to be largely useless (or at least it's not used anywhere in practice, so the effect is the same). Boost is just scary. Qt is almost like a different language by now.

I wish the C++ standard had something like Cocoa's NSArray/CFArrayRef -- a general-purpose ordered container that is consistently used everywhere in APIs and does the job everywhere, even though it may not be quite the optimal data structure. But I guess it's 15 years too late for that.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#20

Post by shin_lao »

pavlov wrote: post #19

C++ has left the horrors of the '90s largely behind it, and I'm rather liking it these days... But every time I work on a C++ project, I soon get "array angst" -- a feeling of profound incompetence because I feel uncertain about basic array operations. Seems like every project has its own take on array classes and their ownership semantics. Std::vector appears to be largely useless (or at least it's not used anywhere…

Could you explain why you think std::vector is useless?
Post reply on HN