/dpt/ - Daily Programming Thread

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

Other urls found in this thread:

open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0781r0.html
twitter.com/NSFWRedditImage

First for JavaScript did nothing wrong.

a reevaluation of my life

Just submitted a paper to IEEE IPDPS. Tired af after pulling an all-nighter.

Should /dptnrf/ be a thing? It would be like /dpt/ but without rustfags.

Reminder that arrays are not pointers, and that you should not use array-style declarations in function parameters.

#include
int main() {
int a[100];
int *b = a;
// Proof that they're the same thing
assert(a == b);
// Proof that they're also not the same thing
assert(sizeof(a) != sizeof(b));
return 0;
}


literally both things are true, all you brainlet plebs get out of here with your limited dichotomous definitions of sameness

>Should be a thing?

No

Reminder that newer C++ compilers really should refuse to compile if an array-style declaration without a size specifier is used in the declaration.

>// Proof that they're the same thing
Equality does not imply identity.

0 == NULL and 0.0 == 0 too, but they are not the same.

>Reminder that newer C++ compilers really should refuse to compile if an array-style declaration without a size specifier is used in the declaration.
char my_cstr[] = {'f', 'u', 'c', 'k', 'n', 'o'};

>cstr
>unterminated

Equality does indeed imply identity, the real problem here is that identity is not a logically consistent property and doesn't abide by the law of noncontradiction.

I meant in the function declaration, as part of the argument in the parameter list. But yeah, I was imprecise, my bad.

i'd fund it

>Equality does indeed imply identity,
>gender equality implies gender identity

On the contrary, arrays are pointers.
>you should not use array-style declarations in function parameters.
That's because when you pass an array, a pointer is passed to the function. Which again, proves that arrays are just pointers to its first elements.

oh
yeah that is a pretty bad idiom that offers nothing of use and just confuses matters
prime example:
#include
void test_nonlocal_size(int a[]) {
assert(sizeof(a) == sizeof(int *));
}
int main() {
int a[100];
assert(sizeof(a) != sizeof(int *));
test_nonlocal_size(a);
return 0;
}

my day job? I go into hacker news threads about C/C++ and bring up rust

you are confusing the evaluation of 'a' with 'a'

Doing gods work, user.

Actually they both are and aren't pointers and this is perfectly logical because identity doesn't abide by the law of noncontradiction.
See:

So you are comparing the size of 100 ints and a single int and calling them different?

No, he's comparing the size of an array of 100 ints with that of a pointer to an indeterminate number of ints and calling them different

Arrays and pointers consist of the same underlying data -- an address -- but that doesn't actually make them the same thing, because of semantic differences: namely an array is the const address of a statically allocated chunk of known size, and the size of the array is treated as the size of that chunk; whereas a pointer is simply any address, may vary at runtime, and may not even be valid, and its size is treated as the size of the address itself

im making a blog to detail the very small things i do and all the resources i used

i dont think anyone will read it though

Post them on HackerNews

Why do people act like there are only two memory spaces, the stack and the heap, when in fact there are three, the stack, the heap, and the data segment?

People should use static allocation more, BAKA

You are describing stack allocated arrays. That STILL boils up to the fact that arrays are pointers that are immutable pointers, (more correctly, addresses) whose size is known at the compile time.

