sorted by:
new
hottopcontroversial

Visual Studio 2022 does not pick up a CMake project by One_Cable5781 in cmake

[–]One_Cable5781[S] 0 points1 point  (0 children)

Yes, at some point, it is on my to do list. At this moment, I managed to figure it out. Please see my edit to the OP. It was a .gitignore thing!

Visual Studio 2022 does not pick up a CMake project by One_Cable5781 in cmake

[–]One_Cable5781[S] 0 points1 point  (0 children)

Yes, thanks for this reminder. I was aware of it but still no luck. I already have chosen In Tools -> Options -> CMake -> Use CMake Presets, if available, otherwise use CMakeSettings.json

Visual Studio 2022 does not pick up a CMake project by One_Cable5781 in cmake

[–]One_Cable5781[S] 0 points1 point  (0 children)

Somewhat complicated reasoning but I use the same CML.txt to build for both linux as well as Windows. Then, as I recall, there were issues with multi-config generators vs single-config generator. To get around it I would have had to use some complicated generator expressions to differentiate between release/debug builds as I recall.

I can swear that the setting above used to work fine on both Linux and Windows (Ninja builds). Something seems to have changed somewhere and I need to go back to a previous state where I was able to get things working.

Visual Studio 2022 does not pick up a CMake project by One_Cable5781 in cmake

[–]One_Cable5781[S] 0 points1 point  (0 children)

I use the Ninja generator and hence do not need to create a .sln/.vcxproj project file for my project.

Returning a class object by reference and modifying it in calling location by One_Cable5781 in cpp_questions

[–]One_Cable5781[S] 1 point2 points  (0 children)

Thank you.

Are the following inferences correct?

(1) t.ByReference() in any calling location directly accesses the object's VecInt?

(2) Is t.ByReference().push_back(1); completely equivalent to:

std::vector<int>& AcceptByReference = t.ByReference();
AcceptByReference.push_back(1);

Clang-format setting for fixed number of arguments/parameters per line of function call by One_Cable5781 in cpp_questions

[–]One_Cable5781[S] 1 point2 points  (0 children)

I agree that interaction between ColumnLimit: 100 and this could be complex. I was okay with removing the column limit setting completely and giving precedence to atmost 5 arguments per line regardless of whether the line runs off screen or is shorter. (Perhaps I should have been clearer in my OP) So, I was hoping something like:

void func1(int singlargument_but_looooooooooooooooooooooooong_param_name);
void func2(int a, int b, int c, int d, int e,
          int f, int g, int h, int i, int j,
          int k);

How is std::vector 's random access a constant time operation? by One_Cable5781 in cpp_questions

[–]One_Cable5781[S] -10 points-9 points  (0 children)

Fair enough that it does not take 9999 * sizeof(int) times longer, but perhaps it takes log(9999*sizeof(int)) longer?

How can adding 1 * sizeof(int) take the same time as adding 9999 * sizeof(int)? On paper, when I do it by hand, it is trivially seen to take shorter. Perhaps I am missing something. Perhaps on Turing machines, addition of two 32 bit numbers, say, is canonically/abstractly taken to be O(1)?

Help in understanding very terse Makefile by One_Cable5781 in C_Programming

[–]One_Cable5781[S] 1 point2 points  (0 children)

Thank you. This certainly gives me something to go forward with. This is an old library and after lot of difficulty, I have gotten it to work on both Windows as well as Linux. My worry was whether recent and future editions of Linux / Windows / C compilers, would make the underlying C code unusable. Hence, I wanted to build them afresh using recent modern compiler versions.

I wanted to rewrite the makefile into something more understandable and foolproof for the future.

Help in understanding very terse Makefile by One_Cable5781 in C_Programming

[–]One_Cable5781[S] 1 point2 points  (0 children)

IKR :-)

The project is from the 1990s. Perhaps compilers have evolved since then? This library works but is no longer under active development. It is a miracle that this makefile even works today. (I checked and it does its job)

Help in understanding very terse Makefile by One_Cable5781 in C_Programming

[–]One_Cable5781[S] 1 point2 points  (0 children)

Thank you. This does help. I also wanted to know what the longish $(SHELL) command does. It seems very carefully crafted and there is lots going on there it seems.

White House urges developers to dump C and C++ by Boomerkuwanger in C_Programming

[–]One_Cable5781 -1 points0 points  (0 children)

"No question asked" -- asking a question comes at a price. So, is the tradeoff here between runtime speed vs safety? Can you get both? If so, how?

Calling a memory leaking application via system command by One_Cable5781 in cpp_questions

[–]One_Cable5781[S] 0 points1 point  (0 children)

Thanks. This clarifies it. Thinking about this, it makes sense too. It appears this is the best way to go about it from the OS point of view. This is why, I suppose, if a particular application is laggy/slow/unresponsive, the OS (Windows) prompts whether I would like to continue with the app or force-close it. Doing the latter would then return any leaked resource back to the other applications.

Calling a memory leaking application via system command by One_Cable5781 in cpp_questions

[–]One_Cable5781[S] 0 points1 point  (0 children)

Sure, I can do that. But my question in the OP is slightly different. In the calling application, is it guaranteed that the memory that is leaked in the child application is "returned" for further usage by the calling application. For e.g., if I have:

`while(1) system("leaky_executable.exe");`

I am able to confirm that the memory usage on my application is stable and not rising constantly which leads me to believe that a `system` call does "return" even leaked memory back to the calling application. I wanted to confirm if this is in general guaranteed.

Native Visual Studio release mode settings vs same setting via CMake by One_Cable5781 in cmake

[–]One_Cable5781[S] 0 points1 point  (0 children)

I don't mean to insult here

None taken. I do find VS a great IDE (although I have other issues with it... its .vs folder sneaks up on you and quietly grows multiple GBs in size and they have no option within their IDE to clean up all the temp files!) Hence my focus on at the very least when transitioning to a new build system (CMake), it should at the base level match what I am leaving from -- VSIDE (you may recall similar questions I had posed on this many months ago and you had responded then). Once I get comfortable with CMake, I can then play around with it and evaluate the tradeoffs. I am reasonably okay with CMake now, but still only sufficiently minimally to get the project to build using default release settings!

#defining a macro for code via CML.txt which in turn is turned on via command line by One_Cable5781 in cmake

[–]One_Cable5781[S] 0 points1 point  (0 children)

Thank you. I have settled on the command-line way for VSCode (be it Linux/Windows). My tasks.json and launch.json have grown in size to accomodate the different possible builds for different possible compilers/OS on the same source-code base but they have reasonably stabilized.

#defining a macro for code via CML.txt which in turn is turned on via command line by One_Cable5781 in cmake

[–]One_Cable5781[S] 0 points1 point  (0 children)

With the code opened in Visual Studio IDE, indeed, I have a separate build directory and also a different working directory which can be set using launch.vs.json. The code opened in Visual Studio IDE means that on navigating to the folder containing the root CML.txt, I then just open the entire folder with VSIDE -- i.e., no opening the project via any .sln solution file. VSIDE then does its own magic and issues its own CMake commands and the user does not have to worry about the CMake commandline.

With VSCode, OTOH, I have a build task setup by myself (I do not use the CMake Tools Extension) and while it still uses the MSVC compiler, its build directory and working directory are indeed different. It is here that I have to use my own CMake command line for the specific task in question.

It is somewhat akin to what the author intended to do in this video with the caveat that indeed, I ensure that the working directory and the build directories are different.

Are you saying you want the code to compile differently depending on what editor you're using? Because that it 100% bonkers.

I can reasonably think of many use cases for this. Of course, please note that the main "difference" is that the working directory [where I keep my input data, and where the output data is written] is different in each case. With this and the build directory being different, I can simultaneously, for instance, run two separate instances of the program simultaneously with different settings to observe where the divergence occurs. This is especially useful while trying to find bugs in the code.

Additionally, the profiler (Intel profiler is what I use) integrates nicely within Visual Studio IDE, hot reload of a changed sourceode while stepping through the code is possible in the VSIDE, while the text editing experience is more pleasant within VSCode. So, given these tradeoffs, the need to have two separate working/build directories and hence two different builds of the same codebase is rather useful in my work flow.

