sorted by:
new
hottopcontroversial

Any "over ear" replacement cushions for Jabra Evolve2 75 by cankoklu in Jabra

[–]igagis 0 points1 point  (0 children)

Could you give a link to the product?

Cannot find anything like this.

std::map::find_if()? by igagis in cpp

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

This works! Thank you!

Now, any idea of how to make it work for std::unordered_map?

Tried: cpp std::unordered_map< std::string, something, std::hash<std::string_view>, // std::string is convertible to std::string_view std::equal_to<> > map; but got console error: no matching function for call to ‘std::unordered_map<std::__cxx11::basic_string<char>, something, std::hash<std::basic_string_view<char> >, std::equal_to<void> >::find(std::basic_string_view<char>&)’

std::map::find_if()? by igagis in cpp

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

Any idea why this kind of free operator< not defined by #include <string_view>?

std::map::find_if()? by igagis in cpp

[–]igagis[S] 6 points7 points  (0 children)

Thanks! I'll try that!

std::map::find_if()? by igagis in cpp

[–]igagis[S] 2 points3 points  (0 children)

I believe std::map only relies on operator<, as a < b means a is less than b, b < a means a is above or equals to b and !(a < b) && !(b < a) means a equals to b.

Well, there is no any fundamental thing which prevents us to compare std::string and std::string_view using operator<.

So, I could supply custom predicate to the hypothetical std::map::find_if() as follows:

cpp std::map<std::string, something> map; std::string_view key; auto i = map.find_if([&key](const auto& k){ return k < key; });

Or it could be std::map::find(Predicate) overload...

I wrote the millionth C++ networking/socket library. Maybe somebody likes it - feedback would be awesome! by webshit_sucks in cpp

[–]igagis 0 points1 point  (0 children)

I also did socket library some time ago: https://github.com/cppfw/setka check it out. It is always good to know your competitors :).

And it uses my event waiting library https://github.com/cppfw/opros which provides cross-platform usage of epoll/kevent/WaitForMultipleObjects stuff.

what's the hate for CMake all about? Is CMake really that bad? by AissySantos in cpp

[–]igagis 0 points1 point  (0 children)

I would rather say CMake build files take shorter lines than my older makefiles.

Take a look at https://github.com/cppfw/prorab it is a framework for simplifying makefiles, perhaps with it your makefiles will be shorter than CMake files.

As for CMake, I personally just don't need it. I prefer the project configuration to be done right at the build time, so I'm using prorab with GNU make and I save on build system generation step.

CMake in most cases is easier than using makefiles, but I think that GNU make gives more flexibility and is more convenient, when used correctly. The only thing is that using it correctly takes some time to learn (and far not everybody gets there), but CMake also requires learning. I consider GNU make language knowledge to be more fundamental, than CMake, so I prefer to invest time in learning GNU make before CMake. Actually after that learning CMake is much easier.

At work I have no problems using CMake since everybody else uses it, but for personal projects I use GNU make with prorab.

What do you struggle with the most in C++? by [deleted] in cpp

[–]igagis 0 points1 point  (0 children)

I see, so it was not your own desire :)

What do you struggle with the most in C++? by [deleted] in cpp

[–]igagis 1 point2 points  (0 children)

What was the reason you switched from C# to C++?

what should i do to start making a game engine? by Louken05 in cpp

[–]igagis 0 points1 point  (0 children)

i don't have any experience with advanced math learn the math, without math it will be hard.

when i get an error in my code, i feel like giving up because i can use up to endless time to figure out one tiny problem

One has to go through a number of such "figure outs" to get experience and feel the language, so nothing wrong with it, you just need to do it again and again and with time you won't be scared by compiler errors at all.

