/dpt/ - Daily Programming Thread

old thread: What are you working on, Sup Forums?

Other urls found in this thread:

youtube.com/watch?time_continue=2815&v=qCGofLIzX6g
en.wikipedia.org/wiki/Netpbm_format
en.wikipedia.org/wiki/BMP_file_format.
rbt.asia/g/thread/63461470/
open-std.org/jtc1/sc22/wg14/www/docs/n2030.pdf
github.com/freebsd/freebsd/blob/master/sys/sys/queue.h
github.com/freebsd/freebsd/blob/master/sys/sys/tree.h
doc.rust-lang.org/1.20.0/book/second-edition/ch13-01-closures.html
godbolt.org/g/FYKgoH
twitter.com/NSFWRedditImage

First for my language

h a s k e l l

C and C++ are garbage

>Le ebin funny trap maymay.
Fuck off to reddit with your shitty forced memes.

Rustfag spotted.

Rate my C lambda!

int lambda01(int, int);
int func1(int a, int b) {
#define lx int lamda01(int a, int b) { return a > b; }
return lambda01(a , b);
}
lx
#undef lx

Is that a problem?

Whitespace programming language anyone?

youtube.com/watch?time_continue=2815&v=qCGofLIzX6g

Why is snek so crazy.

What's a super basic image format a novice can toy with?

bitmap

en.wikipedia.org/wiki/Netpbm_format
About as simple as you could possibly get.

BMP. But be aware that there are multiple header types within that format and they vary in difficulty. BITMAPINFOHEADER is probably the easiest to parse. If you want your images to use it, make sure to save the image as 24-bit RGB and check "do not save colorspace information" in Gimp.

Wikipedia article on the format can be helpful: en.wikipedia.org/wiki/BMP_file_format. A hex editor would probably come in handy too, because you're dealing with binary data.

>tfw create giant main class with dozens of functions and data types
>tfw once you're finished with the program you clean it all up into a perfect and neat OO design to turn into your professor
it looks so beautiful
even more so because of how painful it was to fix it up at the end

Why was the image in the OP deleted?

Proper "lambdas" exist as a C extension.
#include

int main()
{
int a = 10;
int (^fn)(int) = ^(int b){ return a + b; };
a = 5;
printf("%d %d\n", fn(1), a);
}
It's only supported by clang and is only really used by apple, but it has been proposed for C2X and seems likely to get in.

trapfaggotry

Fag shit.

Not him but unironically it was deleted from a male dressed as a girl?

>roasties are having a "#metoo for tech"
How is your country fucked? At least it turns out the sector was more based than I thought.

see for yourself

rbt.asia/g/thread/63461470/

The fuck is this ^ shit, gross

I just mean like if it was a girl dressed as a girl it'd get a pass? Where in the rules is this

It stands in for the * in a function pointer.
Also, if it wasn't there, it would be stupidly hard/ambiguous to parse, since it would look extremely similar to a compound literal.

for a long time the trapfag could post as much trapfaggotry as he wanted as long as it was 2d drawings and not 3d. as for breaking the rules, depending on the pic it could fall under NSFW, off-topic/garbage, and in some cases if he were to post images in the thread and not just the OP it could be considered avatarfagging or spamming.

>Functions as first-class citizens in C
YES! Too bad we'll have to wait 3+ years for it.

Better than C++'s [] syntax. And at least it has a real type that I can call by name.

>it's better than sepples!
Congratulations, that isn't an achievement.

>got highest grade on C test
>now it's Java OOP
>read entire book still feel like I don't know shit
What do?

Write programs

Why don't they put in hashtables and other common data structures in C2x?

Why would they?

>not reinventing the wheel for every program
Do you even C??

What kind of programs?
Can you point me to any small projects?

Because C is about fiddling with bits. There will never be a standardized hash table because C is used in many environments where such a thing makes no sense and would just a liability for whoever implements the standard library. Do you thing a hash table would be of any use on a microcontroller with 8KB of flash memory?

open-std.org/jtc1/sc22/wg14/www/docs/n2030.pdf

C lambdas proposal

>having a feature means being forced to use it.
Won't you Cniles ever get over this?

You clearly don't understand the design of C.

Useful. Why not make an annex with "useful but not compulsory" features - strllen, strllcpy, pascal string functions, common datastructures, etc?
Microcontrollers don't need the whole standard library. There are file system and networking features too, read the specification

>INT_MAX is a macro
>sizeof is an operator
>alignof is either an operator or macro function
defend this

C won't even keep VLAs mandatory, why do you think they would add anything actually useful to the standard library

>mandatory
Who cares? They should still be standardized, even if optional.

>Useful. Why not make an annex with "useful but not compulsory" features - strllen, strllcpy, pascal string functions, common datastructures, etc?
it would just turn into sepples

