They are yeah, but in that scenario you would also not have a window decoration with a close button, so I assumed the OP meant maximized :P
They are yeah, but in that scenario you would also not have a window decoration with a close button, so I assumed the OP meant maximized :P
Reread the OP. They say:
not on GNOME, because you have a panel at the top
And
when usign GTK apps on those [non-GNOME] desktops
So you would not “access the controls above the app”, because having controls above the app is not covered by this scenario.
The scenario is:
Which makes the close button be in the corner of the screen, but without actually extending to it.
On topic: never knew this was a problem, guess I got spoiled by the Qt environment
I don’t know about color profile data, but I can vouch for the EDID potentially being totally wrong sometimes on even basic data like physical size or even logical size (number of pixels).
As for the why, I don’t know, but following Occam’s razor I would guess that it’s cheaper when you just don’t care and leave it as somebody else’s problem.
Since my previous example didn’t really have return value, I am changing it slightly. So if I’m reading your suggestion of “rewriting that in 3 lines and a single nested scope followed by a single return”, I think you mean it like this?
int retval = 0;
// precondition checks:
if (!p1) retval = -ERROR1;
if (p2) retval = -ERROR2;
if (!p3 && p4) retval = -ERROR3;
// business logic:
if (p1 && !p2 && (p3 || !p4))
{
retval = 42;
}
// or perhaps would you prefer the business logic check be like this?
if (retval != -ERROR1 && retval != -ERROR2 && retval != -ERROR3)
{
retval = 42;
}
// or perhaps you'd split the business logic predicate like this? (Assuming the predicates only have a value of 0 or 1)
int ok = p1;
ok &= !p2;
ok &= p3 || !p4;
if (ok)
{
retval = 42;
}
return retval;
as opposed to this?
// precondition checks:
if(!p1) return -ERROR1;
if(p2) return -ERROR2;
if(!p3 && p4) return -ERROR3;
// business logic:
return 42;
Using a retval has the exact problem that you want to avoid: at the point where we do return retval
, we have no idea how retval
was manipulated, or if it was set multiple times by different branches.
It’s mutable state inside the function, so any line from when the variable is defined to when return retval
is hit must now be examined to know why retval
has the value that it has.
Not to mention that the business logic then needs to be guarded with some predicate, because we can’t early return. And if you need to add another precondition check, you need to add another (but inverted) predicate to the business logic check.
You also mentioned resource leaks, and I find that a more compelling argument for having only a single return. Readability and understandability (both of which directly correlate to maintainability) are undeniably better with early returns. But if you hit an early return after you have allocated resources, you have a resource leak.
Still, there are better solutions to the resource leak problem than to clobber your functions into an unreadable mess. Here’s a couple options I can think of.
defer
Example of option 1
// precondition checks
if(!p1) return -ERROR1;
if(p2) return -ERROR2;
if(!p3 && p4) return -ERROR3;
void* pResource = allocResource();
int retval = 0;
// ...
// some business logic, no return allowed
// ...
freeResource(pResource);
return retval; // no leaks
Example of option 2
// same precondition checks with early returns, won't repeat them for brevity
auto Resource = allocResource();
// ...
// some business logic, return allowed, the destructor of Resource will be called when it goes out of scope, freeing the resources. No leaks
// ...
return 42;
Example of option 3
// precondition checks
void* pResource = allocResource();
defer freeResource(pResource);
// ...
// some business logic, return allowed, deferred statements will be executed before return. No leaks
// ...
return 42;
Example of option 4
int freeAndReturn(void* pResource, const int retval)
{
freeResource(pResource);
return retval;
}
int doWork()
{
// precondition checks
void* pResource = allocResource();
// ...
// some business logic, return allowed only in the same form as the following line
// ...
return freeAndReturn(pResource, 42);
}
Bad advice. Early return is way easier to parse and comprehend.
if (p1)
{
if(!p2)
{
if(p3 || !p4)
{
*pOut = 10;
}
}
}
vs
if(!p1) return;
if(p2) return;
if(!p3 && p4) return;
*pOut = 10;
Early out makes the error conditions explicit, which is what one is interested in 90% of the time. After the last if you know that all of the above conditions are false, so you don’t need to keep them in your head.
And this is just a silly example with 3 predicates, imagine how a full function with lots of state looks. You would need to keep the entire decision tree in your head at all times. That’s the opposite of maintainable.
Maybe Eidos would love to get another Deus Ex out there but there’s no publisher interest
You know, they could just… Say this, and placate everyone. I’m honestly sick and tired of companies in general, and game companies specifically, being afforded this stupid level of opaqueness.
If you were to talk to someone that would exclusively stonewall you, you’d be quick to stop talking to this person. When it’s game companies though, everyone bends over backwards to try to find justifications for their behavior on their behalf.
I think it’s possible that the filesystem ran out of inodes, so even though there is space on disk, there is no space in the filesystem metadata to store new files.
Now, I don’t know off the top of my head how to check this, but I assume the answer is on the internet somewhere (am on phone and can’t help much more than this, sorry)