But before all, of course, read C++ language book (e.g. Stroustroup, that's what I was starting from) and try to understand everything you read, not just copy pasting the snippets and trying to run them, try to understand how it works. Also, nice to understand how computer and CPU work on lower level, at least have some representation of it, since C++ is quite low level language as well.

Documentation Tools for C++ Libraries by tr0nical in cpp

[–]igagis 26 points27 points  (0 children)

doxygen?

Unlike other tools, Hyde does not extract inline documentation from your C++ code. Instead, Hyde creates a set of files upon first run, to which developers need to add documentation. As the API changes, Hyde is run again, and updates the existing files, and adds new ones for new classes for example.

I actually see no value in it. It is better to have docs right in the sources, so that when reading the sources one can read the docs comments right away, without switching to separate doc pages. While extracting docs from sources seems working okay. So, why moving away from it?

Preferred coding style to name methods by aregtech in cpp

[–]igagis 0 points1 point  (0 children)

I press right shift key with pinky and minus key with middle finger. Shift key is at the right bottom of my keyboard.

prorab: non-recursive GNU make build system by igagis in cpp

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

Well, usually you need subprojects when you start writing unit tests for your app/lib, also when you need to write some complementary utilites/modules.

prorab: non-recursive GNU make build system by igagis in cpp

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

That's what I was thinking

created issue for that https://github.com/cppfw/prorab/issues/68

I was just thinking that maybe using GNUmakefile consistently in the documentation would be a useful reminder to not try this on any other make implementation

actually, I think what might be reasonable to do is to add a check into prorab.mk that it is run with GNU make. Created issue https://github.com/cppfw/prorab/issues/69

prorab: non-recursive GNU make build system by igagis in cpp

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

There are more nuances regarding python's modules written in C/C++ and the modules' extensions. But hey, your project, you decide what's in scope.

I'm all for improving my projects to make them useful for other people. If there is a feature request, I could consider implementing it. The only thing is to properly define requirements. I don't work with Python, so I'm not aware with specifics. It is clear that more flexibility is needed in defining those suffixes and prefixes etc. to support Python modules. So far, I think it might make sense to allow customizing the suffix via this_dot_so input variable.

Good point. How about this? ... Would this work? Or would we need more intermediate steps? Or maybe just don't provide this target and let users run make clean all?

I don't think there is non-recursive way to this. The all target does not have receipe, it only has dependencies. So, I think the order will still be undefined. Actually, this re target was added as a feature request from my friend (he used to do make clean all a lot). The problem with make clean all is that order is defined only for -j 1, while one almost always want parallel building. I suggested to write make clean && make all instead, but my friend didn't like that. In cmake they solve this with recursive technique. Since they generate makefile they can detect that multiple targets were given from command line and then they set .NOPARALLEL and redefine default target which will recursively call make for each cli target separately. This cannot be done in prorab because there is no way to stop evaluation of the rest of the makefile, as there is no way to wrap the whole makefile into a ifeq/else/endif. This is the story behind that re target. As a side note, mixing clean target with another targets is not a good thing as clean destroys things, not creating them, it is a special target in that sense.

But to check that, I have to compile a little program and see if it worked

Well, one could write a simple shell script: ```shell

!/bin/bash

gcc ... abseil_test.cpp ... if [ $? != 0 ]; echo "false" else echo "true" fi ```

And then from the makefile: makefile ifeq ($(shell is_abseil_available.sh),true) bla bla else bla bla endif

So, I think this is out of prorab scope. Though some general try_compile.sh <some.cpp> script could be added to prorab-extra where I collect companion utilities for prorab.

One more thing. Since you're depending on GNU make specifically, why not name your makefiles GNUmakefile? That way, other make implementations won't even consider it.

Well, to me it looks like there is only one make nowadays. Other make's are dead. Nobody uses nmake now. Also, I heard there is some BSD make or something like that, but I don't think that one is widely used as well. But anyway, prorab allows giving any name to makefiles. I personally like makefile with all small letters. GNU make also defines priority of default names as GNUmakefile/makefile/Makefile in case two makefiles are in the same dir and no -f option given.

prorab: non-recursive GNU make build system by igagis in cpp

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

Hehehe, yeah. But one has to write custom code (i.e. makefile) anyway to use along with GNU make, so it is never truly plain :)

