You get very little feedback other than a handful of grades.
While there are a few teachers who are absolutely terrible -- worse, a few of those have tenure -- I've found far more teachers who actually are passionate about their field, whether or not they can communicate that in class. Talk to them. Go to office hours. If you don't have another class immediately afterwards, follow them out of class!
If you're willing to accept only a handful of grades, that's what you'll get. The few students who care enough to demand more will likely get more.
Even in that case, there are opportunities to make it technical as well. In my first English course, I wrote a script to generate precisely the right amount of random characters to look like "code", then applied that as a background to a brochure on cryptography. The rest of the brochure was designed using Scribus, which was worth learning as a skill, especially since later programming courses will require groups to create posters for their projects.
In my second English course, I was required to give an oral presentation in a PowerPoint presentation. I wasn't going to trust OpenOffice to do this right, as even PowerPoint made it difficult -- you'd have to have it reference audio files physically close to it on disk, zip them all up, and send them to the instructor. I refused to buy and install PowerPoint, or bring a microphone to a computer lab. Instead, I did it all in HTML5, mostly by hand (with jQuery), which also let me build exactly the animations I wanted and sync them to the audio. While the resulting code isn't pretty, it is something I may return to at some point, because the resulting presentation was awesome and I want to be able to do more like that.
Disclaimer: Again, talk to your teacher, especially before you try something like the above. As it turns out, PDF was perfectly acceptable for the brochure (though print was also required), and my teacher didn't really care what format the presentation was in so long as she could view it (and she had a decent browser). But you don't want to try to ask forgiveness instead of permission on something like this.
At a whole lot of schools, these classes have become little more than perfunctory checks on writing and attendance.
So, this is again sounding like English, which did indeed require attendance. It wan't an arbitrary requirement, though -- there would often be class discussions, and the assignments were such that you'd often want to be there to make sure you understood them.
It also attempted to teach rhetorical skills and critical thinking, both of which are incredibly lacking in our field, and both of which are improved both by practice and by being restricted to arbitrary subject matter and forms of presentation.
And that's just the gen-ed English that absolutely everyone needs. There's also a technical writing course required for fields like CS.
How much of this has anything to do with YouTube? I think YT uses the DRM on actual movies, but on individual videos, I can trivially capture the stream -- and often, I can use HTML5 instead.
Also, how much of this has anything to do with politics? It's my understanding that it has much more to do with the demands of content owners, rather than politicians.
I mean, the speed with which all my extensions were patched tells me that either open source developers really are ridiculously better than in-house enterprise devs, or the changes weren't that big.
But security patches do that routinely, too -- it doesn't take a major version number. Ubuntu patched my Firefox to 5. When I started it up, I got a notice that Zotero was incompatible. I clicked "next" a few times while it grabbed the upgrade to Zotero, which is compatible. This is a common occurrence, whether it's a major version or not.
Right. People can and do run pirate WoW servers -- admittedly mostly to avoid paying, but it is entirely possible to play on one of those and earn digital items the same way. They aren't transferable to other servers, so it's more like, if you choose to play in that world, only the admins can run a mint -- their money has no value on other servers.
Playing videos on my laptop without killing battery life and burning my lap would be interesting. Granted, that's Flash's fault, not the kernel's fault, but still.
But some examples:
I just played Angry Birds in Chrome -- I don't have a smartphone. Before JavaScript got fast (thank you, v8!), the choices would've been Flash (which is even slower on Linux than elsewhere, and 32-bit), Silverlight (really only works well on Windows and Mac, other OSes get screwed), or a downloadable binary (more work to port, so who knows if it'd even support the Mac). I also didn't actually have to install anything -- I did install the "Chrome app" anyway, but it worked just fine, much easier than buying an app or downloading an installer.
And as a game, I don't care if it or any data I've associated with it are up in the air.
But until Chrome shook things up with V8, this wasn't possible. JavaScript, even with Canvas, was simply too slow for something like this to be practical, which also discouraged people from adding interesting features or developing interesting things for it.
So it does fit what you described. It's "good enough" -- as far as I know, it didn't require a browser plugin, or Google's "native client", or any hacks like that. JavaScript is good enough now. But it wasn't before, and making it faster only means more options open up.
That's one example. I'm sure you can think of more. There seems to be this recurring cycle where we think we have enough performance in some area, and that more is just making things faster -- or in the case of games, just giving you a bigger e-dick by having hundreds more frames per second when your monitor can only handle 60 anyway. And then we get just enough that something which wasn't possible before, or which we had to fake or work around before, now becomes a real possibility.
Take Doom 3, for example. Previous games had mostly static shadows -- Quake 3 had this interesting trick where every fan you saw was synchronized to a spinning shadow texture on the wall behind the fan, all of which was pre-computed so it didn't have to do any sort of shadow stuff in realtime. Doom 3, we finally had enough hardware to give the player a flashlight and let them make their own shadows.
I could go on, but I think you get the point.
The same is not true of penises, by the way. There may be an ideal size, and it may be bigger than yours, but there is such a thing as too big.
Youtube isn't "the same set of features" as a DVD. Granted, there's no reason it should require as much more than a DVD as it does, but it certainly should require more.
First, at least the Flash I get on Ubuntu with Chrome is 32-bit. There was an x86_64 experiment for awhile, but have they actually kept it up, and is it actually stable? If so, I might install it manually, but I do like how my package manager keeps me up-to-date -- but it does so with 32-bit and nspluginwrapper.
Second, define "accelerated". It sure as hell isn't accelerated the way it is on Windows. Two major things seem to be lacking: First, my video card can do native H.264 decoding, but Flash doesn't appear to be taking advantage of it. Second, even when it isn't being choppy as hell (480p is fine, 1080p is noticeably slower), it's still using much more CPU -- take the exact same video and play it with mplayer or VLC, and it plays perfectly, smooth as butter with minimal CPU usage.
It's possible you're right, but if so, this hasn't actually solved the problem, and the problem certainly isn't the Linux kernel or my video drivers, as other video players work just fine, which is why if a video is particularly cool and actually 1080p, I'll find a way to download it and play it natively instead of watching my machine overheat itself to hell with Flash.
I'm not convinced HTML5 is better right now. It's better in that it has the potential to be better, but Chrome dropped H.264, and in any case, I don't currently have an implementation that has an easy fullscreen button with smooth playback -- though I seem to remember that being the case for Safari (mobile or otherwise).
When a non-connected device drifts, I have to manually synchronize it at some point if I want it to be accurate again. That means the high-end analog could easily be five minutes off after a year, which isn't devastating, but it's annoying, especially if I still have the watch after several years. The digital will last ten times longer, so it becomes less relevant, but it's still there.
All of my computers synchronize themselves whenever they get a network connection. The more permanently-connected ones, I've set to synchronize continuously -- I imagine the algorithm to be something like, estimate drift and jitter from past performance, then use that and some tolerance factor (maybe "How far off will I get before it's noticeable over the jitter?") to decide when to re-synchronize, and repeat. There's no reason I can't run this on any computer I want, but my laptop never drifts far enough for me to care before I either reboot it or suspend/resume it, both of which force it to reconnect and re-syncronize.
Since they're synchronizing from various network sources, which eventually synchronize to authoritative sources like atomic clocks, I never have to manually adjust the time. The closest I ever come to that is when I have to tell my computer I've switched timezones -- but my phone knows, so I have a reference.
Would it be better if my computer kept better time independent of the network! Sure, it'd mean it could (theoretically) synchronize fewer times, and I could (theoretically) have a more accurate time when I'm disconnected. (The last part is theoretical because I'm always connected.) But given the choice, I'll happily take a less-accurate timekeeper with reliable auto-synchronization over a more-accurate one which is still going to drift a noticeable amount in its lifetime.
I have two main clocks: My phone and my computers.
I'm not sure how my phone gets its time -- maybe GPS, but that isn't a feature I actually have enabled on the phone. Whatever it uses, it seems to always be aware which timezone I'm in.
However, my computers get their time via NTP at least once per boot, if not continuously. I've set the timezone once, and whenever the lawmakers decide to waste more taxpayer dollars fucking with DST rules, my OS gets patched.
Other companies are not legally forbidden from using - they just have to pay a licensing fee.
Does Apple actually offer that kind of deal? Because as I understand it, there's nothing about a patent which requires you to license it. See: Watt vs Hornblower. Hornblower made a significant improvement to the steam engine, but was unable to actually implement it until Watt's patent expired.
Kind of like how if I really loved OS X, I'd also love Macbooks, but I'd hate the fact that I can't just build a generic desktop PC and put OS X on it, and that Apple will attempt to stop me with both legal and technological means from doing so. Except without the legal force of patents, it's at least theoretically possible for someone to develop an OS to compete with OS X. With patents, there may be some feature of OS X which no other OS can legally implement for the next 30 years, at least.
I mean, at least it's better than copyright, but with computers, 30 years may as well be lifetime + 70.
So Apple came up with a good design and they can get paid by other companies looking to use their good design.
If this was actually the reality, I'd have much less of an issue with it -- though another comment suggests tat Apple actually didn't come up with this design after all.
Or, the other companies can figure out some other approach which might be better.
This is a possible good side effect of patents -- you figure out another way to do the same thing. It might even apply to the power cord here. But sometimes, there is one obvious way to do something -- sometimes it's even implicit in the definition of the problem. And when someone patents it and sits on those patents, that invention gets locked up for 30 years. For three decades, no one can build on that idea and build something even better as a derivative work, without the permission of the person who came up with the idea.
This is a much better situation that other companies just copying what seems to be "good enough" which is what you seem to advocate... Why not have companies seeking a better solution?
Because it means that until someone invents something better (if there is something better which isn't derived from this thing), or until the patent expires, I have three decades of the shitty choice of either buying a Mac (which has many other qualities I dislike) or risk killing my laptop by tripping over the power cord.
With software patents, it's worse, because I'm actually a developer. I have pretty much zero chance of writing any program that does anything interesting without violating dozens of patents, and if someone does decide to sue me, there's a very good chance it would bankrupt me to fight them. This is the worst part of intellectual property -- unlike trade secrets, IP means I can't independently invent and use anything if someone else has patented it, and the sheer number and absurdly low quality of patents out there means that someone has, and I'll never be able to find who or what until they sue me.
I imagine it's not quite as bad in the hardware world, but that's what I'm seeing here.
I'm also curious why companies wouldn't try to come up with a better solution anyway.
There is a reason - cost. You can't have it both ways, where you want the price of the cheaper product, but the features of the more expensive one.
Ok, first, is cost really prohibitive here? I mean...
I'm sure Dell could work around the patent, as most companies do, but it doesn't mean they want to pay for the connector.
I suppose Dell would be that cheap, but I do have a laptop from Dell with an SSD in it. Clearly, a market exists for people who would pay a few pennies extra for some features, but not all of them -- for instance, I don't particularly care that the laptop body be a "unibody", or that the keys are backlit, etc.
Also, "expensive" isn't nearly as much a problem as "overpriced". Pretty much every Mac geek tells you not to buy your RAM from Apple. While I can't find it now, there was a point where they had a black version for $100 more. There was a point where I'd argue that the extra price did go into valuable features, it's just that no one person wants or needs all of these features, and I'm not sure it's a reasonable price anymore.
Most importantly, though: I don't like OS X. I really don't -- the GUI, especially. I'd prefer it to Windows, maybe, but I want to run Linux. And Linux has historically had trouble with Macbooks -- but there are plenty of PC laptops where Linux runs fine, and there's certainly not going to be software incompatibility with a power cord. So above and beyond any financial concerns, I actually can't have what I want at any price, short of hiring developers to fix the problem.
...and this is why we need patent reform, but in the form of accepting fewer patents and for a shorter period of time.
Look, it isn't as though Apple has gained nothing from their "innovation" (assuming they actually invented it) of this magnetic plug. But having this as yet another thing which only works on Macs, which everyone else is legally forbidden from adding with or without Apple's help...
I want to make a case for how harmful this is to inventors, or even everyday coders. It's pretty much impossible now to do any software development without infringing on patents, and even if you somehow manage not to, it's impossible to know without your own legal army to research it.
Instead, I'm going to make a simpler, easier case: I want a laptop which is not a Mac (never had Linux run well on a Mac, I don't like OS X, and I don't really want to pay the premium), but I want it to have that kind of power cord. Call it a "sense of entitlement" if you like, but this isn't just me being cheap -- I want that power cord, with a machine that runs Linux and Win7 reasonably well, and there's no technological reason I can't have that, not even anything like DRM in the way, just raw legal force.
If he had had BitCoins, he merely would have kept a wallet on his phone then transferred the cash to the woman and could have denied the whole transaction had taken place and was clueless about the shrooms in his car. Would they have been able to make anything stick?
What's the harm if they hadn't? I'm sure you can come up with a better example, and I'm sure I don't speak for the entire Bitcoin community, but I really don't see the point in the "war on drugs".
And I have to imagine they would've been able to make it stick. They could prove he spoke to the woman, or they could gather enough circumstantial evidence... Or are you suggesting they'd have an easier time if he'd used cash? Unless they're going to intercept the cash and get his fingerprints, I don't see it. happening.
All the old organized crime tactics like protection rackets suddenly become virtually untraceable when you can demand the money be sent to an anonymous BTC handle and then move it again.
You can't trace it via the money, sure, but you can trace it via the act itself, just as above.
Who traces the stolen wallet files?
This is a serious downside. There is nothing in Bitcoin, currently, which resembles a bank. Money in your wallet.dat is more or less like cash in your pocket, or stuffed into your mattress. Act accordingly.
I realize this is a huge problem for most people. For me, it's an advantage -- while I'm responsible for keeping wallet.dat secure, I can do so in a way that I can't with most banks.
We are aggressively advocating and promoting the legalization and regulation of the exchanges.
You keep saying this but you fail to provide any details on how this will be done. When transactions are anonymous, how in the hell does this happen?
This bit here is why I replied at all.
Bitcoin transactions are anonymous, meaning I can send any amount of bitcoins (that I actually have) to any address, and it's hard for anyone to figure out that I did it, or even build a profile by watching me, since the receiver address is likely generated for that purpose, and I'll have multiple sender addresses.
But this in no way implies that exchange transactions need to be anonymous. If you buy a Bitcoin with a dollar, the associated Bitcoin transaction may not be traceable, but the dollar transaction will, which means the exchange (at the very least) will be able to see where your dollar came from and where it went, and will certainly have a record of something like "User A bought this many Bitcoins from user B, where user A transferred from this bank account, and user B transferred to this bank account." In practice, the exchanges use things like Dwolla (not PayPal, since PayPal doesn't allow anything to do with Bitcoin), but that's still in the realm of being able to trivially trace bitcoins bought and sold for real money.
This shouldn't be surprising to you, since these transactions are as much dollar-based (or GBP-based, etc) transactions as they are Bitcoin transactions.
Pure Bitcoin transactions are much more difficult to trace. You may be able to see that I bought this many BTC for this much USD from this person, but you'll have a much harder time figuring out who I sent it to or what I spent it on. Still, if I wasn't actually buying things with Bitcoins, it's very possible -- look at exchange A to see which account I received the BTC into, watch a transaction for the same amount leave that account and go to another account, and see someone sell coins from the second account at exchange B, and you can piece the story together as "Looks like this person used Bitcoin to send this amount of money to this other person, who immediately cashed it."
That is so bizarre, you're all for the regulation and legalization of exchanges... are you seriously that daft that you don't think the go
Why do you think you are entitled to watch Netflix?
Why do you think I think I am?
The point isn't "boo hoo, I can't watch Netflix," it's that MS tries to claim Silverlight is an open standard, and they use Moonlight to back up that claim, yet the biggest reason people use Silverlight won't work on Moonlight.
If they'd been honest from the beginning, I'd have less to complain about, but then, there'd probably be less adoption.
That said, the only debated example among yours is the last one, where both sides of assignment are of static type B.
If by "static" you mean the reference type, I suppose that's true, but the right reference in that case is still pointing to an object of type D, and exactly the same operation (and loss of information) is going to happen.
Nope, since otherwise a very common C idiom, namely:
int* p = malloc(sizeof(int) * 10);// malloc returns void*
would give warnings.
Ah, you're right. For some reason, I thought it was being exceptionally smart with malloc. Turns out I was thinking of printf.
However, when I use g++ -Wall instead of gcc -Wall, it does generate warnings, and it does so without any sort of magic to make malloc not generate warnings. That makes sense -- in C++, you'd use new instead of malloc anyway.
The non-obvious thing here is that the names can overlap - i.e. it's perfectly legal to have a variable "foo" or (a typedef "foo"), and a tagged type like "struct foo" (or "enum foo" or "union foo") within the same scope - that's what I meant by "different namespaces". On the other hand, you cannot have "struct foo" and "union foo" in the same scope, despite the tags being different.
That is surprising. But hey, at least this is something which would be caught by the compiler, right?
But arrays aren't pointers. Array values decay to pointers in most contexts, and array types decay to pointer types when used directly in function signatures, but you can still have e.g.:
int* (*a)[10];// pointer to array of 10 pointers to int
and this would be a type different from, and incompatible to, int***.
In what way is it meaningfully different? My understanding was that the array syntax, aside from being a useful shortcut for pointer arithmetic, is mostly about allocating arrays of things on the stack. Other than that, the difference is whether you've allocated space for a single value or an array, so I'm not seeing how I couldn't build a pointer to an array of pointers to int using int*** and malloc.
Or just prohibit mixed operations - if you want one, an explicit cast should be in order.
Or a warning, which I thought you'd get, but nope.
If you're assigning or initializing from B& to B, where B& is actually a reference to an object of some subclass D, that's not slicing. Slicing is when you assign from D (not a reference, but an object directly) to B...
Erm... that seems entirely backwards. Your example is indeed slicing, but if I assign from a reference to some subclass D, to a local object (or to another reference) of some superclass B, both of those operations will eventually call the copy constructor or assignment operator, which means they'll be creating a new object of type B which won't have all the fields of type D.
Isn't that what's meant by slicing -- that you're getting a new "copy" of some subclass object, but the copy is in the parent class and loses some things?
As I understand it:
class B{}; class D:B{};
int main() {
D d;
B b = d;// slicing
B &bref = b;// not slicing
B &bref2 = d;// not slicing
D &dref = d;// not slicing
bref = dref;// slicing!
bref = bref2;// also slicing! }
Am I missing something?
On the other hand, if you only have references, then your perf goes down very significantly. If you really implement all your primitives as references to boxed values, then even basic arithmetic has way too many indirections. In practice (i.e. in Python or Ruby), they normally do tagged references so that at least integers don't have to be boxed, but now you have the cost of checking for that tag bit to see if your reference is actually a value or not.
All true, so far. It's interesting to note how performance improves -- sometimes it improves by deliberately killing things, like JRuby's experimental fast math options. (Ruby has open classes and integers, despite being tagged references, are really objects from a semantic point of view, so you can redefine addition. If you disallow that, JRuby makes some aggressive optimizations to make primitive math almost as fast, if not actually as fast, as Java primitive math.) But sometimes, it improves by making smarter compilers and VMs.
My philosophy lately is, 99% of my code could take a thousandfold performance hit and nobody would care. The remaining 1%, I'll rewrite in C.
Alternatively, you can do something like Java, where primitive types are values, and class types are references. But now there's no way for the programmer to extend the set of primitive types with something that looks similar - i.e. no way to have something like Complex as a library type that otherwise behaves exactly like float or double.
It's worse than that. Java's == operator really means "compare reference or primitive". So you have to use Object.equals() when you actually have at least one object, but testing for null requires == anyway. Since == works on primitives, it's probably the first thing most Java newbies will learn, and it even works, sometimes, with actual objects like Strings.
An explicit design consideration for C++ was that it should be able to use C libraries with no or minimal changes. This, in particular, means that it should be able to parse C header files, and provide identical data representation.
I can't remember where, but I've had to do extern "C" anyway, so we don't really have this.
This would actually be a good warning: if we're using "delete" on an operand of type B*, and it has known derived classes and no virtual destructor, then warn.
Helpful, but now we have two additional problems. First, you don't always know about derived classes -- suppose you're writing a library, do you need to also include a test case for everything and check warnings on that? Second, even when warnings are fatal (often a good
On the bright side, that's job security - consider how few people will have the patience to read through all of that.
Frankly, if I wanted job security, I'd be focused even more on mainframes -- stuff like COBOL. If they haven't replaced that stuff by now, they probably won't, and nobody wants to deal with that shit. For that matter, there's this tongue-in-cheek claim that C++ is a hoax, designed for job security.
But I'm much more interested in having a job I actually like. I much prefer my job security is based, not on the amount of crap I'm willing to put up with, but on the quality of the work I actually do.
Slicing is evil, no ifs or buts about that. I'm not against the concept as such, but they clearly should have made it an explicit operation.
Except it's not clear that it could be, or that there wouldn't be some performance penalty if there was. Certainly, at compile-time, you don't always know what the real class is for each object you've got a reference to. At runtime, as I understand it, the idea is that the code which interacts with that object actually is just doing the exact same operations it would do on the parent class, with very little indirection except for (maybe) a virtual call.
I'm not sure, though. C++ seems to allow quite a lot of copying, and probably at least partly for efficiency reasons -- you've got operator=, copy constructors, and now move constructors. I like the Ruby/Java model better, but it isn't without its costs -- the solution is that everything's on the heap, so every variable assignment is either a primitive copy or a reference assignment -- if you want to copy one object into another, you have to implement your own explicit methods to do so.
So I'm not sure C++ actually made a mistake, given its goals, but I really don't like dealing with those semantics when I can avoid them.
A good rule of thumb for dealing with object casts in C++ is to always use dynamic_cast.... And for cases like yours, as in e.g. downcast from void*, it will refuse to compile.
So, not terribly helpful.
The problem may well have been in my design. This was for a class, so I couldn't use something like Boost, so I implemented my own reference-counting pointers. I gave them the ability to be casted, though I remember having to give them their own syntax for this. The original solution was to have the backend object, where the count is actually stored, use a void pointer, and then perform the cast at the reference site -- which worked well, aside from this issue, and I did include code to check that I could make such a cast.
What I eventually ended up doing to work around this problem was to effectively have the casts start to build a tree, so if I did something like:
rc_ptr<X> x = new X(); rc_ptr<Y> y = x.cast<Y>(); rc_ptr<Z> z = y.cast<Z>();
I would then, on every access to z, have the original X object cast to Y and then to Z. Effectively, z now has an rc_ptr to y inside it, which now has an rc_ptr to x.
Ew. There has got to be a better way of doing that, but the best I can think of is to make the object graph even more complex by having a pointer to the real object stored somewhere for each type I need to access it as.
Then again, do shared_ptrs allow casting at all? What do people actually use in situations like this? From what I could tell, it looks like people mostly just use pointers directly.
This is the consequence of "don't pay for what you don't use". Any virtual member means vtable, which makes instances fatter by the size of vtable pointer, adds extra code to constructor to initialize that pointer, makes calls to the member slower due to one extra level of indirection, and makes the class non-POD (meaning that many guarantees about layout of d
MS uses Silverlight, the nerds rage. MS stops using Silverlight, the nerds rage.
The correct approach would have been to either never start with Silverlight, or make it an actually open standard to begin with -- I still can't watch Netflix on Moonlight. When someone's beating you with a stick, and they stop, you don't thank them for stopping, do you?
To be fair, though, I wasn't going to bash them for it. I wasn't likely to praise them much, more like "Hey, they're finally doing something right! Shock!" But on this thread already, it seems like we're seeing at least as many pre-emptive strikes against the bashing as we are actual bashing.
I dare say that the big thing about C++ are really templates, not classes/exceptions.
Actually, now that I think about it, that and proper namespaces are pretty huge. Classes aren't that big a deal, but having decent containers in the standard library is very helpful. Exceptions are near the top of my list, though, because that instantly cuts the amount of error-handling code I have to write in half, while probably making my program twice as robust, since there's much less chance it'll just ignore an error and keep going.
Anyway, what's bloated about it? Remember, you don't pay for things that you don't use.
Yes, I do. I still need to learn about those things at least enough to read them when others use them.
If you want, you can write code that is just as efficient (literally: opcode for opcode) as in C.
Clearly "bloated" was the wrong term, as you're the second person to interpret this largely in terms of performance.
The issue is that C++ is a big enough and complex enough language that very few people come close to actually understanding it, and I'd guess most people that use it sanely restrict themselves to a sane subset. This has a few very hazardous affects: First, if you're using a subset, this means that when you come across something someone else wrote, it's much harder to figure out what's going on. Second, it means there are tons of quirks in the language that are going to surprise you, no matter how well you think you know the subset you've staked out as "sane".
A few things that surprised me, though I thought I had a decent understanding of C++:
Slicing. When I first encountered this, I thought I could get around it by allocating everything where this is likely to happen on the heap. Nope.
Typecasting a pointer can change the numerical address it points to. This means typecasting to void and then to a subclass or superclass of the original object doesn't work the way you expect.
Virtual destructors. Apparently, it's a good idea to define a virtual constructor which does nothing, even if you would otherwise not have to write a constructor, because the implicit one is not virtual.
I suppose some of this is basic common knowledge, but really? This is as bad as Java fucking up the == operator. In addition, I need to either declare everything virtual and outside the function body (hoping the compiler is smart enough to inline when it makes sense, or turning that option on), or I need to think about low-level crap like that all the time despite that my build system, if not the compiler itself, almost always has enough information to figure it out -- and to make something not be inline, I need to put the class definition in a header and actually type the function in another file so that it's physically not inline, which means I'm typing the name of my class all through this file which is really nothing but defining methods on that class.
So, tons of pointless verbosity (the auto keyword will help a little here), tons of low-level details the programmer is forced to either think about or adopt a suboptimal habit because the compiler couldn't be bothered, tons of cruft for backwards-compatibility (even with C)... I'm not talking about the resultant binary. The language itself is bloated, and the actual source code I'd be writing is bloated. I'll happily take a severe performance penalty where I can to avoid dealing with that bloat.
That means that what you tought about the first example is now true.
According to other posters, no it's not. There's a new syntax introduced which allows me to write code similar to the naive swap, but which runs efficiently. To be efficient, it requires support from the underlying object, but that object doesn't need to be COW at all -- in fact, it's a move, not a copy, the old version is invalidated at that point.
Making a general porpouse library with copy-on-write semantics on C++ used to be quite hard
Not really. Other posters have suggested that std::string might not use COW implementations because that's hard to make efficient and thread-safe, but it's certainly not difficult to do in a thread-unsafe way (trivial, really), and I can't see it being difficult to do (however inefficient) in a thread-safe way.
The second part of the type inference section is not about using auto, but about declaring a type from an expression (rather than just defining it from another type).
That wasn't why I was confused. I was confused because between the first part and the second part is this code:
I didn't see the point of that. It's possible the article has been fixed since then, or maybe I missed it the first time, because now it's pointing out the difference between that and the fact that you can now do:
auto ci=vi.begin();
If by bloated you mean a rich feature set that takes time to learn, then yes. If by bloated you mean a syntax that is sometimes convoluted because of the need for backward compatibility, then yes.
Both of these, and more.
Let me put it this way: The Lisps are, generally, very small languages. The syntax is incredibly small, and there are pretty much the bare minimum of language features, but they give you tools which allow you to build more interesting things.
Ruby is about my sweet spot. It's a bit bigger, but there's still a lot of stuff which is moved to the standard library at best, rather than the core language. For example, there's a 'foreach' loop and a 'while' loop, and any other looping construct can be built using those, and can even look pretty, syntactically.
Keeping the core language (especially the syntax) small means there are fewer surprises. It means it's much more likely I can read any arbitrary code snippet and either be confident that I know what's going on, or have a reasonable idea of where to look next.
It's not just that C++ has a lot of features. It's that so many of them are baked into the language and the syntax, rather than a standard library. Even some of the libraries make this difficult by using things like macros instead of language constructs -- partly because the language isn't designed to make this sort of thing easy without macros.
The best advice I've heard regarding C++ that it's actually a fairly nice language, if you deliberately restrict yourself to a reasonable subset. But that also means I can never be sure I'll be able to read someone else's C++ code without having to go back and learn more C++, since maybe they chose a different subset.
The design of C++ was deliberately done to maintain the performance and efficiency of C. Adding objects has no effect on that...
I'm not talking about performance, really. While C++ can feel "heavier" than C, that's purely subjective on my part, and probably has something to do with how much slower C++ compilers seem to be.
I'm talking about the fact that aside from all of the new issues that come with the new features (slicing is my favorite), even the old C-style functionality doesn't always behave as expected, particularly when you're mixing it with C++. For example, in C, this would be reasonable:
int do_something(int (*callback)(void *data), void *data);
int main() {
struct mystruct data;
do_something(&mycallback, &data); }
Phew, that's some ugly syntax, and I'm not entirely sure it'll compile -- certainly needs error checking, but that'd make it even uglier -- but hopefully it gets the point across. This is a pattern I picked up from languages like Ruby and Lisp, and it's about to get a lot easier in C++ with closures. But the relevant bit is that void pointer. This works perfectly well in C, which doesn't have inheritance. And the concept of a pointer being a single ad
Apples and oranges. You can't just say platform independence is less important than garbage collection, they're not comparable.
Bullshit. They are both features Java had which C++ effectively didn't -- and even today, stuff like Boehm doesn't apply universally. All I'm doing is asking which one is the deciding factor for people who started using Java instead.
The main point of this discussion is that a browser OS's could make apps platform independent...
Maybe so, but in that case, I wasn't the one who brought it offtopic. The person I was replying to said this:
And the big thing about Java was that you would be able to write code that was platform-independent, and just rely on a Java interpreter that would be released on any necessary platforms. Which is why everything is written in Java now...
In fact, I quoted exactly that. That is what I was replying to. I was not replying to some abstract main point, I was replying to the actual points the person I actually replied to actually made.
How many people think Java failed?
I should've chosen my words more carefully, but I'd think it was clear from context that this is about Java failing in its goal of "compile once, run anywhere." How many people think this is actually a reality today?
As a desktop platform, Java pretty much has failed, with some notable exceptions. How many people install Java just to play Minecraft? No, it's on the server where it's really successful, and where compile-once, run anywhere is pointless, because even if I have to compile, I can compile specifically for machines I control, without the portability nightmare of trying to support, say, Windows, Linux, and Mac (especially pre-OSX Macs).
Of course IE no longer comes with a JVM,
Nor does Windows.
Coding like this is just dumb. Using it as an argument is even dumber. If you plant to say that Java shouldn't leave you open to shooting yourself in the foot like this...
I never said anything of the sort. The point is that this kind of coding, dumb as it is, would not happen in HTML, for the reasons I outlined -- specifically, because you actually can't just test your code in one browser on one OS, you have to at least make sure it works in multiple browsers.
It's also worth mentioning that unless you happen to know the File library intimately, particularly if you don't really know or care about Unix, creating filenames by concatenating strings seems like a reasonable approach. It seems dumb when you know better, just as attempting to parse HTML with regexes seems dumb when you know better. But it's not "just dumb" in the same way that most of the stuff on TheDailyWTF is.
And if you have to know which libraries to use (java.io.File) and how to use them effectively in order to make your app portable, what's the point of the JVM again? C++ has libraries, too.
And this is how you'd like the future of coding to be?
Coding more or less to the standards? Sure. In fact, I tend to do that, and survive developing it mostly in one browser -- when I test it on other browsers, I only find mild issues these days, because most of them do have good standards support.
Consider the equivalent on Java -- I'd have to develop on one OS, but then test on several others. I'd need a suite of VMs. I suppose I could get the same benefits if I'm careful, but it's a hell of a lot easier to fire up multiple browsers on one OS. I suppose technically I should be firing up other OSes to make sure that it works in the same browser on multiple OSes, but it's incredibly rare that it'll work on three or four browsers on one OS and fail on a different OS.
There are loads of different VMs out there, with far far less compatibility problems than there are between browsers.
It's been awhile since I've had to do any C++, so maybe I'm just missing something, but it seems like either there's a lot of retarded functionality here, or there's a lot of TFA which introduces a feature, even motivates it, but doesn't actually explain what the new version looks like. For example, with "Rvalue References":
void naiveswap(string &a, string & b) {
string temp = a;
a=b;
b=temp; } This is expensive. Copying a string entails the allocation of raw memory and copying the characters from the source to the target...
Ok, first, what? I thought standard library string implementations were supposed to be efficient, and include some sort of copy-on-write semantics, which would (I would hope) make the above a shuffle-pointer-around instruction instead of a copy-data-around instruction.
Second, here's the newer, better syntax:
void moveswapstr(string& empty, string & filled) { //pseudo code, but you get the idea
size_t sz=empty.size();
const char *p= empty.data(); //move filled's resources to empty
empty.setsize(filled.size());
empty.setdata(filled.data()); //filled becomes empty
filled.setsize(sz);
filled.setdata(p); }
Regarding the first comment, no, I really don't, unless the point is that this is what the code for "moving" would look like if implemented in older versions of C++. But also:
If you’re implementing a class that supports moving, you can declare a move constructor and a move assignment operator like this: class Movable { Movable (Movable&&);//move constructor Movable&& operator=(Movable&&);//move assignment operator };
Ok, cool... But where is this used in the "moveswapstr" example? Does this make the "naiveswap" example automagically faster? Or is there some other syntax? It doesn't really say:
The C++11 Standard Library uses move semantics extensively. Many algorithms and containers are now move-optimized.
...right... Still, unless I actually know what this means, it's useless.
It looks like there's a lot of good stuff here, and the article is decently organized, but the actual writing leaves me balanced between "Did I miss something?" like the above, and enough confusion that I'm actually confident the author screwed up. For example:
In C++03, you must specify the type of an object when you declare it. Yet in many cases, an object’s declaration includes an initializer. C++11 takes advantage of this, letting you declare objects without specifying their types: auto x=0;//x has type int because 0 is int auto c='a';//char auto d=0.5;//double auto national_debt=14400000000000LL;//long long
Great! Awesome! Of course, this arguably should've been there to begin with, and the 'auto' in front of these variables is still annoying, coming from dynamically-typed languages. But hey, maybe I can write this:
for (auto i = list.begin(); i != list.end(); ++i)...
Instead of:
for (std::list<shared_ptr<whatever> >::iterator i = list.begin(); i != list.end(); ++i)...
It's almost like C++ wanted to deliberately discourage abstraction by making it as obnoxious as possible to use constructs like the above. Anyway, that's what I expected the article to say, but instead, it says this:
Instead, you can declare the iterator like this: void fucn(const vector<int> &vi) { vector<int>::const_iterator ci=vi.begin(); }
Slashdot Mirror
You get very little feedback other than a handful of grades.
While there are a few teachers who are absolutely terrible -- worse, a few of those have tenure -- I've found far more teachers who actually are passionate about their field, whether or not they can communicate that in class. Talk to them. Go to office hours. If you don't have another class immediately afterwards, follow them out of class!
If you're willing to accept only a handful of grades, that's what you'll get. The few students who care enough to demand more will likely get more.
Even in that case, there are opportunities to make it technical as well. In my first English course, I wrote a script to generate precisely the right amount of random characters to look like "code", then applied that as a background to a brochure on cryptography. The rest of the brochure was designed using Scribus, which was worth learning as a skill, especially since later programming courses will require groups to create posters for their projects.
In my second English course, I was required to give an oral presentation in a PowerPoint presentation. I wasn't going to trust OpenOffice to do this right, as even PowerPoint made it difficult -- you'd have to have it reference audio files physically close to it on disk, zip them all up, and send them to the instructor. I refused to buy and install PowerPoint, or bring a microphone to a computer lab. Instead, I did it all in HTML5, mostly by hand (with jQuery), which also let me build exactly the animations I wanted and sync them to the audio. While the resulting code isn't pretty, it is something I may return to at some point, because the resulting presentation was awesome and I want to be able to do more like that.
Disclaimer: Again, talk to your teacher, especially before you try something like the above. As it turns out, PDF was perfectly acceptable for the brochure (though print was also required), and my teacher didn't really care what format the presentation was in so long as she could view it (and she had a decent browser). But you don't want to try to ask forgiveness instead of permission on something like this.
At a whole lot of schools, these classes have become little more than perfunctory checks on writing and attendance.
So, this is again sounding like English, which did indeed require attendance. It wan't an arbitrary requirement, though -- there would often be class discussions, and the assignments were such that you'd often want to be there to make sure you understood them.
It also attempted to teach rhetorical skills and critical thinking, both of which are incredibly lacking in our field, and both of which are improved both by practice and by being restricted to arbitrary subject matter and forms of presentation.
And that's just the gen-ed English that absolutely everyone needs. There's also a technical writing course required for fields like CS.
How much of this has anything to do with YouTube? I think YT uses the DRM on actual movies, but on individual videos, I can trivially capture the stream -- and often, I can use HTML5 instead.
Also, how much of this has anything to do with politics? It's my understanding that it has much more to do with the demands of content owners, rather than politicians.
I mean, the speed with which all my extensions were patched tells me that either open source developers really are ridiculously better than in-house enterprise devs, or the changes weren't that big.
Firefox 5 broke quite a few extensions.
But security patches do that routinely, too -- it doesn't take a major version number. Ubuntu patched my Firefox to 5. When I started it up, I got a notice that Zotero was incompatible. I clicked "next" a few times while it grabbed the upgrade to Zotero, which is compatible. This is a common occurrence, whether it's a major version or not.
Right. People can and do run pirate WoW servers -- admittedly mostly to avoid paying, but it is entirely possible to play on one of those and earn digital items the same way. They aren't transferable to other servers, so it's more like, if you choose to play in that world, only the admins can run a mint -- their money has no value on other servers.
Playing videos on my laptop without killing battery life and burning my lap would be interesting. Granted, that's Flash's fault, not the kernel's fault, but still.
But some examples:
I just played Angry Birds in Chrome -- I don't have a smartphone. Before JavaScript got fast (thank you, v8!), the choices would've been Flash (which is even slower on Linux than elsewhere, and 32-bit), Silverlight (really only works well on Windows and Mac, other OSes get screwed), or a downloadable binary (more work to port, so who knows if it'd even support the Mac). I also didn't actually have to install anything -- I did install the "Chrome app" anyway, but it worked just fine, much easier than buying an app or downloading an installer.
And as a game, I don't care if it or any data I've associated with it are up in the air.
But until Chrome shook things up with V8, this wasn't possible. JavaScript, even with Canvas, was simply too slow for something like this to be practical, which also discouraged people from adding interesting features or developing interesting things for it.
So it does fit what you described. It's "good enough" -- as far as I know, it didn't require a browser plugin, or Google's "native client", or any hacks like that. JavaScript is good enough now. But it wasn't before, and making it faster only means more options open up.
That's one example. I'm sure you can think of more. There seems to be this recurring cycle where we think we have enough performance in some area, and that more is just making things faster -- or in the case of games, just giving you a bigger e-dick by having hundreds more frames per second when your monitor can only handle 60 anyway. And then we get just enough that something which wasn't possible before, or which we had to fake or work around before, now becomes a real possibility.
Take Doom 3, for example. Previous games had mostly static shadows -- Quake 3 had this interesting trick where every fan you saw was synchronized to a spinning shadow texture on the wall behind the fan, all of which was pre-computed so it didn't have to do any sort of shadow stuff in realtime. Doom 3, we finally had enough hardware to give the player a flashlight and let them make their own shadows.
I could go on, but I think you get the point.
The same is not true of penises, by the way. There may be an ideal size, and it may be bigger than yours, but there is such a thing as too big.
Youtube isn't "the same set of features" as a DVD. Granted, there's no reason it should require as much more than a DVD as it does, but it certainly should require more.
First, at least the Flash I get on Ubuntu with Chrome is 32-bit. There was an x86_64 experiment for awhile, but have they actually kept it up, and is it actually stable? If so, I might install it manually, but I do like how my package manager keeps me up-to-date -- but it does so with 32-bit and nspluginwrapper.
Second, define "accelerated". It sure as hell isn't accelerated the way it is on Windows. Two major things seem to be lacking: First, my video card can do native H.264 decoding, but Flash doesn't appear to be taking advantage of it. Second, even when it isn't being choppy as hell (480p is fine, 1080p is noticeably slower), it's still using much more CPU -- take the exact same video and play it with mplayer or VLC, and it plays perfectly, smooth as butter with minimal CPU usage.
It's possible you're right, but if so, this hasn't actually solved the problem, and the problem certainly isn't the Linux kernel or my video drivers, as other video players work just fine, which is why if a video is particularly cool and actually 1080p, I'll find a way to download it and play it natively instead of watching my machine overheat itself to hell with Flash.
I'm not convinced HTML5 is better right now. It's better in that it has the potential to be better, but Chrome dropped H.264, and in any case, I don't currently have an implementation that has an easy fullscreen button with smooth playback -- though I seem to remember that being the case for Safari (mobile or otherwise).
When a non-connected device drifts, I have to manually synchronize it at some point if I want it to be accurate again. That means the high-end analog could easily be five minutes off after a year, which isn't devastating, but it's annoying, especially if I still have the watch after several years. The digital will last ten times longer, so it becomes less relevant, but it's still there.
All of my computers synchronize themselves whenever they get a network connection. The more permanently-connected ones, I've set to synchronize continuously -- I imagine the algorithm to be something like, estimate drift and jitter from past performance, then use that and some tolerance factor (maybe "How far off will I get before it's noticeable over the jitter?") to decide when to re-synchronize, and repeat. There's no reason I can't run this on any computer I want, but my laptop never drifts far enough for me to care before I either reboot it or suspend/resume it, both of which force it to reconnect and re-syncronize.
Since they're synchronizing from various network sources, which eventually synchronize to authoritative sources like atomic clocks, I never have to manually adjust the time. The closest I ever come to that is when I have to tell my computer I've switched timezones -- but my phone knows, so I have a reference.
Would it be better if my computer kept better time independent of the network! Sure, it'd mean it could (theoretically) synchronize fewer times, and I could (theoretically) have a more accurate time when I'm disconnected. (The last part is theoretical because I'm always connected.) But given the choice, I'll happily take a less-accurate timekeeper with reliable auto-synchronization over a more-accurate one which is still going to drift a noticeable amount in its lifetime.
I have two main clocks: My phone and my computers.
I'm not sure how my phone gets its time -- maybe GPS, but that isn't a feature I actually have enabled on the phone. Whatever it uses, it seems to always be aware which timezone I'm in.
However, my computers get their time via NTP at least once per boot, if not continuously. I've set the timezone once, and whenever the lawmakers decide to waste more taxpayer dollars fucking with DST rules, my OS gets patched.
Other companies are not legally forbidden from using - they just have to pay a licensing fee.
Does Apple actually offer that kind of deal? Because as I understand it, there's nothing about a patent which requires you to license it. See: Watt vs Hornblower. Hornblower made a significant improvement to the steam engine, but was unable to actually implement it until Watt's patent expired.
Kind of like how if I really loved OS X, I'd also love Macbooks, but I'd hate the fact that I can't just build a generic desktop PC and put OS X on it, and that Apple will attempt to stop me with both legal and technological means from doing so. Except without the legal force of patents, it's at least theoretically possible for someone to develop an OS to compete with OS X. With patents, there may be some feature of OS X which no other OS can legally implement for the next 30 years, at least.
I mean, at least it's better than copyright, but with computers, 30 years may as well be lifetime + 70.
So Apple came up with a good design and they can get paid by other companies looking to use their good design.
If this was actually the reality, I'd have much less of an issue with it -- though another comment suggests tat Apple actually didn't come up with this design after all.
Or, the other companies can figure out some other approach which might be better.
This is a possible good side effect of patents -- you figure out another way to do the same thing. It might even apply to the power cord here. But sometimes, there is one obvious way to do something -- sometimes it's even implicit in the definition of the problem. And when someone patents it and sits on those patents, that invention gets locked up for 30 years. For three decades, no one can build on that idea and build something even better as a derivative work, without the permission of the person who came up with the idea.
This is a much better situation that other companies just copying what seems to be "good enough" which is what you seem to advocate... Why not have companies seeking a better solution?
Because it means that until someone invents something better (if there is something better which isn't derived from this thing), or until the patent expires, I have three decades of the shitty choice of either buying a Mac (which has many other qualities I dislike) or risk killing my laptop by tripping over the power cord.
With software patents, it's worse, because I'm actually a developer. I have pretty much zero chance of writing any program that does anything interesting without violating dozens of patents, and if someone does decide to sue me, there's a very good chance it would bankrupt me to fight them. This is the worst part of intellectual property -- unlike trade secrets, IP means I can't independently invent and use anything if someone else has patented it, and the sheer number and absurdly low quality of patents out there means that someone has, and I'll never be able to find who or what until they sue me.
I imagine it's not quite as bad in the hardware world, but that's what I'm seeing here.
I'm also curious why companies wouldn't try to come up with a better solution anyway.
There is a reason - cost. You can't have it both ways, where you want the price of the cheaper product, but the features of the more expensive one.
Ok, first, is cost really prohibitive here? I mean...
I'm sure Dell could work around the patent, as most companies do, but it doesn't mean they want to pay for the connector.
I suppose Dell would be that cheap, but I do have a laptop from Dell with an SSD in it. Clearly, a market exists for people who would pay a few pennies extra for some features, but not all of them -- for instance, I don't particularly care that the laptop body be a "unibody", or that the keys are backlit, etc.
Also, "expensive" isn't nearly as much a problem as "overpriced". Pretty much every Mac geek tells you not to buy your RAM from Apple. While I can't find it now, there was a point where they had a black version for $100 more. There was a point where I'd argue that the extra price did go into valuable features, it's just that no one person wants or needs all of these features, and I'm not sure it's a reasonable price anymore.
Most importantly, though: I don't like OS X. I really don't -- the GUI, especially. I'd prefer it to Windows, maybe, but I want to run Linux. And Linux has historically had trouble with Macbooks -- but there are plenty of PC laptops where Linux runs fine, and there's certainly not going to be software incompatibility with a power cord. So above and beyond any financial concerns, I actually can't have what I want at any price, short of hiring developers to fix the problem.
...and this is why we need patent reform, but in the form of accepting fewer patents and for a shorter period of time.
Look, it isn't as though Apple has gained nothing from their "innovation" (assuming they actually invented it) of this magnetic plug. But having this as yet another thing which only works on Macs, which everyone else is legally forbidden from adding with or without Apple's help...
I want to make a case for how harmful this is to inventors, or even everyday coders. It's pretty much impossible now to do any software development without infringing on patents, and even if you somehow manage not to, it's impossible to know without your own legal army to research it.
Instead, I'm going to make a simpler, easier case: I want a laptop which is not a Mac (never had Linux run well on a Mac, I don't like OS X, and I don't really want to pay the premium), but I want it to have that kind of power cord. Call it a "sense of entitlement" if you like, but this isn't just me being cheap -- I want that power cord, with a machine that runs Linux and Win7 reasonably well, and there's no technological reason I can't have that, not even anything like DRM in the way, just raw legal force.
If he had had BitCoins, he merely would have kept a wallet on his phone then transferred the cash to the woman and could have denied the whole transaction had taken place and was clueless about the shrooms in his car. Would they have been able to make anything stick?
What's the harm if they hadn't? I'm sure you can come up with a better example, and I'm sure I don't speak for the entire Bitcoin community, but I really don't see the point in the "war on drugs".
And I have to imagine they would've been able to make it stick. They could prove he spoke to the woman, or they could gather enough circumstantial evidence... Or are you suggesting they'd have an easier time if he'd used cash? Unless they're going to intercept the cash and get his fingerprints, I don't see it. happening.
All the old organized crime tactics like protection rackets suddenly become virtually untraceable when you can demand the money be sent to an anonymous BTC handle and then move it again.
You can't trace it via the money, sure, but you can trace it via the act itself, just as above.
Who traces the stolen wallet files?
This is a serious downside. There is nothing in Bitcoin, currently, which resembles a bank. Money in your wallet.dat is more or less like cash in your pocket, or stuffed into your mattress. Act accordingly.
I realize this is a huge problem for most people. For me, it's an advantage -- while I'm responsible for keeping wallet.dat secure, I can do so in a way that I can't with most banks.
We are aggressively advocating and promoting the legalization and regulation of the exchanges.
You keep saying this but you fail to provide any details on how this will be done. When transactions are anonymous, how in the hell does this happen?
This bit here is why I replied at all.
Bitcoin transactions are anonymous, meaning I can send any amount of bitcoins (that I actually have) to any address, and it's hard for anyone to figure out that I did it, or even build a profile by watching me, since the receiver address is likely generated for that purpose, and I'll have multiple sender addresses.
But this in no way implies that exchange transactions need to be anonymous. If you buy a Bitcoin with a dollar, the associated Bitcoin transaction may not be traceable, but the dollar transaction will, which means the exchange (at the very least) will be able to see where your dollar came from and where it went, and will certainly have a record of something like "User A bought this many Bitcoins from user B, where user A transferred from this bank account, and user B transferred to this bank account." In practice, the exchanges use things like Dwolla (not PayPal, since PayPal doesn't allow anything to do with Bitcoin), but that's still in the realm of being able to trivially trace bitcoins bought and sold for real money.
This shouldn't be surprising to you, since these transactions are as much dollar-based (or GBP-based, etc) transactions as they are Bitcoin transactions.
Pure Bitcoin transactions are much more difficult to trace. You may be able to see that I bought this many BTC for this much USD from this person, but you'll have a much harder time figuring out who I sent it to or what I spent it on. Still, if I wasn't actually buying things with Bitcoins, it's very possible -- look at exchange A to see which account I received the BTC into, watch a transaction for the same amount leave that account and go to another account, and see someone sell coins from the second account at exchange B, and you can piece the story together as "Looks like this person used Bitcoin to send this amount of money to this other person, who immediately cashed it."
That is so bizarre, you're all for the regulation and legalization of exchanges ... are you seriously that daft that you don't think the go
Why do you think you are entitled to watch Netflix?
Why do you think I think I am?
The point isn't "boo hoo, I can't watch Netflix," it's that MS tries to claim Silverlight is an open standard, and they use Moonlight to back up that claim, yet the biggest reason people use Silverlight won't work on Moonlight.
If they'd been honest from the beginning, I'd have less to complain about, but then, there'd probably be less adoption.
That said, the only debated example among yours is the last one, where both sides of assignment are of static type B.
If by "static" you mean the reference type, I suppose that's true, but the right reference in that case is still pointing to an object of type D, and exactly the same operation (and loss of information) is going to happen.
Nope, since otherwise a very common C idiom, namely:
int* p = malloc(sizeof(int) * 10); // malloc returns void*
would give warnings.
Ah, you're right. For some reason, I thought it was being exceptionally smart with malloc. Turns out I was thinking of printf.
However, when I use g++ -Wall instead of gcc -Wall, it does generate warnings, and it does so without any sort of magic to make malloc not generate warnings. That makes sense -- in C++, you'd use new instead of malloc anyway.
The non-obvious thing here is that the names can overlap - i.e. it's perfectly legal to have a variable "foo" or (a typedef "foo"), and a tagged type like "struct foo" (or "enum foo" or "union foo") within the same scope - that's what I meant by "different namespaces". On the other hand, you cannot have "struct foo" and "union foo" in the same scope, despite the tags being different.
That is surprising. But hey, at least this is something which would be caught by the compiler, right?
But arrays aren't pointers. Array values decay to pointers in most contexts, and array types decay to pointer types when used directly in function signatures, but you can still have e.g.:
int* (*a)[10]; // pointer to array of 10 pointers to int
and this would be a type different from, and incompatible to, int***.
In what way is it meaningfully different? My understanding was that the array syntax, aside from being a useful shortcut for pointer arithmetic, is mostly about allocating arrays of things on the stack. Other than that, the difference is whether you've allocated space for a single value or an array, so I'm not seeing how I couldn't build a pointer to an array of pointers to int using int*** and malloc.
Or just prohibit mixed operations - if you want one, an explicit cast should be in order.
Or a warning, which I thought you'd get, but nope.
If you're assigning or initializing from B& to B, where B& is actually a reference to an object of some subclass D, that's not slicing. Slicing is when you assign from D (not a reference, but an object directly) to B...
Erm... that seems entirely backwards. Your example is indeed slicing, but if I assign from a reference to some subclass D, to a local object (or to another reference) of some superclass B, both of those operations will eventually call the copy constructor or assignment operator, which means they'll be creating a new object of type B which won't have all the fields of type D.
Isn't that what's meant by slicing -- that you're getting a new "copy" of some subclass object, but the copy is in the parent class and loses some things?
As I understand it:
Am I missing something?
On the other hand, if you only have references, then your perf goes down very significantly. If you really implement all your primitives as references to boxed values, then even basic arithmetic has way too many indirections. In practice (i.e. in Python or Ruby), they normally do tagged references so that at least integers don't have to be boxed, but now you have the cost of checking for that tag bit to see if your reference is actually a value or not.
All true, so far. It's interesting to note how performance improves -- sometimes it improves by deliberately killing things, like JRuby's experimental fast math options. (Ruby has open classes and integers, despite being tagged references, are really objects from a semantic point of view, so you can redefine addition. If you disallow that, JRuby makes some aggressive optimizations to make primitive math almost as fast, if not actually as fast, as Java primitive math.) But sometimes, it improves by making smarter compilers and VMs.
My philosophy lately is, 99% of my code could take a thousandfold performance hit and nobody would care. The remaining 1%, I'll rewrite in C.
Alternatively, you can do something like Java, where primitive types are values, and class types are references. But now there's no way for the programmer to extend the set of primitive types with something that looks similar - i.e. no way to have something like Complex as a library type that otherwise behaves exactly like float or double.
It's worse than that. Java's == operator really means "compare reference or primitive". So you have to use Object.equals() when you actually have at least one object, but testing for null requires == anyway. Since == works on primitives, it's probably the first thing most Java newbies will learn, and it even works, sometimes, with actual objects like Strings.
An explicit design consideration for C++ was that it should be able to use C libraries with no or minimal changes. This, in particular, means that it should be able to parse C header files, and provide identical data representation.
I can't remember where, but I've had to do extern "C" anyway, so we don't really have this.
This would actually be a good warning: if we're using "delete" on an operand of type B*, and it has known derived classes and no virtual destructor, then warn.
Helpful, but now we have two additional problems. First, you don't always know about derived classes -- suppose you're writing a library, do you need to also include a test case for everything and check warnings on that? Second, even when warnings are fatal (often a good
On the bright side, that's job security - consider how few people will have the patience to read through all of that.
Frankly, if I wanted job security, I'd be focused even more on mainframes -- stuff like COBOL. If they haven't replaced that stuff by now, they probably won't, and nobody wants to deal with that shit. For that matter, there's this tongue-in-cheek claim that C++ is a hoax, designed for job security.
But I'm much more interested in having a job I actually like. I much prefer my job security is based, not on the amount of crap I'm willing to put up with, but on the quality of the work I actually do.
Slicing is evil, no ifs or buts about that. I'm not against the concept as such, but they clearly should have made it an explicit operation.
Except it's not clear that it could be, or that there wouldn't be some performance penalty if there was. Certainly, at compile-time, you don't always know what the real class is for each object you've got a reference to. At runtime, as I understand it, the idea is that the code which interacts with that object actually is just doing the exact same operations it would do on the parent class, with very little indirection except for (maybe) a virtual call.
I'm not sure, though. C++ seems to allow quite a lot of copying, and probably at least partly for efficiency reasons -- you've got operator=, copy constructors, and now move constructors. I like the Ruby/Java model better, but it isn't without its costs -- the solution is that everything's on the heap, so every variable assignment is either a primitive copy or a reference assignment -- if you want to copy one object into another, you have to implement your own explicit methods to do so.
So I'm not sure C++ actually made a mistake, given its goals, but I really don't like dealing with those semantics when I can avoid them.
A good rule of thumb for dealing with object casts in C++ is to always use dynamic_cast.... And for cases like yours, as in e.g. downcast from void*, it will refuse to compile.
So, not terribly helpful.
The problem may well have been in my design. This was for a class, so I couldn't use something like Boost, so I implemented my own reference-counting pointers. I gave them the ability to be casted, though I remember having to give them their own syntax for this. The original solution was to have the backend object, where the count is actually stored, use a void pointer, and then perform the cast at the reference site -- which worked well, aside from this issue, and I did include code to check that I could make such a cast.
What I eventually ended up doing to work around this problem was to effectively have the casts start to build a tree, so if I did something like:
I would then, on every access to z, have the original X object cast to Y and then to Z. Effectively, z now has an rc_ptr to y inside it, which now has an rc_ptr to x.
Ew. There has got to be a better way of doing that, but the best I can think of is to make the object graph even more complex by having a pointer to the real object stored somewhere for each type I need to access it as.
Then again, do shared_ptrs allow casting at all? What do people actually use in situations like this? From what I could tell, it looks like people mostly just use pointers directly.
This is the consequence of "don't pay for what you don't use". Any virtual member means vtable, which makes instances fatter by the size of vtable pointer, adds extra code to constructor to initialize that pointer, makes calls to the member slower due to one extra level of indirection, and makes the class non-POD (meaning that many guarantees about layout of d
MS uses Silverlight, the nerds rage. MS stops using Silverlight, the nerds rage.
The correct approach would have been to either never start with Silverlight, or make it an actually open standard to begin with -- I still can't watch Netflix on Moonlight. When someone's beating you with a stick, and they stop, you don't thank them for stopping, do you?
To be fair, though, I wasn't going to bash them for it. I wasn't likely to praise them much, more like "Hey, they're finally doing something right! Shock!" But on this thread already, it seems like we're seeing at least as many pre-emptive strikes against the bashing as we are actual bashing.
TFA provides nothing useful over the site itself, other than a bunch of hover-over-this-text ads.
I dare say that the big thing about C++ are really templates, not classes/exceptions.
Actually, now that I think about it, that and proper namespaces are pretty huge. Classes aren't that big a deal, but having decent containers in the standard library is very helpful. Exceptions are near the top of my list, though, because that instantly cuts the amount of error-handling code I have to write in half, while probably making my program twice as robust, since there's much less chance it'll just ignore an error and keep going.
Anyway, what's bloated about it? Remember, you don't pay for things that you don't use.
Yes, I do. I still need to learn about those things at least enough to read them when others use them.
If you want, you can write code that is just as efficient (literally: opcode for opcode) as in C.
Clearly "bloated" was the wrong term, as you're the second person to interpret this largely in terms of performance.
The issue is that C++ is a big enough and complex enough language that very few people come close to actually understanding it, and I'd guess most people that use it sanely restrict themselves to a sane subset. This has a few very hazardous affects: First, if you're using a subset, this means that when you come across something someone else wrote, it's much harder to figure out what's going on. Second, it means there are tons of quirks in the language that are going to surprise you, no matter how well you think you know the subset you've staked out as "sane".
A few things that surprised me, though I thought I had a decent understanding of C++:
I suppose some of this is basic common knowledge, but really? This is as bad as Java fucking up the == operator. In addition, I need to either declare everything virtual and outside the function body (hoping the compiler is smart enough to inline when it makes sense, or turning that option on), or I need to think about low-level crap like that all the time despite that my build system, if not the compiler itself, almost always has enough information to figure it out -- and to make something not be inline, I need to put the class definition in a header and actually type the function in another file so that it's physically not inline, which means I'm typing the name of my class all through this file which is really nothing but defining methods on that class.
So, tons of pointless verbosity (the auto keyword will help a little here), tons of low-level details the programmer is forced to either think about or adopt a suboptimal habit because the compiler couldn't be bothered, tons of cruft for backwards-compatibility (even with C)... I'm not talking about the resultant binary. The language itself is bloated, and the actual source code I'd be writing is bloated. I'll happily take a severe performance penalty where I can to avoid dealing with that bloat.
What? Really?
That means that what you tought about the first example is now true.
According to other posters, no it's not. There's a new syntax introduced which allows me to write code similar to the naive swap, but which runs efficiently. To be efficient, it requires support from the underlying object, but that object doesn't need to be COW at all -- in fact, it's a move, not a copy, the old version is invalidated at that point.
Making a general porpouse library with copy-on-write semantics on C++ used to be quite hard
Not really. Other posters have suggested that std::string might not use COW implementations because that's hard to make efficient and thread-safe, but it's certainly not difficult to do in a thread-unsafe way (trivial, really), and I can't see it being difficult to do (however inefficient) in a thread-safe way.
The second part of the type inference section is not about using auto, but about declaring a type from an expression (rather than just defining it from another type).
That wasn't why I was confused. I was confused because between the first part and the second part is this code:
I didn't see the point of that. It's possible the article has been fixed since then, or maybe I missed it the first time, because now it's pointing out the difference between that and the fact that you can now do:
If by bloated you mean a rich feature set that takes time to learn, then yes. If by bloated you mean a syntax that is sometimes convoluted because of the need for backward compatibility, then yes.
Both of these, and more.
Let me put it this way: The Lisps are, generally, very small languages. The syntax is incredibly small, and there are pretty much the bare minimum of language features, but they give you tools which allow you to build more interesting things.
Ruby is about my sweet spot. It's a bit bigger, but there's still a lot of stuff which is moved to the standard library at best, rather than the core language. For example, there's a 'foreach' loop and a 'while' loop, and any other looping construct can be built using those, and can even look pretty, syntactically.
Keeping the core language (especially the syntax) small means there are fewer surprises. It means it's much more likely I can read any arbitrary code snippet and either be confident that I know what's going on, or have a reasonable idea of where to look next.
It's not just that C++ has a lot of features. It's that so many of them are baked into the language and the syntax, rather than a standard library. Even some of the libraries make this difficult by using things like macros instead of language constructs -- partly because the language isn't designed to make this sort of thing easy without macros.
The best advice I've heard regarding C++ that it's actually a fairly nice language, if you deliberately restrict yourself to a reasonable subset. But that also means I can never be sure I'll be able to read someone else's C++ code without having to go back and learn more C++, since maybe they chose a different subset.
The design of C++ was deliberately done to maintain the performance and efficiency of C. Adding objects has no effect on that...
I'm not talking about performance, really. While C++ can feel "heavier" than C, that's purely subjective on my part, and probably has something to do with how much slower C++ compilers seem to be.
I'm talking about the fact that aside from all of the new issues that come with the new features (slicing is my favorite), even the old C-style functionality doesn't always behave as expected, particularly when you're mixing it with C++. For example, in C, this would be reasonable:
Phew, that's some ugly syntax, and I'm not entirely sure it'll compile -- certainly needs error checking, but that'd make it even uglier -- but hopefully it gets the point across. This is a pattern I picked up from languages like Ruby and Lisp, and it's about to get a lot easier in C++ with closures. But the relevant bit is that void pointer. This works perfectly well in C, which doesn't have inheritance. And the concept of a pointer being a single ad
Apples and oranges. You can't just say platform independence is less important than garbage collection, they're not comparable.
Bullshit. They are both features Java had which C++ effectively didn't -- and even today, stuff like Boehm doesn't apply universally. All I'm doing is asking which one is the deciding factor for people who started using Java instead.
The main point of this discussion is that a browser OS's could make apps platform independent...
Maybe so, but in that case, I wasn't the one who brought it offtopic. The person I was replying to said this:
And the big thing about Java was that you would be able to write code that was platform-independent, and just rely on a Java interpreter that would be released on any necessary platforms. Which is why everything is written in Java now...
In fact, I quoted exactly that. That is what I was replying to. I was not replying to some abstract main point, I was replying to the actual points the person I actually replied to actually made.
How many people think Java failed?
I should've chosen my words more carefully, but I'd think it was clear from context that this is about Java failing in its goal of "compile once, run anywhere." How many people think this is actually a reality today?
As a desktop platform, Java pretty much has failed, with some notable exceptions. How many people install Java just to play Minecraft? No, it's on the server where it's really successful, and where compile-once, run anywhere is pointless, because even if I have to compile, I can compile specifically for machines I control, without the portability nightmare of trying to support, say, Windows, Linux, and Mac (especially pre-OSX Macs).
Of course IE no longer comes with a JVM,
Nor does Windows.
Coding like this is just dumb. Using it as an argument is even dumber. If you plant to say that Java shouldn't leave you open to shooting yourself in the foot like this...
I never said anything of the sort. The point is that this kind of coding, dumb as it is, would not happen in HTML, for the reasons I outlined -- specifically, because you actually can't just test your code in one browser on one OS, you have to at least make sure it works in multiple browsers.
It's also worth mentioning that unless you happen to know the File library intimately, particularly if you don't really know or care about Unix, creating filenames by concatenating strings seems like a reasonable approach. It seems dumb when you know better, just as attempting to parse HTML with regexes seems dumb when you know better. But it's not "just dumb" in the same way that most of the stuff on TheDailyWTF is.
And if you have to know which libraries to use (java.io.File) and how to use them effectively in order to make your app portable, what's the point of the JVM again? C++ has libraries, too.
And this is how you'd like the future of coding to be?
Coding more or less to the standards? Sure. In fact, I tend to do that, and survive developing it mostly in one browser -- when I test it on other browsers, I only find mild issues these days, because most of them do have good standards support.
Consider the equivalent on Java -- I'd have to develop on one OS, but then test on several others. I'd need a suite of VMs. I suppose I could get the same benefits if I'm careful, but it's a hell of a lot easier to fire up multiple browsers on one OS. I suppose technically I should be firing up other OSes to make sure that it works in the same browser on multiple OSes, but it's incredibly rare that it'll work on three or four browsers on one OS and fail on a different OS.
There are loads of different VMs out there, with far far less compatibility problems than there are between browsers.
Really? Citation,
It's been awhile since I've had to do any C++, so maybe I'm just missing something, but it seems like either there's a lot of retarded functionality here, or there's a lot of TFA which introduces a feature, even motivates it, but doesn't actually explain what the new version looks like. For example, with "Rvalue References":
Ok, first, what? I thought standard library string implementations were supposed to be efficient, and include some sort of copy-on-write semantics, which would (I would hope) make the above a shuffle-pointer-around instruction instead of a copy-data-around instruction.
Second, here's the newer, better syntax:
Regarding the first comment, no, I really don't, unless the point is that this is what the code for "moving" would look like if implemented in older versions of C++. But also:
Ok, cool... But where is this used in the "moveswapstr" example? Does this make the "naiveswap" example automagically faster? Or is there some other syntax? It doesn't really say:
The C++11 Standard Library uses move semantics extensively. Many algorithms and containers are now move-optimized.
...right... Still, unless I actually know what this means, it's useless.
It looks like there's a lot of good stuff here, and the article is decently organized, but the actual writing leaves me balanced between "Did I miss something?" like the above, and enough confusion that I'm actually confident the author screwed up. For example:
Great! Awesome! Of course, this arguably should've been there to begin with, and the 'auto' in front of these variables is still annoying, coming from dynamically-typed languages. But hey, maybe I can write this:
Instead of:
It's almost like C++ wanted to deliberately discourage abstraction by making it as obnoxious as possible to use constructs like the above. Anyway, that's what I expected the article to say, but instead, it says this: