/dpt/ - Daily Programming Thread

>no brain activity
>it's actually the plastic cap that's dreaming

i think i'll keep my good music, thanks :^)

the new C standard you dumbo

Your mistake is in assuming the dream pictured is of the sort that requires brain activity at all.

What's the point of p[1:5] if C doesn't support slices?

You ever find yourself looking over the logs of language/platform specific IRC and find tons and tons of talk about highly volatile features or libraries they're using that admittedly offer them mild convenience.

I just feel so sad for them. In a year or two they'll be completely without these tools they enjoy so much.

hopefully none of them. C's only saving grace is its relative simplicity.

I tried running make, I got this
:~/ps4/ps4sdk-firmware505$ make
make -C base all
make[1]: Entering directory '/home/guts/ps4/ps4sdk-firmware505/base'
Makefile:9: *** Neither PS4SDK, Ps4Sdk nor ps4sdk set. Stop.
make[1]: Leaving directory '/home/guts/ps4/ps4sdk-firmware505/base'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2

When I try and run cmake it says Cmakelists.txt aren't there.

Attached: 1511520411171.jpg (901x1200, 145K)

p[1:5] is just p + 1.
>string functions that return const char*
One look at the function signature for free() tells you why this is a bad idea.

C isn't simple, it's primitive, and it's not simple to use primitive tools.

Ok. Unless they introduce modules, namespaces or proper metaprogramming or otherwise fix some crippleshit, I'm not really interested, though.

C is indeed simple, not primitive. No one said it was simple to use. Indeed it's not simple to use simple tools either. It IS simple to use simple-to-use tools, by definition, but you're falsely equating the two.

I find most of my needs are met by external tools.

Why do you think C needs namespaces?

well the string proposal was more about having both functions the old one and new one that returns const. Then there would be macro abusing _Generic to return non const or const depending on the input type.

>One look at the function signature for free() tells you why this is a bad idea.
The function free() is a bad idea because it doesn't take type or size. It harms any allocator implementation.

Of course none of us actually use malloc or free so it's not that important.

Look the readme on the repo. It's with cmake.

Why not just use the functions that return non-const and store the results in const pointers.

A hammer is primitive. A knife is primitive. They're elegant and do the job they were designed to do very well.

Because I don't want to write SFS_doShit() all the time when creating a library.

because sepplestards want their forced const correctness in C.

You don't NEED type or size, because no two or more data will be stored at the exact same address.

Even so, the behavior I describe IS const-correct. It would only be incorrect to do it the other way around.

So use a macro.

That's what isn't clear, he says that's for the macOS build. Regardless of that, I've tried cmake and make, and in each case I get different errors.

C2x is getting ranges?
What does p[1:5] actually return? a struct with pointer and size? or just a simple pointer.
If just pointer, then there's no fucking point in the upper bound.

I didn't ask for a proposal to make it even worse, user.

Oh, man! That image is going make some C programmers butt hurt!

How is using SFS::doShit; better than #define doShit SFS_doShit?

Const "correctness" is a damned lie. There's no such thing as immutability in a real computer, so there shouldn't be any such thing in a language that was designed from day 1 to be a universal, portable assembler on every form of silicon.

It already did,

What language is the best pajeet filter?

Should I use TensorFlow or start with something like Keras?

>You don't NEED type or size
You should use them though. Because it allows for allocators to be better.
I can't be bothered to explain.
IIRC this talk explains quite well how allocators should be. (note, Andrei isn't particularly happy about C++'s options either)
youtu.be/LIb3L4vKZ7U?t=338

But for a tl;dr on the size. You almost always need the size somewhere in the application for your allocation. It's either sizeof(type) or sizeof(type)*size. So you're already taking care of the size yourself. It'd allow for more sensible allocators to either expose the size from the allocator or provide it on the user side.

And I'm not saying malloc/free WAS bad. I'm sure it's a justified decision somehow. I can't really see it though.

using namespace SFS;, dumbshit.

I would like to see a defer statement like Go.
Maybe better error handling or something

Because defines spill whereas using ident within a scope will keep it in that scope.
#include

static void foo()
{
#define a 5
}

static int bar()
{
return a;
}

int main(int, char *argv[])
{
printf("%d\n", bar());
return 0;
}

Immutability has nothing to do with it. It's not about reflecting whether or not the pointed-to data is actually immutable in memory, it's about reflecting whether the pointed-to data is immutable for the purpose of separation of concerns. "const int *f(..." means, "the function f returns a pointer to an int, advises you not to modify said int, and takes no responsibility for anything breaking if you do."

That's bad style, it makes it harder to see what namespaces the symbols you use really belong to. It makes refactoring tricky and it makes forward compatibility with libraries hazardous.

Stop using C and go back to writing machine code with a hex editor then.
You clearly don't understand the point of programming languages.

Putting a #define inside a scope is a code smell, constants should be global

user was asking how is using shit; better than define shit;. I don't disagree with what you said though.

I still don't get it why middle-aged cantankerous C programmers with the C hacker syndrome hate newer languages like Rust. Rust is by no means perfect. It still needs some work done on it to iron out any wrinkles, but overall, it's a good language.

>dude make everything global lmao
cniles make me sick

>I still don't get it why middle-aged cantankerous C programmers with the C hacker syndrome hate newer languages like Rust.
not fast

Any nim fans?

>to iron out any wrinkles
The BC is one big fucking wrinkle. I wonder when they'll iron (remove) that one out.

One is understood by the compiler, one is a retarded text replacement. But that is beside the point, user. I simply don't want to uglify my function names in the library with some retarded pretext like some dumcumpster that likes hungarian style, just because some asswhiped fuckpuppets in a committee of precomposted cumdrinkers can't be assed to introduce a perfectly introducable feature that has been standard in all non-laughing-stock programming languages since the 80s.

In some cases, Rust programs have been faster than C/C++ programs.

wasn't me, btw

>dumcumpster

>defer statement
I miss this every time it's missing.
Go enforces an arbitrary order though. Might be sensible for a language like Go. For any other language I'd rather manage the order myself. Especially since we don't have destruction like in C++.

Anyone got a programming challenges image?

python, js, lisp, ... fags have been claiming to be faster than in some cases for ever.

How is the borrow checker a wrinkle? Originally, they were going to have a GC, but then they decided something more low level and something that could be run a compile time instead of runtime.

Ok I should clarify a bit on the type side aswell. When I say it should take a type. I don't really mean that. It should take some context for allocating that type. Alignment is the most common thing.

It was written on Vegetas pink shirt, it's a perfectly normal word. If nothing else, you can trick some shit tier word filters.

It's shorthand for "dumb compster." Compster is the hip new term for programmer

>defer
use goto

GOTO MY ANUS

wtf, you fucking cum dumpster

> I simply don't want to uglify my function names in the library with some retarded pretext like some dumcumpster that likes hungarian style
You'd rather have your compiler do it in an implementation defined way that breaks any FFI.

>debugging for hours trying to fix a bug
>turns out i was on the wrong variable
>the bug was a simple typo
Never dev with a sleep deprived mind, lads.

I made more progress in developing my own homegrown operating system.
Pic unrelated (the gui shell was actually developed quite some time ago), the improvements I made consist of porting tcc to run under my system, to allow some degree of self hosting.
Right now, the user may JIT compile-and-run most userland applications (recompiling the kernel / libc is not yet possible, but I'll eventually get there).
Still not much progress in implementing TCP tough.

Attached: screen.jpg (1024x768, 183K)

>You'd rather have your compiler do it in an implementation defined way that breaks any FFI.
Hell, yes. Impeding script fags is a nice side effect indeed.

Impressive.
How long have you been working on this project?

>use goto
type_t* i = malloc(sizeof(type_t));
initialize_type(i);
goto cleanup;
/* actual work */
label: cleanup;
unhandle_type(i)
free(i);

Now add another.

user defer if for entirely different purpose.
It's where you want to declare an action somewhere in the code that isn't where it's executed. And it's not for universal use like goto.

Also I don't suggest the actual use in code, even with defer. But it has its place. Intrusive profiling is probably the simplest example.

ask me how i know you're a scriptfag

the standard could force it be something human readable

int y; // just y
int x; // just x
namespace muh_ {
int x; // muh_x
void fn() {
// muh_fn
int z = muh_x; // valid finds namespace local x
z = x; // muh_x
extern x; // using global x
z = x; // global x, namespace local x could still be used with muh_x
}

int main() {
muh_fn();
using muh_ {
fn();
}
}

}

sure this is crude example and needs more specs for case like nesting but the compiler could just give error in cases that cannot be handled sanely.
It would c abi compatible but reduce prefix typing, it would also be more flexible than hardcoded prefix on everything.

you'd be wrong.

That's the first thing I thought about, too, but he also could be a retard and have variable names like x1, x2, x3.
We are on 4chlinks, after all.

Not him but if you're unintelligent enough to use a debugger instead of just walking through it in your head, then you're unintelligent enough to use a scripting language.
Is that how?

>the standard could force it be something human readable
That's not the problem here, otherfag.
Anyway, FFIfags could create and maintain their own wrappers for all I care.

dobugging doesn't always mean literally using a debugger you know.

I thought of Ruby and Python and their lack of declaration.

Adding new "features" which only serve to create additional work for no benefit is the domain of sepples. please keep your hands off c.

"Henry"fags will defend this

as you said
>You'd rather have your compiler do it in an implementation defined way that breaks any FFI.
the standard could define it in way that it's FFI friendly and not leave any freedom to the implementors.

True enough, if you have to use a debugger then clearly you don't know what de' bugger your code is doing.

>on the wrong variable
I don't know what this could possibly be referring to other than a variable watcher in some debugger.

ALSO IF I HAVE TO SOLVE ONE MORE FUCKING CAPTCHA I AM GOING TO FUCKING SHOOT UP GOOGLE HEADQUARTERS
THIS SHIT IS PISSING ME THE FUCK OFF

>Adding new "features" which only serve to create additional work for no benefit is the domain of sepples. please keep your hands off c.
It only creates more work for people that do it wrong in the first place, so it's good. Agree about C++, though.
>"Henry"fags
???

I started around october 2017, but I didn't start entirely from scratch, since the osdev wiki gives you a solid base of makefiles/build scripts to improve upon.
Also, one year earlier (dec 2016) I did try to make a kernel in rust (following philip opperman's blog), but rust's design was too cumbersome for me, and thus I decided to start over in C.

>Adding new "features" which only serve to create addition work for no benefit
Features that are added to a language are put there to improve efficiency of production or to fix a problem. If the feature actually DOES SUCK then don't use it.

>please keep your hands off c.
I will. No need to touch such an unsafe language.

Using a C FFI is doing it right. A lingua franca is a good thing.

66593557
(You)

Defining an ABI is not the role of a language standard. A language standard should strive to be simple so that a simple ABI follows naturally.

Why are you/did you learning programming lads?

I want to make a simple online quake defrag game but with competitive race modes

Attached: fe0281f181f916e8cd64f199c95979bc.jpg (564x404, 35K)

This.

Fucking visual studio

>file access is fine
>now randomly cant access folder

It's official, programming gave me the yellow fever.