/dpt/ - Daily Programming Thread

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

Other urls found in this thread:

en.wikipedia.org/wiki/Self-modifying_code
github.com/robpike/filter
bbc.com/news/av/world-asia-40852480/japan-s-golden-coder-making-games-apps-aged-82
youtube.com/watch?v=2UC6_rfJuAw
twitter.com/SFWRedditVideos

C is a shitlang

Please never start this pretentious retarded thread again. Thank you.

A sufficiently smart compiler (or a dumb one with sufficiently annotated code) could easily know that instantiations of certain type parameters won't affect the compiled code and thus can be used in higher rank polymorphic situations. For example:
fn higher_rank_id(x: &T) -> &T {
x
}

Monomorphization has no effect on this function, so it should be possible to pass it around without instantiating T.

How much do you get paid in your Haskell jobs?

I work for food.

Tendies?

Or you can just wait for the linker to merge duplicate functions without inventing ad-hoc semantics for edge cases.

nigga you don't understand

Reposting from the last thread.

Is it possible to detect whether libstdc++ has been linked into the program using my library and then fuck shit up if it has?
I don't want subhuman trash using my library.

Perhaps look into a technique that was used in virus programs / rootkits... Scan your own program's memory and then modify it to break if you detect libstdc++

I don't think you need to be worried about anyone using your library

It already has users, though.
I might want to add detection of the rust standard library as well, whatever that is called.

Rust libraries are usually statically linked tho.

en.wikipedia.org/wiki/Self-modifying_code

Mix this technique with some sort of heuristic analysis used on your own program's memory space and it should be possible as I stated earlier...

Actual implementation depends on the platform and is probably going to be a royal pain. But if you're that stubborn there is a way to achieve it.

I'm assuming that you're talking about statically linking the libraries not dynamically.

I think if you get dlsym with null library it will search the current program for symbols.

You won't have to worry about people using your library once they found out you made that change, though.
I don't think even the Cfags will appreciate you doing retarded unnecessary hacks and memory scans.
Just stop being retarded.

>I don't think even the Cfags will appreciate you doing retarded unnecessary hacks and memory scans.
if it fucks sepples user, I approve.

I don't like libraries unnecessarily wasting CPU cycles, so I don't.
I think this just makes C users look incredibly bad.

How do I write a C library that will actually see some use? Everything easy or useful has been done.

Also, it makes you look the complete opposite of what you claim to be: efficient and simple.

Go away Bjarne. Nobody likes you.

Why should we care about the repercussions of this guy's goal being fulfilled. If they want to do a bunch of stupid bullshit for a random prejudice let them.

Any sane user will just stop using the library and anyone of like mind will not care about the extra crap.

> just makes C users look incredibly bad
Implying anybody thinks overwise, considering these retards ruined the industry with their unsafe bullshit of a language.

this.

>I think this just makes C users look incredibly bad.
It's really fault of the sepples programmers. They never export C api from their library so fuck them.

Because C api's suck and they're ugly.

>What exactly do you need templates for in low level programming?
they can eliminate a shitload of redundancy (and make things possible that would otherwise be intractable). imagine trying to write variations of types, (combinatorial) conversions, and all the various operations for 2D, 3D, and 4D vectors and 2x2, 2x3, 3x2, 3x3, 3x4, 4x3, and 4x4 matrices of signed/unsigned 8 thru 64 bit integers, float, and double

>Most data structures are tailored for specific use cases for reasons of performance
>you still can't seem to grasp that "optimized data structures" are optimized for a given purpose
it's quite possible to tailor/optimize a templated data structure for range of potential types in the same way. there are plenty of times when a section of code is already optimal despite type parameterization (or can be made so given data from compile-time computations based on template arguments), at the very least for the range of types you expect/allow (if this the case, make it your default case). then you can use template specialization for further tuning of specific cases as needed. for example, you could define default templates to cover the range of vector/matrix types mentioned above for the general case, and then specialize certain cases to use SIMD operations where applicable based on element type and dimension. it'll be an absolute shitload less code than not using templates, while performing just as well in any given case

I find it baffling that C++ bases so much of its existence around being backwards compatible with C yet it's not 100% backwards compatible and there's no standard for using a C++ API from C (such as generating structs for vtables and macros for templates).

>they can eliminate a shitload of redundancy (and make things possible that would otherwise be intractable). imagine trying to write variations of types, (combinatorial) conversions, and all the various operations for 2D, 3D, and 4D vectors and 2x2, 2x3, 3x2, 3x3, 3x4, 4x3, and 4x4 matrices of signed/unsigned 8 thru 64 bit integers, float, and double
easily done with macros, see any linear algebra library.

>generics are useless for low level code because macros exist
Okay grandpa.

>there's no standard for using a C++ API from C.
That would be forward compatibility.

Oh, true. They should have gone for that, too.

>easily done with macros
Ok now specialize those macros. Oh and make it not disgustingly ugly.

>implying templates are not disgustingly ugly
Fuck you sepplesfags are just the absolute worst.

>they can eliminate a shitload of redundancy (and make things possible that would otherwise be intractable)
You keep stating this, but zero examples have been given so far.

>imagine trying to write variations of types, (combinatorial) conversions, and all the various operations for 2D, 3D, and 4D vectors and 2x2, 2x3, 3x2, 3x3, 3x4, 4x3, and 4x4 matrices of signed/unsigned 8 thru 64 bit integers, float, and double
Imagine finding out that this has nothing to do with low-level programming. Just another instance of the Rustlet's inability to provide a legitimate example of its claims.

>it's quite possible to tailor/optimize a templated data structure for range of potential types in the same way
Still waiting for any evidence of these claims. You're going to be the 4th or 5th shill who fails to do so today.

vtables were a stupid idea anyway, if C++ just differentiated between concrete and dynamic types this wouldn't be a problem
struct Sepples;
Sepples *ptr; // points to actual Sepples
virtual Sepples *ptr // points to Sepples or some class extending Sepples
No more intrusive vptrs so you can inherit from ABCs without data members at no cost and implement a stable struct layout for C ABI. And also less unnecessary dynamic dispatch for member functions.

templates are not as ugly as macros

Write a library that you yourself want to use. If it's useful and high quality enough, other people might start using it.

Go home, SJW scum.

>C-tards failing to comprehend generics, again
I'm still waiting for them to produce both optimal and generic implementation of a sorting algorithm.

reminder that std::sort outperforms qsort

#ifdef __cplusplus
#error "This language is not supported"
#endif
If your header files don't contain this, your library is trash.

Reminder that stdio massively outperforms iostreams.

#undef __cplusplus
#include "anons_shitty_lib.h"
#define __cplusplus

spotted the fizzbuzzer

lucky that sepples has both

Man, I'm really enjoying Go. It has some really nice ideas and language features. I don't understand why people hate on Go for not having generics when interfaces are basically generics (I think interfaces are pretty cool.)

>Imagine finding out that this has nothing to do with low-level programming
What, you've never done graphics programming on a low level?

Also, Rust "templates" can't do everything he's claiming. C++ templates can though.

Interfaces aren't generics.

Bait.

I'm 30, is it too late to learn programming?

/* anons_shitty_lib.h */
static fn() {
int tmp, *p = &tmp;
char *xoxoxo = tmp;
printf("checkmate sepplesfags\n");
}

Go has features?

But they basically are.

>when interfaces are basically generics
go programmers, everyone.

Isn't this just demonstrating how shit C's type system is?
I wouldn't want to use such a library in the first place.

#ifdef __cplusplus
#error "This language is not supported"
#endif

static inline void dummy(void *arg) { int *val = arg; }

No. But it'll be uphill. Just like learning a spoken language is uphill when you're not a kid anymore.

That's a completely retarded analogy.

No.

kek

Can you show me a generic map function in Go?

I wouldn't want to use a library that implicitly casted a void* to an int* in the first place.
Your library is most likely shit.

You're fucking retarded.

extern void foo(void) __attribute((weak));

if (&foo != 0) {
// foo was linked in, call it
foo();
}

Now do this with some sepples fuction.

github.com/robpike/filter

/dpt/-chan, daisuki~

bbc.com/news/av/world-asia-40852480/japan-s-golden-coder-making-games-apps-aged-82

she learned to program in Swift by herself at +80 years old and is now rich.

Sepples functions are mangled, and the mangling is not standard.
So good luck with that.

>I just think it's reasonable to expect that + will always be associative and commutative, that * will always be associative, that * always distributes over + when they can be used together, and that 0 and 1 are the respective identities when the type has those constructors.
i guess generally, sure. and that's how it's been with basically everything i've seen (where applicable), with the exception of + for string concatenation, which i don't personally have a problem with. there ought to be some way to concatenate them without nested or chained calls, at least

it was a simple/illustrative example, dumbshit. the point is obviously that the concept translates to a shitload more than that

macros are semantically-unaware and error-prone, specialization would be ugly/difficult and introduce redundancies, the "code" would be primarily made up of macros and very difficult for a user to navigate, and such an approach would still be ultimately non-generic and wouldn't scale to other code like a C++/templates approach could if desired

i'm not the same guy you were talking to before. i'm not even talking about Rust, i'm talking about C++. though i imagine it's pretty similar, at least in this context. and i just gave you an example, you moron. did you even read it?

>interface{}
Next you'll tell me that void*s are generics.

There's only gcc, clang and some microshit compiler that people use because sepples such cluster fuck nobody even wants to write compiler to it so getting those 3 different function names isn't that hard.

it is, given that they can't stay constant between compiler versions

just use extern "C" if you need to link in this manner

IAR C/C++ Compiler
Intel C++ Compiler
Zapcc
Solaris Studio
Edison Design Group C++ compiler

>just use extern "C" if you need to link in this manner
It doesn't work like that.

you have to find the mangled sepples symbol so you can abort the execution or call rm on every file the user has write access to fuck only sepples users over.

>there ought to be some way to concatenate them without nested or chained calls, at least
For sure. I like ++ in Haskell. I'd even be fine with * because it's the go-to notation for the operation of an arbitrary monoid.

Are monads related to rings (as in algebraic ring theory)?
If so, how?

Wew that burn at Rust youtube.com/watch?v=2UC6_rfJuAw

Tangentially. Categorically, a monad is a monoid of endofunctors. return is the identity (Id -> M) and join is the operation (M * M -> M). These arrows are both natural transformations, so in Haskell, you get the expected:
// Id(A) = A
return :: a -> m a
// (M * M)(A) = M(M(A))
join :: m (m a) -> m a

A ring is an Abelian group and a group plus distributivity. A group is a monoid plus an inverse operation.

>no time code

Iirc it's actually clang/gcc and Microsoft. Not clang, gcc and Microsoft.

It's at 1:18.

I should learn what all this notation means some time.

>Rustlets shitpost everywhere enough to get a mention in a talk
wow

Category theory can seem impenetrable at first but once you understand what a category is, what an object is, and what a morphism is, it all kind of comes naturally. All the jargon like functors, endofunctors, natural transformations and whatnot can be expressed in terms of these simpler concepts (a functor is a morphism between categories, an endofunctor is a morphism from a category to itself, a natural transformation is a morphism between functors).

Sweet, off to some tutorials i am then.

Many years ago when I was a Haskell-fanboy I spent some time reading on CT. It's not that hard, once you get used to the jargon, but in the end, it felt like a waste of time. Sure, I was able to understand that monad is just a monoid in the category of endofunctors, but there was no practical use for that knowledge.

hm. those seem like they'd feel a bit out of place in an imperative language. ++ wouldn't even be possible in C++, because it's only a unary operator. and * doesn't mean anything quite so general in C++, however it does already carry a few distinct meanings (making it one of the more ambiguous symbols), one of which is dereferencing a pointer. so if you had pointers to strings and wanted to concatenate their dereferenced values (which probably wouldn't be an uncommon case), it'd look a bit wacky

string* s1 = ... ;
string* s2 = ... ;
string* s3 = ... ;
string s = *s1 * *s2 * *s3;

~ makes the most sense.
++ is objectively shit.

Please use a different pic for the /dpt/ thread because the pic feels very homosexual with socks, smooth legs, and super short shorts

...

Haskellfags btfo

When should I use C++ over Python?

When your program is CPU-/memory-bound, as opposed to IO-bound.

self taught CNC programmer
trying to learn C# and .Net

would potential employers consider CNC experience as real programming?

When the performance from C++ is required or when your restrictions require very heavy reasoning and optimization (Memory requirements, very strict requirements on number of cpu cycles to perform operations, etc)

A lot of the time you're probably better off either writing a module used by python in c++ or embedding python depending on what exactly you're doing.

Category theory is all about relating seemingly unrelated parts of mathematics to reuse proofs. This is notable when it comes to programming because, under the right conditions, proofs are programs. While the monoid/monad correspondence itself is not all that useful unless you are using dependent types and writing actual proofs, it hints at the existence of things that are like monads which you get from interpreting things that are like monoids in the same way. Like, what if you had a *group* over endofunctors? That might be a useful abstraction. Category theory is basically generic programming taken to the extreme. I find that quite cool. Of course, if you are using dependent types, the direct application of category theory to proof reuse is also attractive.

Also, if you plan on understanding academic papers about cutting edge type systems, you'll probably need to know category theory because it's the common language of type theories. If I had a nickel for every time I saw the word "presheaf"...

>What, you've never done graphics programming on a low level?
Why do Rustlets always lie about their knowledge? Graphics programming does not involve "2D, 3D, and 4D vectors and 2x2, 2x3, 3x2, 3x3, 3x4, 4x3, and 4x4 matrices of signed/unsigned 8 thru 64 bit integers, float, and double". 95% of the operations are between 3D vectors and other 3D vectors or 3D vectors and 4x4 matrices with float components.

Is it just me, or basically all programming nowadays involves just the following:
>find a shitty library that does the job for you
>mix some calls to it in you're code
>done

>not sure how to approach project
>just generate a load of generic code using templates
>get bored then move on

No one here is talking about Rust you fucking retard, are you even paying attention? We're talking about C++ here.