>>having a feature means being forced to use it.
He's just a dumbass. The real reason why C will never have a hash map is that the people who really have to use C and need a hash map are never going to use a standard implementation of one. They're going to use one that's crafted and fine-tuned specifically for their purposes, or even have several specialized hash map implementations for different use cases in the same project. A standard implementation of any non-trivial data structure is going to be sub-optimal for all use cases.

This is correct. If you're in a situation where you don't need to hand optimize absolutely everything, you're just going to use sepples instead.

>There are file system and networking features too, read the specification
No, there certainly aren't. Don't confuse POSIX or whatever with ISO C.
>strllen, strllcpy, pascal string functions
Unnecessary bloat which is completely incompatible with everything that's already out there.
Massive standard library duplication.
>common datastructures, etc
With the somewhat harsh requirement for something to get into C (although sometimes not harsh enough; shit like annex K slipped in), it's extremely unlikely that something like this would ever get in.
It needs to be
- easy to implement
- efficient
- not lead to "surprising" code generation (e.g. C++ templates)
- doesn't break existing code
It also breaks the precedent of the C library never calling malloc for you.

I'm working on a parser. Should validation happen while trying to parse or should it validate the syntax before parsing?

"validating" what?
If you're talking about semantic analysis, that should happen after parsing.
You also don't "validate" syntax; that's going to happen during lexing/parsing anyway.

>Should validation happen while trying to parse or should it validate the syntax before parsing?
How can you validate the syntax before trying to parse? It sounds like you're confusing validation of tokens (which should be done beforehand) with validation of syntax. Are you mixing together the lexing phase with the parsing one?

Listen boyos, I'm a noob to programming parsers. I just need to check if the brackets and stuff are correct and then create some kind of object tree.

Just parse shit, then. If the syntax is invalid, the parser should fail anyway.

>I just need to check if the brackets and stuff are correct
That's done during parsing. If the parser is expecting a closing bracket but there is none, you throw an error etc.

>no I was just curious if it can be done and if yes what's the simplest code it could be achieved with

sorry for the wait. if you're still around:

yeah, this is technically doable. it's kind of a doozy, though. the double brace thing isn't bad, you just have to add a constructor that initializes the wrapped tuple by perfect-forwarding the arguments. the structured binding bit is uglier, since it potentially decouples the bindings from the structure of the object (given that i'm honestly kind of surprised it's allowed at all). but the standard does allow it, by letting the user supply specializations of std::tuple_size, std::tuple_element, and then defining a get() function it looks for and tries to resolve with argument-dependent lookup:

template
struct ret
{
std::tuple data;

constexpr ret(Ts&&... args) :
data {std::forward(args)...} { }
};

template
constexpr decltype(auto) get(T&& r) noexcept { return std::get(r.data); }

/*
hoping by using a forwarding reference and decltype(auto) above this allows us to
avoid defining four separate functions for non/const lvalue/rvalue references like std::get
since they'd all call std::get anyway but i admit i'm not certain if this is will work correctly in all cases
*/

namespace std
{
// tuple_size specialization
template
struct tuple_size :
std::integral_constant { };

// tuple_element specialization
template
struct tuple_element {
using type = std::tuple_element_t;
};
}

ret fun()
{
return { false, 5, 2.0f };
}

int main()
{
auto [b, i, f] = fun();
// ...
return 0;
}


so, uh... yeah. i'd probably just use std::tuple (or an alias of it if you want a distinct name for expressing intent)

>No, there certainly aren't. Don't confuse POSIX or whatever with ISO C.
stdio.h
>Unnecessary bloat which is completely incompatible with everything that's already out there.
Would just be strnXXX(s, s-sizeof(size_t)), we already have parts of it in memXXX family. strlXXX was close to standardization but strXXX_s.won out. There already is wchar_t everything.

>It also breaks the precedent of the C library never calling malloc for you.
Can be done without. And standard library does call malloc.

alright, thanks

>stdio.h
This doesn't actually imply the presence of a filesystem. "filenames" are implementation defined, and an implementation could map them to be just about anything.
There are no networking functions in stdio.h.
>strXXX_s
Annex K is fucking shit, and basically everyone agrees so.
>Can be done without
How on earth are you going to have a dynamic data structure work without dynamic memory allocation?
>And standard library does call malloc
The ISO C standard library does not. The POSIX C standard library does.

C++ should be banned from this thread with its offensive eyesores. C++ is not programming-related.

