previous thread >>51315151
what are you working on /g/?
Is int always 32 bits in C?
>>51319025
Nope, it's implementation defined.
it would be pretty funny if someone actually made an operating system in Go just to prove that, indeed, Go is a language capable of building a kernel.
to the retards laughing about the "Go is a systems programming" thing: https://www.google.com/search?q=systems+programming+language
>A system programming language usually refers to a programming language used for system programming; such languages are designed for writing system software, which usually requires different development approaches when compared with application software.
Go IS a systems programming language. try building system tools in PHP.
it's not difficult to google something to find a definition, really. stop spreading bullshit
>>51318989
LMC implementation is going pretty well, working on turning the instructions into their respective "machine code"
>>51319039
On what platforms is it different?
>>51319055
Consider AVR, where they are 16 bits wide.
https://gcc.gnu.org/wiki/avr-gcc
>>51319025
No, but usually atp. Originally, they were all 16bits, which is why size_t is always unsigned in C++.
>>51319077
>they were all 16bits, which is why size_t is always unsigned
how the fuck does that correlate?
>>51319041
>Go IS a systems programming language. try building system tools in PHP.
> try building system tools in PHP.
I'm sure it's possible, even though they'd be shit. PHP must be a systems language too!!
How come I can control a loop with fscanf, but sscanf won't do the same thing?while (fscanf(file, "%d", &n) && !feof(file))
will grab every subsequent integer and then end when it reaches the end of the file.while (sscanf(buf, "%s", current))
will keep grabbing the same first string separated by spaces over and over and never traverse the whole string buffer.
>>51319025
int is at least 16 bits
>>51319077
size_t is unsigned because having something take up negative bytes doesn't make a lick of sense
>>51319101
read the manpage for both functions
Thinking of releasing a moddable fps on steam for 1 dollar. You can host your own servers and design your own games
Kinda like halo CE
What do you think? Feasible? I already have an engine and assets/basic knowledge of the networking required(which is practically already built)
>>51319097
>"In particular, for historical reasons going back to the early days of C when ints were 16 bits and every bit mattered, v.size() for a vector is an unsigned integer."
For that double capacity vs. 15 bits.
>>51319068
Let me rephrase it: is it something else than 32 bits on any platform that matters for servers/desktops/mobile? Aka. not ultra niche purpose microcontroller.
>>51319106
>int is at least 16 bits
That's not true, it's implementation defined. Look at https://gcc.gnu.org/wiki/avr-gcc
>>51319106
>because having something take up negative bytes doesn't make a lick of sense
True enough, but that's not actually the reason. This is:
>>51319129
can i store multiple data types within a node for a binary search tree in c++?
likestruct node* Athlete {
string firstName;
string lastName;
int rank;
float salary;
float earnings;
float endorsements;
string sport;
ptr left*;
ptr right*;
}
I have to read 100 athletes from an excel file and store them in a binary search tree and allow the user to sort them by any of those data types.
I really dont know how to go about it.
am I close?
>>51319129
that sounds like bullshit; link?
>>51319130
>is it something else than 32 bits on any platform that matters for servers/desktops/mobile?
No.
But consider using stdint.h and int32_t if you need fixed size integers.
>>51319130
Then you real question isn't anything about C, it's about common implementations of C, in which case, sure, it's ~usually~ 16 bits.
>>51319025
An int may be as little as 16 bits. On platforms where the length of a register is less than 32 bits, it is typical for an int to be 16 bits. On some rare platforms, such as Tru64 Unix, an int is 64 bits.
The following are always true in any C implementation:
sizeof char ≥ 8 bits.
sizeof short ≥16 bits
sizeof int ≥ 16 bits
sizeof long ≥ 32 bits
sizeof long long ≥ 64 bits
>>51319112fscanf() reads input from the stream pointer stream, and sscanf() reads
its input from the character string pointed to by str.
That didn't help at all.
Their function declarations are almost identical.
also i triedwhile (fscanf((FILE *)buf, "%s", current))
and that didn't work either
>>51319153
>>51319140
it's implementation defined but the standard states that the int type is at least 16 bits.
>>51319162
>it's ~usually~ 16 bits.
aka 32
Just finished working on a simple game.
It works on both Windows and OSX, with gamepad support for both platforms:
http://www.raskie.com/octjective/
Please test in out and let me know what you think on this beta chatboard here.
http://raskie.com:85
Opinions on both projects welcome.
>>51319129
>C++'s std::vector is the motivator for C's size_t
nope. that might be why vector.size() returns size_t but it's absolutely 100% not why size_t is unsigned.
>>51319175
Some implementations deviate from the standards. Taking up the high horse on this is not a lot of use when suddenly you overflow after 255.
I agree that following the standards would be best but I don't make the compilers.
>>51319176
Sometimes. Sometimes it's bigger still.
>>51319210
>but it's absolutely 100% not why size_t is unsigned.
meh, take it up w/ bjarne anon.
>>51319168
>>51319129
>For that double capacity vs. 15 bits.
You're an idiot.
>>51319101
Because you're passing the same buf every time.
Need to advance it yourself if you wanna grab the next thing, i.e:
buf += strlen(current)
>>51319116
Probably the wrong place to post this huh
I'll just make it and ask questions later though
>>51319155
This. If the size of a data type is important, accept no substitute.
And if you can't do that, then_Static_assert(sizeof(int) * CHAR_BIT == 32, "int is not of correct size");
>>51319237
same to you
>>51319236
>>51319236
>take it up w/ bjarne anon
bjarne doesn't talk about size_t, he talks about vector::size, moron.
>>51319251
. . .
>>51319217
>usually
>sometimes it's bigger
>usually
>sometimes
are you pretending to be a retard?
>>51319217
>Some implementations deviate from the standards
Those are not implementations.
>>51319247
>If the size of a data type is important
In portable code, the exact size is NEVER important.
Is C++ a strong typed language? Is C?
>>51319247
>_Static_assert(sizeof(int) * CHAR_BIT == 32, "I'm incompetent and my code makes useless assumptions from this point on");
ftfy
>>51319217
>Some implementations deviate from the standards.
Those you can ignore since they wouldn't be valid C implementations.
Should you worry about some 'C implementation' which defines + as subtraction and use work-arounds in your code for such a retarded target?
>>51319266
vOv
>>51319277
Well, they're not standards compliant implementations of C, but they are realistically close enough.
Specifically providing an option to deviate from standards to users can sometimes be useful, but really at this point we're just arguing semantics of the word "implementation".
Nice picture retard. Nobody wants to look at Donald Duck's face.
>>51319236
i'm pretty sure that bjarne did not invent size_t
>>51319304
>they're not standards compliant implementations of C
Then they are not implementations of C. They might be implementations of a language similar to C, but it's not C.
>>51319307
Frig off
>>51319041
>A system programming language usually refers to a programming language used for system programming
No shit retard.
Google's own employees which designed Go say it's not supposed to be one, so shut the fuck up.
>>51319282
>portable code
meme
I'd like to ask again, any good advice about persisting C++ objects to disk storage in JSON format /g/?
>>51319193
Nobody cares about your botnet-infested binaries. Post source or get out.
>>51319292
They are basically similar, namely weakly typed. Sepples is much more strongly type-checked, however.
>>51319292
systems programming languages are purposely weak by design, C has the weakest typing you can possible have
i do the dpt roll but i get shit that is way beyond my understanding
anyone here wanna suggest something a shit brain like myself can handle?
>>51319282
It's important e.g. when working with binary formats.
>>51319378
]do the faggotbuzz
>>51319340
if you don't care about portable, int is always 32-bits so no checks required either
>>51319310
I'll grant that's possible anon, I don't have any historical versions of the C++ docs handy that would illuminate on that question.
>>51319282
no anon you're getting things backwards. in properly portable code, no assumptions are made about the sizes of non-fixed-size types. this is a bit of a mental burden for programmers.
if you use fixed-size types, your code is automatically more portable because you know exactly how big everything is going to be. you can take that char* and offset by 4 and know that you'll be at the next int32_t. the only thing you need to look out for now is endianness.
>>51319385
How so? Are you saying you can't handle a binary format if you don't have fixed width types?
>>51319398
>int is always 32-bits
that's fundamentally wrong anon.
>>51319440
>reading comprehension
>>51319378
Program that spawned random particles at the top of a 2d array and every half second moves them down a position. When they hit the bottom they stay there until you have a full row of values which it deletes
>>51319422
>if you use fixed-size types, your code is automatically more portable
If by "more portable" you mean "less portable" I agree. Because those fixed width types are optional, thus available on fewer implementations than the standard types.
Again, for portable code you NEVER need fixed width types.
>>51319447
lolwut. portability isn't part of the issue. ints can be any width the engineers decide it is. currently that happens to generally be 32 bits wide. That wasn't the case in the past (and still isn't on a wide array of h/w), and won't be in the future.
>>51319473
>and won't be in the future
wrong, int is 32 bits on all future implementations
>>51319473
>portability isn't part of the issue
>wasn't the case in the past
>still isn't on a wide array of h/w
>won't be in the future.
>portability isn't part of the issue
>portability isn't part of the issue
>portability isn't part of the issue
>full retard
>>51318989
Nothing because I am indecisive and have trouble committing to any particular project.
>>51319484
I'm becoming very interested in Forth. I've completed "Starting Forth" and those last 3 chapters really sent my mind spinning and now I can't stop thinking about the expressive capabilities of Forth. I really, really want to develop something in Forth now.
>>51319484
heh, i sure hope i don't have to deal with any of you're code in the future anon. pls, do us all a favor and at least just stick with int32_t k?
>>51319378
Implement this shitty game: https://en.wikipedia.org/wiki/Bulls_and_Cows
BONUS: Make it so that you can easily change the number of digits in a code.
EXTRA BONUS: Make it changeable by command line argument.
http://pastie.org/10553779
>>51319431
computer a writes an int, 32 bits, to a file
computer b receives the file and tries to read the int, computer b knows int to be only 16 bits, so only reads 16 bits
you need to know the sizes of what you're reading and writing
>>51319472
>fixed width types are optional
okay it seems we're working under different defintions of portable here. im working with "will work as expected on any other platform that implements the standard" and you are working on "will compile on more computers"
i don't really think compiling on more computers is a feature if they're going to be wrong
>>51319497
Whoopsie didn't mean to post that
>>51319496
Welp, do you have any interests that seem to outweigh all others in you're mind anon?
>>51319495
>>full retard
>>int is always 32-bits
>teh irony
Post what music you're currently coding to
https://www.youtube.com/watch?v=nZB3RgTEhrQ
>>51319501
Wait wasn't this called something else? Played with the little pins and you have 20 tries? It like tells you if you are in the right pos or right number there
>>51319498
>I really, really want to develop something in Forth now.
https://www.youtube.com/watch?v=ZXsQAXx_ao0
>>51319533
Don't listen to music while programming. It's a detriment.
>>51319544
In the UK it's known as Mastermind.
Why do people complain about bugs in their code? Why can't they just git gud?
>>51319546
Hai senpai, megassa DO IT desu na
>>51319562
>>51319561
Yeah! We had that in Australia too. The cover of the board game was a fella with a white beard and hair sitting at a desk and a classy lady standing beside him with her hand on his shoulder. I used to play that game all the time with my sisters.
>>51319623
>ignoring science just so you can listen to music that makes you feel good
>>51319506
>computer a writes an int, 32 bits, to a file
It shouldn't write an int, it should write 32 bits.
>computer b knows int to be only 16 bits, so only reads 16 bits
It shouldn't read an int, it should read 32 bits.
>you need to know the sizes of what you're reading and writing
Yes, but that doesn't require fixed width types in C.
>im working with "will work as expected on any other platform that implements the standard" and you are working on "will compile on more computers"
I'm working with the same definition as you. Not relying on fixed width types gives you more portable code. You must be competent enough not to fuck up the logic though.
>>51319242
I keep forgetting c strings are simply arrays.
Thank you!
>>51319528
>portability isn't part of the issue
>>51319571
https://www.youtube.com/watch?v=KxGRhd_iWuE
>>51319638
>not doing both
>>51319506
>im working with "will work as expected on any other platform that that matches my shitty assumptions"
ftfy
>>51319354
Those binaries are more sanitary than anything found in any place you've lived in.
>>51319640
>Not relying on fixed width types gives you more portable code.
full retard.
>>51319560
heh, apparently you've never worked in a big environment while coding.
>>51319683
Yes, apparently you are; being able to follow simple logic proves to be too much for you.
>>51319685
I've got a big environment
>not implementing functional command-line tools for yourself$ map echo 1 2 3
1
2
3#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int
execute(const char *execfile, const char *arg) {
int status;
pid_t child = fork();
if (child < 0) {
perror("fork");
return status = 1;
} else if (child == 0) {
execlp(execfile, execfile, arg, NULL);
perror("execlp");
_exit(1);
} else {
wait(&status);
}
return status;
}
int
map(const char *execfile, const char *const *args) {
int status;
for (size_t i = 0; args[i]; ++i)
status |= execute(execfile, args[i]);
return status;
}
int
main(int argc, const char *const *argv) {
if (argc < 2)
return 1;
const char *execfile = argv[1];
const char *const *args = argv + 2;
return map(execfile, args);
}
>>51319705
>just as wasteful as functional programming itself
checks out
>>51319282
Here's an example of portable code that requires fixed-width types.uint32_t x = UINT32_T_MAX;
x += 1;
I await your apology.
>>51319703
hehe. i'll give you the benefit of the doubt anon. but the day you walked into my cubicle insisting i don't wear headphones "because science" is the day you'd see my ass walking.
>>513197034 * "u"
>>51319513
One thing I would like to do/learn more about is UI. I would like to find a project that needs some UI work and just dive in.
>>51319151
yeah that looks fine. You'll just use different sort functions.
>>51319745
The day I walk into your cubicle is the day you get your pretty ass beat, boy.
>>51319730
>implying it's not useful# kill all the little browser niggers using my RAM (pkill only takes one pattern)
map pkill firef chrom st thunderb
>>51319759
C# if you're into botnet. QT otherwise.
Any other interests?
>>51319766
Fuck off cock-mongler
>>>/lgbt/
What's the idiomatic C way to initialize a string buffer?
Valgrind is throwing a lot of warnings because my strlens are reading uninitialized garbage.
Is something likechar buffer[80] = ""advisable?
>>51319794
You can do char buffer[80] = {0} to null fill the thing
>>51319794char buffer[80] = { 0 }; // set 80 bytes to 0
>>51319794
Yeah, I guess, but usually the first thing you do with a buffer is strcpy something into it so why does it matter?
>>51319732
This does the same thing, even more portableunsigned long x = 0xFFFFFFFF;
x += 1;
x &= 0xFFFFFFFF;
My code works on ANY C implementation, yours doesn't.
I await your apology.
>>51319640
>You must be competent enough not to fuck up the logic though.
that's exactly the point. code is less likely to rely on false assumptions. therefore code is more portable. if you're using fixed width types and it works on your own computer, it will probably work on any other computer (again, endianness excepted). if you don't, you can't be so sure. particularly if you're working with other people who aren't quite so amazing as you are.
>Yes, but that doesn't require fixed width types in C.
but anon, what type do you read into? do you just deal with raw bytes? how would you go about e.g. printing that integer? do you replicate integer formatting code with a byte stream just to be your own definition of portable?
>>51319815
I thought C would default to NULLs?
>>51319794
http://ideone.com/2ZDsji
>>51319843
C doesn't initialize anything unless you force it to.
>>51319861
I see. Somehow I thought the newer standard changed that. Makes sense for C though.
>>51319861
I think he means why {0} instead of {}, as >>51319855
shows
>>51319832
>>51319732
Uh, isn't x+=1 undefined?
>>51319870
Overflow on signed ints is undefined, yes, but you can get some neat optimisations if you allow it.
>>51319879
>but you can get some neat optimisations if you allow it.
you can also create write-only code too.
>>51319861
Static data gets initialized right? Data the exists in the compiled binary file.
>>51319835
>code is less likely to rely on false assumptions. therefore code is more portable
How the fuck is code more portable when you add restrictions to the implementation?
>what type do you read into?
unsigned long: it's guaranteed to be at least 32 bits; you read one byte at a time, you shift and or: this way you also tackle endianness at the same time.
>how would you go about e.g. printing that integer?
printf with %lu
You must have some fucked up definition of portable if this is not all obvious to you.
>>51319893
that one is guaranteed by the standard, yes.
>>51319832
your code also produces different results depending on the size of long
in cases where long is 32 bits you have overflow
in cases where long is 64 bits you don't
nice "portable" code
>>51319870
Not for unsigned, x + INT_MAX + 1 is = 0.
>>51319889
C is well into the market of allowing nasal demons if people write that.
If people want to write in a language that is similar to C but adds safety, Ada is a good place to look, as is Rust, although I don't personally like it.
Power, responsibility, etc.
>>51319870
>>51319879
>>51319889
the code uses unsigned types, you idiots, they wrap without undefined behavior
>>51319832
too slow to be usable on for example SysV amd64.
>>51319913
All this stuff makes me glad I'm living in an age where compilers are more than happy to tell me what I'm doing wrong. I couldn't imagine programming back in the 80s where the compilers just let everything slide without warnings
>>51319927
I only mentioned signed ints, what's your point?
>>51319921
>in cases where long is 32 bits you have overflow
I don't use long, I use unsigned long; unsigned long doesn't overflow, it wraps; same as your uint32_t.
>in cases where long is 64 bits you don't
The result is the same as wrapping in 32 bits due to the mask with 0xFFFFFFFF.
>nice "portable" code
It really is.
I await your apology.
>>51319832
More verbose, and you have to mask after every arithmetic operation. But you are correct in the sense that fixed-width types can be emulated with least-width types.
>>51319933
back in the day, people WERE the compiler
assembly was hand assembled
>>51319911
>How the fuck is code more portable when you add restrictions to the implementation?
Not him, but that should be obvious. You generally need to restrict the capabilities of a language to be able to ensure it will always run the same across different architectures. If there's aspects of the language that behave differently depending on the platform, then obviously code that relies on those things is prone to failing on some architectures it was not tested for.
>people in this thread think Java is slower than C
>>51319950
your reading comprehension while following the thread
I've got a stupid question, but it feels like not the /sqt/ kind.
If you make something and a bug causes a much bigger improvement over what you did before, do you try to implement it as a feature, or go back to your original idea?
>>51319924
>C is well into the market of allowing nasal demons if people write that.
heh right.
>>51319927unsigned int ui = -1;
int si = ui;
int si2 = ui + 2;
unsigned int ui2 = ui + 2;
It may not be undefined, but it sure isn't rational anon.
>two words:
Justsay
No.
When is the "portable C" meme going to die? People who want to write actual portable code use Java.
>>51319932
How would you know? You obviously haven't tested because otherwise you'd know they produce the same code.
Also, where's the apology?
>>51319980
>>51320007
Javapologists get out this is a Reform C thread
Also anyone who isn't Christian GET OUT
>>51320007
What's the point if using C if it won't run on other architectures?
You might as well write asm.
>>51319966
>you have to mask after every arithmetic operation
You don't, you can safely ignore the extra bits in between operations. You only need to mask at the end.
>>51319041
>Developer : Google Inc.
>>51320026
It's much less tedious than asm though, anon.
I like being able to write complex mathematic expressions in relatively intuitive forms and let the compiler take care of that shit.
Likewise, many higher level affordances such as structs, typechecking (even if it is weak, it still moans when I try to ram a string into a function expecting a char), etc
>>51319911
ok i'll admit i fucked up on the last 2 but the first one i stand by (i really have to go to bed now though i'm sorry i can't argue further)
>>51319962
i apologise for being retarded and missing the mask at the end and mocking your code
(but overflow is still overflow even if overflow is defined to wrap)
>>51320021
>You obviously haven't tested because otherwise you'd know they produce the same code.
They don't because long is 64 bits on that ABI.
(assuming we're talking about actual runtime values, the exact snippet will just be folded away into nothing as dead code obviously)
>mfw switching from writing HTML to using an HTML generating library
Feels good, manimagePage image @ (Entity id Image {..}) =
document ("Image " ++ show id) $ do
tagsBox imageTagNames
forM_ imagePages (thumbnail image)
>>51320000
Throw out what you did before, just keep the bug.
>>51319973
Not him, but you're a fucking idiot if you actually believe what you wrote. What you're arguing is that "if you make it less portable it will be more portable", "if it only runs on one platform it is more portable", "if it only works on 2's complement with 8 bit chars and 32-bit points it is more portable". Are you this fucking brain damaged?
What does high level ASM code look like?
>>51320000
Understand what the bug does better, and then implement that in the original, or ditch the original for the "buggy" version, but re-written to do what the bug did on purpose.
Depends on the bigger picture.
>>51320085gcc -s fizzbuzz.c
>>51320002
>It may not be undefined, but it sure isn't rational anon.
The cast from unsigned to signed is implementation defined.
>two words:
Justlearn
C.
I"m working on making some shekels like the jew I am nigger
>>51320112$ make shekels
make: *** No rule to make target `shekels'. Stop.
>>51320068
>>51320094
Rather than a bug I guess it's more of a logic error on my side. Still very unexpected. I will keep it, modify it. Thank you.
>>51320000
Dunno anon. Ask Linus.
>>51320105
two words:
>lolno
>u
>
>>51319730
https://storify.com/realtalktech
I've been being slandered on reddit and twitter for saying the truth about functional programming - it's utter shit.
If you support me, I'd appreciate it if you'd spread the word. Functional programmers are horrific trolls and harassers when you confront them with reality.
In any event. Anyone have a favorite permissive licensed linked list implementation for C?
I've been looking at BSD's queue, postgres', etc.
I've gotten recently into a Computer Science university course but my biggest problem with programming is setting up the path before coding. How do you analyze the programming exercices and organize thoughts before laying shit down on the keyboad? What kind of notes do you take before coding?
>>51320165
Reddit (or at least /r/programming) is also super anti-RMS and pro-corporate.
>>51320165
>https://storify.com/realtalktech
>"Tech for Alpha Males. No code of conduct. Vote Trump."
See now this makes me want to vote.
>>51320165
>https://storify.com/realtalktech
Here's your you.
Though I do personally like BSD's data structures.
>>51320180
I use the code itself as my science journal while designing software. The process of writing ideas out as comments in the appropriate spots helps me to devise better approaches.
>>51320165
Why do you say that functional programming is utter shit? I don't think that it is the end-all be-all of programming, but I think that applying functional concepts to programming can help reduce bugs. I also believe that strongly-typed functional languages have their place in high-stability applications.
I think its pretty naive to dismiss an entire paradigm as 'utter shit'
>>51320225
Clickbait trolls will write anything for attention.
>>51320057
>They don't because long is 64 bits on that ABI.
Again, you haven't tested AND you don't know how amd64 works; hint: when you write a register's lower 32-bits, the upper 32-bits get cleared.
>assuming we're talking about actual runtime values
We're talking about the snippet posted to which you replied with "too slow", dumbfuck.
>the exact snippet will just be folded away into nothing as dead code obviously
Backpedalling already? On your bullshit claim about speed in a talk about PORTABILITY? I never expected this from you, anontard! Say it ain't so!
Fuck off already, you stupid cunt.
>>51320202
>>51320192
/r/haskell already banned me to censor my message.
/r/programming also piles on me.
https://www.reddit.com/user/realtalkintech
I feel so hurt by how they treat my posts.
They call me stupid, unintelligent, etc. simply because I point out their inconsistencies.
I really wanted them to see things for how it is. Instead, they dig deeper into denial and try to hide ideas they don't like.
Subreddits are safespaces where uninformed people who've stuck with decisions stick with subjects and memes that same way sports teams worked in the 80's.
it's not about reason, it's just about picking a side, wearing a jersey and virtue signalling.
>>51320237
I just read some of the stuff in the link he posted, and realized I wasted valuable time writing out my reply.
>>51320160
>two words
>damage
>control
>>51320069
>if it only works on 2's complement with 8 bit chars and 32-bit points it is more portable
Not necessarily no. But if certain data types behave differently on different platforms, then yes, that makes it less portable.
>>51320255
>I feel so hurt by how they treat my posts.
>I feel so hurt by how they treat
>I feel so hurt by how
>I feel so hurt
Just man up anon. Fuck em if they can't take a joke.
>>51320259
Pretty much this. Just ignore his posts, he's baiting for attention.
>>51320255
why don't you respond to my post >>51320225?
>>51320260
>well
>memed
>>51320290
>thank
>you
>>51320259
Same here. I think there are good arguments to be had around the functional programming trend, but his are just lame shitflinging.
Personally, one presentation that has really stuck with me recently is Bret Victor's "The Future of Programming" [1] Especially his points about the lack of scientific method in the way we approach our programming. It's a solid watch.
[1] https://vimeo.com/71278954
>>51320225
Sure, you can reduce cancer if you hack away at your flesh.
Functional language takes mutex's, posix threads and says hey, instead of learning how to make lock data and work with threads, let's make a whole new dumbed down language just to sidestep the fact we're too stumped buy POSIX realtime standards.
Misery loves company. The programmers who were too "dump" to understand how SMP/threading works now created their own little esoteric language that's of little use beyond pure arithmetic.
You say help reduce bugs - it's reducing the power of the language, and adding on severe creep in other places.
It is other shit unless you're tackling a narrow set of issues (quantitative finance).
Regarding strong-typing, that's not necessarily unique to fp.
>>51320270
Thank you.
Wait what? Who said it's a joke? This is *truth* here. :^)
>>51320282
I got you.
>>51320302
>>51320259
Functional autistic trolls huh.
So tell me what successful programs you have written in fp?
>>51320262
Ok, so you're actually retarded; I don't mean this as the usual /g/ joke, you actually have a mental disability, right? Because there's no way a person with a functioning brain can keep spewing this same inane shit that defies all logic.
inb4
>I was only pretending
>>51320165
>Anyone have a favorite permissive licensed linked list implementation for C?
kvec.h is short, sweet, and MIT licensed.
>>51320244
>Again, you haven't tested AND you don't know how amd64 works;
I have tested it and I know perfectly well how amd64 works.
>hint: when you write a register's lower 32-bits, the upper 32-bits get cleared.
hint: encoding 64 bit registers require more bytes (REX.W prefix)
hint: with a 32 bit register part you can then branch (or use seto) on the overflow flag for subsequent operations.
hint: if x is a variable it will be 8 bytes to load.
>We're talking about the snippet posted to which you replied with "too slow", dumbfuck.
The *literal* snippet as-is, is dead code (in fact it doesn't even compile as C code since there's no function context or a main).
>Backpedalling already?
Nope, just clarifying an obvious point.
>>51319041
so hun why dont you make your own small kernel in go then? shouldnt be too hard tbqh mi familia
>osdev.net
>>51320302
thanks senpai
>>51320318
Ok you completely misrepresented my argument and resorted to shitflinging
im done posting for tonight
goodnight anons
>>51319832
Replace 1 in the example with 2. If sizeof(unsigned long)==8, then there is no overflow and x is 0 (it should be 1). The correct emulation would be:unsigned long x = 0xFFFFFFFF;
x +=2;
x = (x >> 32) & 0xFFFFFFFF
But this also breaks down in the case where sizeof(unsigned long) is not a power of 2. E.g. if unsigned long is 33 bits wide and your arithmetic operation overflows, then the shift+mask will not give the correct result.
>>51320319
Well can you explain why?
Portable code to me means code that will run consistently across multiple platforms. For example, if I copy and paste a lot of C# from an online source, and compile it to a PCL assembly, I will have extremely high confidence it will run consistently across different platforms. I can be far less sure of this for C, as certain parts of C are prone to behaving differently across different platforms and different compilers.
I think that's a reasonable definition of portable code, and I think that's a pretty clear explanation of why I think aspects of C behaving differently on different platforms makes C code in general less portable.
Instead of just insulting me, please explain what you see wrong in my reasoning.
>>51320330
>I have tested it and I know perfectly well how amd64 works.
hint: the posted code (both of them) compile to "xor eax, eax" when wrapped in a function that returns the computed x
hint: you can tell yourself whatever you want about encoding length; it's irrelevant here
hint: there's no branching involved
hint: x IS a variable; one with automatic storage duration
In other words: backpedalling when you get rekt.
>>51320318
nprb. :^)
i hope the days of meritocracy in tech will arise again. i'm not too hopeful about it happening in 'murrika however--short of a big war or something similar in effect culturally.
>>51320225
>I think its pretty naive to dismiss an entire paradigm as 'utter shit'
I judge it as utter shit - if you read my blog - based on the following reasons:
- Lack of success in the industry (don't fucking give me "FB has an open source project using it") No successful business rose to IPO with pure fp. However, many have failed in part due to shoddy inconsistencies to engineer a product in X way. Some of those times were fp.
- Community reaction, snobbiness (but imbued in the fact they're in fact *not* smart or upper tier at all!), lack of ability to even take simple criticism. Censorship.
- Lack of readability
- Lack of libraries (compared to java, node, .net, ruby, python)
- High learning curve
- Lack of corporate backing (exception would be F#) Don't give me horse shit about small organizations. No one on NASDAQ is backing pure FP. Geniuses and brilliant artists think imperatively.
Autistic man children in tyrannical CTO positions pick FP. This is a meme of many startups that close shop.
The seeds of denial run deep within the functional programmer. Truth brings to them great fear.
They need to understand computer science better. Basically, they're like first year CS dropouts who gave up and decided to pick a language to "feel special".
All for this tiny little "ego victory" - what they want to do is create an *intentionally ugly* language with *no really benefit, less tooling, less libraries, less power, less speed* and then diss you a schmuck when you say "nah thanks, fine with C++11 :>"
Come on guys, these is *childish*. Give up on FP and come toward the light.
>>51320361
>If sizeof(unsigned long)==8, then there is no overflow and x is 0 (it should be 1).
It's not 0, it's 0x100000001, which after masking becomes 1.
>The correct emulation would be
No.
>>51320415
>inconsistencies
s/inconsistencies/insistencies
>>51320383
If you idea of portable code comes from C#, that would explain a lot of misconceptions. Run that C# code on a microcontroller or DSP and then we'll talk about portability.
>>51320165
people who are both fanatically for or against functional programming or both idiots who dont know what they are talking about
people hooked on the idea of functional programming are usually kids who read half a book on Lisp or Haskell and drunk on kool-aid and really dont fully understand what it means to program in a functional way
the guy who wrote that article is against functional programming simply because of the kool-aid kids who go around spouting stuff about how functional purity is the silver bullet that will end all programming problems and ignores the fact that theyre are some compitent programmers who are actually using Closure or Ocaml in real commercial software. Instead of trying to STOP functional programming he should be encouraging people to be properly educated in it
tl:dr most people on /dpt/ who argue fanatically for or against programming dont fully understand it
> Man, if you follow the links there is a whole series of articles against functional programmers on that site... they are full of resentment and never offer any actual point besides "I find functional languages very hard to read, it looks like math to me". I can only imagine that whole site is the personal vendetta of some deranged man who was once bullied by a haskell's enthusiast.
What desperation.
It's like they're SJW+Scientologist+Autistic
https://www.reddit.com/r/programming/comments/3sk2hr/startup_ceos_dont_use_functional_programming/
Literally these fp fucks are the worst of every world. What a bunch of hateful bigots.
>>51320415
>Lack of success in the industry
True, but for projects were this does not affect you, it's pretty good.
>Community reaction, snobbiness
I've found the F# community to be extremely nice
>Lack of readability
F# is extremely readable.
>Lack of libraries
F# has full supports of the .NET ecosystem and can use native libraries easily too.
>High learning curve
That's true. But F# at least lets you keep doing things imperatively and slowly use functional concepts as you learn them.
>>51320383
>C behaving differently on different platforms makes C code in general less portable
On the contrary: being loosely specified allows C to run on as many platforms as necessary. This portability is also the reason behind undefined, unspecified and implementation-defined behavior.
>>51320415
Daily reminder that 99.9% of the world's software is written in multi-paradigm languages.
>>51320052
It's pointless, anon. Retards actually think writing C is as difficult as Assembly.
In reality C is one of the easiest and most fun languages to write in, especially compared to shit like Java and C++ which just make me want to kill myself. Maybe C isn't great for large scale projects with many contributors but as a solo dev there's nothing more enjoyable.
>>51320491
>multi-meme languages
ishiggydiggy
>>51320453
>Run that C# code on a microcontroller
easily done
https://en.wikipedia.org/wiki/.NET_Micro_Framework
I'm still not sure what you're issue with my reasoning is though.
>>51320491
daily reminder that paradigms are a code monkey meme
>>51320415
>someone on /r/haskell called me a faggot
>therefore anything functional is bad
nice logic there friendo
ill be nice though, and respond
>- Lack of success in the industry (don't fucking give me "FB has an open source project using it") No successful business rose to IPO with pure fp. However, many have failed in part due to shoddy inconsistencies to engineer a product in X way. Some of those times were fp.
I don't see what this has to do with higher order functions, etc.?
>- Community reaction, snobbiness (but imbued in the fact they're in fact *not* smart or upper tier at all!), lack of ability to even take simple criticism. Censorship.
I agree, but I don't see what this has to do with actual functional programming.
>- Lack of readability
It depends on what language you use.
>- Lack of libraries (compared to java, node, .net, ruby, python)
Not really, but this doesn't really have to do with functional programming as a paradigm
>- High learning curve
This is Computer Science, not welding. Some things are hard.
>- Lack of corporate backing (exception would be F#) Don't give me horse shit about small organizations. No one on NASDAQ is backing pure FP. Geniuses and brilliant artists think imperatively.
Again, I don't see what this has to do with functional programming.
I don't want to sound like a snob, but you do not sound like you really know what you are talking about. Learn a little more about FP before you criticize it.
>>51320502
>as a solo dev there's nothing more enjoyable
except python
>>51320384
>hint: the posted code (both of them) compile to "xor eax, eax" when wrapped in a function that returns the computed x
Obviously, it's useless code.
>hint: you can tell yourself whatever you want about encoding length; it's irrelevant here
It's not irrelevant for real code, bigger instructions = more icache misses.
>hint: there's no branching involved
It's an example of here it would be more efficient to use uint32_t.
>hint: x IS a variable; one with automatic storage duration
As in memory.
Stop trying to damage control with a contrived example.
>>51320476
>being loosely specified allows C to run on as many platforms as necessary.
in what sense? What platforms can C only run on because of it's loose specification?
>>51320513
>resource-constrained devices with at least 256 KBytes of flash and 64 KBytes of RAM
>256KBytes
>64KBytes
>K
>constrained
Now try it on an 8-bit cpu with 512 BYTES of ram.
>>51320470
I don't know about F#. It is a tool language.
To my knowledge i don't know any websites, games, etc that run in F#
I don't think any NASDAQ, moon landing, etc were done in F#. No billionaire IPO's.
It may be a *fun* language. It may perhaps be a far more cultivated FP language than the others, especially being able to run in CLR.
Also it's back by MS
My largest point about a language and being indicator is its' success in business.
>>51320526
Read my blog, i'd prefer not to rehash the same ideas.
kindly note a lot of the stuff you're bringing up is already mentioned on the blog.
also your response is kinda boilerplate as far as FP pushers go. you have to understand that "you don't know it enough" doesn't mean every bus driver, trucker, investor, engineer is going to drop everything to completely forget every habit, intuition they built over their life just to finally "come to the realization" of how monads work.
My nanny can read C
>>51320530
Python is fucking awful. Slow as shit with awful syntax. Doing any gfx stuff is impossible.
But then I guess the kind of stuff I do is not suited for Python.
>>51320574
Probably, when done correctly, one of the most readable languages.
Holy shit is there a more wonderful programming environment than emacs + CEDET? This is amazing.
>>51320535
>Obviously, it's useless code.
B-but anon, you said it's slow! Are you backpedalling now? You seemed so sure of yourself that the more portable code is slow without referring to a specific use case.
>As in memory.
Or registers, r-right, anon? Y-you knew that too, r-right? Just like you know amd64, right?
>muh damage control
You always get so mad when you get your shit rekt hard on anonymous vietnamese image boards?
>>51320568
>It is a tool language.
What does that mean?
>To my knowledge i don't know any websites, games, etc that run in F#
jet.com's backend is 100% F#. It's used a lot in the financial sector too. I've used it for games personally, which it's excellent for. I don't know of other games that use it though.
>My largest point about a language and being indicator is its' success in business.
Well, it's certainly proven it's at least capable in that regard.
>>51320530
>>51320574
The thing is boys, you can really do both.
Python lets you handle the logical parts in a nice high level language, and then defer the fast or should-be-native stuff in C with ctypes or cffi.
>>51320543
All of them.
>>51319794
use calloc to initialize a variable size string
I have yet to see a single example of clean, maintainable C code.
Everything I've looked at is spaghetticode garbage that makes use of "clever hacks" and undefined behavior that would break the whole program if you change anything.
>>51320655
While you may have a point, the fact you're an anime poster renders your opinion invalid.
Thanks for using some fucking old man as the OP image instead of an anime image. Really appealing to look at... NOT.
>>51320568
> C-uck
> Blog
Self important faggot that thinks he has it all figured out detected.
No significant software detected however.
>>51320255
Grow up and stop calling everyone you disagree with 'autistic' and 'schizophrenic' and maybe you'll stop being banned.
I said banned, not censored. You're not Alkeksandr Solzhenitsyn, the KGB doesn't give a fuck about you.
You're just an asshole who thinks being banned for calling everyone in a sub mentally ill is on the same level as being persecuted by the state.
>>51318989
I'm in the early phases of building a Lisp. I'm working on a parser written in BTYaCC right now. I will be providing support for both S-expressions and what I'll call A-expressions, which are going to have an infix syntax.
About the "is Go a systems language" debate - what is a systems language in this context? I imagine it'd be pretty difficult to, say, use Go for a kernel - not impossible of course - but anyway, if we're talking about writing the next launchd or upstart or whatever then Go is up to the task. I say that as someone very critical of Golang.
>>51320165
I have one that is designed for speed, stability, and flexibility. It requires a malloc, a free, and a mutex interface, which I provide for C11 Threads, Win32 threads, and PThreads. It also offers a simple runloop function you can call on some thread, which will wait until something has been added to the list and let you process that. It has been stress-tested through use as a message queue for inter-thread communications (its main intended purpose), tested on FreeBSD (using C11 threads), Linux (using PThreads), and Windows (using C11 threads acting as a wrapper on Win32 threads). It is not particularly exciting in any way but I'm quite pleased that it works well and it offers an API which includes fun stuff like generating a variant for whatever datatype you want and giving you an iterator handle to play with (which is safe for use in a loop where the list is manipulated). Post in support of gay rights and you can consider it in the public domain for you.
>>51320670
I didn't post an anime pic, I posted linus_fuckyou.jpg
4chan just replaced my image with someone else's.
>>51320678
>I can only jerk it to kids, please satisfy my degenerate needs next time
ftfy
>>51320568
Ironically the programmers who use functional features the most along side imperative programming are javascript programmers. They use closures and high order functions all the time and would get a kick out of your crusade to stop functional programming.
Realistically functional languages like Erlang/Elixir will get used more and more for high concurrency servers, once more programmers are properly trained. Languages like Haskell are not going to see mainstream use because programming in a fully functional way means designing programs bottom up which does not support the imperative way libraries work which is methods on data types.
>>51320699
If 4chan did that then that'd only change the thumbnail, you're an anime poster.
>>51320696
>designed for speed
>requires a malloc, a free, and a mutex interface
anon...
>there are people in this thread who don't use custom memory arenas
baka desu senpai
>>51320568
F# is based on OCaml (although it's a shittier version)
OCaml has been used as part of MirageOS by a ton of websites and servers in general
It's been used by Facebook, Bloomberg, Citrix, Jane Street, and a shit ton of other companies
It was used to create Coq, which is basically the de facto theorem prover in use today
I think F# will get this kind of usage in the next 3-5 years, although I don't think the language is mature enough for that kind of shit just yet
>>51320655
You're not reading enough C - look at algorithmic C, and you can find some really lovely stuff.
Most C is enterprise crap or written by opensores philosotards who want to make things like "cat" extendable and portable, as a result, gnu coreutils is a nightmare mess of horrible C hacks.
C is weird in that it gives so much to the programmer - if you want to make something elegant, you have the freedom to do so, but at the same time you can do really evil shit as well.
>>51320741
What's shittier about F#?
>tfw you fell for the Python meme
Tbh nothing turned me off programming more than being forced to learn the snake meme language. It's just so shit in so many ways. The dev environment sucks. Even JavaScript would've been better.
>>51320792
F# does everything python does but better
>>51320792
Redeem yourself out of that shithole and learn one of these:
- Ruby
- Go
- Rust
- JavaScript
>>51320754
It's still missing a lot of what makes OCaml good with very little to offer over OCaml
lacks:
>GADTs
>ML modules (AKA F# is ML for keks)
>full object type inference
>an actual macro system
>open types
>various community maintained compilers or syntax extensions
has:
>units of measure
>type providers
The F# compiler also has a lot more bugs/inconsistencies still
>>51319705
>what is xargs -n0
this.output = document.createElement('div');
this.output.className = 'output';
this.input = document.createElement('input');
this.input.type = 'text';
this.input.className = 'input';
this.prompt = document.createTextNode();
this.prompt.nodeValue = '>';
let temp = document.createElement('span');
temp.appendChild(this.prompt);
temp.appendChild(this.input);
parent.appendChild(this.output);
parent.appendChild(temp);parent.insertAdjacentHTML('beforeend', '<div class="output"></div><span>><input class="input" type="text"></span>');
let temp = parent.querySelector('span:last-child');
this.prompt = temp.childNodes[0];
this.input = temp.childNodes[1];
this.output = parent.querySelector('div:last-child');
Which approach should I use when creating DOM elements in JS?
>>51319041
>>A system programming language usually refers to a programming language used for system programming; such languages are designed for writing system software, which usually requires different development approaches when compared with application software.
See, Go does not fit this description at all.
>>51320722
You can use spinlocks instead of mutexes. It's a matter of find/replace with pthreads.
The malloc and free are usually provided by DLmalloc operating in MSpace mode, which is practicable and fast.
How well can a compiler (i.e. gcc, clang and msvc 2015) optimize template functions?
Will this not bother doing the .back().get() and cast if the return result is unused?template<typename T, typename... Args>
T& Add(Args&&... args) {
m_systems.emplace_back(std::make_unique<T>(std::forward<Args>(args)...));
return static_cast<T&>(*m_systems.back().get());
}
It's not too expensive (static_cast and a vector, compared to a dynamic_cast and a map or something), but still if it's a potential performance problem I could just make it two apis (insert and then get, to match the standard container's interfaces).
>>51320000
quints of >>>/g/sqt
If I'm working in C# on a little application for keeping track of money in accounts and I want to be able to transfer money between accounts that use different currencies what's the best way to handle this? On program load at the beginning of the main method have it fetch the latest currency conversions for the used currencies?
It depends on your use case.
Do you need to look up conversion rates every time you do a transfer? Or on a background thread every n seconds/mins?
Make sure you are using decimal not float for currency btw.
>>51319116
Try asking another board, but I will say I loved Halo CE
>>51318989
objective see
>>51321078
It's not for anything significant, just a first little project so I don't think the small fluctuations throughout the day would be that big of a deal. I suppose I could just do a check every time the transfer function is run though. That seems like a relatively simple solution that will ensure a higher degree of accuracy.
I would be comfortable with a daily check or an on program launch check though. What kind of data structure would be optimal for this kinda data?
>>51320678
>Thanks for using some fucking old man as the OP image
You're welcome anon.
>in /dpt/
>not recognizing the greatest software mind in history
>>51319042
>LMC implementation
Sounds neat. How does that work anon?
>>51320696
>I'm in the early phases of building a Lisp
Sounds complex. Good luck anon.
>>51321085
I tried it but really never got used to it.
>>51319480
rollin
>>51321169
>Sounds complex
Not really.
https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours
