|
Subjunctive posted:Working from the C standard, or JS standard, or C# standard, or Java standard is...not much better. programming languages should be intuitive like natural languages are. If you need to look at the reference standard and you're not writing a compiler or re-implementing the core library, something has seriously gone off the rails.
|
#
?
Jan 9, 2016 07:01
|
|
|
|
| # ? Jun 2, 2024 05:50 |
|
|
In the case of Java the de jure standard was seriously broken until the 1.5 memory model revision, so the de facto standard (i.e. the thing implemented by compilers and virtual machines) ignored the broken bits
|
|
#
?
Jan 9, 2016 09:49
|
|
|
The C standard pisses me off because in 2015 with the latest standard in use, it is still perfectly legal for sizeof(int) to be 2 bytes. That is some serious early 70s poo poo and I do not appreciate it. There are many stupid little gotchas in the standard like this. This is just the tip of the iceberg.
|
|
#
?
Jan 9, 2016 10:31
|
|
|
Kazinsal posted:The C standard pisses me off because in 2015 with the latest standard in use, it is still perfectly legal for sizeof(int) to be 2 bytes. On an 8-bit micro, a 16-bit int makes sense. That said, it's difficult/impossible to write proper portable code that uses native types directly, due to the unknown widths. I guess that's why C99 added <stdint.h> which gives you know only fixed-width types, but other metatypes such as uint_least16_t to make portable code possible. In my own code I use the <stdint.h> types exclusively, with the exception of float/double.
|
|
#
?
Jan 9, 2016 11:17
|
|
|
Kazinsal posted:The C standard pisses me off because in 2015 with the latest standard in use, it is still perfectly legal for sizeof(int) to be 2 bytes. Embedded platforms are still a thing and mostly you program them in C.
|
|
#
?
Jan 9, 2016 11:24
|
|
|
Kazinsal posted:The C standard pisses me off because in 2015 with the latest standard in use, it is still perfectly legal for sizeof(int) to be 2 bytes. There are platforms that still exist today where ints are 1 byte long, and bytes are 16 bits long.
|
|
#
?
Jan 9, 2016 12:59
|
|
|
KernelSlanders posted:programming languages should be intuitive like natural languages are. If you need to look at the reference standard and you're not writing a compiler or re-implementing the core library, something has seriously gone off the rails. So people should learn to use programming languages without reading anything other than source? What is the official documentation (as referenced in the post I was quoting) for those languages if not the standards?
|
|
#
?
Jan 9, 2016 14:40
|
|
|
Subjunctive posted:So people should learn to use programming languages without reading anything other than source? What is the official documentation (as referenced in the post I was quoting) for those languages if not the standards? The standard is a reference not a tutorial. You wouldnt learn French by just buying and reading a formal grammar.
|
|
#
?
Jan 9, 2016 15:08
|
|
|
So what's the other official documentation?
|
|
#
?
Jan 9, 2016 15:22
|
|
|
Depends on the language. K&R for C, Stroustrops big tome for C++.
|
|
#
?
Jan 9, 2016 15:32
|
|
|
Interesting, what makes those official? (Learning C++ from D&E would be a mess, I think.) Subjunctive fucked around with this message at 15:40 on Jan 9, 2016 |
|
#
?
Jan 9, 2016 15:34
|
|
|
Subjunctive posted:Interesting, what makes those official? Why are you so hung up on the word 'official' here? Theyre written by the languages creator(s) so are most likely to reflect the intended use of the language by said creator. Theres no, like, certification authority or anything. http://www.stroustrup.com/4th.html was what I meant for c++.
|
|
#
?
Jan 9, 2016 15:57
|
|
|
Subjunctive posted:Interesting, what makes those official? Why is "official" relevant to most coders of a language?
|
|
#
?
Jan 9, 2016 15:59
|
|
|
eth0.n posted:Why is "official" relevant to most coders of a language? I was replying specifically to that term in a post, if you read back in the chain.
|
|
#
?
Jan 9, 2016 16:03
|
|
|
Subjunctive posted:I was replying specifically to that term in a post, if you read back in the chain. Official documentation (the term originally used) is not the same as official standard (the word you started using in response). PHP (and a lot of other newer languages like Python and Java) have official documentation which is meant for all coders. They may also have standards that are not. C and C++ have official standards, but not official documentation.
|
|
#
?
Jan 9, 2016 16:12
|
|
|
I'm surprised that you don't consider the language standards to be official documentation, I admit. They seem to be the epitome of both elements, and for some languages the only such. But fair enough!
|
|
#
?
Jan 9, 2016 16:15
|
|
|
Kazinsal posted:The C standard pisses me off because in 2015 with the latest standard in use, it is still perfectly legal for sizeof(int) to be 2 bytes. The C standard pisses me off because it has so much undefined behavior, often needlessly so. It's hard to imagine that any significant c or c++ program doesn't have undefined behavior lurking in it somewhere. Fun fact: "An unmatched ‘ or ” character is encountered on a logical source line during tokenization" isn't a syntax error, it's undefined behavior.
|
|
#
?
Jan 9, 2016 16:16
|
|
|
eth0.n posted:Official documentation (the term originally used) is not the same as official standard (the word you started using in response). PHP (and a lot of other newer languages like Python and Java) have official documentation which is meant for all coders. They may also have standards that are not. C and C++ have official standards, but not official documentation. You kidding me? 90% of the C standard is documentation for the standard library. I use it all the time. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf#page=364
|
|
#
?
Jan 9, 2016 16:42
|
|
|
Subjunctive posted:I'm surprised that you don't consider the language standards to be official documentation, I admit. They seem to be the epitome of both elements, and for some languages the only such. I feel the same but in the opposite direction. Probably just a function of what languages we use the most.
|
|
#
?
Jan 9, 2016 17:18
|
|
|
Suspicious Dish posted:You kidding me? 90% of the C standard is documentation for the standard library. I use it all the time. I didn't say a language standard cannot satisfy any of the purposes of documentation. That other 10% is pretty darn important (perhaps more important than that 90%), but you already know it. For someone who doesn't already know the C language, reading the standard is a very poor way of learning it. Whereas that's a purpose that should be satisfied by proper documentation. The point is, judging PHP by its poor documentation is sensible. It's judging it based on what it's purpose is supposed to be; to help users understand it. Judging C/C++/C#/Java by how well their language standards help a new coder learn is, in contrast, pointless. That's not what it's there for. Judging the official C#/Java documentation on the same basis as the PHP judgement would, instead, be reasonable. No similar comparison exists for C/C++ since no official documentation comparable to PHP, C#, and Java exists. Judgement of unofficial documentations like K&R and Stroustrup, on the other hand, on the basis of how they help new coders learn would be reasonable.
|
|
#
?
Jan 9, 2016 17:23
|
|
|
nobody disagrees and i have no idea what we were arguing about in the first place
|
|
#
?
Jan 9, 2016 17:46
|
|
|
It must be early in the month, we're back to "the horrors are coming from inside the thread".
|
|
#
?
Jan 9, 2016 18:42
|
|
|
Suspicious Dish posted:nobody disagrees and i have no idea what we were arguing about in the first place I think this is my fault, I woke up an idiot today or something.
|
|
#
?
Jan 9, 2016 18:52
|
|
|
Suspicious Dish posted:nobody disagrees and i have no idea what we were arguing about in the first place Nested functions in PHP being bad, then php being bad, then all other languages being bad, then C being bad. All bad language arguments turn into "C" is bad.
|
|
#
?
Jan 9, 2016 19:45
|
|
|
Suspicious Dish posted:nobody disagrees and i have no idea what we were arguing about in the first place yospos bi--oh wait
|
|
#
?
Jan 9, 2016 20:02
|
|
|
Any C code written today should use the _t suffixed type definitions, not the built in types.
|
|
#
?
Jan 9, 2016 20:15
|
|
|
fleshweasel posted:Any C code written today should use the _t suffixed type definitions, not the built in types. Also, pretty much any C code written today should be written in C++.
|
|
#
?
Jan 9, 2016 20:44
|
|
|
b0lt posted:Also, pretty much any C code written today should be written in C++. Don't you go starting holy wars now.
|
|
#
?
Jan 9, 2016 20:51
|
|
|
Subjunctive posted:I think this is my fault, I woke up an idiot today or something. I'm glad this happens to other people as well.
|
|
#
?
Jan 9, 2016 20:53
|
|
|
b0lt posted:Also, pretty much any C code written today should be written in C++. Yeah, when I am coding on a micropic with a few k of memory what I really need is a a huge increase to my footprint of the binary.
|
|
#
?
Jan 9, 2016 21:10
|
|
|
fleshweasel posted:Any C code written today should use the _t suffixed type definitions, not the built in types. If overflow's gonna be a problem it's still going to be a problem with _t types. Edit: Here is a list of uses I've found for non-_t types in a recent 20k-line C project: - argc is of type int, - int was used all over as the boolean type for portability reasons -- _Bool doesn't have a _t either, you know :-) - some values in the range 0-3 and 0-7 were made to be of type int, - operator precedence levels, which are numbers in the 100-999 range, are ints, - format string sizes have to be converted to int, - a runtime limit whose value was 50 is an int, - some stand-in values for representing interval boundaries (that had the same ordering as the real values) ranging from -11 to 12 were represented as int, - some compile time assertions cast enum values to int in order to compare them (and pass warning flags), - ftell returns a long (and the return value gets converted to a size_t beneath a compile-time assertion that LONG_MAX < SIZE_MAX), - argv was of type char**, - filepaths are of type char*, because they come from argv and are used in C library functions that take char, - certain other functions take const char * so you can pass a string literal, or emit const char * in order to be used in printf functions, - an arena allocator uses char * because you can do pointer arithmetic on it, unlike void *, - some other buffers are char because they use ascii digits or other ascii characters, and they get cast to void* pretty soon, - a few buffers use char when it would probably be better to use uint8_t -- not that you can have sizeof(uint8_t) > sizeof(char). - nothing uses short, long long, or anything with "unsigned". Generally speaking I used an int whenever I cared to do so. You should use whatever interoperates with your other functions correctly. If malloc took an int, I'd recommend using int for sizes of things -- but malloc takes a size_t, so you should use that instead. The protocol buffers APIs use int for lengths, so you should use int when indexing into those. I used int32_t and uint32_t a lot more, in particular because the file format I was working with demanded it. It had nothing to do with C specifically or C safety concerns. The way I see it, all you're doing is deciding the limit at which some runtime overflow check can kick in. sarehu fucked around with this message at 22:06 on Jan 9, 2016 |
|
#
?
Jan 9, 2016 21:10
|
|
|
feedmegin posted:Depends on the language. K&R for C, Stroustrops big tome for C++. k&r is ancient and it encourages dumb poo poo sarehu posted:No. If overflow's gonna be a problem it's still going to be a problem with _t types. its about documentation more than anything
|
|
#
?
Jan 9, 2016 21:43
|
|
|
ratbert90 posted:Yeah, when I am coding on a micropic with a few k of memory what I really need is a a huge increase to my footprint of the binary. So use -fno-exceptions -fno-rtti, and don't use the STL (or only the constexpr-y part)? Pretty much the core philosophy of C++ is that you only pay for the parts of the language that you use, so just turn that poo poo off. You end up with a language that is still better than C, but with identical output. Malcolm XML posted:its about documentation more than anything size_t, ptrdiff_t, etc. are obviously better than long, if they're used correctly. int32_t is not obviously better at representing types that aren't explicitly defined as being 32 bit integers, like in file formats or network communication. b0lt fucked around with this message at 22:12 on Jan 9, 2016 |
|
#
?
Jan 9, 2016 22:09
|
|
|
Malcolm XML posted:k&r is ancient and it encourages dumb poo poo Is there a better book that you know about that doesn't teach dumb poo poo? And maybe acknowledges that IDEs, auto-completion, identifiers with more than eight characters and the shift key exist? b0lt posted:So use -fno-exceptions -fno-rtti, and don't use the STL (or only the constexpr-y part)? So you're saying he should just use C. Sauer fucked around with this message at 05:07 on Jan 10, 2016 |
|
#
?
Jan 10, 2016 05:03
|
|
|
Malcolm XML posted:k&r is ancient and it encourages dumb poo poo There's tons of out of date programming tomes. Numerical Recipes assumes that cosine is calculated from a taylor expansion.
|
|
#
?
Jan 10, 2016 06:53
|
|
|
 No thanks.
|
|
#
?
Jan 10, 2016 12:30
|
|
|
b0lt posted:So use -fno-exceptions -fno-rtti, and don't use the STL (or only the constexpr-y part)? Pretty much the core philosophy of C++ is that you only pay for the parts of the language that you use, so just turn that poo poo off. You end up with a language that is still better than C, but with identical output. unless you know the compilation triple's choice of data model it's better to explicitly say "I want this integer to be 32 bits exactly" rather than "it's 32 bits on windows and 64 on linux" i guess if you don't care so much then it doesn't matter, but given that every major C project rolled its own sized types like u32, s32, s16 etc you might as well use the standard's KernelSlanders posted:There's tons of out of date programming tomes. Numerical Recipes assumes that cosine is calculated from a taylor expansion. numerical recipes is also mostly garbage and i guarantee that you have broken the terms for its source code license at least a few times if you're like most people Sauer posted:Is there a better book that you know about that doesn't teach dumb poo poo? And maybe acknowledges that IDEs, auto-completion, identifiers with more than eight characters and the shift key exist?
|
|
#
?
Jan 10, 2016 13:25
|
|
|
Carbon dioxide posted:
You would think the marketers who make these stupid ads would get an actual programmer to look over their poo poo so it doesn't insult the intelligence of the people they're trying to recruit. Not only is the "== true" redundant and the curly brace placement an atrocity, you're also forced to apply regardless of the conditional!
|
|
#
?
Jan 10, 2016 17:16
|
|
|
TooMuchAbstraction posted:You would think the marketers who make these stupid ads would get an actual programmer to look over their poo poo so it doesn't insult the intelligence of the people they're trying to recruit. Not only is the "== true" redundant and the curly brace placement an atrocity, you're also forced to apply regardless of the conditional! Also, the missing semicolon.
|
|
#
?
Jan 10, 2016 17:25
|
|
only
|
|
| # ? Jun 2, 2024 05:50 |
|
|
Maybe that's the point, they want everyone in the world to apply for a job, but front end developers get the special "for you" tag.
|
|
#
?
Jan 10, 2016 17:27
|
|