condit =
+ ( board(1,1) .eq. board(1,2)
+ .AND. board(1,2) .eq. board(1,3).and..not.(board(1,1).eq.'-'))
+
+ .OR. ( board(2,1) .eq. board(2,2)
+ .AND. board(2,2) .eq. board(2,3).and..not.(board(2,1).eq.'-'))
+
+ .OR. ( board(3,1) .eq. board(3,2)
+ .AND. board(3,2) .eq. board(3,3).and..not.(board(3,1).eq.'-'))
+
+
+ .OR. ( board(1,1) .eq. board(2,1)
+ .AND. board(2,1) .eq. board(3,1).and..not.(board(1,1).eq.'-'))
+
+ .OR. ( board(1,2) .eq. board(2,2)
+ .AND. board(2,2) .eq. board(3,2).and..not.(board(1,2).eq.'-'))
+
+ .OR. ( board(1,3) .eq. board(2,3)
+ .AND. board(2,3) .eq. board(3,3).and..not.(board(1,3).eq.'-'))
+
+
+ .OR. ( board(1,1) .eq. board(2,2)
+ .AND. board(2,2) .eq. board(3,3).and..not.(board(1,1).eq.'-'))
+
+ .OR. ( board(1,3) .eq. board(2,2)
+ .AND. board(2,2) .eq. board(3,1).and..not.(board(1,3).eq.'-'))

how do i stop being retarded

javascript scripters need to go back to /wdg/

>javascript scripters need to go back to /wdg/
I don't see any here. All I see is your abominable sepples spam.

>alignof is either an operator or macro function
wrong
>defend this
no need, you don't know C

make an array of winning boards and iterate?

Are you trying to tell me this
condit= winbrd(1) .or. winbrd(2) .or. winbrd(3) .or. winbrd(4) .or. winbrd(5) .or. winbrd(6) .or. winbrd(7) .or. winbrd(8)

so that it's shorter?
Or am I still not cured of my disabilities

it's two characters for a reason. you know you can put things inside the "[]", right?
you can capture from enclosing scope by value or reference. also less people know about this but you can initialize new state scoped to the lambda, and you can even mutate that state if the lambda is mutable-qualified

int main()
{
auto foo = [i=0]() mutable { std::printf("%d\n", i++); };

foo();
foo();
foo();

return 0;
}


0
1
2

Stop making shitty excuses, fuckboi.
C++ objectively has horrible syntax.

in what other language with lambdas do you need to explicitly capture lambda variables?

anyway that's not the biggest problem with sepples lambdas, main issue is that there isn't something akin to interfaces to make storing one persistently efficient. Closest you have is std::function, which stinks.

>How on earth are you going to have a dynamic data structure work without dynamic memory allocation?
the same way it can be done for lists and trees
github.com/freebsd/freebsd/blob/master/sys/sys/queue.h
github.com/freebsd/freebsd/blob/master/sys/sys/tree.h
>The ISO C standard library does not
where do you think fopen returns you an allocated object from?

>in what other language with lambdas do you need to explicitly capture lambda variables?
All the other languages with lambdas are GC shit, so they don't care about lifetimes and references. The only exception being Rust, but it has the borrow checker so it can figure it out by itself.

that's some other person. i'm the one who wrote the code

and i was answering a question regarding obscure functionality which happens to be pretty ugly. he simply wanted to know if it was possible to do it that way. realistically you would just do multiple return like this:

std::tuple fun()
{
return { false, 5, 2.0f };
}

int main()
{
auto [b, i, f] = fun();
// ...
return 0;
}


doesn't get much simpler than that

I'm curious how Rust handles variable capture actually. Is it documented anywhere?

Either way, traits make closures in Rust saner than C++.

>I'm curious how Rust handles variable capture actually.
It either moves the variables into the closure (making them unusable outside of it) or "borrows" them (stores references), making the closure mostly useless. It's not much better than the GCC extension for nested functions.

But your toaster doesn't have anything vaguely resembling a file, file system, or stream. Just the "basic" stdlib (what's required for freestanding)

business idea
base e floats
worst of both worlds

doc.rust-lang.org/1.20.0/book/second-edition/ch13-01-closures.html
The compiler tries to capture by reference if possible, but you can mark the closure with `move` keyword to tell it to capture everything by value.

1-3 cobol be
4-5 scala middle ware
6-7 osx cli
8-9 wangblows cli
0 spamming job offers

> It's not much better than the GCC extension for nested functions.
Nested functions don't have their own context, they aren't closures.
> "borrows" them (stores references), making the closure mostly useless
False, you can use closures with captures by reference for lots of things, the standard map/filter/fold stuff for example. Sure, code accepting such a closure can't save it to call it later, but that's exactly the point of borrow checker.

Why is memory management needed? Why not just double indirection? Malloc returns void**, OS can move around memory area and change second ptr

Who and when frees the memory tho?

>Nested functions don't have their own context, they aren't closures.
In gcc they are.
#include

