These are not keywords
Your question doesn't make sense
Ok, 😅
Sorry i am a noob in this 😅😅
@unchanted
@unchanted
Thanks by the way
pappupanchi
Anonymous
/warn Brachy PMing
pappupanchi
/warn
pappupanchi
sorry
数学の恋人
I'd suggest you to install wsl and install clang or gcc there then learn C
pappupanchi
Ok thanks
Anonymous
I want to learn C++
Anonymous
Anybody help me
Anonymous
??????
数学の恋人
I want to learn C++
learncpp.com
en.cppreference.com
Book by Bjarne Stroustrup,
Tony Gaddis, etc
Last and most important
A search engine like google, duckduckgo, bing, etc.
Anonymous
Tokin
Tokin
Just kidding
Tokin
He's using Visual Studio code.. Maybe he didn't install the necessary toolchain
Tokin
At all
数学の恋人
possible
Tokin
Oh didn't see the gcc command.. So well my bad.. He wasn't interested in msvc at all
Tokin
Well he can also check out msys.org too
Tokin
I'm told it's much better than wsl thingy
数学の恋人
I don't know I'm on linux and just love working on this system
数学の恋人
I'm told it's much better than wsl thingy
I have no idea in slightest, though I do have experience with wsl and then vscode as an experiment
Patrick
I've been having a bit of strange behaviour in my program, and I haven't been able to find an answer on the internet. Is the order of evaluation just not guaranteed for something like this:
arr[++i] = ++i;
Tokin
I've been having a bit of strange behaviour in my program, and I haven't been able to find an answer on the internet. Is the order of evaluation just not guaranteed for something like this:
arr[++i] = ++i;
Why do I have a mental note that I should never do something like this
Tokin
😂
Patrick
Because it seems undefined... but I don't think I've ever been bitten by it before
Artöm
Patrick
Guaranteed in C++17 and above, but this code stinks
And which direction is it guaranteed to be? rvalue, lvalue?
数学の恋人
I've been having a bit of strange behaviour in my program, and I haven't been able to find an answer on the internet. Is the order of evaluation just not guaranteed for something like this:
arr[++i] = ++i;
anyone who wrote that in actual production code must rot in bottom chamber of hell
数学の恋人
that's something even noob like me can tell
Artöm
And which direction is it guaranteed to be? rvalue, lvalue?
> In every simple assignment expression E1=E2 and every compound assignment expression E1@=E2, every value computation and side-effect of E2 is sequenced before every value computation and side effect of E1
Patrick
Excellent. I'm keeping it because it's a private project able to use C++17 😁
Patrick
Thank you.
Artöm
Patrick
Why not?
Artöm
It is unreadable
Patrick
If it's guaranteed to work in a particular way I'm comfortable with it personally
Artöm
One needs to do mental evaluation order checking every time he sees it. What for?
Artöm
Trying to stuff as much as possible in one line is retarded
Patrick
Well, alternatively, will GCC optimise this into one subtraction only?
arr[i - 1] = arr[i];
--i;
Instead of arr[i] = arr[i--]
Artöm
Maybe. Check assembly output
Anonymous
Well, alternatively, will GCC optimise this into one subtraction only?
arr[i - 1] = arr[i];
--i;
Instead of arr[i] = arr[i--]
Premature optimizations? I love it!
Anonymous
(no)
Pavel
Well, alternatively, will GCC optimise this into one subtraction only?
arr[i - 1] = arr[i];
--i;
Instead of arr[i] = arr[i--]
Is it defined that decrement operator will be called before calculating the index on the left side?
Anonymous
It won't? I'm writing a li'l test to see the assembly now
The "no" means that premature optimizations are the root of all evil
Tokin
Also will it not work differently on a different platform?
Pavel
Also will it not work differently on a different platform?
Yep, that's what I'm thinking of, looking at this code
Patrick
It does subtract twice, as far as I can tell
Patrick
int test1 () {
volatile int arr[2] = {1, 2};
volatile int i = 1;
arr[i] = arr[i--];
return arr[0];
}
int test2 () {
volatile int arr[2] = {1, 2};
volatile int i = 1;
arr[i - 1] = arr[i];
--i;
return arr[0];
}
test1 has one sub and test2 has two sub in the disassembled O3 c++17
Artöm
Of course it will, i is marked volatile
Patrick
Oh yeahhh
Patrick
How do I get it to not optimise the whole thing away?
Artöm
Also will it not work differently on a different platform?
Order of evalation is specified for all platforms
@unchanted
#include<stdio.h>
int main()
{
char temp[100];
printf("enter the character value:\n");
fgets(temp, 100, stdin);
int i;
for (i = 0; temp[i] != '/0'; i++)
{
}
char reverse[i+ 1];
int len = i + 1;
for (int j = 0; j < len; j++)
{
reverse[j] = temp[i - j];
i--;
printf("%c", reverse[j]);
}
return 0;
}
@unchanted
fgets is for files isn't it?
Artöm
No
@unchanted
ok let me try
@unchanted
ok what about the arguments in fgets it is showing insufficient arguments
@unchanted
it will ask for file stream and max count
Artöm
ok what about the arguments in fgets it is showing insufficient arguments
Read function description on cppreference
Artöm
it will ask for file stream and max count
stdin is file stream for standard input (console usually), max count is length of a buffer
Artöm
temp is your buffer
Ajay
Is it problamatic to write auto itr = st.begin() and then itr = prev(itr) ?
Artöm
Is it problamatic to write auto itr = st.begin() and then itr = prev(itr) ?
I'd say type is obvious here
Artöm
Ah, you asked different thing