Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:Plain ol' C might a better option (Score 1) 296 296

std::vector a {1, 2, 3,4, 5};
for(int &v : a) {...}

Uses a reference, short and clean. Before C++11 the STL was a little copy constructor heavy, but only if you use it that way. If you use large objects, make your vector a vector of unique_ptr. It cleans up the data automatically when you delete the vector. On top of that, move construction/assignment should remove the majority of the cost of copying objects around in STL containers.

An STL implementation presumably could fairly easily optimise a vector> to a single type erased implementation, as long as the code that called delete had the type available. In the end you're trading code growth against pointer indirection and most evidence I've seen suggests that code growth is the smaller issue in the majority of code bases. I'm sure there are exceptions though.

Comment: Re:Plain ol' C might a better option (Score 1) 296 296

It's more the association of destructors with objects that makes C++ different. Ensuring that a particular function is called when an object is destroyed needs compiler support. RAII is a huge benefit of C++ over C. Although admittedly it is most important in the context of exceptions, which are themselves a C++ feature.

Comment: Re:Expect an updated U.S. travel advisory. (Score 1) 28 28

Right. It's a pleasant experience for an organised tour. From the tourist point of view much less of a hell hole than all sorts of places you can visit in more liberal countries - including poorer parts of the US. Of course, in a large part that's because they are presenting an image to try to make the place seem better than it really is. In reality they do a good enough job to make the tour pleasant, but not a good enough job to make you come away thinking it's the utopia they would like to make out - the reality is pretty hard to hide. You can get enough of a gist of what they don't want to show you to see something of the underlying situation.

The US takes a far harder line on NK travel advice than other countries do. Partly because the authorities really do dislike the US and have been known to take that out on American citizens. Partly presumably for the same underlying reason the US has such a harsh line on travel to Cuba that other countries do not have. After all, I don't think many people outside the US believe the Cuba travel/spending ban is intended to benefit Cubans. There were Americans on our tour, though, and they were well treated. This was all long enough ago that they still held mobile phones at the airport, but my understanding is that rules have relaxed considerably since then both in terms of phones and freedom to leave the hotel without a guide.

The bigger challenge with travel to NK is the ethical question about giving money to the authorities there when paying for travel in the first place. We were torn on that for a long time before deciding to go. In the end we decided to largely because it would be better to see something of it than to jump to conclusions.

Comment: Re:The problem with older developers... (Score 1) 429 429

Often even up to VP level. Other companies treat management as an optional add on to a technical role up to some fairly high level in the organisation. It still depends a lot on what you want to do, though. Few of those Fellow/Director of Technology/whatever other tech track title roles at the high level end up really having a lot of coding. You're exchanging making decisions about people for making decisions about projects.

Comment: Re:nonsense (Score 1) 532 532

That is true, but maybe one reason for that is that only people the government doesn't care about, democratically speaking, suffer from it. The NHS in the UK affects almost all voters, even most middle class people use it for most things, and so there is more incentive to keep a reasonable standard of service. It also means the service for the very poor is integrated with the service for everyone else, so you don't end up in the same situation of a doctor restricting NHS patients in favour of private ones to anything like the same degree you see with medicaid.

Dental care is a bit of an exception, but in part that is because while dental bills get high they don't generally reach bankruptcy levels in the way hospital bills do. A lot of UK dentist have dropped support for NHS dental treatment for adults. Not for children, though, which is probably why the UK rates so well on dental health.

Comment: Re:nonsense (Score 1) 532 532

Have your French cousins experienced American healthcare? One of the big things British and French expats miss when living in the US is the healthcare.

If you are wealthy and have good private insurance, then American healthcare works well. British and French top up insurance and private care is comparable, though. If you are not rich, and had to rely on the government healthcare in Europe, then the American version is inferior.

Comment: Re:nonsense (Score 1) 532 532

Before even reaching single payer, there needs to be a legal requirement for a single charger! If you go to a particular doctor for treatment, ALL bills should come from that doctor or his facility. If they contract, that doesn't matter, that doctor is responsible for telling you how much you owe, being in-network with the insurance companies and so on. The current situation of going to an in-network doctor only to find he uses an anaesthetist or lab who is out of network and thus only partially covered is insane.

Comment: Re:stupidly weak (Score 2) 267 267

Your first word is 7 digits your second is 3, so clearly one is stronger than the other. "nom" is not in the diceware set, which helps a little, but it isn't so uncommon to be in a search dictionary. The numbers are in the diceware set.

You're comparing 7700^3 against 7700^7. Your more secure password isn't any better than chickensandwichwafflesworkcraigcrossafrica, probably a lot less good because chicken, delicious and nom clearly correlate heavily and nomnomnom is almost one word really. 7700^7 is 1604852326685300000000000000 according to my calculator. If I assume 72 characters (52 letters, 10 numbers, 10 special characters) then I need a 15 character random password to beat it in terms of search space. Maybe this: }&X$0ueUo~ravx&.

Further, if you put numbers between your letters you are turning a search space of 7700 into 7710 or whatever. If you replace l with 1 and so on, you are surely turning 7700 into 7700*(number of replacement options and combinations thereof). So mathematically, I would think that replacing e with 3, a with @ would actually be a stronger encoding that what you suggest.

Comment: Re:Why do we need Auto? (Score 1) 193 193

You are indeed correct. Polymorphic lambdas as defined in C++ only apply template polymorphism to them. That's a subset of the possible forms of polymorphism, but I shouldn't really have used the term given that it has a definition in the standard now. Java lambdas (or C++ std::function wrapping of a lambda) is a different situation - those are only statically typed to the point of the interface, so any use of the lambda has to rely on a more dynamic typing mechanism (virtual function calls, maybe JIT inference), which is the situation I was alluding to.

Comment: Re:Why do we need Auto? (Score 4, Informative) 193 193

Lambdas are a primary place where auto is there precisely because C++ is a strong, statically typed language as far as possible. The alternative might be polymorphic lambdas, which would require dynamic typing. With auto the type you get, and can propagate through templates, is the type of that specific lambda. With polymorphism the type you'd get is the type of a lambda, from which you'd need to infer which lambda. Auto ensures that with a lambda, though the type is not easily known to the programmer, the type can be statically defined in the code and propagated accordingly.

Comment: Re:The answer is called LLVM (Score 1) 69 69

Google supports LLVM in the NDK. Renderscript is more like OpenCL where they restrict the input to make portability easier. Google also has the portable native client definition that aims to do something more general as you are suggesting, though that's for the desktop not android, admittedly. The thing is that LLVM is not actually portable between 32-bit and 64-bit anyway because C loses too much of that information at the early stages of compilation.

If you look at the SPIR spec (https://www.khronos.org/spir), which is an attempt to write a standardised version of an LLVM subset as you suggest, but for the OpenCL C subset so avoiding some of the complexities, you'll see that there are 32-bit and 64-bit versions and it really relies on the fact that OpenCL defines the sizes and layout of types more strictly than pure C does. LLVM is not a panacea in this case and a browse of past LLVM mailing lists will tell you that many of the devs are not keen on using it for portability because it isn't really what the IR was designed for.

Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who, "Androids of Tara"

Working...