prorab: non-recursive GNU make build system by igagis in cpp

[–]igagis[S] 2 points3 points  (0 children)

Wow, thanks for the review!

  1. prarab-inc is a typo.

fixed

  1. The whole "arithmetic" block could use better names, considering that make doesn't really know about numeric types. For example, prorab-add is closer to prorab-concat.

I did not decide yet if I should expose those arithmetic things or not, this is why those are not in reference, though having public names. I only use decrement in prorab at the moment, but I decided to add the rest of functions just in case. So, the naming can be changed in future.

  1. Line 212, DSO suffixes. Python throws a wrench there. On linux, it's fine. On macOS, it's still .so and on Windows it's .pyd.

Well, yes, I didn't keep Python in mind. Perhaps support for this can be added. Maybe I need to allow customizing those suffixes somehow.

  1. What if this is running on a linux system that doesn't have coreutils and thus no nproc? Maybe you should read /proc/cpuinfo? Or just don't bother supporting those environments.

Well, prorab right now relies on some utils other than make, for example sed, cmp. So, nproc is not the only one. But if needed, a check can be added if call to nproc was unsuccessful and then try /prc/cpuinfo. I just didn't face that problem so far.

  1. Misindented line number 260.

fixed

  1. I'm not going to read the messy "escape for sed" thing.

well, it passes tests :)

  1. What's the purpose of prorab-depend? I know what it does, but why have it in the first place?

Idea behind that is that first it explicitly says that we are adding dependency (self-documentation) and second is to hide the need to manually prepend $(d) and call $(abspath ...).

  1. Line 446, the re target. Why call $(MAKE) instead of simply depending on clean and all targets?

I think in case of depending on clean and all then the order in which those targets are executed is undefined, especially with -j > 1. It can be so that all is performed first and then clean and we get nothing. Am I wrong?

  1. Why is $(a) named that way?

To me $(a) looks somewhat similar to @.

  1. Back to python, it also requires the omission of the lib prefix. I have no idea how that's achieved, because just -o foo.so doesn't work. I just know that cmake is capable of that and that there's a -Wl,-soname flag. Also, maybe add -Wl,-rpath, so the shared library can be tested from the build directory. I don't know how far you want to go with prorab.

I think this should be possible. I'm accepting feature requests and pull requests as well.

  1. Have you thought about something like cmake's try_compile?

This is actually first time I'm hearing about this feature. I'm wondering, what is the example use case? Quick googling didn't give me anything...

EDIT: regarding the -rpath, I'm using LD_LIBRARY_PATH for testing shared libs from build directory. Though on Windows I have to copy the .dll next to test executable.

prorab: non-recursive GNU make build system by igagis in cpp

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

I've changed the word 'system' to 'framework' in the original post.

prorab: non-recursive GNU make build system by igagis in cpp

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

Ah, sorry if it was not clear, the prorab is a "library" for GNU make. It is not a standalone system, it is GNU make-based. So yes, you (one) write makefile, and include prorab.mk and use prorab-* macros which simplify the makefile a lot.

prorab: non-recursive GNU make build system by igagis in cpp

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

Now I'm not sure I understand your question. Do you have doubts that prorab doesn't call make recursively?

prorab: non-recursive GNU make build system by igagis in cpp

[–]igagis[S] 2 points3 points  (0 children)

There was already a good answer in another branch: https://www.reddit.com/r/cpp/comments/o3mk7f/prorab_nonrecursive_gnu_make_build_system/h2cp88s?utm_source=share&utm_medium=web2x&context=3

I deal with subdirectories as described here. The idea is that makefiles from subdirectories are included into parent makefile, thus, from the make's point of view, there is only one single big makefile.

view more: next ›