>arrays are pointers that are immutable pointers
pointers that are immutable,* (more...

this is a gateway to static asserts, and static math expansion, constexpr and other shit that bloats up the binary.

>ITT: Cniles struggle to understand implicit conversions

Can't really blame them, when their whole language is based on it in order to work around it's shitty type system.

you would think that would cause them to try to understand it better

Real-life C programmers do.

Memeposters on Sup Forums that learned C last semester and now thing they're hot shit hasn't come to that realization yet.

>t. r/programmingcirclejerk

But then how would I write shit like this?

int somefunc(int someArray[main()]) {}

Valid code as you can put in the [] any expression that returns an int.

...

...

You got a response to this.

A response that says there are not conversion that occurs there

Yeah, because you're allocating with new. Not using a local or static variable.

>You are describing stack allocated arrays.
That's the only kind of array there is. Heap allocated memory is never an array, or more correctly, no array can exist that indexes it.

>That STILL boils up to the fact that arrays are pointers that are immutable pointers, (more correctly, addresses) whose size is known at the compile time.
>(more correctly, addresses)
No argument here. That is indeed more correct. Calling them pointers, however, is outright incorrect. An array is a kind of address. A pointer is a kind of address. They are functionally interchangeable, but only functionally; semantically, an array is not a pointer.

(cont from )
Also, the size of any pointer is known at compile time. It's simply the size of the address.

>You are describing stack allocated arrays.
What are heap allocated arrays?

No such thing. If you allocate something by calling malloc, calloc, realloc, operator new, or operator new[], that is not an array. No, not even that last one, because C++ is inconsistent and garbage.

How would you allocate an array of 999999 longs dynamically?

One of the hottest takes I've seen in a while

You wouldn't. You would dynamically allocate a 999999-long-wide contiguous chunk that can be safely indexed like an array if you make sure to call it a long * but is technically not one.

how do I make a variable sized array in C?

Let's say I have a sampled signal with the values in an array like so:
short x[102] = {x0,x1,x2,...,x101};

I need to apply a median filter to my signal, which involves a window of size N that is used to find the median at a certain point in the array.

for example, if my window size is 3 and I am looking at sample x1, then I look at
{x0,x1,x2}

find the median of the three numbers, then set that as my new value for x1. problem is, at the edge cases like x0 and x101 I can't make that window, since I will be out of bounds in the array. I need to pad either side of my signal with zeros depending on how large my window size is. So if my window size is N=5, I want to create an array that looks like
N=5;
short x[102+(N-1)] = {0,0,x0,x1,x2,...,x100,x101,0,0};


how can I achieve this?
>pic is this concept applied to a 3D image

>You wouldn't.
Ha!

Enjoy your delusion, Cnile.

Just use the heap you fucking retard.

Why are you using C for this?

Either hardcode the array size, or use malloc to create the array e.g.

short* xArray = malloc(sizeof(short) * size);
//... do something ...
// cleanup
free(xArray);

>implying any programming language other than C is valid
You can "do this" in C++, but C++ isn't a real programming language, so none of its concepts are actually applicable to this debate.

Nice blog post

>sizeof(short) * size
>not sizeof(short[size])

Daily reminder that 1 based arrays are superior for anything algorithmic. Even Djkstra himself frequently uses 1-based indexing for heaps. CLRS uses 1-based indexing almost everywhere.

There is absolutely no reason why you'd need 0-based indexing, except if your language doesn't have multidimensional arrays.

damn, I never thought doing it that way. That's comfy. Maybe I should switch to doing it that way instead of the sizeof *identifier way.

very helpful, thank you for posting lad
it's for an EE project this will be going on a microcontroller
my initial thought was to hardcode it, as there is a maximum window size that would e used depending on the number of samples. I will look into using malloc to create an array of variable size. thanks user

What is ``algorithmic``?

Djkstra is faggot.
Languages that use anything but 0-based indexing are shit.

Any situation where you need to implement a nontrivial algorithm on an array that actually requires accessing the elements through indexing.

0-based indexing is very rarely superior to 1-based indexing, and the few cases where it is useful, multidimensional arrays and subarray views eliminate that usecase completely.

The most powerful language for manipulating arrays is Fortran. It allows both 0 and 1 based indexing depending on settings, but 1-based indexing is overwhelmingly the standard because 0-based indexing offers no advantages in modern Fortran.

Djkstra was the guy who originally started the 0-based indexing meme train faggotry. Before him, people were leaning towards 1-based indexing.

So the guy whom everyone is quoting on why we should all use 0-based indexing, is a hypocrite.

open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0781r0.html

Does modern mean as cluttered as possible?

who cares about what number your array starts at

Is it possible to have a language as low level as C with semantics as high level as a scripting language?

>modern
When you want to change something for the sake of changing, no matter if it's worse.

Not Lua. Tables there are just hashmaps, so you can have indices 1,0, -3, 9.75, etc etc.

>t. uses 3-based indexing

Shouln't it be "*b = &a"?

No. There have been numerous attempts and they've all been horrific failures, especially C++.

Situations that do not require ``non trivial`` algorithms don't have algorithms?

An array is its own address, actually, so the & would be redundant.
Yet another reason arrays aren't pointers.

D gets close, but isn't by any means perfect. It's a pleasant language to write in.

Yes, kind of.

Only real big question is stack vs heap and needing to free garbage, which adds significantly to the incidental complexity of programming in a systems language.

>An array is its own address, actually, so the & would be redundant.
It's redundant because arrays are pointers already.
Yet another example why arrays are pointers.

Im actually not working on anything right now,
What should i work on Sup Forums? I can code in c++ and build circuits lmao

If the algorithms are trivial, typically you can just use foreach loops, vectorized operations, or higher order functions, so you never have to deal with array indices to begin with.

The issue is that when the thing you need to do is complex enough that you need the indices, typically 1-based indexing is better. 0-based indexing is only better for the trivial cases that should never come up in modern languages.

That doesn't answer my question. Why are you dancing around my question?

No, it's redundant because arrays are addresses.
A pointer isn't its own address.

name one case where 1based indexing is objectively superior to 0based indexing

>A pointer isn't its own address.
void *ptr = &ptr;

you can translate algorithms one-to-one to your code

So now that your argument has been debunked you are basically screeching about arrays being address instead of pointers. Good for you.

You are basically saying a isn't an int in the following example:
int a;
a = 5

>your argument has been debunked
how so
>You are basically saying a isn't an int in the following example:
No, what I'm saying is more like saying a isn't a uint32_t.

sizeof(int[27]) != sizeof(int *)

So is Rust useful for anything yet?

>b--but muh sizeof
Not an argument, sizeof is a lying piece of shit you mong.

Of course, size of an int is not the same as the size of 27 ints. Why do you keep posting that?

Yeah, you can write web browsers and kernels with it
>inb4 yeah but there are better tools for those
Yeah but that's not what you asked

sizeof(char[1]) != sizeof(char *)

Wtf? Those are the same though.
Nice outright lie you got there.

>address size is 8 bits
>t. still uses a famicom in 2017

GroupMe is shit but at least their API seems pretty straightforward. I think I'll make a command-line client.

#include
#include
auto main() -> int
{
int a{ 1 };
int x = 1;
int* b = &x;
std::cout

#include
#include
auto main() -> int
{
int a{ 1 };
int x = 1;
int* b = &x;
std::cout

Why are you comparing the size of an address and an int?

Does CPP really not have interfaces?
I want to make a function that takes in an array with combinations of 1 of 6 different structs. Normally, I would just make it an array of interfaces and have each of my 6 structs extending this interface. Easy.
How the fuck do I do this with cpp if there are no interfaces? Fuck this shitty language.

a isn't an int, it's an array

dumb frogposter

but it does