Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

-std=c99 my anus

Name: Anonymous 2009-11-25 15:29

[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?

Name: Anonymous 2009-11-25 15:29

fuck, pardon my lack of bbcode skills

Name: Anonymous 2009-11-25 15:39

If by “some shit around” you mean that this non-standard extension is not enabled in strict c99 mode, then yes. Use gnu99 or use a real language like Lisp.

Name: Anonymous 2009-11-25 16:10

Use C89 because C99 is silly and bloated

Name: Anonymous 2009-11-25 16:34

>>4
Enjoy declaring variables at the beginning of a scope.

Name: Anonymous 2009-11-25 17:26

>>5
I will, along with my job

Name: Anonymous 2009-11-25 20:22

>>4
Hear, hear! Real programmers don't eat quiche, and they certainly don't use any of this newfangled C99 shit.
Complex programmers on the other hand...

Name: Anonymous 2009-11-25 20:52

C99 is awesome. It's basically a standardization of features that have been common extensions for decades.

The only thing that's not awesome is const. It was broken in sepples, and it's even more broken now...

Name: Anonymous 2009-11-25 20:55

>>8
The only thing that's not awesome is const. It was broken in sepples, and it's even more broken now...
How so?

Name: Anonymous 2009-11-25 21:11

It's broken because it does not propagate.

typedef struct box {
  int* p;
} box_t;

void func(const box_t* box) {
  box->p[0] = 5; // WTF NO ERROR!! hax mah box
};

Here's another example:

void func(const std::vector<const Box>);

int main() {
  func(std::vector<Box>()); // ERROR, incompatible types
}

It's broken because attempts to fix it (in sepples) cause code duplication due to permutations of const arguments ('const-overloading').

class BoxList {
const Box& operator[] (int i) const;
      Box& operator[] (int i);
}

It's even more broken in C because the above hacks aren't allowed.

Name: Anonymous 2009-11-25 21:19

>>10
Learn what 'const' means, and what your const is really referring to.

Also the const keyword in C++ is such an abomination.

Name: Anonymous 2009-11-25 21:46

>>11
I'd const my dick into... wait, fuck that.

Name: Anonymous 2009-11-25 21:54

>>11
I know how it works shitface. My point is that it's worse than useless. It does not work the way you would expect or want.

Name: Anonymous 2009-11-25 22:50

>>13
Works fine in C for me, what's the problem?

Name: Anonymous 2009-11-25 23:03

>>10
It works exactly how I expect; maybe you have been brain damaged by too many stupid languages to understand pointers. The data you are manipulating is not const, your box is. If you don't want your code to work, make your int pointer const, not the box.

Name: Anonymous 2009-11-25 23:46

>>15
The data you are manipulating is not const, your box is.
THAT'S THE PROBLEM. Christ, I know how they fucking work. Why don't you explain to me again what is const?

make your int pointer const, not the box.
No, you can't do that. If you make the int point to const in the struct, then the implementation of the box can't ever modify it. You can't make two boxes (i.e. Box, with int* and ConstBox with const int*) because they're inconvertible.

That's the whole problem, don't you see? There's no way to make a const box where the const is propagated to its pointers. Yes, they fucking work according to the spec, we get it. The spec is BAD. It was a BAD DECISION to make them work the way they do.

But go ahead, explain to me again how the int is not constant but the box is.

Name: Anonymous 2009-11-26 0:12

>>16
ergo your wrong bitch

Name: Anonymous 2009-11-26 0:57

>>16
Are you really the same person who wrote // WTF NO ERROR!! hax mah box? It's no wonder everyone you wouldn't know how const works.

Name: Anonymous 2009-11-26 1:25

struct Box {
  int* getp();
  void setp(int*);
  int const* getp() const;
private:
  int* p;
};

There's the Sepples ``solution''. It fits nicely with the rest of Sepples, with its PIG DISGUSTINGness.

Name: Anonymous 2009-11-26 2:55

>>10
sry but I gotta agree with everyone else; you're a fgt. how is the second example "broken"? temporaries not binding to non-const references makes sense to me.

Name: Anonymous 2009-11-26 19:29

>>18
Yes I am that person. For the last time, I know WHY there's no error there. I'm saying const is not a good language feature BECAUSE of the fact that there's no error there. It's a WTF because there's no way to tell the compiler that the int* is owned by the box such that 'const box' automatically implies 'const int* const'.

Were I a language designer, I would have made const propagate through struct pointers this way (and in fact through any indirection, so that int** const p automatically implied const int* const * const p). If the language designers attempted this and it was somehow internally inconsistent, please enlighten me; otherwise I will continue to think that they made a fucking stupid design decision with the behaviour of const.

>>20
In the second example, there is no reference; the vector is passed by value, so your comment makes no sense. I assume you thought it should look like this:

void func(const std::vector<const Box>&);

int main() {
  func(std::vector<Box>()); // ERROR, incompatible types
}

In this case, it IS a const reference, so how is your comment about non-const references relevant?

For the record I do agree that temporaries not binding to non-const makes sense, but *only* when move semantics and r-value references are available so that you can actually overload a function to take a non-const r-value parameter. Honestly move semantics should have been in the base language to begin with, not awkwardly grafted in decades late leaving other shit broken in the meantime (e.g. lack of perfect forwarding).

Name: Anonymous 2009-11-26 20:14

>>21
apologies, I'm >>20, next time tell me not to read code drunk. that said, now that I'm sober, while the original accusation is unfounded, of course they are still incompatible types because I can specialize on the const qualifier. observe

template<typename T>
struct something { int a; };

template<typename T>
struct something<const T> { double a; };

clearly a something<int> is not equivalent to a something<const int>, so you can't cast the two types implicitly. how is this not what should be the expected behavior fgt

Name: Anonymous 2009-11-26 20:43

>>21
Yes, all things are horrible because they can be misused by idiots. Let's go back to pounding rocks together in caves.

Name: Anonymous 2009-11-26 21:23

>>22
of course they are still incompatible types because I can specialize on the const qualifier. observe
God damnit, another one explaining to me the rules of const, as though I don't understand them. Specializing a template on const would not be necessary if the const was propagated. If the implicit cast was allowed, then upon implicitly converting a something<T> to something<const T>, the compiler could automatically instantiate the const template, and the template functions that don't respect the const simply wouldn't be compiled into the copy (SFINAE).

>>23
You'd rather we just work with what we have and never try to improve anything? No need to invent a screwdriver folks, we already have hammers.

Name: Haxus the Sarcastic 2009-11-26 21:51

>>24
woosh!

Name: Anonymous 2009-11-26 22:11

>>24
you're a moron. you're talking as if the only possible differences between a <T> template and its <const T> specialization are, well, that every time a T is used in the original template, the same code is replicated in the <const T> specialization but just with a "const" in front of all Ts. tell me, how does this fantasy language of yours deal with a conversion between somethings, e.g.
something<const int> a = something<int>();
does it convert the int a to double a? what if I called it double b, would the compiler magically still link int a to it?

understand that your suggestion is also tantamount to saying we should implicitly allow stuff like
something<double> a = something<int>();
y'know, I mean, I can do double f = 3;, so why can't my templates implicitly convert between these types as well.

Name: Anonymous 2009-11-26 22:30

What on Earth? In what context would something<const int> be useful?

Name: Anonymous 2009-11-26 22:44

>>27
who knows. the point is, the language allows it, and it allows me to partially specialize templates based on whether the type passed to a template is const or not.

Name: Anonymous 2009-11-26 23:25

>>26
you're talking as if the only possible differences between a <T> template and its <const T> specialization are, well, that every time a T is used in the original template, the same code is replicated in the <const T> specialization but just with a "const" in front of all Ts.
Yes, if C++ was like this, const would be wonderful. In my 'fantasy language', a const specialization *would not be allowed*, because it would not be necessary; the const version would be generated implicitly (really it's the same code, just with compile-time const checking) so it would have the same class layout.

understand that your suggestion is also tantamount to saying we should implicitly allow stuff like something<double> a = something<int>();
No, of course it it's not you fool. something<const int> would necessarily have the same class layout as something<int> because it's not a different class; it's the same code, just const-checked at compile time.

does it convert the int a to double a?
If you think you should be able to change your int to a double based on a const specialization, then you're fucking retarded. The fact that you are happy that such a hack to be possible is the true mark of a sepples programmer. There is no hope for you.

Name: Anonymous 2009-11-26 23:54

Alright, as >>10-chan here, let me take a step back and try to gather everyone's thoughts. Here are two mutually exclusive snippets of code.

Snippet 1:
template<typename T>
struct something { int a; };
template<typename T>
struct something<const T> { double a; };

Snippet 2:
void func(const std::vector<const Box>& box);
int main() {
  func(std::vector<Box>());
}

Currently, snippet 1 is valid C++, while snippet 2 is not. Answer honestly now: are you guys happy that this is the case? Do you think this is a good way for a declaration called 'const' to work? Because I sure as hell don't. I consider this a fundamental problem with the definition of const.

I'm trying to propose a system which would fix this problem. If const behaved as I've been trying to describe, then snippet 2 would be valid, and snippet 1 would not.

So why am I getting such hostile responses? Is it because I started by saying 'const is broken', and everyone took it literally, thinking I didn't understand how it works? Is it because you think my definition of const is somehow internally inconsistent? Or is it just because you truly like the current behaviour (keeping in mind that it allows snippet 1 and not snippet 2)?

I'd like to explore the idea of a propagating const, rather than a type qualifier that creates distinct types. This would allow snippet 2 to work instead of snippet 1. If you have real arguments about why it's a bad idea, then by all means, share them. But if you still think I don't understand how const works, or if you like the fact that snippet 1 is possible and not snippet 2, well I'm not sure how we can continue this discussion.

Name: Anonymous 2009-11-28 7:10

At least compile it properly:

gcc -x c -std=c99 -v -Q -pipe -pass-exit-codes -pedantic -Wall -Wextra -Wfatal-errors -g3 -o test test.c

Name: Anonymous 2009-11-28 7:57

>>31
Without -O you're missing a number of possible errors.

Name: Anonymous 2009-11-28 8:40

>>32

Optimization will mess up with the debugging information embedding (-g3 in this case) and [i]could/i] mess up the purpose (or output) of your program.

Name: Anonymous 2009-11-28 15:39

>>10
If you want a pointer to const you should man up and actually use a pointer to const. Quit bitching that a const pointer doesn't do what you want.

Name: Anonymous 2009-11-28 16:38

>>33
I sometimes, but rarely, have issues with optimized-out values with -O; with -O2 or so, it does become a more frequent problem. These can usually be resolved by temporarily peppering 'volatile' around the pertinent area (and then a :%s~volatile ~~ afterward to clean up). Sucks but that way you get warnings about useless and unused variables, and a couple other classes of warnings that never come up unless the code gets run through the optimizer. I'm sure there is some way to get the benefits of the warnings without incurring many of the hindrances to debugging, but I simply have never bothered narrowing down from the flags set by -O to the minimal subset necessary to enable those warnings, as it works well enough for me already.

>>34
Try it with the example here, and you will find that writing to the fields is still permitted regardless of which part of the struct variable declaration is const. The underlying problem is that the fields inside the struct aren't const just because the struct is -- with either const box_t *foo or box_t *const foo, the int * is still not a const pointer, and surely is not pointing to const data. It's the same as char **foo versus char *const *foo versus char **const foo, except you're only capable of defining the top level const without defining a different, technically-incompatible struct. In this case you'd still need another "const box" type, which is not possible in C. Try it.

Name: Anonymous 2009-11-28 17:19

>>35
technically-incompatible struct
Uh casting solves incompatibility.
Try it.
blah.c:18: error: assignment of read-only location ‘*mybox->numbers’

But you know what? None of this even matters. Nobody abuses const. It just doesn't happen. I wish you'd pick something people actually cause problems with to complain about.

Name: Anonymous 2009-11-28 22:50

>>36
Post your code.

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.

You're right though; >>10 is still a fgt.

Name: Anonymous 2009-11-29 5:47

>>36
Nobody abuses const
wat

Name: Anonymous 2009-11-29 15:02

>>37

typedef struct { int *numbers; } box;
typedef struct { const int *numbers; } box_consts;
Allocate a box, accept a box_consts. You can figure out the rest. You can also provide the struct anonymously in the function. If you don't want to cast, try using onion.

(Of course none of this is practical.)

>>38
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. People who write code like that don't collect many paycheques.

Name: Anonymous 2009-11-29 15:07

STD::MY_ANUS

Name: Anonymous 2009-11-29 15:10

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

Name: Anonymous 2009-11-29 23:36

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

Name: Anonymous 2009-11-30 3:08

>>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?

Name: Anonymous 2009-11-30 3:15

>>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.

Name: Anonymous 2009-11-30 3:20

shut the fuck up idiots.

Name: Anonymous 2009-11-30 11:23

>>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.

Name: Anonymous 2009-11-30 18:50

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

Name: Anonymous 2009-11-30 22:12

>>47
You mean 5 days ago?

Name: Anonymous 2009-11-30 23:16

>>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.

Name: Anonymous 2009-11-30 23:23

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

Name: Anonymous 2009-12-01 2:02

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

Name: Anonymous 2009-12-01 9:10

>>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.

Name: Anonymous 2009-12-01 9:15

>>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.

Name: Anonymous 2009-12-01 9:26

>>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.

Name: Anonymous 2009-12-01 9:49

>>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.

Name: Anonymous 2009-12-01 10:09

>>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?

Name: Anonymous 2009-12-01 10:25

>>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.

Name: Anonymous 2009-12-01 10:27

>>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."

Name: Anonymous 2009-12-01 13:46

>>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.

Name: Anonymous 2009-12-01 14:21

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 istanbul qualifier to express mutability within a const.

Name: Anonymous 2009-12-01 15:09

>>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)

Name: Anonymous 2009-12-01 15:11

>>61
IHBS

Name: Anonymous 2009-12-01 15:12

>>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.

Name: Anonymous 2009-12-01 15:26

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

Name: Anonymous 2009-12-01 15:56

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

Name: Anonymous 2009-12-01 16:32

>>65
Been a long time gone, Constantinople

Name: Anonymous 2009-12-01 16:44

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

Name: Anonymous 2009-12-01 16:50

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

Name: Anonymous 2009-12-01 17:04

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

Name: Anonymous 2009-12-01 17:10

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

Name: Anonymous 2009-12-01 18:39

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

Name: Anonymous 2009-12-01 19:29

>>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.

Name: Anonymous 2009-12-01 19:55

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.

Name: Anonymous 2009-12-01 19:56

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

Name: Anonymous 2009-12-02 20:35

>>74
Your grandfather. LAST NIGHT!

Name: Anonymous 2009-12-02 22:37

>>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.

Name: Over 75 Thread 2009-12-02 22:43

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

Name: Anonymous 2009-12-04 3:08

http://dis.4chan.org/read/prog/1250330533/10,12,18,21
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -