next »

[Dacke]

I think you misunderstood my complaints.

The article was about the Justice Department promoting something incredibly stupid. Which is incredibly troubling, even if other parts of the system end up getting it right in the end.

As you hopefully know the US political system is incredibly corrupt, it's largely a plutocracy. Most decisions are made on the basis of capital interests with complete disregard for public opinion or the common good. The copyright system has been broken for a long time, in large part thanks to lobbying from Disney. This broken form of copyright has since been "exported" to the rest of us, to great detriment. It's incredibly important that they get this right, or we'll all suffer. Since they have completely fucked up in the past due to a broken political system I think it's completely reasonable to be worried.

But I would never argue that all hope is lost in this case. Since there are big commercial interests of both sides of the conflict it will at least be taken seriously.

edit: and yes, the supreme court is somewhat of a special case. But they are politically appointed and which statements can be made by interest groups is still a matter lobbying and resources

[Sik]

Why do they get to decide this? Why don't they form a committee of experienced programmers from many different backgrounds to decide these things instead of uninformed law people?

If you had programmers on board since the beginning (assuming that was possible) it's likely copyright would have never existed in the first place. In the end it's all about business, not about author rights.

[BorisTheBrave]

Oh, whoops, I've been using the term "Justice Department" incorrectly. I'll amend my post to be less confusing.

It's true that US law making has some problems (not that other countries are much better). But I'll remind you that this issue is about interpreting the existing laws (I think - this is very confusing stuff). The Justice department's position is not crazy. After all, the appeals court agrees with it. And I can see the logic in it myself. You might not like the consequences of some laws, and they certainly weren't intended when copyright was drafted, but those facts shouldn't alter what interpretation is given. The *intended* route to fix laws that aren't working as intended is to amend the law, not hope that the Supreme Court essentially ignores what the law says.

In the end it's all about business, not about author rights.

I am baffled by this belief, particularly on a Game Dev forum, that copyright is a bad idea. Without copyright, it would be difficult to develop a game with the hopes of selling it. Because not only would piracy be higher without fear of being caught, but services like Steam wouldn't bother greenlighting you - they'd just copy the game and sell it via their own store.

[InfiniteStateMachine]

Of all the api's to squabble over lol


Perhaps I'm malinformed via different article but apparently the initial verdict was done by a judge who was formally a programmer. Now it's being promoted to a higher court?

[Dacke]

But I'll remind you that this issue is about interpreting the existing laws (I think - this is very confusing stuff). The *intended* route to fix laws that aren't working as intended is to amend the law, not hope that the Supreme Court essentially ignores what the law says.

Except that the US has a common law system. They actually do rely on the court system to generate precedents that become law. If you've listened to arguments made in the Supreme Court, it's often not a matter of just discussion what the law actually says but in large a matter of considering consequences etc. The law isn't a well designed specification and in this case it can (obviously) be interpreted in two different ways. Which is why the Justice Department statement is much more loaded, it's not simply an attempt to objectively interpret what the law says. It's an opinion, likely based on special interests - which may be based on specific lobbying or a consequence of all the other corruption surrounding the design of copyright law (my speculation).

It's true that US law making has some problems (not that other countries are much better).

All states are indeed corrupt to different degrees, there is no state that fully serves it people. I doubt such a thing is even possible. But money plays a bigger part in US politics, as a natural consequence of the USA being the world's primary imperial power. They are the most powerful, so it makes sense to invest more money in manipulating the outcomes of the system. So you get results like these, that indicate that almost no US political decisions are grounded in public opinion:
http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid=9354310

[Sik]

In the end it's all about business, not about author rights.

I am baffled by this belief, particularly on a Game Dev forum, that copyright is a bad idea. Without copyright, it would be difficult to develop a game with the hopes of selling it. Because not only would piracy be higher without fear of being caught, but services like Steam wouldn't bother greenlighting you - they'd just copy the game and sell it via their own store.

Of course if history had taken this course then we'd have been already looking for other ways to make a living than selling software (maybe to the point that the idea copyright would get rendered useless in the first place).

Mind you, people will always claim to prefer as less restrictions as possible. To anybody who isn't a technical person, copyrighting an API not only makes sense, they'd probably think it should be patentable as well (much like how many standard protocols have patents on them, since from their viewpoint it's the same kind of thing, just for software).

[gimymblert]

If programmer thought it copyright would be a good idea, you wouldn't be able to make game periods, c++ would have been on an expensive license and the internet hugely gated by money, forums wouldn't exist, only elite would be able to stuff behind industry patent laws, etc ...

[oahda]

Agh, why do variables still have to be manually initialised to 0 in C++14? So much bug potential that could be easily avoided by such a simple thing. It's not 1998 any more.

[ProgramGamer]

Agh, why do variables still have to be manually initialised to 0 in C++14? So much bug potential that could be easily avoided by such a simple thing. It's not 1998 any more.

Because when something is automated the risk of unexpected results increases due to the programmer not being in control.

Also sometimes it's fun to see what value was in that memory block before

[oahda]

As long as it's a known standard of the language (not compiler-independent), much like the fact that indices start at 0 rather than 1, which it is in a lot of other modern languages, I would still be in full control if that's expected behaviour.

But because of C++ I still keep paranoidly initialising everything to 0 even in languages where I don't have to. ;(

[Sik]

Agh, why do variables still have to be manually initialised to 0 in C++14? So much bug potential that could be easily avoided by such a simple thing. It's not 1998 any more.

Large arrays, those aren't that easy to detect if they will get completely rewritten before being read back and they can't be stored in registers, and in the case of local ones they have to be explicitly cleared (since they're on the stack). But yeah, arrays are easily distinguishable from individual variables so they could have changed that for individual variables at least.

I wonder if somebody was paranoid about breaking old stuff (but old stuff would never upgrade to a newer language anyway).

[oahda]

I don't see how it could break old stuff, tho. Old stuff would just initialise everything explicitly anyway.

Or are people out there relying on this for random number generation or something?

[InfiniteStateMachine]

Well also defaulting a variable is work. As minor as it is, defaulting a variable is less performant.

Maybe a compiler flag like -allowdefaults would satisfy everyone.

[Sik]

I don't see how it could break old stuff, tho. Old stuff would just initialise everything explicitly anyway.

You'd be surprised how fragile is that stuff =P

Or are people out there relying on this for random number generation or something?

I believe OpenSSL did this? (which then somebody patched thinking it was a bug because it was uninitialized, when really the code relied on this) Probably a very bad idea anyway since it's undefined behavior and the compiler can do anything it wishes, not to mention it most likely not being even remotely random anyway.

[Boreal]

Agh, why do variables still have to be manually initialised to 0 in C++14? So much bug potential that could be easily avoided by such a simple thing. It's not 1998 any more.

If you're using C++14 you should be using `auto` judiciously.  Among other benefits, it forces initialization.  Herb Sutter (one of the big C++ developers) talks about this and more in this presentation:





In cases where you want to leave something like a large array uninitialized (where the initialization cost would be somewhat significant), just don't use `auto`.  The jarring difference in style makes it obvious where you are doing something "C-style" as an optimization.

[oahda]

Kind of annoying to have everything look like a dynamically typed language where you don't explicitly write out the types of what you're declaring, tho. And you can't declare auto member variables anyway, can you?

Anyway, someone else talked about auto on Twitter in response to this too, so I guess I'll take a look.

[Boreal]

Kind of annoying to have everything look like a dynamically typed language where you don't explicitly write out the types of what you're declaring, tho. And you can't declare auto member variables anyway, can you?

That's what I thought at first, but when I got into it I realized how useful it is to have your types inferred.  Besides, you're still really writing out types explicitly, you're just doing it without implicit conversions.  Like this:

Code:

// old
int a = 10;
unsigned int b = 10;
float c = 10;

// new
auto a = 10;
auto b = 10u;
auto c = 10.0f;

And yes, you can't specify fields with `auto`.  There's also unfortunately no way to currently create an array with `auto` except using something like `std::array`.

All in all, `auto` is really just making C++ into more of a functional programming language.  Basically, some of the cool special features that lambdas brought (or ended up needing) are being carried over to the procedural side.

[oahda]

I wasn't aware there was an unsigned u suffix.

[Sik]

The U suffix is one of the oldest probably, along with L (for long) and more recently, LL (long long) as well as their combinations (UL, ULL). Also don't forget the L prefix for string literals (which makes them wchar_t instead of char).

Doesn't C++14 allow you to initialize member variables in the class declaration? I recall this working for structs, and in C++, structs are just classes that default to public instead of private. Maybe it's just for a more limited instance than what I'm thinking on, though.

[InfiniteStateMachine]

Agh, why do variables still have to be manually initialised to 0 in C++14? So much bug potential that could be easily avoided by such a simple thing. It's not 1998 any more.

If you're using C++14 you should be using `auto` judiciously.  Among other benefits, it forces initialization.  Herb Sutter (one of the big C++ developers) talks about this and more in this presentation:





In cases where you want to leave something like a large array uninitialized (where the initialization cost would be somewhat significant), just don't use `auto`.  The jarring difference in style makes it obvious where you are doing something "C-style" as an optimization.

How does that work? Auto needs a init value to infer the type.

EX

auto x;

how is it going to know the type?

if you do the following :

auto x = 10.0f;

then you aren't default initializing it because you are explicitly initializing it to the rvalue.

EDIT : Your answer doesn't seem to relate to his question (he wants zero-initialization, not inferred init). Did you mean to quote a different post?