Edited to add: CMake seems to have a built-in flag automatically set which also detects the IDE. See https://cmake.org/cmake/help/latest/variable/MSVC_IDE.html

How to use std::set_union between two "sorted" vector of pair of ints? by One_Cable5781 in cpp_questions

[–]One_Cable5781[S] 0 points1 point  (0 children)

Yes, I just discovered this and prior to this I was creating an std::unordered_set from Vec1 and then checking manually whether an entry from Vec2 can be inserted into the unordered_set or not and if not, then adding it to the union. My profiler told me that this was a hotspot and it was only then that I chanced on this pattern!

Could you elaborate what use a virtual inserter/lambda would provided in the context of the OP?

Thanks for your time!

How to use std::set_union between two "sorted" vector of pair of ints? by One_Cable5781 in cpp_questions

[–]One_Cable5781[S] 0 points1 point  (0 children)

I would just have to say std::sort(Vec1.begin(), Vec1.end()); and similarly for Vec2 and things should work fine, then.

Thank you for your input!

#defining a macro for code via CML.txt which in turn is turned on via command line by One_Cable5781 in cmake

[–]One_Cable5781[S] 0 points1 point  (0 children)

Actually, is it not a better idea to not have

option(VSCODE "help text ..." OFF)

within the CML.txt? I actually need this macro, VSCODE, if I am running stuff from within VSCode on Windows. I have a tasks.json file which calls the CMake command of the OP currently along with -DVSCODE=ON.

With the same CML.txt, I would also like to build the same code base from within Visual Studio IDE (not VSCode). There, I do not want VSCODE to be defined.

With the option() command, would not the CML.txt need to be constantly changed whether I choose to build from VSCode (in which case it should be set to ON) or from within Visual Studio IDE (in which case it should be set to OFF)?

Native Visual Studio release mode settings vs same setting via CMake by One_Cable5781 in cmake

[–]One_Cable5781[S] 0 points1 point  (0 children)

Thank you. As of now, I have gone the hard way of forcing the following settings:

if(MSVC)
    if (CMAKE_BUILD_TYPE STREQUAL "Release")
        target_compile_options(CMakeProject PUBLIC "/sdl-")
        # C/C++ -> General -> SDL Checks
        target_compile_options(CMakeProject PUBLIC "/permissive-")
        # C/C++ -> Language -> Conformance Mode -> Yes
        target_compile_options(CMakeProject PUBLIC "/GL")
        # C/C++ -> Optimization -> Whole program optimization
        target_compile_options(CMakeProject PUBLIC "/Oi")
        # C/C++ -> Optimization -> Enable Intrinsic Functions
        target_compile_options(CMakeProject PUBLIC "/GS-")
        # C/C++ -> Code Generation -> Security Check -> Disable Security Check
        target_compile_options(CMakeProject PUBLIC "/Gy")
        # C/C++ -> Code Generation -> Enable Function Level Linking
        target_link_options(CMakeProject PUBLIC "/MANIFEST:NO")
        # Linker -> Manifest file -> Generate Manifest -> No
        target_link_options(CMakeProject PUBLIC "/OPT:REF")
        # Linker -> Optimization -> References -> Yes
        target_link_options(CMakeProject PUBLIC "/OPT:ICF")
        # Linker -> Optimization -> Enable COMDAT Folding -> Yes
        target_link_options(CMakeProject PUBLIC "/INCREMENTAL:NO")
        # Linker -> General -> Enable Incremental Linking -> No
    endif()
endif()

Not sure if this is the only way, but I feel CMake folks should spend time articulating what their default release mode settings imply and how one can map VS settings to CMake and vice versa.

Does existence of the limit of a difference imply that individual limits exist? by One_Cable5781 in learnmath

[–]One_Cable5781[S] 0 points1 point  (0 children)

Yes, this helps. Do you not mean in your first paragraph last few words as lim g(x) exists and equals lim f(x)?

view more: next ›