/dpt/ - Daily Programming Thread

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

Other urls found in this thread:

github.com/enfiskutensykkel/ssd-gpu-dma/tree/api-rewrite
m.youtube.com/watch?v=eg8HsJm9ynk
en.m.wikipedia.org/wiki/Formal_verification
internals.rust-lang.org/t/pre-rfc-catching-functions/6505
godbolt.org/g/S9K7Xa
godbolt.org/g/9b927v
twitter.com/SFWRedditGifs

Orthodox C++!!

why tho

Threadly reminder.

Have exam in 3 hours. Wish me luck /dpt/

>rust is like Haskell with manual me-

Daily reminder that
Monadic error handling(Haskell, Rust) > Exceptions (C++, Java, etc.) >>> Returning error codes (C, Go)

Are you sure it's not in 4 hours?

good look astolfo

Moandic error handling (Haskell, Rust) > multiple return (Go) > exceptions (C++, Java) > single return with out parameters (C)

what's wrong with lisp?

Fake and gay. The original is based on actual scientific data.

Is it guaranteed that identical value passed to srand() will causing rand() generate the same output everytime?
Also what is time_t?
How to generate a time_t from an int?

>rust is like Haskell with manual memory management
Whom are you quoting? No one said that. Rust is like Haskell without GC.

