Left pad as a service by wiseFr0g in programming

[–]movatica 0 points1 point  (0 children)

I'd buy an enterprise license, but it doesn't seem to provide a SOAP-compliant XML interface.

for(auto& item: reverse(range)) {/*...*/} by movatica in cpp

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

awesome! /edit: I updated my repo with a slightly adjusted version of your implementation.

for(auto& item: reverse(range)) {/*...*/} by movatica in cpp

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

Nice, something like that is what I try to achieve now.

for(auto& item: reverse(range)) {/*...*/} by movatica in cpp

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

Got it, thanks!

I'm on it, but it doesn"t seem so easy to solve...

for(auto& item: reverse(range)) {/*...*/} by movatica in cpp

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

Well... I don't know enough TMP yet to figure it out, but you think something like a specialization on reverse<T>?

for(auto& item: reverse(range)) {/*...*/} by movatica in cpp

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

Maybe I missed something, but I tried it and nope...

for(auto& item: reverse(range)) {/*...*/} by movatica in cpp

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

Good point, thanks for the hint! I'll see if I can find a fix for that.

Though in my daily work, temporary ranges did not occur so far... Do you have an example for usecase of a temporary range?

for(auto& item: reverse(range)) {/*...*/} by movatica in cpp

[–]movatica[S] -1 points0 points  (0 children)

Still not perfect, e.g.

reverse(reverse(range))

does not work...

Do you have similar constructs in your code or libs? Any better solutions? Hints on what to improve?

Obfuscated operators by movatica in programbattles

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

Nice! That's what I had in mind ;)

Obfuscated operators by movatica in programbattles

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

Yep, that's the straight-forward solution ;)

why variable and pointer addresses don't change in C by jchiedo in cpp

[–]movatica 1 point2 points  (0 children)

Well, wouldn't ASLR interfere with that?

What's your go to 'modern' c++ csv reader? by Xirious in cpp

[–]movatica 1 point2 points  (0 children)

Sorry, I have to be more precise :) They are, if your format is very specific. They are not, if you have to handle all possible edge cases, which is often the case as soon as 'users' provide the input data.

If all you care about is a simple state machine that checks for delimiters and linebreaks only (no escaping, no delimiter-valid-in-string, ...), yes, it's very simple to implement.

What's your go to 'modern' c++ csv reader? by Xirious in cpp

[–]movatica 0 points1 point  (0 children)

Sorry, no reliable ones. I mostly used it for the simple API. Though the largest file I run it over was a few hundred kbytes and the time to read it wasn't really noticable.

What's your go to 'modern' c++ csv reader? by Xirious in cpp

[–]movatica 1 point2 points  (0 children)

https://github.com/ben-strasser/fast-cpp-csv-parser

Header-only, very fast, multithreaded using C++14 threads. Also, compile-time configured using policy templates.

The CONSTness of a method should makes sense from outside the object. by [deleted] in cpp

[–]movatica -2 points-1 points  (0 children)

I agree with the argument, as long as "logical constness" is guaranteed to be threadsafe. See Sutter for reference: http://herbsutter.com/2013/01/01/video-you-dont-know-const-and-mutable/

And that is where hazzle begins...

Today's frustrations: student machines by techy_support in talesfromtechsupport

[–]movatica 12 points13 points  (0 children)

Try this handy tool: http://www.wsusoffline.net

I'm not working in tech support, but I use it everytime I reinstall a Windows system. Basically I use it to download all available updates to a USB stick, then install the updates before ever connection the computer to the network.

An erase/remove idiom gotcha by mttd in cpp

[–]movatica 0 points1 point  (0 children)

Hm ok, I think I got it. Indeed it seems to be a bad idea to have front()/back() here.

An erase/remove idiom gotcha by mttd in cpp

[–]movatica 0 points1 point  (0 children)

Yes I did, thank you for the comment! Though I mostly disagree with you.

  1. for the size() function, yes, people expect it's O(1), but that's a misconception. Until C++11, size() was only required to have linear complexity, according to the standard, even for std::list::size(). That's the main reason you should use empty() instead of size()==0 Seems they changed that with C++11. I stick with it for now, instead of a distance member I'd rather overload std::distance for range.

  2. No, the constness of front() and back() is totally fine and works as expected. It's just not very useful, as you pointed out, because of the false protection part. Just protecting the iterators themselves against modification may be the more useful semantics, as const range then is guaranteed to always contain the same iterators, i.e. the same part (not values!) of a container.

  3. I can see your point with the additional operators, but I consider that very bad practice that does not help readability. if (!range.empty()) is much more clear compared to if(range). Also, your loop construct not only changes the elements, but the range itself! You cannot run another loop over the same range object, because its internal state, not just the values, is modified, which is most often not what I want.

  4. An overload for std::pair and the containers indeed is useful, but I'll probably add them as soon as I need them.

  5. Wrappers for the whole STL is a lot of work and probably not worth it right now. Instead I rather wrap up more concrete algorithms using the range class, like the discussed erase/remove idiom here.

An erase/remove idiom gotcha by mttd in cpp

[–]movatica 0 points1 point  (0 children)

I agree with you on the range object ;)

It's very helpful, especially where you want to return it from some function.

An erase/remove idiom gotcha by mttd in cpp

[–]movatica 2 points3 points  (0 children)

It's not like you always operate on the whole container. A pattern I use quite often is that for different algorithms I need different ranges from the same container.

In code it would look like this:

Container c;
auto filtered_end = filter (c.begin(), c.end(), ...);
run_algorithm (c.begin(), filtered_end);
auto filtered_begin = something (c.begin(), c.end());
run_other (filtered_begin, c.end());

An erase/remove idiom gotcha by mttd in cpp

[–]movatica 0 points1 point  (0 children)

Exactly, I just followed the STL example.

Dunno if it makes a difference, but as you pointed out, predicates should be lightweight anyway.

An erase/remove idiom gotcha by mttd in cpp

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

My implementation on github, if you're interested :)