/dpt/ - Daily Programming Thread

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

Grading reports. I'm in deep shit and have dozens of reports to grade for tomorrow, but I can't stop procrastinating and posting here.

botnet

well for one, a void main in that specific situation would immediately denote that the program is not meant to be total.

You're retarded.

How?
Void main certainly has its uses beyond that. And returning integer error/success codes is archaic and very flawed. Which is why many modern langs have rectified that.

Nice strawman, fuckface.

volatile uint8_t read_time;

typedef struct why_would_you_do_this
{
uint64_t y[200];
} diov;

ISR(PCINT2_vect)
{
read_time = TCNT0;
}

void init_timer()
{
TCCR0A = _BV(WGM01);
TCCR0B = _BV(CS01);
OCR0A = 0XFF;
}

void init_pcint(void)
{
PCICR |= _BV(PCIE2);
PCMSK2 |= _BV(PCINT23);
}

uint8_t timer_poll()
{
sei();
read_time = 0;
TCNT0 = 0;
while(read_time == 0);
cli();
return read_time;
}

void sync()
{
timer_poll();
timer_poll();
timer_poll();
}

uint8_t manchester_decode(uint8_t bit)
{
uint8_t out = 0;
uint8_t tmp = 0;
tmp = timer_poll();
if(tmp < T2_MAX)
{
if((tmp > T2_MIN) && (tmp < T2_MAX))
out = bit ^ 1;
else if((tmp > T_MIN) && (tmp < T_MAX))
{
tmp = timer_poll();
if((tmp > T_MIN) && (tmp < T_MAX))
out = bit;
}
}
return out;
}

