I'll check it out. Thabk you!

long fib(long n){ if (n<2){ return 1; }; else{ return fib(n-1)+fib(n-2); } }

a better one, using DP: int fib_topDown(int n, int dp[]) { if (dp[n] == -1) { int res; if (n == 0 or n == 1) res = n; else res = fib_topDown(n - 1, dp) + fib_topDown(n - 2, dp); dp[n] = res; } return dp[n]; }

Anyone here have used linux?

#include <stdint.h> #include <stdio.h> void main() { uint16_t dividend , divisor ; printf(" enter the dividend and divisor \n"); scanf("%u %u" , &dividend , &divisor ); uint16_t s1,s2; s1 =( 0 != dividend%2)?1:0; s2 =(0 != divisor%2)?1:0; printf( "the value of s1 and s2 is %u and %u " , s1,s2); //jus to verify the value of s1 and s2 and here i am getting s1=0

[ Hmm void main. How damn hard is it for professors out there to teach int main correctly? ] You have invoked undefined behavior here, in your case, %u expects uint32_t which is 4 bytes, but you write to uint16_t storage which is 2 bytes in size. So you got 2 bytes out of bound write which may overwrite other variables. The correct specifier for uint16_t is %hu.

[ Hmm void main. How damn hard is it for professors out there to teach int main correctly? ] You have invoked undefined behavior here, in your case, %u expects uint32_t which is 4 bytes, but you write to uint16_t storage which is 2 bytes in size. So you got 2 bytes out of bound write which may overwrite other variables. The correct specifier for uint16_t is %hu.

See also: man 3 printf

First time that I see void main :/

Thanks worked 🙏

???

[ Hmm void main. How damn hard is it for professors out there to teach int main correctly? ] You have invoked undefined behavior here, in your case, %u expects uint32_t which is 4 bytes, but you write to uint16_t storage which is 2 bytes in size. So you got 2 bytes out of bound write which may overwrite other variables. The correct specifier for uint16_t is %hu.

Please be nice to the seniors with patience. Thanks.

Yes, excuse for my impolite sentence.

😆 I was joking btw

When your function doesn't return anything (not recommended, as if it doesn't return zero or a computer value it's harder to debug the code) or when a function doesn't take any arguments.

@ehsan687 Take a look at the following code snippet: #include <stdio.h> int funOne(void) { printf("Hello"); return 0; } int main() { funOne(); return 0; } If I you change "int funOne(void)" to "int funOne()" and "funOne()" to "funOne(["Any Argument"])" the program will still run, but the code is wrong and might cause problems in the future. Using "void" when the function takes no arguments prevents this from happening by halting the program and throwing the following error: // too many arguments to function call, expected 0, have 1

I'd personally change the last function for the reasons explained above. - From: main() { ... } - To: int main(void) { ... return 0; } Fun fact: void main() is the old way to do it which doesn't solve the problems I mentioned. You'll certainly find this style in old tutorials on the internet.

Better option ?😅

I mean... Mr void main must have lived longer than you and I ... lol

Good compiler should warn you about that, you should really take advantage of it. Or even activate more warn flags like -Wall -Wextra.

When your function doesn't return anything (not recommended, as if it doesn't return zero or a computer value it's harder to debug the code) or when a function doesn't take any arguments.

It's manpage, if you don't have it, you can type that on Google.

@K_P_Shetty read this message and the following two others

I'd personally change the last function for the reasons explained above. - From: main() { ... } - To: int main(void) { ... return 0; } Fun fact: void main() is the old way to do it which doesn't solve the problems I mentioned. You'll certainly find this style in old tutorials on the internet.

I think in most cases that code doesn't interact with other codes it has no difference to use void or int.

@ehsan687 Take a look at the following code snippet: #include <stdio.h> int funOne(void) { printf("Hello"); return 0; } int main() { funOne(); return 0; } If I you change "int funOne(void)" to "int funOne()" and "funOne()" to "funOne(["Any Argument"])" the program will still run, but the code is wrong and might cause problems in the future. Using "void" when the function takes no arguments prevents this from happening by halting the program and throwing the following error: // too many arguments to function call, expected 0, have 1

The return value of int main(void) is used as exit code these days.

Or this... I'm on in my cell phone and I can't teste it, but that's the logic int fib(int n){ int fibs[], i=0; for (i=0; i<=n; i++); if (i == 0){fibs[i]=0}; else if (i ==1 or i==2){fibs[i]=1}; else{fibs[i]=fibs[i]+fibs[i-1]}; return fibs }

[ Hmm void main. How damn hard is it for professors out there to teach int main correctly? ] You have invoked undefined behavior here, in your case, %u expects uint32_t which is 4 bytes, but you write to uint16_t storage which is 2 bytes in size. So you got 2 bytes out of bound write which may overwrite other variables. The correct specifier for uint16_t is %hu.

in systems where %u really expects uint32_t (i.e. unsigned int is 32 bits), integer promotion guarantees that the uint16_t argument is converted to int32_t. no undefined behaviour there.

> integer promotion guarantees that the uint16_t argument is converted to int32_t. Yes, I am sure that's what happens with printf, but in this case scanf() does not actually accept integer, instead it accepts pointers. So the integer promotion still happens, but to uintptr_t rather than int. But that's not the main problem here, the main problem is the memory write itself. scanf with %u writes sizeof(unsigned int) in size. scanf with %hu writes sizeof(unsigned short) in size. Those size differences cause out of bound write which leads to UB.

oh wait me dumb dumb, i saw printf on both lines for some reason

Guys anything wrong with this code?

Did not get bro

Use of undeclared identifier 'numbers' numbers(a,b)

#include<iostream.h> #include<conio.h> int main() { int a,b,x,y; numbers(a,b); swap(x,y); return 0; } void swap(int &i,int &j) { int z; z=i; i=j; j=z; cout<<"sfter swapping"<<i<<j; } void numbers(int k, int l) { cout<<"entee no"; cin>>k>>l; cout<<"before swapping"<<k<<l; }

your number function def in below the main() use function prototype or put the numbers function def above main()

Exactly

Oh but better to use int?

#include <iostream> #include<vector> #include<string> using namespace std; vector<string> v; void addSub(int n,string s) { int i=0; int j=0; char ans[s.length()]; while(n>0) { int last_bit=(n&1); if(last_bit==1) { ans[i]=s[j]; i++; } j++; n=n>>1; } v.push_back((string)ans); } void findAll(string s) { int n=s.length(); for(int i=0;i<(1<<n);i++) { addSub(i,s); } } int main() { string s="abc"; findAll(s); for(auto x:v) { cout<<x<<endl; } return 0; } i wrote this code to find subsequences of a string. but it gives me wrong answer and i can't find out why

#include <iostream> #include<vector> #include<string> using namespace std; vector<string> v; void addSub(int n,string s) { int i=0; int j=0; char ans[s.length()]; while(n>0) { int last_bit=(n&1); if(last_bit==1) { ans[i]=s[j]; i++; } j++; n=n>>1; } v.push_back((string)ans); } void findAll(string s) { int n=s.length(); for(int i=0;i<(1<<n);i++) { addSub(i,s); } } int main() { string s="abc"; findAll(s); for(auto x:v) { cout<<x<<endl; } return 0; } i wrote this code to find subsequences of a string. but it gives me wrong answer and i can't find out why

In addsub, 1) make ans an array of length s.length() + 1 2) Initialize it with all '\0' or after the while loop ends, add a ans[i] = '\0'; 3)v.push_back(ans) is good enough. You dont need a cast here.

thanks I got it. But Why don't I need to cast here

There is no performance difference but I think it is best practice to stick to standards

Ok fine, I don't get why my professor still uses that old format.

Any c/c++ course

For curiosity, if it is possible ask him to see what is the intention. maybe there would be something that we are not aware of it.

Yea sure tomorrow, I will update you