-std=c99 my anus

[code]$cat test.c
#include <stdlib.h>
#include <string.h>

int main(void) {
    char *foo;
    foo = strdup("bar");
    free(foo);
    return 0;
}
$gcc test.c
$gcc -std=c99 test.c
test.c: In function 'main':
test.c:6: warning: implicit declaration of function 'strdup'
test.c:6: warning: assignment makes pointer from integer without a cast[code]
What the heck is this, /prog/? Is there some shit around strdup() in c99?

>>40
Don't::STD my -std=fucker.

>>39
char* line = strtok((char*)string().c_str(), " ");
I do that all the time.

>>39
When was the last time someone accepted your const data and then mangled data it referred to in an unexpected manner? I'm guessing never. People who write APIs like that don't acquire many users.
Is that why sepples has the mutable keyword? A significant number of people had to want to mutate data in a const struct in order to get this into the standard.

Besides, it's almost always unintentional. You change the behaviour of a function to modify pointed data, not realizing it was meant to be const. This works for a while until someone changes something else and triggers a bug, and days are spent figuring out what's going on. The compiler of course is perfectly happy.

Your whole argument presumes that people will notice the const and manually follow additional, unverifiable rules to respect it. So what's the point of const if it's worse than good documentation and simple code comments? Why was it added to the standard at all?

You can also provide the struct anonymously in the function. If you don't want to cast, try using onion.
You still need to cast. Transparent unions are not standardized in any way. In GCC you have to give the union a special attribute to allow implicit casting.

>>36
(Of course none of this is practical.)
Congratulations, that is the exact problem with const. While it is technically possible to make it propagate as it should, you have to do it by hand, and so it is infeasible. The maintenance problems with duplicating all your structs are worse than just not using const (in C, not sepples unfortunately since STL uses it). And these structs are still incompatible according to standard C!

Are you folks going to admit that const is broken yet?

>>37
And since you don't have to cast anything to pass a pointer to non-const into a function that expects something with const in it, so your suggestion of casting is pretty weak.
We're talking about casting a box to box_consts here, a separate struct that has member pointers to const. See >>39. You definitely do need to cast. There is no solution to this.

shut the fuck up idiots.

>>43
Sepples
I'd like to point out right now that I don't (and haven't) had anything to say about C++.

You change the behaviour of a function to modify pointed data, not realizing it was meant to be const.

An API function? No, I don't. My own function? Why would I be so stupid? My coworker's function? I'm not that kind of asshole.

You still need to cast.
No I don't. I know how to pass it happily without casting. Maybe it means I'm cleverer than you, but I think it just means I know C and you don't.

It stops here for now, we can continue arguing about this whenever you've learned how to do this.

Holy shit guys
I created this thread some time ago, and you are now flaming about some silly seeples issues. Why does anyone keeps on bumping this? Fuck

>>47
You mean 5 days ago?

>>46
An API function? No, I don't. My own function? Why would I be so stupid? My coworker's function? I'm not that kind of asshole.
Oh so you never modify code then! Or you're just never in a hurry, never under pressure to get things done. No deadlines I guess? No weekends or 2am nights for you, no sir, because you're the EXPERT /PROG/RAMMER

Well guess what, not all programmers are as awesome as you are. We don't often get to decide who our coworkers are, and like it or not, they do have to change our code sometimes.

No I don't. I know how to pass it happily without casting. Maybe it means I'm cleverer than you, but I think it just means I know C and you don't.
Well you're going to have to explain how you're doing this in a portable way.

>>49
Nice try, but you haven't figured it out yet. I will give you a hint: it's fully standards compliant.

>>50
Nonsense, put up or shut up. Show me a real solution without casting or similar hacks. You're either trolling or just wrong.

>>27
Processors with memory-mapped I/O are filled with const volatile unsigned ints, as anyone who understands how computers work and what "const" and "volatile" mean might expect.

>>43
Besides, it's almost always unintentional. You change the behaviour of a function to modify pointed data, not realizing it was meant to be const.
const is not a short form of "constant." A promise not to change something is not a promise that it will never change.

>>51
Nope. You should know this. It's using union for its intended purpose. If you don't know this you're not worth arguing with.

>>53
It is *of course* a short form of constant. And we are not talking about 'const data', we are talking about a const member function which is not supposed to modify its arguments.

On a side note, looking up the actual definition of const on Wikipedia, apparently in D, const behaves as I've been describing.

Unlike C++ const, D const and immutable are "deep" or transitive, and anything reachable through a const or immutable object is const or immutable respectively.
class Foo {
    Foo next;
    int num;
}
 
immutable Foo foo = new immutable(Foo);
foo.next.num = 5;  // Won't compile.  foo.next is of type immutable(Foo).
                   // foo.next.num is of type immutable(int).

Wow, a sane language designer. I might have to take a look at this D language after all.

>>55
It is *of course* a short form of constant.
So you finally admit you just don't understand const.
#define PBIN ((const volatile unsigned int *)0x0F04)
OMG const and volatile, whatever will I do?

>>56
const volatile makes perfect sense actually.
const is a promise you make to the compiler that YOU won't be changing that location, this won't stop the OS/hardware/BIOS/other applications, or even some other thread or non-standard code(for example, someone's library) from changing it. A common usage would be a clock/tick count location the OS updates, but which you shouldn't change (as it would be meaningless in the best scenario, or harmful in the worst(page protection or hardware registers or whatever)).
volatile is used to tell the compiler the location may be changed by outside events/code, so it should be careful about what optimizations it does and that it should always use a reference when refering to that location.
A const volatile would mean a location in memory that may be changed by something else other than your code, but which should not be modified by your code at all.

>>57
const is a promise you make to the compiler that YOU won't be changing that location
I know. Which is why const isn't a short form of "constant."

>>58
This is the fucking stupidest argument I've ever heard. Of course const is short for constant. What else is it short for? constantine? constantinople?

Now, what you are trying to say (that is, if IHNBT) is that a const variable doesn't mean that it is permanently "constant" in the truest sense of the word. There I'll agree with you, but to say that Bjarne pulled const out of his ANUS to just magically represent (what are referred to as) constant variables is stupid.

constantinople?
Yes, yes it does. See, you can't go back to Constantinople.

For the Cx7da standard, they are considering altering const qualifier to behave the way you would like, and adding an istan^bul qualifier to express mutability within a const.

>>60
it may suprise you, but Constantinople is named after a roman emporer Constantinus whose name in turn was derived from the latin for constant (because of his stable, steadfast nature i assume)

>>61
IHBS

>>59
Now, what you are trying to say (that is, if IHNBT) is that a const variable doesn't mean that it is permanently "constant" in the truest sense of the word.
You don't have to pick the truest sense of the word. Even the ordinary sense will do.

[b][code]BBCODE MY ANUS[/b][/code]

>>61
It may surprise you, but that illustrates my point. Constantinople is no longer Constantinople.

>>65
Been a long time gone, Constantinople

>>66
I had a date in Constantinople. :(

>>67
I had a date with Constantine. :(

>>67
Well, maybe she's waiting in, you know.

>>69
Used to date a girl named Crisco. She was a little fat in the can.

>>67
I had a date with Constantine. :(

>>56
Haha oh wow. I don't understand const because I think it's short for "constant". I fucking lol'd.

We all know how const volatile works and how it applies to memory mapped input, among other things. const does not mean the value can't change; just that this variable can't be used to change it.

This is the stupidest argument I've ever had on /prog/, and I've argued with FV. I going to check out now, thanks. I'm off to read more about D, where const is actually done properly.

No, volatile means that whenever a variable is used in a statement, the value is referenced directly from the variable in case it has been changed by an outside source.

>>73
Thats true, but who are you saying 'no' to?

>>74
Your grandfather. LAST NIGHT!

>>72
Your entire judgment of why const is ``wrong´´ is because it doesn't adhere to English semantics, and the implications of those semantics in terms of mathematical properties, of ``constant´´. It may be that the impetus for the symbol 'const' was the word 'constant' but that has no bearing on whether its implementation is sensible. C and C++ are not languages you would design; this does not make them broken.^† Good day.

†_{^{Of course, C++ is broken, but not because of const.}}

This thread has over 75 replies.
You can't reply anymore.

http://dis.4chan.org/read/prog/1250330533/10,12,18,21