I am but a pea brain, so I'm building a function that takes a Lo Shu Magic Square function that takes a 3 by 3 array
and sums it by row, col, and diagonally, then tells the user whether it's a magic square or not.
Still working on the diagonal summing as well as how to express the if else to decide whether it's a magic square or not.
Maybe I'll return it as a bool.
void loShuMagic(const int numbers[ROW][COL])
{
for (int x = 0; x < ROW; x++)
{
int sum = 0;
for (int y = 0; y < COL; y++)
{
sum += numbers[x][y];
}

}
for (int y = 0; y < COL; y++)
{
int sum = 0;
for (int x = 0; x < ROW; x++)
{
sum += numbers[x][y];
}
cout

i showed you my Coq answer me

...

Threadly reminder that type theory is a cult.

I'm trying to learn how to write formally verified software using a proof assistant called coq. I'm not even joking. Unfortunately, that requires some math, and math is hard.

That's great, but then how do you know that you didn't introduce a bug into your coq program after going through all that trouble? :^)

Rails/Django/Golang/Node are finished

Elixir/Phoenix is the future and there's nothing you can do about it

> multiple return (Go)
1. Multiple returns in a language created in the 2000s is an embarrassment, all the modern languages have actual first-class tuples.
2. Multiple returns don't help with the retarded error handling, it's not that different from errno in C. You still have to check them after each call and there's nothing preventing you from implicitly ignoring the error.

>What are you working on, Sup Forums?
Redesigning my API, making it more convenient to use and a lot more comfy to extend in the future.

github.com/enfiskutensykkel/ssd-gpu-dma/tree/api-rewrite

Nothing, it's just dead. Lispers are obnoxious tho.
He's retard.

Adding this to the summing loops

if (sum == 15)
flag = true;
else
flag = false;

I agree that multiple returns is a result of Go being designed by a handful of UNIX dinosaurs that clearly haven't been keeping up with programming language theory the last 30 years, but:

>You still have to check them after each call and there's nothing preventing you from implicitly ignoring the error.
Doesn't the compiler cry out loud if you leave an error unchecked?

flag = (sum == 15)

Math is harder to fuck up then code, which coq generates for you. I'm a bit new to the subject, so don't ask me for expert advice, but there was a nice presentation on it at 34c3. m.youtube.com/watch?v=eg8HsJm9ynk

>1. Multiple returns in a language created in the 2000s is an embarrassment, all the modern languages have actual first-class tuples.
This is correct and actual tuples are better. We share no disagreements here.
> Multiple returns don't help with the retarded error handling, it's not that different from errno in C.
Errno is the bottom of the barrel, far worse than returning error codes.
>You still have to check them after each call and there's nothing preventing you from implicitly ignoring the error.
This is why monadic error handling is superior. That said, it's much easier to ignore a thrown exception than it is to ignore a return value. Explicit > implicit.

The compiler complains about unused variables so you have to explicitly dump it with _. It's still sorta fucked because you can reuse a previously declared err to get around the handholding.

both are implementation specific, I believe while you may be getting the same rand() output on one machine/with one compiler it may be different on another, as for time_t it's a numeric type so you should be assign an int to it as-is

Thanks.

>That's actually the mascot
Now I'm interested.
But it seems that it requires emacs.

Just realized you probably won't watch an hour video, so here's a Wikipedia article you lazy fuck. en.m.wikipedia.org/wiki/Formal_verification

unlikely because with all the former solutions you can have a literal brainlet develop web backends

>Is it guaranteed that identical value passed to srand() will causing rand() generate the same output everytime?
No

>Also what is time_t?
Usually a typedef'd integer type, but the formal answer is a suitable format for representing number of seconds since epoch.

>How to generate a time_t from an int?
You shouldn't, you should rather use relevant time functions.

You're just going through extra effort to move the problem somewhere else. Coq won't catch flaws in the program spexlc, only trivial mistakes which shouldn't be a problem in the first place.

>she

>That said, it's much easier to ignore a thrown exception than it is to ignore a return value
Depends on the language, user. Java requires exception declarations to either be thrown or caught.

There is a different IDE that's installed with Coq. It doesn't come with a waifu though.

Java is the only language I'm aware of which uses checked exceptions. I guess you could call it ghetto monadic error handling, but it's still a pain in the ass to read through code with possibly-throwing method calls and understand the control flow graph.

>Is it guaranteed that identical value passed to srand() will causing rand() generate the same output everytime?
Actually, yes it will. That's kind of the whole point of seeding your own number.
It might not be the same numbers across different implementations, though.

>Java is the only language I'm aware of which uses checked exceptions
So, would you say that Java is the ... exception ? hue hue hue

I was mistaken, you are correct.

>github.com/enfiskutensykkel/ssd-gpu-dma/tree/api-rewrite
I'm a brainlet, what is this?

there's literally a giant ass readme that explains

Say in a same machine i have this code
srand(12);
int a=rand();
int b=rand();
int c=rand();

Is it guaranteed by the specification no matter how many times I run the program, the value of a, b, and c will be the same?

I believe it to be a mistake. Exceptions should represent exceptional circumstances and not be used for results that are anticipated and often expected (see: python iterators)

>Exceptions should represent exceptional circumstances
It literally is though. Exceptions allow the programmer to write code assuming the successful code path (and, similarly, allow the compiler to optimize for the successful code path).

...

>yfw OCaml and C++ handle all of these elegantly

I would not call C++-style maybe's (i.e. boost::optional) are "elegant", but it is certainly possible to implement them in C++.

I should've said flawlessly

C++ handles them all, but not elegantly.
// Suitable for error handling, but not the general case.
// Can't have multiple variants of the same type - prepare to make a bunch of shitty wrapper objects.
// Matching syntax is garbage.
std::variant monad();

// Might have to construct an expensive T pointlessly.
// Unwrapping syntax is garbage.
std::tuple multiple();

// No idea what it may throw, what I will have to catch
T exception() noexcept(false);

// Can't construct an object unless you maybe use a pointer and placement new.
// Also out parameters in general are unwieldy.
E cstlye(T &out);

Based sepples.

>No idea what it may throw, what I will have to catch
I really wish that sepples had exception specifiers in signatures, preferably making it mandatory to catch them or re-throw them.

at least not shilling for languages that doesn't even exist anymore (lisp)

include for time function
unsigned seed = time(0);
srand(seed);
cout

Hey guys, I'm a sysadmin in Yurop. What programminglanguage you think I should learn and why? I'm maintaining windows and linux systems usually.
I'd appreciate the help!

>windows and linux
Unironically, Python

Would be most useful in your job.

It did, but it was only enforced at runtime because the compiler could not reason about might be thrown. That is to say:
void foo();
void bar() throw(FooException)
{
foo(); // the compiler doesn't know that foo might throw
}

Trying to retrofit compiletime exception checking to C++ wouldn't work without a shitton of breaking changes.
Just use std::variant. Exception checking is backward-thinking. If you want it to be declared in your signature, make it a return type or parameter - if you don't, make it an exception. It's in the name, exceptions shouldn't be common cases.

Thanks a lot man! That's what I thought too but I wasn't so sure about it because everyone says it's shit. I'd only need something to automate things.

C++ can't handle monadic error handling tho. Sure, you can "emulate" it, but there's nothing stopping you from ignoring the error case and just trying to use the value, not until the runtime. Also, there's no sugar for early return.

That's what Python's good at. Maybe perl if you're doing a lot of text shit too.

>wasn't so sure about it because everyone says it's shit.
General advice: don't listen to Sup Forums.

>I'd only need something to automate things.
Python would be nice for this.

> the following setence is a lie
> the previous setence is a lie

>Sure, you can "emulate" it, but there's nothing stopping you from ignoring the error case and just trying to use the value, not until the runtime.
If you remove std::get and alternatives and only implemented std::visit, there'd be no way to access a variant that isn't the actual value.

>error handling
Check out this pre-RFC: internals.rust-lang.org/t/pre-rfc-catching-functions/6505 , I kinda like the idea, but I don't like them reusing the keywords from exception-handling tradition with different semantics.
throw $expr return Err(From::from($expr))

// All `?`s and throws will convert into io::Error
catch io::Error {
function()?;
throw expr;
}

fn foo() -> i32 catch Error {
if bar() {
// Ok wraps explicit returns
return 0;
} else if baz() {
// Err wraps throws
throw MyError;
}
// ? works
quux()?;
// Ok wraps final return
7
}

It's a riddle.

>nothing is stopping you from shooting yourself in the foot if you go out of your way to break idioms
Sure, user. But that's the philosophy of sepples in the first place.

>don't listen to Sup Forums.
If I didn't listen to Sup Forums, then should I listen to you?

You should preferably investigate yourself.

>std::
The fact that the std lib implementation doesn't allow some behavior doesn't mean it can't be implemented. std lib is supposed to give you the most profitable tools with minimal overhead.
>Don't pay for what you don't use
Also
>Might have to construct an expensive T pointlessly
not anymore

1st sentence :"The following sentence is a lie"
2nd sentence : "previous sentence is a lie"
Do what the 1st sentence ask for will modify the second sentence to:
"The previous sentence is not a lie"
And there fore the first sentence is true and all premise is true. It's only a tautological premise

You're making a very vague post.
>The fact that the std lib implementation doesn't allow some behavior doesn't mean it can't be implemented.
What behavior are you talking about?
>Might have to construct an expensive T pointlessly
How would you avoid constructing T in the tuple case?

yeah, no.

What the fuck is the matter with Microsoft?

It's like type hell. There are types withing fucking types stop this shit. STOP

Any small project ideas to start programming in python?

get fucked brainlet

typelet

identify child pron in google

>They used Hungrarian notation for names
>The names are all wrong because they wrote them all back during 16 bit Windows but can't change the names because of backwards compatibility
>InitializePrintProvidor and PRINTPROVIDOR will never be changed because of this either
>HMODULE is just a pointer to the beginning of the header and therefore has no reason to exist as distinct type
>Half of your 64-bit .dlls are in system32
>Enabling the EnableJITcompileOptimizer disables the JIT compiler optimizer and vice versa

godbolt.org/g/S9K7Xa
C++ is shit.

What are you even trying to do? Of course, the result of a method call on an extern not-constexpr value won't be constexpr - the compiler can't possibly know the result at compile-time.

this is your mind on Sup Forums

If none of the constructors can possibly throw an exception, when would the variant be placed into an empty state?

No shit, Win32 is a legacy API in maintenance mode, just like POSIX. The difference is, MS actually provides you with modern APIs based on .NET.

What language does Hakase use?

The value is extern so the compiler can't possibly know what its value would be.

A wild Isabelle has appeared.
This shit is breaking my brain tbqh.

>Enabling the EnableJITcompileOptimizer disables the JIT compiler optimizer and vice versa

Nani?

It knows it's not going to be empty, because the variant will only be empty if an exception is thrown during move construction/move assignment. Clearly that isn't the case.
There's no way to statically check if a std::variant will be hiding an empty state. Just another shitty spec.

It's an extern symbol so it can't assume anything. But yeah, even if it wasn't "extern" compiler isn't a theorem prover and can't deduce that since all the constructors are nothrow the value can't be empty.

>It's an extern symbol so it can't assume anything.
The type information is right there, the compiler has everything it needs to know. Foo(Foo&&) will not throw and Bar(Bar&&) will not throw, thus no object of type std::variant will ever enter an empty state. No further assumptions need to be made.
Why does std::variant not contain a constexpr static function that states whether an instance of this type will ever enter an empty state?

A static function wouldn't even be necessary. The compiler is smart enough to realise that if the value isn't used, a non-constexpr parameter can be passed to a constexpr function.
godbolt.org/g/9b927v
This applies to the this pointer in nonstatic functions too, so there's no excuse.

dead and the smug lisptards don't have time for coding anything in it because they spend their life proselytizing

>1. the following setence is a lie
>2. the previous setence is a lie
Assume (1) is true, (2) is false:
From (1) it follows that (2) is false. This is consistent.
From (2) it would follow that (1) is false, but (2) is false, so (1) is still true.
No contradictions.

Assume (2) is true, (1) is false:
From (2) it follows that (1) is false. This is consistent.
From (1) it would follow that (2) is false, but (1) is false, so (2) is still true.
No contradictions.

Assume both (1) and (2) are true:
From (1) it follows that (2) is false. Contradiction.

Assume both (1) and (2) are false:
From (1) it follows that (2) is false. From the falsity of (2) it follows that (1) is true. Contradiction.

So either proposition can be true, but not both. What's the problem with this?

Except the only people "proselytizing" Lisp ITT are false-flagging Haskell evangelists who are still butthurt about that one Lisp coder who called them cultists. This is literally what they do when they're not busy shilling their pet type system.

At least Haskell is active and has an industry presence.

>implying lisp is inactive
>implying haskell has a non-negligible "industry presence"
Well, you do look like a guy whose statements can be accepted as true at face value without further evidence, so I guess I'm gonna bow before the superiority of Haskell now.

>>implying lisp is inactive
>implying it isn't