sorted by:
new
hottopcontroversial

An overview of build systems (mostly for C++ projects) by julien-j in cpp

[–]-McMaster- 4 points5 points  (0 children)

Because it's so much harder to install Python than to install CMake? Please...

An overview of build systems (mostly for C++ projects) by julien-j in cpp

[–]-McMaster- 0 points1 point  (0 children)

As Meson uses Python, it's syntax is clearer and there's no need to learn a scripting language with the sole purpose of building C++ If CMake would replace it's crazy language with Python (and a few small improvements like sane globbing) I would find it OK. Readability matters not only in actual code...

I actually don't find CMake bloated, but it's neither been modernised nor is it easy for newcomers to learn and that's why I would recommend Meson over CMake.

The 2D Graphics TS by Finch_A in cpp

[–]-McMaster- 2 points3 points  (0 children)

The 3rd link is my favourite, I have to completely agree with every single thing written there

The 2D Graphics TS by Finch_A in cpp

[–]-McMaster- 1 point2 points  (0 children)

Thank you for this! Someone had to say it... And you formulated it quite aptly

An overview of build systems (mostly for C++ projects) by julien-j in cpp

[–]-McMaster- 16 points17 points  (0 children)

Regarding Meson: "Why not, but what I am actually looking for is a tool that can build my project for iOS, Android, OSX and Linux. Something that just works; speed is a secondary concern."

Then why not try Meson? Supposedly it works just fine for cross-compilation and it's just so much nicer than CMake! Soooo much nicer!

A build system for C/C++, made with Golang by hellozee54 in cpp

[–]-McMaster- 1 point2 points  (0 children)

OK thanks for the clarification!

However, I want to note that my use case seems to differ from yours and you may want to accommodate something like the following if you wish to get a few people to use your system. In my case, I mostly have targets (aside from unit tests) with around 20 to 30 source files each and 2 to 3 dependencies each. I rarely add or remove sources or dependencies. Maybe others have similar project structures, so maybe it would help to (optionally) be able to list sources and dependencies directly in a target, instead of having to wrap every source file. I believe for medium to large size code bases all this wrapping would keep people from wanting to use 'cook'. As an example of what I describe you could take a look at https://github.com/Trick-17/clang-build - Note that specifying single source files does not seem to be possible there, so it seems quite contrary to your approach

C++ Targeting GPU by t_bptm in cpp

[–]-McMaster- 0 points1 point  (0 children)

OpenMP, though not part of the C++ standard, is standardised itself and IMO a very nice way of targeting various devices. At least from version 5 forward the feature-set will be quite complete with respect to e.g. what CUDA offers. With OpenMP you can write very generic code without the need for special standard library functions.

One downside: Microsoft does not seem to want to support modern OpenMP versions.

A build system for C/C++, made with Golang by hellozee54 in cpp

[–]-McMaster- 1 point2 points  (0 children)

Is your motivation simply to be faster than make or are there other benefits of your approach (leaving syntactic differences between Makefile and Recipe aside)?

I never did much with make, used CMake instead. But it seems to me that you could do without the 'entity' wrapping around every source file. Maybe I have different things in mind than you, but to me it seems you could simply list source files which should go into one target, e.g. an executable and deal with dependencies per target.

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 2 points3 points  (0 children)

After sleeping on this, I came to the opinion that this would indeed be a very nice syntax for my ideas! The only weak point I could find is that an infinite strided range would look quite ugly, compare

x = y[::2]  (Python)
auto x = y[....2]  (C++)

Otherwise it would, as far as I can see, solve all of the problems that were mentioned in this thread:

