you have multiple distinguishable fingertips, though. I just tapped around a bit on my wrist; index- middle- and ring finger seem make a workable(*) toolset to enter ternary digits, every group of three of which could represent 27 states; there's your alphabet plus room for an escape character to get a different alphabet.
You're not making it better by actively promoting horrible, non-portable, implementation-dependent and error-prone coding practices.
What's wrong with [depending on] implementation-defined behaviors and using static assertions to verify them?
(Ignoring that that's quite a stretch from what I said, and deliberately ignoring the 'error-prone' part), if you do verify your assumptions about the implementations then of course it's less horrible. However, you do pay the price in losing portability, so if it isn't for a particular good reason, not unnecessarily relying on implementation-defined or unspecified behaviour is preferrable.
For example, would it be poor form to assume (and assert) things like 8-bit bytes or that the character set is ASCII, and if so, why?
This way, the compiler will fail and kick out a diagnostic if the environment doesn't match the assumptions.
That's quite a hack (but better than nothing, sure). If you had a hard requirement such as "has to be ASCII-based" or "char must be 8 bits wide", then I'd wonder where it comes from. I don't deny that there may be a few good reasons, but it turns out that often you could write code in a way that is agnostic of such details and hence portable.
For instance, the ctype.h functions (isprint(), isalnum() and friends) can be used to implement encoding-independent text processing. For requiring char to be of some specific width, there's hardly a reason, unless you're improperly (de)serializing. The (mandatory as of C99) types (u)int_leastN_t come to mind, and for the rare cases where you actually need a fixed-width-no-padding type, there are the (optional but widely implemented) (u)intN_t types)
I guess i can outnitpick you on that; #include "stdio.h" is actually fine. Not that it's a good idea, but it will give you the same effect #include does, as far as the standard is concerned.
Besides, the real failure about that line is that in C++ it should probably read #include <cstdio> (unless i'm mistaken; i do know my C, but C++ not so much)
"The" compiler? You do realize that C is a language specification, right?
doesn't care if you return nothing from a 'int' function.
That's just wrong. It's possible (though unlikely) that your compiler "doesn't care"> It's undefined behaviour to fail to return a value from a non-void function. It doesn't get much wronger; and as a consequence of UB, the compiler isn't even required to do anything meaninful afterwards. If your particular implementation tolerates it, fine, but please don't conclude that it must be how C works then. You're outside the scope of C at that point.
So, while 'void f()' would be cleaner, only 'f()' without a return type set (ie 'int') is seen a lot.:-)
Yes, garbage code is seen a lot. You're not making it better by actively promoting horrible, non-portable, implementation-dependent and error-prone coding practices. Also, again, () means "unspecified number of parameters", (void) means "no parameters". C isn't quite C++.
More general hint: The principle of minimum scope exists for a reason. Declare your variables at the point where they can be initialised, not at some arbitrary point and you make life easier for people trying to understand the lifetime of the variable.
Sorry for double posting, but your more general hint is largely moot after after applying my less general hint, because there won't be as much code in a function in order to make it confusing wrt. to scope and storage duration anymore.
I completely agree, and as said, C99 intruduced mixed declarations and code, and i use it a lot.
I don't understand why you'd be telling me this, unless for some reason you have the same misconception about C89 that GP had - the gibberish about 'top of function'
Also compiles under gcc and g++. Except for the file extension;)
You cannot use "$compiler compiles it" to determine whether it's portable or correct C, just look at all the non-C garbage gcc happily accepts.
Though in this case i'm not saying it wouldn't be correct; I just pointed out that C programmers usually wouldn't declare their function to have an unspecified number of arguments when what they really want is no arguments. It's not wrong; just unusual, C++ influenced style.
the PM's code is legal and portable C
Possibles &= ~(Possibles & -Possibles); Portable my ass. This at least requires two's complement. I'm also fairly sure that in addition to being nonportable, it's undefined behaviour unless there's a sequence point i'm missing (can verify that later)
and therefore also legal C++.
Don't be silly. Valid C isn't automatically valid C++, and if you have a program that happens to be something both a C and a C++ would accept, it doesn't need to have the same behaviour. Consider:
int main(void)
{
int class = 42;
}
That's strictly conforming C, and invalid C++
Further consider:
int main(void)
{
for (size_t i = 0; i
puts("poof");
}
That's valid C++, invalid C89, strictly conforming C99/C11. When treated as C, it will behave different from when treated as C++, unless your implementation has char and int being of the same width, which is rather unusual.
Thanks for playing.
I was able to compile it with both gcc and g++ [...] [s]o yes, it is legal as both C and C++ code.
Hahaha. You're so mistaken, it's not even funny anymore. (No, not even with -ansi -pedantic). The language that gcc accepts is a twisted superset of C, so using gcc to evaluate whether it's correct C code is completely meaningless.
everything has to be declared at the top of the function... Always.
That's not true, and has never been. Until about 16 years ago, you had to declare your variables at the beginning of a block/compound statement. That can be well within the function.
As of about 16 years ago, you're even allowed to freely mix your declarations and code.
[incoherent gibberish]. And stuff like that.
Yeah. The kind of stuff you seem largely unfamiliar with.
General hint: If your functions are so long that having to (suppose this was indeed the case) declare/define all your variables at the top becomes a serious annoyance, then chances are that your functions are too long/do too much. Fix that instead.
Yes I was referring to economies of scale. After you have created a usable $language webhosting environment (say, a VM image), supply is essentially infinite (modulo hardware).
Streaming movies over the internet and playing them on a computer is not a simple thing, that's only what idiots with no understanding of the details think.
Geeks wouldn't quite be geeks if they felt like deferring all the difficult (i.e. interesting) things to some company while at the same time giving them money. Get a clue.
presumably to wait for the system to truly be 'off', with caps discharged and all.
A faster way to achieve the same is pressing the power button after turning off the PSU (or pulling the mains, if the PSU doesn't have a mechanical on/off switch).
On my private machines, i handle it the same. On machines where I'm not the only admin, the policy is to use sudo and getting a root shell is strictly verboten (except in rare cases which actually demand it). The reason for this is is logging. Way easier to fix a mess someone else created if there's a log of what exactly they did with elevated privs
Charging a premium for not-shitty languages encourages continued development of applications in the shitty language because site owners know they'll be able to get a discount by paying only for the use of the shitty language. Do you agree at least with this point?
I sort of agree, but I think you're having it backwards. I don't think it's a premium on non-shitty languages, but rather a reduction in price on PHP hosting due to high demand.
And what should have been done in the first place to discourage widespread use of the shitty language?
Dunno, not have invented the www? I don't think there is or was anything one can or could have done about it.
Slashdot Mirror
you have multiple distinguishable fingertips, though. I just tapped around a bit on my wrist; index- middle- and ring finger seem make a workable(*) toolset to enter ternary digits, every group of three of which could represent 27 states; there's your alphabet plus room for an escape character to get a different alphabet.
(*) once it has become muscle memory
Only Windows 7 luddites use programming language. Modern app appers app apps apped in Apple's App apper!
FTFY. Next time at least do it right.
You're not making it better by actively promoting horrible, non-portable, implementation-dependent and error-prone coding practices.
What's wrong with [depending on] implementation-defined behaviors and using static assertions to verify them?
(Ignoring that that's quite a stretch from what I said, and deliberately ignoring the 'error-prone' part), if you do verify your assumptions about the implementations then of course it's less horrible. However, you do pay the price in losing portability, so if it isn't for a particular good reason, not unnecessarily relying on implementation-defined or unspecified behaviour is preferrable.
For example, would it be poor form to assume (and assert) things like 8-bit bytes or that the character set is ASCII, and if so, why?
This way, the compiler will fail and kick out a diagnostic if the environment doesn't match the assumptions.
That's quite a hack (but better than nothing, sure). If you had a hard requirement such as "has to be ASCII-based" or "char must be 8 bits wide", then I'd wonder where it comes from. I don't deny that there may be a few good reasons, but it turns out that often you could write code in a way that is agnostic of such details and hence portable.
For instance, the ctype.h functions (isprint(), isalnum() and friends) can be used to implement encoding-independent text processing.
For requiring char to be of some specific width, there's hardly a reason, unless you're improperly (de)serializing. The (mandatory as of C99) types (u)int_leastN_t come to mind, and for the rare cases where you actually need a fixed-width-no-padding type, there are the (optional but widely implemented) (u)intN_t types)
ME? Certainly not. It didn't happen until vista that speech recognition was brought to perfection
Fortunately, you can open a new scope at basically any point. If you don't care about long functions, what's there to lose?
That's right, but that doesn't change that it's all C code as well. Labeling it C++ code is quite a stretch IMO.
I guess i can outnitpick you on that; #include "stdio.h" is actually fine. Not that it's a good idea, but it will give you the same effect #include does, as far as the standard is concerned.
Besides, the real failure about that line is that in C++ it should probably read #include <cstdio> (unless i'm mistaken; i do know my C, but C++ not so much)
Care to teach me what the types of 0, '0' and "0" in C are?
In C, the compiler
"The" compiler? You do realize that C is a language specification, right?
doesn't care if you return nothing from a 'int' function.
That's just wrong. It's possible (though unlikely) that your compiler "doesn't care"> It's undefined behaviour to fail to return a value from a non-void function. It doesn't get much wronger; and as a consequence of UB, the compiler isn't even required to do anything meaninful afterwards. If your particular implementation tolerates it, fine, but please don't conclude that it must be how C works then. You're outside the scope of C at that point.
So, while 'void f()' would be cleaner, only 'f()' without a return type set (ie 'int') is seen a lot. :-)
Yes, garbage code is seen a lot. You're not making it better by actively promoting horrible, non-portable, implementation-dependent and error-prone coding practices. Also, again, () means "unspecified number of parameters", (void) means "no parameters". C isn't quite C++.
More general hint: The principle of minimum scope exists for a reason. Declare your variables at the point where they can be initialised, not at some arbitrary point and you make life easier for people trying to understand the lifetime of the variable.
Sorry for double posting, but your more general hint is largely moot after after applying my less general hint, because there won't be as much code in a function in order to make it confusing wrt. to scope and storage duration anymore.
I completely agree, and as said, C99 intruduced mixed declarations and code, and i use it a lot.
I don't understand why you'd be telling me this, unless for some reason you have the same misconception about C89 that GP had - the gibberish about 'top of function'
for (size_t i = 0; i puts("poof");
Duh, /. ate a <. That should read:
for (size_t i = 0; i < sizeof '0'; i++) puts("poof");
Also compiles under gcc and g++. Except for the file extension;)
You cannot use "$compiler compiles it" to determine whether it's portable or correct C, just look at all the non-C garbage gcc happily accepts.
Though in this case i'm not saying it wouldn't be correct; I just pointed out that C programmers usually wouldn't declare their function to have an unspecified number of arguments when what they really want is no arguments. It's not wrong; just unusual, C++ influenced style.
the PM's code is legal and portable C
Possibles &= ~(Possibles & -Possibles);
Portable my ass. This at least requires two's complement. I'm also fairly sure that in addition to being nonportable, it's undefined behaviour unless there's a sequence point i'm missing (can verify that later)
and therefore also legal C++.
Don't be silly. Valid C isn't automatically valid C++, and if you have a program that happens to be something both a C and a C++ would accept, it doesn't need to have the same behaviour. Consider:
int main(void)
{
int class = 42;
}
That's strictly conforming C, and invalid C++
Further consider:
int main(void)
{
for (size_t i = 0; i puts("poof");
}
That's valid C++, invalid C89, strictly conforming C99/C11. When treated as C, it will behave different from when treated as C++, unless your implementation has char and int being of the same width, which is rather unusual.
Thanks for playing.
No; please learn C.
In the absense of a return type, that'd be 'int', and GP doesn't seem to understand the difference between no parameters and unspecified parameters...
I was able to compile it with both gcc and g++ [...] [s]o yes, it is legal as both C and C++ code.
Hahaha. You're so mistaken, it's not even funny anymore. (No, not even with -ansi -pedantic). The language that gcc accepts is a twisted superset of C, so using gcc to evaluate whether it's correct C code is completely meaningless.
everything has to be declared at the top of the function... Always.
That's not true, and has never been. Until about 16 years ago, you had to declare your variables at the beginning of a block/compound statement. That can be well within the function.
As of about 16 years ago, you're even allowed to freely mix your declarations and code.
[incoherent gibberish]. And stuff like that.
Yeah. The kind of stuff you seem largely unfamiliar with.
General hint: If your functions are so long that having to (suppose this was indeed the case) declare/define all your variables at the top becomes a serious annoyance, then chances are that your functions are too long/do too much. Fix that instead.
void Succeed()
That's actually more C++'ish, a C programmer would put it as
void Succeed(void)
Which means in C what the former means in C++.
</nitpick>
Apart from that, yeah. It's pretty much C. Almost C89, even, were it not for the C++ style comments and two instances of mixed declarations and code.
Yes I was referring to economies of scale. After you have created a usable $language webhosting environment (say, a VM image), supply is essentially infinite (modulo hardware).
Streaming movies over the internet and playing them on a computer is not a simple thing, that's only what idiots with no understanding of the details think.
Geeks wouldn't quite be geeks if they felt like deferring all the difficult (i.e. interesting) things to some company while at the same time giving them money. Get a clue.
presumably to wait for the system to truly be 'off', with caps discharged and all.
A faster way to achieve the same is pressing the power button after turning off the PSU (or pulling the mains, if the PSU doesn't have a mechanical on/off switch).
sudo -s doesn't log in as root, it merely gives you a root shell with mostly your old environment. Speaking of failure to RTFM...
On my private machines, i handle it the same. On machines where I'm not the only admin, the policy is to use sudo and getting a root shell is strictly verboten (except in rare cases which actually demand it). The reason for this is is logging. Way easier to fix a mess someone else created if there's a log of what exactly they did with elevated privs
Charging a premium for not-shitty languages encourages continued development of applications in the shitty language because site owners know they'll be able to get a discount by paying only for the use of the shitty language. Do you agree at least with this point?
I sort of agree, but I think you're having it backwards. I don't think it's a premium on non-shitty languages, but rather a reduction in price on PHP hosting due to high demand.
And what should have been done in the first place to discourage widespread use of the shitty language?
Dunno, not have invented the www? I don't think there is or was anything one can or could have done about it.
Burma Shave