It should be possible to do that using one Ethernet port using VLANs. You could buy a cheap L2 managed switch and use it to trunk two different Ethernet networks on the same port. Then you would configure the Linux networking stack to split the VLANs into separate interfaces.
I am by no means a networking expert and was able to use technique to work around a similar issue in the past. It was easier than I expected!
SIGBOVIK is a parody of computer science conferences. It's a running joke hosted on April Fools Day every year at CMU - and apparently a quite convincing one. ;-)
Source: I attended SIGBOVIK a few times in grad school.
As someone who lives in Pittsburgh - and likes the city quite a bit - I can attest to the fact that: (1) the weather is rarely perfect, (2) the entire city is under perpetual construction, and (3) the lines have not been painted in years. It took me quite some time to comfortably drive in the city because to the narrow streets, poor road maintenance, and bizarre traffic patterns induced by the many bridges and tunnels.
It will indeed be interesting to see how the well the Uber deployment goes in practice. They certainly did not choose an easy place to start.
Concepts, modules, a file system library, and an asynchronous I/O library have all been discussed as additions for C++17 and beyond. Most of these features are standard in modern languages. I would not consider any of these to be "scarcely useful." As someone who uses C++11 on a daily basis, I very much look forward to using these features without a Boost dependency.
That being said: I don't think that a graphics is a good addition to the standard library. It would tremendously difficult to standardize this for the reasons others have mentioned.
"That being said: I don't think that a graphics is a good addition to the standard library. It would tremendously difficult to standardize this for the reasons others have mentioned."
I think that graphics would be a great addition to the standard library. However, it will be tremendously difficult to create a good API that is simple to use for simple cases, yet doesn't limit one to the simple cases, and is flexible enough to fit a wide range of devices and OSes with their favorite graphics libraries.
Web developers want all browsers to support CSS, canvas and SVG, so that their applications port easily between platforms.
Why wouldn't C++ developers get it as easy?
First thing to spend a lot of time on would be what one means with 'graphics'. 2D? 3D? Static or also animated? Windowing system included?
I would go for 2D, static, no windowing system, certainly in the first version. That already could be very useful. Imagine having a standardized way to query what bitmap graphics formats the OS supports, and to easily read and write them.
Also imagine writing a plotting package on top of such a library. Porting it between various OSes would be way simpler than it is now.
But as I said: designing this will be very difficult.
I forgot to add "mostly scarcely useful", instead of "scarcely useful". There are some things that make sense, like file system library and async I/O library that you've mentioned (althrough I don't agree on concepts and modules, but that's up to one's preference), but then comes stuff like constexpr, rvalue reference, Deleted and Defaulted Functions, that aren't essential to most programmers, and mostly just clutter the language, because only like, 1% will use them, and the rest will be like "what the hell is this" when looking at that 1%'s code.
I disagree. I'm a scientific programmer working mainly in C++ and Python. Deleted and defaulted functions help a lot by reducing the amount of code that needs to be written, maintained, and debugged. Rvalue references help by reducing unnecessary copying, which is a huge benefit when working with large data structures. Before, the workaround was classes that wrapped pointers with shallow copy semantics, which turns into an aliasing nightmare.
I had this issue fixed on my mid-2012 15" rMBP. It's known issue with some of the early LG panels on that model. The technician at the Apple store ran some standard image persistence diagnostic script to replicate the issue.
They replaced the display for free outside of AppleCare. I didn't have to argue with them at all, so I suspect that this is their standard response. YMMV if you have a newer model.
The bitfield example is misleading. Section 6.7.2.1/10 of the C99 standard says:
"The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined"
There is no guarantee on the order of the bits inside a bitfield. The compiler may also introduce padding, e.g. for alignment purposes. This makes bitfields unusable for unpacking binary data.
Unfortunately, you're stuck with shifting and masking to replicate the same effect.
I've had very nasty experiences with bitfields even though the order was well defined on that platform. It was an embedded system where someone got the idea to create bitfield access to a cpu register.
The problem was that some bits in that register would be cleared automatically each time, so even if you wrote 0 it would read back as 1 the next time. Some other bit would always trigger an action if you wrote to it regardless if you wrote the same value as it had before, this was called the send_bit and when you wrote 0 it sent some stuff onto the network cable. So code that looked perfectly fine like this:
Actually sent 3 packets instead of 1 because the compiler translated each write of a bitfield member to a write of the whole register, some other bits in bitsa could get corrupted by the bitsb-write since they didn't read back as they were written. I assume the cpu had a minimum addressable unit of 8 bits so the compiler had to translate each line into something like register = (register | setbits) & clearbits; which requires reading the previous value each time just to write a single bit, this is very easy to overlook when you just see the three lines of code being written in a neat sequence.
"sent 3 packets instead of 1 because the compiler translated each write of a bitfield member to a write of the whole register"
So the problem was the fact that the language gives the impression of having more control than what the hardware is actually offering. In this case bit access must have been better left to platform-dependent libraries (when it would present itself as something more than what masks usage can do).
> It was an embedded system where someone got the idea to create bitfield access to a cpu register.
Most PCI/PCIe devices have memory mapped registers that behave similarly. Like DMA registers... Although it's a bit bad idea to trigger send on writing 0 bit to the corresponding bit in the register. But hardware memory mapped registers are weird and these things are common. Like writing 1-bit to clear.
Yeah, combining bitfields with volatile is an extremely bad idea. I've heard, and give some credence to, opinions using volatile at all in normal code, rather than hiding it in a helper or something, is a bad idea, given that that allows reading and writing registers to look the same as normal memory accesses, despite it having extremely different consequences.
That's one of the few nag I have about C; this syntax is fantastic, and theoretically allow the compiler quite a lot of freedom to optimize access to the bitfield, and the fact that it was never standardized means you just can't use it if you want portable code.
Why would you not use A* from the beginning? It's a trivial extension to Dijkstras and is often orders of magnitude faster when an informative heuristic is available.
Also, both algorithms require identical data structures. After all, Dijkstras is just A* with a zero heuristic.
I do agree about the constant factor, though: it's likely that a binary heap would be faster on most data sets.
Unfortunately not. Matrix inversion (or any type of linear algebra, really) deals with real numbers. This problem is nearly a linear program, which can be solved very efficiently, except that some variables are constrained to { 0, 1 }. As a result, it's an integer program, which is NP-hard. Intuitively, this is hard because there are no derivatives (e.g. gradient, Hessian) to exploit in discrete optimization problems.
One heuristic is to solve an IP is to relax the integer constraint to inequality constraints, solve the LP, and round the results. However, this can do arbitrarily poorly on most problems.
I am by no means a networking expert and was able to use technique to work around a similar issue in the past. It was easier than I expected!