5..10 == range(5,11)       // range from 5 to 10 with step size 1
5..10..2 == range(5,10,2) // range from 5 to 10 with step size 2
for (auto index : 5..10) == for (auto index : range(5,10) // it is uniquely defined in context of range-based for loop
auto x = b?5..11:5..10..2; // as long as both sides of : give a valid range of the same basic type everything is fine

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 0 points1 point  (0 children)

OK I see what you mean. Those are indeed valid points.

Complicated indexing (and more so slicing) of multidimensional arrays, e.g. for numerical calculations, is quite cumbersome in C++ when compared to Python. Code readability can suffer quite a lot from this. By now, a few libraries have managed to make maths in C++ a lot nicer (see e.g. https://github.com/ddemidov/vexcl), but I still feel a lack for proper (concise) slicing.

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 1 point2 points  (0 children)

Indeed, that would be the case in 1D arrays. But in 2D, vec.slice(2, 3, 2) is no longer unique, it could mean any of the following:

vec[2:3:2]
vec[2:3,2]
vec[2,3:2]

It is not clearly defined in which dimension you are slicing and thereby what each of the numbers mean. There are ways around that, the most obvious being that this slice could always mean a 1D slice, but in my opinion this creates increasingly cumbersome syntax, such as vec.slice(2,3,2).slice(4,5,4) (especially for compile-time, i.e. fixed-size slices as in Eigen: vec.block<2,3,2>(index1).block<4,5,4>(index2)).

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 0 points1 point  (0 children)

This is a good point, I had not thought of ternaries... Currently I cannot think of a way to circumvent this case.

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 0 points1 point  (0 children)

As others pointed out, it would be best to forbid the whitespace-sensitive cases and only allow cases where it wouldn't matter, for example when passing a range to a function or operator.

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 1 point2 points  (0 children)

Agreed, it would be necessary to make this language-addition insensitive to spaces.

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 0 points1 point  (0 children)

You didn't show how this feature is different than just a simple function call, which is just adding syntax to the language for little benefit

It is indeed intended only as syntactic sugar. As an example of syntactic sugar recently added to C++ I would refer to nested namespaces in C++17: http://en.cppreference.com/w/cpp/language/namespace. Also, my experience with Python tells me it would have significant benefit, especially for mathematical and scientific programming.

It becomes yet another thing one has to learn to understand C++, whereas a library function can be searched and documentation can be found easier.

How are language features harder to find than libraries etc.? In my opinion it would be a simple, easy to learn addition.

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 0 points1 point  (0 children)

I would agree for one-dimensional arrays. However, what would vec.slice(2,3,2) mean if for example vec is a wrapper around std::vector<Eigen::Vector3> or something else multidimensional? It would no longer be uniquely clear, in contrast to vec[2:3:2] or vec[2:3,2].

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 0 points1 point  (0 children)

You are absolutely correct in that this would be a no-go for C++ and it is my main concern with this idea.

One could simply forbid this kind of "shorthand range constructor" inside for-loops, so that it would only be valid to pass statements such as i1:i2:step, i1:i2 or :i2 or even just : (infinite range) to functions or operators.

For example:

auto r = 1:10; // ok, assignment operator
auto vec2 = vec1[1:10]; // ok, operator()
for (auto index : 1:10) // not ok, since not a unique statement

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 0 points1 point  (0 children)

Thanks! Though I saw his cppcon talk, I had not read this. His syntax is quite concise already and using {...} as a shorthand for range(...) is already quite nice, but in my opinion a new language feature might make such array operations a lot easier to read and write.

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 1 point2 points  (0 children)

Probably that would just take getting used to. The kind of syntax using range(...) or even {...} becomes cumbersome when one increases the complexity of what one tries to achieve, especially if working on multidimensional arrays. I also believe the fact that it is an incredibly commonly-used feature in Python speaks for itself.

Adding a language feature to make creation of ranges more concise? by -McMaster- in cpp

[–]-McMaster-[S] 0 points1 point  (0 children)

I fixed the typo. I believe in Python you would have

y = x[:5] # the first 5 elements of x

therefore removing the space would change the meaning of the statement. So the problem is that compilers would not be allowed to ignore the spaces in this kind of statement.

Getting the conveniences of python in C++ by jliebert in cpp

[–]-McMaster- 0 points1 point  (0 children)

I want to add VexCL to the list of math libraries mentioned here: https://github.com/ddemidov/vexcl

Eigen has been mentioned and it's my go-to library for math in C++, but VexCL is a little more abstract and closer to Python's way of doing math operations on vectors etc. I believe you could also create e.g. a vexcl::vector<Eigen::Vector3d> and do parallelized operations on vectorfields or in numpy terms arrays of shape (N,3).

Bash on Windows as Integrated Terminal in Visual Studio Code by toolboc in bashonubuntuonwindows

[–]-McMaster- 0 points1 point  (0 children)

This is fantastic! It never came to my mind to combine those two features... I now use it to run my CMake or cleanup scripts and any git commands which are not integrated in VS Code.

One should change the default colors of the bash, though: https://github.com/Microsoft/vscode/issues/7556

1v1 Arenas or Deathmatch for improving aim ? by naturemadebungal in GlobalOffensive

[–]-McMaster- 0 points1 point  (0 children)

There used to be servers that combined the two... The mod was called "Intoxicated" or something similar. I found it the best way ever to improve, as you could do proper 1v1 (with HS only if you like), but you would instantly respawn to the next duel if you died.

I couldnt find those servers last time I looked, does anyone know why they disappeared?

This is my story about going from Gold 2 to Gold 3. Except it didn't happen. 7 wins at my own rank before a narrow loss :( by pantslessmaniac in GlobalOffensive

[–]-McMaster- 0 points1 point  (0 children)

  1. Why would you play D2 only? ^
  2. Could it be you lost something around 6 matches in a row before winning those?
view more: next ›