i = 10 ++i i = 11 ++i i = 12 i+i = 12+12 = 24

That what i said

#include <stdio.h> int main() { int i=1,j; j= ++i + ++i + ++i; printf("\n%d",j); return 0; }

so we it is like ( (++i) + (++i)) + (++i) (or the other way around not sure, doesn't change the result (3+3) + 4 = 10

Okay then...

so we it is like ( (++i) + (++i)) + (++i) (or the other way around not sure, doesn't change the result (3+3) + 4 = 10

#include <stdio.h> int main() { int i=1,j; j= ++i + ++i + ++i + ++i; printf("\n%d",j); return 0; }

kilmi acc to u we need to get 21 but op is 15

i = 10 ++i i = 11 ++i i = 12 i+i = 12+12 = 24

(((++i) + (++i)) + (++i)) + (++i) ((3+3) +4) +5 = 15

#include <stdio.h> int main() { int i=10,j; j= ++i + ++i; printf("\n%d",j); return 0; }

#include <stdio.h> int main() { int i=1,j; j= ++i + ++i + ++i + ++i; printf("\n%d",j); return 0; }

with -Wall even gcc warns about it... i guess i should have enabled warnings from the beginning

This is Undefined Behavior as well

Ufff Y these people are assigning a tricky ques Anyway thank you so much @K11M1 🤝

i was wrong, it's UB

what i written is how gcc interprets this, but the result is uncertain

Sorry i thought just a few lines

depending on compiler you can get different answers... (in this case)

undefined behaviour

That is implementation defined behavior. Undefined Behavior means that the standard or the compiler offer no guarantees and anything can happen.

In this case it should be the same no? ( i don't know)

No. In this case even on the same compiler between different runs, the output can be different. It can cause your system to crash. When output varies from compiler to compiler and it is documented, and the standard allows such differences, then it is called Implementation Defined Behavior. There is another thing called Unspecified Behavior. I have tried to explain all 3 of them here: https://t.me/cpp20programming/204

hello friends, I'm working on my first simple project and I face a lot of problems so if someone can help me, please I need help. thanks in advance

Is it a bad idea to #include a .c file to avoid having to reference it on compilation time?

How to add an existing cpp file to a project in clion? without adding executables to cmake

If you use CMake you can add it to CMake (add to your executable sources list in one way or another) and reload CMake file in clion. Note that you can add multiple files to one executable in CMake and there are also options to add all files from a folder (glob).

hello guys, i need help print words that begin and end with the same letter. words are separated by a space

hello guys, i need help print words that begin and end with the same letter. words are separated by a space

but how to convert string to const string?

555555555 544444445 543333345 543222345 543212345 543222345 543333345 544444445 555555555

If you use CMake you can add it to CMake (add to your executable sources list in one way or another) and reload CMake file in clion. Note that you can add multiple files to one executable in CMake and there are also options to add all files from a folder (glob).

Hello, I want to print a pattern using C:

<quote>there are also options to add all files from a folder (glob).</qoute> This is a must be avoided feature in cmake. This screws up build rules and will bite you in the future if you later decide to replace globbing with a list of files instead.

what do you mean? Is it like polindrom words?

and like... in what part you need help? you don't know how to print the letter? how to access array?

Adding files manually to cmakelists every time is super annoying, I have read that it's suggested to avoid it, but I don't see how it can break anything and what are alternatives that don't require doing things manually. I can't imagine going back to listing every single file (a lot of my cpp/h files also generated with script that called from CMake)

It is bad for many reasons. If you are working in a group and your cmakelists.txt file uses globbing. Suppose you add a new file A.cpp and commit it. Suppose some other developer who has built his project recently, does a pull - since his CMakeLists.txt file has not changed, the build system will conclude that nothing needs to be built again. And the build would fail. This can be corrected by using CONFIGURE_DEPENDS. But this brings with it its own set of issues. Now incremental builds are slowed down. For the ninja generator, which is considered to be the fastest build system in existence on *nix systems, CONFIGURE_DEPENDS brings down performance so much. This is because everytime you kick off a build a check is performed to see if any new file has been added to the filesystem. This is a very slow process and decreases the value of TDD for incremental builds that pisses off people who work on a source system that has more than a MLOC. And btw CONFUGURE_DEPENDS is not guaranteed to work with every generator. Another solution that is considered for such issues is to check constantly for changes on the filesystem using things like inotify and stuff. But this is so fragile that even a small change in things like cgroups limits can cause his monitoring to break which in turn would break your build and tracking suck things would be a big pain in the a**. And even if you have a lot of generated source files, assuming they are all generated by the same process, you can always use a custom target and then create an implicit dependency to your final Target. The generator would be triggered through a custom command. This would totally negate the requirement for globbing given all the disadvantages above.

In the teams I worked with you always call cmake to update the project after you pull (usually from custom script that does other housekeeping as well). Cmake is pretty smart about updating the project, and fast. I've never actually seen any project where people would edit cmakelists manually unless they want to change build rules.

When did I say that you have to edit CMakeLists text file?

In the teams I worked with you always call cmake to update the project after you pull (usually from custom script that does other housekeeping as well). Cmake is pretty smart about updating the project, and fast. I've never actually seen any project where people would edit cmakelists manually unless they want to change build rules.

How it's going to be changed if not edited

When did I say that you have to change CMakeLists.txt file everytime you trigger a build?

Booting is a huge topic. Just ask a specific question. People might answer if they know. Booting doesn't concern itself with the partition table (MBR or GPT). In particular, if you are using a GPT partitioning scheme, then it is highly likely that you are booting a UEFI system. The UEFI can recognise an EFI partition and therefore load the bootloader directly from there unlike on an old BIOS system where you need the bootloader split across multiple stages with each stage progressively doing more work to get ato a stage where the bootloader can read from a specific disk partition and load the kernel from there. That is why BIOS based systems require a ramdisk which contains file system code. UEFI systems got rid of this requirement.

Not every time you trigger a build, at all, when you add/delete/rename file for example, we don't do that

Not every time you trigger a build, at all, when you add/delete/rename file for example, we don't do that

hi do you know what is repo sync for?

I am not sure if you understood what I was trying to say. Tell me which part is causing confusion so I can clarify

but when the UEFI finds the EFI partition, how do it know which file contains the bootloader?

Well it depends on the NVRAM configuration. Try the command efibootmgr on your Linux system. It will list things like BOOT0001, BOOT0002 and so on. Each of them will point to an .EFI file in the EFI partition. The UEFI system will choose the .efi file accordingly

You say that glob is bad because cmakelists won't be updated and it can cause build failure, I say that it's solvable by running cmake after you pull new changes

but whats in the efi partitions that makes the UEFI choose

If you run cmake and then do a cmake --build, then you again do what I suggested. That is the equivalent of scanning the filesystem for changes. That is what I said is slow. On an incremental build system, you don't need to call cmake again and again. The configuration and generation step need not happen everytime.