int (*closure_generator(int x))(void)
{
int lambda(void)
{
return x * x;
}
return λ
}

int main()
{
printf("%d", (*closure_generator(10))());
}

free takes void** too, OS then frees

#define malloc(...) ((void*)NULL)

Friendly reminder that the C specification allows for this.

>relying on malloc
I hope you know how to use VLAs.

>Handles were a popular solution tomemory managementin operating systems of the 1980s, such asMac OS[1]andWindows. The FILE data structure in theC standard I/O libraryis afile handle, abstracting from the underlying file representation (onUnixthese arefile descriptors). Like otherdesktop environments, theWindows APIheavily uses handles to represent objects in the system and to provide a communication pathway between the operating system anduser space. For example, a window on thedesktopis represented by a handle of typeHWND(handle, window).

>Doubly indirecthandles have fallen out of favour in recent times, as increases in available memory and improvedvirtual memoryalgorithms have made the use of the simpler pointer more attractive. However, many operating systems still apply the term to pointers to opaque, "private"data structures—opaque pointers—or to indexes into internal arrays passed from oneprocessto itsclient.

You're 30 years too late

1. Your code doesn't compile godbolt.org/g/FYKgoH
2. Even if it did, the documentation says nothing about making a closure, your code would fail since it would try to access x from the stack where it's no more. It's like returning a pointer to an argument.

it's far better than it used to be. and it seems like a lot because it allows you to express more in terms of semantics. when languages have simpler syntax it's generally because they simply lack some of the semantics which C++ supports. but that also makes them less effective

>in what other language with lambdas do you need to explicitly capture lambda variables?
see above. the functionality of captures is meaningful in many ways. lambdas which don't capture, for example, can decay to function pointers; ones which capture can't, because they are accompanied by state, and passing them through a function pointer would sever that state. capture by value is often a straightforward way to achieve efficient thready safety. also, you do not have to explicitly capture every variable. you can use "[=]" or "[&]" to automatically capture any odr-used object from enclosing scope by value or reference respectively. or you can use a mixture of objects captured by value and reference. or you can initialize state local to the lambda. without some such syntax, a language simply can't support the same level of functionality

>main issue is that there isn't something akin to interfaces to make storing one persistently efficient
>Closest you have is std::function, which stinks
std::function is less than ideal, to be sure, though no matter what some overhead would be incurred when implementing a type which generalizes function pointers, stateful lambdas, pointer to member data/function, and possibly has to manage lifetime. you can often simply store a function pointer (when dealing with stateless lambdas), or store by value with a template:

template
struct foo
{
F func;
// ...
};

So you still need to manage your memory, what's the point then? Also, indirect pointers destroy performance on modern CPUs, since they break cache locality.

I want to do stuff with microcontrollers. What do I buy and from where? Aliexpress? Would be nice to have fast pwm and clock/timer.

>Nested functions don't have their own context, they aren't closures.
Non-moving Rust closures can't access anything from their lexical scope after the function returns, just like the GCC extension, so they're pretty much useless as "closures".

>you can use closures with captures by reference for lots of things, the standard map/filter/fold stuff for example
You can do the same with the GCC extension.

Why are you using a C++ compiler? It's complaining that you're using a nested function, which isn't permitted by g++.

You're right though, x has gone out of scope at this point.

You are responding to one of your false-flagging Rust buddies. See for a legitimate response.

Define "Systems programming language"

no generics

Yeah Ali is pretty good for cheap dev boards.
The 2$ STM32 boards are pretty nice unless you want to program it in assembly then you're better off with something simple like a 8-bit PIC or AVR.

Keep in mind you also need a 2$ STlink adapter to flash it (a USB-TTL adapter/Pi can also be used but it's more hassle).

I guess it's really true that C is a brainlet language for brainlet retards.

>Better than C++'s [] syntax
You mean 1000000000000000000x worse.
^ makes zero sense and it's ugly trash.

Try again.

>Define "Systems programming language"
A suitable for (and, preferably, designed for) systems programming.

Define "Systems programming"

>Define "Systems programming"
Programming the infrastructure of a system, as opposed to user-facing applications.

>Why are you using a C++ compiler?
I'm compiling with -std=gnu11, which is C11 + gnu extensions.
>Non-moving Rust closures can't access anything from their lexical scope after the function returns, just like the GCC extension,
Well, ok, they are somewhat similar in this respect. The obvious differences are 1) the compiler won't allow you to use it outside the scope 2) Rust's closures are passed via generic arguments, making them inlinable and optimizable, while whatever C does it's stuck with inherently inefficient function pointers.
> so they're pretty much useless as "closures".
How are they "useless" if you can use them with map/fild/filter etc. just fine?