u/_node

Are you doing this with an Arduino or Raspberry Pi? Its easy with the Pi, as you are running Linux, and with LIRC installed, running the command:

irsend SEND_ONCE <remote-name> KEY_POWER

Would send the code for the power button, so you just need to repeat that for each key press in your sequence. The python code in the gist linked to below is a quick and dirty way of running a webserver that accepts URLs of the form http://<ipaddr>/power/1/2/3, and would transmit the IR codes to turn the TV on, and switch to channel 123, where <ipaddr> is the IP of the RPi (assuming you are using LIRC on Linux). You can build any combination of key presses by separating them with /.

https://gist.github.com/anonymous/e0e19347e48c581e53f29a1849a5dbd8

If you want to save key combinations and run them in your script, the easiest way is probably to write them to a text file, and modify the above to load the file and run through the commands.

I don't have any experience with an Arduino, so can't help you there.

I've done something similar with my setup. I have a z-wave controller, that supports interacting with devices and triggering scenes via HTTP requests. Using ha-bridge you can configure virtual devices, that Echo can discover, and interact with.

Here are the steps I followed:

1. Solder an IR LED and receiver to a Raspberry Pi Zero, and configure LIRC. See here for a guide.
2. Run a little python script on the RPi that is a flask server that invokes irsend (the LIRC command line tool).
3. Install ha-bridge on my server, and add virtual devices that hit the web server on the RPi to trigger IR commands.
4. Tell Echo to discover them.

I use the above to turn the TV on/off, if you just want scene control, then all you need is steps 3-4. Might be easier than going full custom.

Why format after the push?

You might what to log something that is expensive to format.

In Two's Complement, 11111111 is -1, 10000001 is -127.

not knowing how large an int will be

C++11 has the <cstdint> header, that defines all the integer types. For C++03, you can use Boost

So, you died?

I agree, I'm not sure I like the idea of extending the language to support that, when the same could be achieved with a relatively simple library function.

#include <iostream>
#include <iterator>
#include <vector>

namespace std {
template <class Range, class Function>
auto for_if(Range& range, Function func) -> std::pair<decltype(std::begin(range)), bool>
{   
    auto it = std::begin(range);
    auto endit = std::end(range);

    for (; it != endit; ++it)
    {   
        if (!func(*it)) break;
    }   

    return std::make_pair(it, it == endit);
}   
} // namespace std {

int main()
{   
    std::vector<int> v{1, 2, 3}; 
    auto r = std::for_if(v, [](int i)
    {   
        // do something with i;
        return false; // or false to break.
    }); 

    if (r.second)
    {   
        std::cout << "all done" << std::endl;
    }   
    else
    {   
        std::cout << "break early: " << *r.first << std::endl;
    }   
}   

Edit: alternatively, define for_if to accept 2 forward iterators if you don't/can't use ranges.

The benchmark code and details of their test setup should be distributed along with the code to back up the high performance claim. At the very least it could serve to catch the attention of people for whom performance is critical, as it allows easy benchmarking on their hardware setup.

This isn't thread safe though. Might be something to consider.

Businesses would continue using it for office though.

The author is discussing the algorithm, not the language of implementation.

You can specify a custom deleter with unique_ptr to handle deallocation the way the third party library needs it.

You could do the same before C++11, using boost::ref to store it in the std::vector (which is just a wrapper around a raw pointer, same as std::reference_wrapper).

I'm not sure that's the best example. I would be using std::atomic for a counter shared between threads.

And what it provides are the building blocks for creating more complex scheme. Now you can implement your message passing etc. in a platform independent way.

How do you mean? if you don't know what you're looking for I imagine you'd be doing the same in gdb or a gui debugger, i.e. examining the backtrace (bt) or looking at what variables are in the stack frame (info args)

So unless you're testing very religiously along each execution path (every time you touch it)

Every large system should have unit tests that should (hopefully) pick this up.

what could be easier this? []{ std::cout << "hello world" << std::endl; }

Either way, the kids get something fun to learn with. They used lego technic when I was at school.

The other relevant complaint about C++'s syntax and conventions is that its begin/end iterator things aren't really amenable to chaining. With eager evaluation like in your example you can map/filter/reduce/whatever in one big expression, but I don't think you can do that so well lazily. Ranges (as in D) look like a better solution.

You can use Boost range adaptors for that. It would be nice to see this sort of thing in the standard.

TIL there is a Unix spell checker.

you'd need to introduce a non-nullable pointer type.

Thats what references are for, although they do not guarantee the object being referenced is valid.

If myBlah isn't implicitly convertible to bool, then that won't compile. It would be silly to have a conversion to bool and an operator! that had different semantics.

You can use explicit conversion operators now (works in g++4.7, not sure when it was introduced), the following fails to compile with a missing operator==

#include <iostream>

struct A
{
    explicit operator bool() const
    {
        return true;
    }
};

struct B
{
    explicit operator bool() const
    {
        return true;
    }
};

int main()
{
    A a;
    B b;
    std::cout << (a == b) << std::endl;
}

I wouldn't recommend using it for a meaning other than checking validity of objects, unless you're doing something really wierd. In my experience its what people expect.

Exactly what I was about to post.