uint8_t manchester_decode_byte()
{
uint8_t data = 0;
uint8_t b = 1;
uint8_t i;
sync();
for(i = 0; i < 8; i++)
{
b = manchester_decode(b);
if (b == TIMING_ERROR)
{
spi_write(TIMING_ERROR);
}
data = (data

>returning integer error/success codes is archaic and very flawed
how?

Void main has exactly one use: causing the program to not compile because it is in direct violation of the C standard.

main does not return type int. Program fails to compile.

nah it gives a warning and compiles anyway

If diov is a typedef for int, that is valid.

Because crashing your whole program for one error is insane and idiotic. As is referencing said errors by integer value.

All warnings are errors.

diov is a typedef of a struct containing an array of 200 uint64_t values.

>crashing your whole program for one error is insane and idiotic
That has literally nothing to do with this.
>As is referencing said errors by integer value
There is no convention to what exit codes actually mean besides 0 == success, non-zero == failure.
Most programs don't bother with anything other than that.

well it can put a value in a register to return with, but once it returns it turns off so I don't see why it's a big deal

>I don't see why it's a big deal
Because it's not int. It is only acceptable for main to return int, or a typedef of int. Not short, not long, not double, not a pointer, not a struct, not even a char or unsigned... just int. You can't return void either.

>That has literally nothing to do with this.
That's C's error "system" though. If you say error handling should be handled separately, then you admit returning int for main is flawed because then one or the other becomes redundant.
>There is no convention to what exit codes actually mean
that's the core issue.

it pretty much can't return, there's nothing to return to. it's not running on top of an os or kernel, once the software ends, the chip powers down. Or on some compilers it ignores the return value and calls main again.

It's inefficient.

You obviously shouldn't crash your program for sake of a small error unless it's a small, command line program.

Then you don't know why that error happened unless you handle it separately, which leads to my point here.

I don't know why people defend C's shit with such fervor.

>Then you don't know why that error happened
Why would you not put stderr output in the same block that checks for invalid returns to crash the program?

>Then you don't know why that error happened unless you handle it separately
That's what stdout/stderr is for

Exactly which makes returning error codes redundant.

I personally agree that returning error codes isn't a great way of doing things, but they're not redundant in this context. You should obviously have some sort of log where you print details of any error that occurred, but you'd still need to return an error code so the caller knows how to proceed.

You can't script stderr, you fucking retard.

>That's C's error "system" though. If you say error handling should be handled separately, then you admit returning int for main is flawed because then one or the other becomes redundant.
This statement makes no fucking sense.

>Error handling here is fine
>Error handling here is not fine
What?

It doesn't fucking matter. Even if your main function is an infinite loop, it still has to have return type int.

even if your program never return anything, it must return an int
wut

Well in an ideal world, you don't throw any error at all. Only default to a normal case that signifies something fucked up. But the middle-ground is return descriptive errors.
Main shouldn't have to return anything arbitrary, i.e useless error codes.

This fucking retard that had the gall to say that I didn't understand error codes () clearly doesn't know what they're for himself.
God damn it, you should really kill yourself.

That is correct. Read the goddamn standard. The return type of main is not something you can choose for yourself depending on whatever makes sense to you at the time. It must ALWAYS be int.

It doesn't matter if you think that error handling in main could be done better.
It doesn't matter if you don't use return codes at all.
It doesn't matter if your main doesn't return at all.

The return type of main is non-negotiable. It is always of type int.

is it bad to allocate memory to a passed argument in a function but free it outside of the function?

thank god i don't use C.

It depends.
You should be VERY clear about who "owns" (should free) the pointers.
e.g. strdup will hand you a pointer that must be passed to free.

That's fine. Use whatever programming language you want that satisfies how you want things structured. But if you do use C, follow the fucking standard. Same goes for C++.

It's likely that every single program on your OS has a return code, regardless of which language it was written in.

>The return type of main is non-negotiable
But why does that matter?

So I'm new to programming and mostly just understand basics. Anyway, when would I use "var" as opposed to an explicit variable?

thanks mate +1 stackoverflow point

actually if i make main void it doesn't load anything into r25, so not only can i pick its type but I can pick whether or not I want to load anything into those registers

what do you mean lad?

You mean with Javascript?

never

Nevermind, I'm retarded

Having a lot of trouble with memcpy (see pic related).

Anyone know why memcpy is changing the value of a pointer pretty unrelated to the current operation?

Thanks in advance for any insight. Below is the code that calls on memcpy
void*
Vector_pushBack(Vector* v, const void* valuePtr)
{
//possible realloc call needed to resize vector
if(v->num_elems == v->max_elems)
Vector_resize(v, v->max_elems * 2);

void* v_end = (char*) v->vec_ptr + (v->num_elems) * v->elem_width;
void* init_vecptr = v->vec_ptr;

//memcpy(dest, src, width);
memcpy(v_end, valuePtr, v->elem_width);
assert(v->vec_ptr == init_vecptr);

v->num_elems++;
return v_end;
}

can you make a copy of it and make it const, then check where the error comes up

void*
Vector_pushBack(Vector* v, const void* valuePtr)
{
//possible realloc call needed to resize vector
if(v->num_elems == v->max_elems)
Vector_resize(v, v->max_elems * 2);

const void* const vec_ptr_cpy = (char*) v->vec_ptr;

void* v_end = (char*) v->vec_ptr_cpy + (v->num_elems) * v->elem_width;
void* init_vecptr = v->vec_ptr;

//memcpy(dest, src, width);
memcpy(v_end, valuePtr, v->elem_width);
assert(v->vec_ptr == init_vecptr);

v->num_elems++;
return v_end;
}

v_end == v in your screenshot. This explains that. Can't tell more from what you provided except that vecptr + 0x50 == v also in your screenshot, which hints me that either Vector_resize ain't working or that you made a fuckup somewhere else entirely

4got to remove the cast to char pointer but you get the jist

Because you are writing your C programs wrong.

He's not asking the technical reason, he's asking the design reason.
And don't respond with "because that's the standard".

>v_end == v
Holy shit. That's really fucking strange... You're a flipping genius for discovering that, man. I can't thank you enough (been looking at this bug for several hours)

Looking at it a bit, I think what's happening is that:
-I dynamically allocate a pointer to a Vector
-I dynamically allocate the array whose pointer I store in a vector

Eventually, they overlap, which is really fucking strange, but I guess I'll need to take care of it.

Thanks for the help, man!

This didn't really change much (and init_vecptr was already sort of doing the vec_ptr_cpy's job)... Again, it looks like the issue is completely unrelated to memcpy not that I look at it.

Thanks for the help, man!

You aren't incrementing v_end after you memcpy -- you'll want to do:
v_end = ((char*)v_end) + v->elem_width;

After performing the memcpy. So the first Vector_pushBack ought to succeed, but the subsequent ones will just keep overwriting!

Also, you should double check Vector_resize puts v_end in the right spot but I suspect it's correct.

>ITT: Sup Forums discovered Arduino and gets triggered
>Also, the main thread of the Unix kernel returns an int

There is no standard entry point for freestanding C.
main is hosted only.

I need some A E S T H E T I C Block Comment Formats.
Headlines, Function and module descriptions etc.

I have a huge project and would like to restructure it a bit.

Description, Date and revision above each function and some eye-catching headlines to put some hierarchy into Constants.

It needs to be beautiful, not this low effort asymmetrical

/*author
date
revision
*/

shit

Thank you Sup Forums I know I can count on you

Err, sorry, I misread that. Nevermind. It probably is in Vector_resize. Somehow it looks like your v pointer ends up pointing to your vector data rather than the vector state. Maybe Vector_resize is operating on the v passed in as if it's a value rather than a pointer or something.

Code banners are shit. Don't use them.
Also, your text editor should be able to nicely format multi-line comments for you.
/*
* This is a multiline comment.
* The first line is empty, but some styles don't do that.
* They all basically agree that the *s should line up and the
* last line is empty, though.
*/

I'm fucking screaming

The error was:
I was doing the wrong realloc call:
void* new_vec = realloc(v->vec_ptr, newsz);


Instead of
void* new_vec = realloc(v->vec_ptr, newsz * v->elem_width);


I can't believe I fucking forgot one fucking multiplication.
Ah well...
My vector works now, at least

The design reason is that C and Unix are tied hand in hand and near inseperable.
Unix is designed around the idea of a lot of small programs that all do one thing very well. So one program, that wants to do something outside its scope will run another program, and it will ALWAYS know it the program it called did what it wanted, or failed.
It never needs to check with the program, pipe, read logs or status. It just says "do this" and gets told "I did" or "I couldn't". Always in the same format, totally universal.
Now, why that's important when you're running an application specific OS on a microcontroller, why the main thread MUST return an int, that depends on the hardware. But Ol' Kenny didn't wanna write "All C programs MUST return an int, unless it's the OS in which case ahh, fuck it."
Plus, there's nothing to stop an OS from being called from another OS, a la chrooot. God forbid them MIT boys had the foresight to predict power management and ACPI.

On a micro, either you never exit main, so the code simply won't get called, and you can MAYBE bitch about three wasted bytes, or it does at some point and what it returns night tell the micro how to respond, either power off, go to low power, reset etc.

>Main is hosted only
(Unless compiled to the boot sector, humph humph AVR)
Anyway I'm surprised, I haven't read up much on early Unix but I thought they where pretty keen on it ALL being C. If so, how'd they manage that? Compile an object they boot from?

Are we better than stack overflow?

>(Unless compiled to the boot sector, humph humph AVR)
There is nothing stopping freestanding C from also having main, but it's only standardised for hosted C.
I doubt a freestanding implementation is going to have something like arguments to main, though.

lol no

Excluding the obvious retards, and shitposters, sure.
Not that SO or /dpt/ are exactly high quality discussion.

I wish all the CS kiddies would fuck off.

>implying /dpt/ is better than anything
I would rather employ a Pajeet than the toxic retards on /dpt/

>toxic
You should probably head back to wherever you came from lad.

So you think everyone has to be hostile on Sup Forums just because it's Sup Forums? I think you're the one who has to go back lad

I never said that, if you get offended by anonymous posts, you should probably look to forums where they have much stricter posting rules.

Threadly reminder.

int boy = 1, girl = 0;
if(boy == girl)
boy = girl;

Holy shit.

Is #'aquire-lock atomic?

>if(boy == girl)
>boy = girl;
I see you're already a girl, nice.

???

>#'aquire-lock
Take your hashtags back to twitter.

hey guys, i feel like a complete retard and i know im out of my zone asking you guys for help, but any tips would be appreciated

im working on a program in c++ that makes a database of entries and stores them to a text file. there's supposed to be a main menu with all the options you can select. in my main function i listed the main menu, and also used a switch function using the input of the user to decide which function to make. whenever i run the program and input a selection, none of the functions get called, and the program just terminates, here's what the switch function's code looks like

switch (selection)
{
case '1':
addEntry();
break ;
case '2':
showEntries();
break ;
case '3':
saveEntries();
break ;
case '4':
loadEntries();
break ;
case '5':
searchEntries();
break ;
case '6':
deleteEntries();
break ;
//default:
//cout

*decide which function to call, not make

The code looks fine, there may be something wrong with the way you read `selection` tho. In any way, try debugging the program, or at least print the values you're using.

What's 'selection'?

i probably should have added the other code in the main function, selection is the number the user inputs, my bad guys

here's the code right before the switch function previously mentioned.

int main()
{
cout

err nevermind just tried switching to string and compiler gives me an error expecting an integer in the switch statement

why the fuck are my terminal colours different in tmux?

>is it possibly because i made selection an integer when the switch statement is expecting a string?
In a way, since selection is an int, the number you enter gets parsed and stored as an integer value 1, 2, 3, etc., not a character '1', '2', '3'. All you have to do is to change the values in the switch to int values.

i fucking love you. THANK you so much. i know this is probably peanuts to you guys, but im just starting to learn this stuff so little shit like that goes over my head. thank you again so fucking much.

To be honest, the way C and C++ handle characters is inherently confusing, it should be a separate (4-bytes) type with no implicit conversion to/from integers. Instead, we have three separate types (signed char, unsigned char, char), but all of them are just 1-byte integers.

(You)
And then we have the really fucked up things like char literals being ints in C.

> it should be a separate (4-bytes) type with no implicit conversion to/from integers
I don't think you really understand/appreciate why C was designed the way it was.
C's often used in embedded systems, where memory is a scarce resource, and having four bytes per character, when you only really need at least seven bits to represent ASCII codes is really wasteful. Strings would be four times longer

>And then we have the really fucked up things like char literals being ints in C.
The fact that chars are represented as ints allow for many optimizations that wouldn't necessarily be allowed if they were their own types:
char toUpper = (ch) | 0x20;
char toLower = (ch) & ~(0x20);

just to name a couple.

The compiler does all it can to help you, with C's compiler messages being some of the most helpful I've seen (I say, looking disgusted at how little Julia helps you)., but there's a certain learning curve inherent to C.
The best thing I can say about C is that it's a really small, yet incredibly robust language that reminds you that you're working in a computer with as little abstractions as possible. Once a beginner learns these quirks, it's pretty much smooth sailing until they hit a seg fault

c++ is the greatest language of all time

>I don't think you really understand/appreciate why C was designed the way it was.
I do, and I guess it made sense on 16-bit machines 45 years ago, but nowadays it's a sad anachronism.
>C's often used in embedded systems, where memory is a scarce resource, and having four bytes per character, when you only really need at least seven bits to represent ASCII codes is really wasteful. Strings would be four times longer
What is utf8.
>The fact that chars are represented as ints
What does your example have to do with char literals being ints? I mean they aren't integers like in char, they're literally of type `int`, because someone 45 years ago thought it's an acceptable hack.

And then there's the whole Unicode thing. C is really an outdated legacy language which shouldn't be taught anymore. It can have its low-level embedded niche for now.

Please don't fool the naive people with bait.

Is there a way we could learn to program as a team?

Isn't there something like a co-operative programming game where people work on their own files to solve a small problem?

Yes, but enjoy trying to get anyone on here to do it. People have tried.

But you can always just add a unicode type in, what is it in C, a 'wide char'?

Say you want to store the number 5 in a 32 bit variable. Using groups of 8 bit this gives
00000101 00000000 00000000 00000000
or in hex:
05 00 00 00
Converting this to an 8 bit value is just cutting off the other variables to get "05".
Converting it the other way is also trivial.
You just insert 0's or 1's depending on the value of the original. (some platforms don't use little endian, but you are most likely using it).

As for using 1 byte instead of 4 for each letter in a string, you can do that, just use UTF-32.
It is a waste of space, but you can do that if you want.
And there is only two char types: signed or unsigned.
If you care about whether it is signed or unsigned, you should specify it.
If you don't, use the default as it is unspecified by the standard and can change if you want to port your application to another platform.
But this is where we have problems anyway.
When you are writing software for a specific platform, you often need to define these things yourself anyway.
I usually make a header file called "platform.h" or something where I specify what my types are and then I typedef all the things I will be using so the bitlength is noted in my application.

>What is utf8.
Utf8 uses 8 bit chars. when you insert special chars, you add more chars to it.
There is nothing weird about it.
It is very close to the way we in ascii use escape chars to create special chars.
'\n' is a newline char, everyone can read this much more clearly than writing 10.
It is fine.

utf-8 and runes is the way too go lad, wchar_t is for MicroShits

Why not just go to a university?

He played himself