I don't think anyone claimed that new and delete were no longer *used*; the point is that *you* don't use them; they are safely wrapped and managed. In the code I work on, any PR containing new or delete would be rejected unless there was a strong and valid reason for making an exception.
And yes, my example was intentionally "super simple" because it was purely to illustrate how they can be used effectively. Creating complex stuff is obviously possible; and in fact easier than creating simple stuff. You can't create an intertwined spaghetti mess of cyclic references without having to manually cope with undoing the mess. So you need to factor that into your design; and let's be honest, it does in most cases constrain the developer to simpler acyclic structures, which is not a bad thing. If you were managing these structures manually with new and delete, the only change you'd need to make is putting a.reset() where you'd originally have the delete, so it's not like this is particularly burdensome. Also note that Java does also have weak references (WeakReference) and for largely the same reasons as weak_ptr.
Have you actually looked at what's going on over IPv6 on your local network right now? Lots of stuff will do autodiscovery and communicate over IPv6 link-local even if you don't have any outside connectivity or global addressing.
And for a local network, all-IPv6 is quite a bit nicer than NATed IPv4; and you can use NAT64/DNS64 to talk to the outside IPv4 world without having any IPv4 networking internally. Rather than being dual-stack, you can be IPv6-only and push IPv4 outside. My ISP explicitly supports this setup.
Well, the arguments to make_unique or make_shared are passed directly to the constructor, so it will call the appropriate constructor in the class. You are not limited to the default constructor.
And circular references aren't a big deal. In the rare event you have a data structure with cycles you can often use weak_ptr in place of shared_ptr (real example: an in-memory representation of an XML tree uses shared_ptr to implement a DAG of element objects and weak_ptr to implement arbitrary cross-references between elements, avoiding cycles of shared_ptr). If that's not possible, the worst case is that you have to manually reset() one or more of the pointers to break the cycles.
Also, note that the make_unique will reduce to a single new at construction and a delete at scope exit, same as if you'd done it by hand (and possibly an additional one on unwind depending upon the implementation, which the old way doesn't cater for unless you explicitly add a try/catch). If you care about exception safety at all times, they make your code massively cleaner, more readable and more robust. And it's removed the possibility for me to lose track of anything.
I think you missed an important concept here: std::make_unique can never, ever ever leak. It returns a std::unique_ptr<T> which will free the allocation and/or transfer ownership to another unique_ptr instance (or to a shared_ptr). At no point can it lose track of the memory it is managing for you.
Forget about "focussing on things have an equivalent delete/free". Understand that unique_ptr does this for you. So does shared_ptr. Their whole point is to manage allocations for their whole lifetime. No more need for manual make-work or tedious checking; this ensures it's correct under every circumstance. If it's not correct it won't compile, end of story. Ownership transfer is explicit. Doing it by hand the old way is error prone because it's possible to forget; we see time and time again that programmers aren't perfect and do forget, or introduce leaks when refactoring, or misunderstand who is the owner. These smart pointers eliminate that entire class of bugs at a stroke. And they are not "new" by any means; they have been around for over 15 years in boost, in C++03 TR1 and in C++11.
I would highly recommend taking a read of Meyers' new Effective Modern C++ book, which covers all this in detail with really good examples.
// old {
Foo *f = new Foo();// bare pointer with no clear ownership
f->bar();// leak on throw
delete f;// leak if omitted }
// new {
std::unique_ptr<Foo> f(std::make_unique<Foo>());// managed unique pointer with defined ownership
f->bar();// cleanup on throw }// cleanup at scope exit
These are equivalent. Except: I didn't need to delete f in the second case; it happened automatically when f went out of scope. And if the bar() method threw an exception, it would automatically free the memory when the stack was unwound. There are other corner cases it also protects against. And this is about as trivial an example you can get; you can do much, much more with them.
Smart pointers, well shared_ptr, has an overhead on incrementing and decrementing the reference count due to the use of atomic inc/dec. It has no overhead for *use*, i.e. dereferencing.
At least in my own code, shared_ptr passing/copying is a rare event; that all happens during some setup phase; the real high-performance parts don't perform any allocation/deallocation/refcount operations. So as with everything, there are tradeoffs and design constraints to consider before blindly using it everywhere. (I actually *do* use it everywhere. But I also think about *how* I use it to avoid creating performance problems.)
And while I could use new and delete in constructors and destructors, why wouldn't I use unique_ptr here to have it done for me? For me, shared_ptr and unique_ptr are about *correctness* and *safety*, including exception-safety and thread-safety. The performance is a secondary concern which is also important, but which can be worked on in the knowledge that the logic is correct.
Well, rather than "not liking the sound of it", I would highly recommend you educate yourself about them. There's plenty of examples floating around. I've been using std::shared_ptr for well over a decade, first as boost::shared_ptr, later std::tr1::shared_ptr and today std::shared_ptr (they are all the same, just going to the final standard name with C++11). The number of memory leaks I've had in my released software over that period: zero, checked regularly with valgrind.
Smart pointers aren't magic. They are just an instance of RAII to acquire a resource (memory) upon construction of an object and release it upon destruction. For std::unique_ptr, there's only ever one instance, though you can transfer it. For std::shared_ptr the object can be referenced multiple times, handled with reference counting, so destruction decrements the shared count by one, and deletes the memory once the reference count reaches zero. The smart pointer can be a variable in a function or class method, a class member, static member or global variable. It's the same in all cases.
Think about how many bugs there are in C code due to malloc/free issues--double free, not freeing, and if using reference counting failure to increment or decrement where needed (just see how many times this crops up for GTK/GObject-based code). And no way to know who owns a pointer and who is responsible for freeing it--it's just a bare pointer. Smart pointers handle all of this for you, that is to say that the compiler does all the work automatically that you would have to do by hand *anyway*. And it's thread-safe and exception-safe. It makes it impossible to mess up memory management--if it's broken it won't compile. In terms of writing robust and reliable code, it's a world apart from plain C with malloc/free or old-style C++ with new/delete. It's vastly simpler for the programmer, too. There's little to dislike about this--IMO it's one of the most beneficial additions to best practices for C++ ever made.
While this is true, the value in github isn't in the git hosting alone. It's in the workflow it enables--PR submission, collaborative review, merging, and being able to hook the PRs into CI systems to test them prior to merging. These are unmatched by anything else. You could install gitlab as an alternative, but setting up all this stuff by hand and maintaining it can be a significant investment you might want to avoid.
I upgrade my system piecemeal over time as bits get too slow and/or fail. It's currently:
Case: Corsair Obsidian 550D Mainboard: ASUS Sabertooth R2.0 CPU: AMD FX 8350 Memory: Crucial 16GiB ECC GPU: AMD Radeon 6850 w/ 1GiB VRAM Disks: 256GB Crucial M550 SSD (Windows 8.1), 120 GB Intel SSD (FreeBSD 10.1), 256GiB Seagate HDD (data) (Important data is on a FreeBSD NAS w/ ZFS RAID) Monitor: HP LP2475w Keyboard: Kinesis Freestyle2
Primary use is software development and secondary is gaming. People criticise the AMD 8350, but with 8 cores it's a beast for parallel building; shared FPU isn't a big deal at all.
Planned upgrades: New monitor; I'd like a 16:10 (or greater aspect ratio) at least 4K resolution with at least 10 bit depth (I do scientific imaging work). Might have to settle for the 5K Dell or similar if the ghastly 16:9 is all that's available. New GPU: I'm waiting on the forthcoming AMD releases, probably wait until the new year for a reasonable deal; might have to wait on the monitor as well if I need a new one to drive a much bigger display.
That's a good question, and I'm not sure I have seen enough different employers to know what's typical here. I don't think we've specifically advertised a position as "entry level" or more advanced; that may be because we do expect some level of expertise, but that could have come from open source participation/contributions, and if the specific job criteria were met then you'd likely make the shortlist.
I may have inflated expectations. I taught myself C++ while also being a full time undergraduate molecular biologist, and then joined ACCU and became familiar with RAII, smartpointers etc. from following their mailing lists, monthly publications and comp.lang.c++, while in my first programming job after graduating. I was also busy being a Debian developer by this point as well, and made use of C++ writing tools for that which greatly expanded my understanding and appreciation of modern C++ programming techniques outside what's in the books. I guess what I'm trying to say is that anyone who is sufficiently motivated and enthralled by programming can pick this up outside of a formal degree programme without great effort, and I do have an expectation that people can proactively explore and stretch their abilities outside the confines of their course curriculum, particularly at university level. I don't know how reasonable that expectation is for the general case. As a scientist I was strongly encouraged to extensively read around the subject to broaden my knowledge and understanding at a theoretical level and also to spend time in labs e.g. over the summer holidays working on small research projects to expand my practical skills; is this not typical for CompSci also?
On my current team several of the team have CompSci degrees, but several of us have PhDs in completely different areas; one of the most senior people doesn't have any degree. While a CompSci degree is certainly useful to have, it's by no means required if you can demonstrate your competence--being a great computer scientist doesn't necessarily mean you're a great programmer as you say--and in many positions specific knowledge of the domain is just as important. For example, in my current position having expertise with many different forms of microscopy from my PhD is almost as desirable as 16 years of programming experience; and having a diverse mixture of backgrounds and skillsets on the team balances this out so that pure compsci people aren't disadvantaged by lack of domain knowledge, and others who are experts in other areas but weaker on the pure compsci theory can be supported by them, etc.
For all our job applications, it is very encouraging to see applicants who provide examples of what they have done in practice, e.g. links to git repos, github/bitbucket, open source project participation, etc.. For an entry level position where they might have trouble demonstrating experience in previous roles, this is a clear demonstration of what they can do and if they also had the right attitude and aptitude it could have a significant influence when comparing with otherwise similar applicants.
I was, by coincidence, on an interview panel for a developer position earlier this week. We were looking for someone with Java and C++ skills, but didn't fail them for specific gaps in their knowledge--general attitude, aptitude and competence were what we were really evaluating. Once they are on the team you can easily fill the gaps in with training, books, code review and team working. It's better to have someone competent you can work well with, but you need to be sure they are competent and capable of picking up new things effectively.
That said, if I was in a position to be specifically hiring a C++ developer I'd not really consider you if you didn't have a good grasp of the basic language and common idioms. That includes correct use of RAII and exceptions, and the understanding of when to pass by value, [const] reference or with shared_ptr or unique_ptr. These are essential to writing decent, robust code today. Under what circumstances would you consider it safe to use new and delete? If you haven't heard of smartpointers, I'd be very worried--have you been living under a rock? Likewise I'd also like to see that you are aware of C++11 and 14, and know a bit about them even if you haven't used them much yet--it shows you care about keeping up to date with the language and libraries. For my current work projects, we use C++11 library features where we can remain compatible with C++98 using Boost to provide missing types; i.e. we have an eye to selectively use features where we can remain backward compatible and move up to language features proper once our minimum compiler versions get bumped over time. I've been playing with writing examples to test each C++11/14 feature as GCC/clang has enabled them, to keep up to date and evaluate what would be useful for our projects; keeping up to date with this stuff is a fairly basic requirement if you want to do this professionally, IMO, and if you're not enthused by the language enough to care about doing this, why would we want to employ you? In the same vein, I'd expect you to know about Boost or an equivalent such as poco even if you've not used it in anger.
It's not realistic to expect someone to be experienced with all your pet library features, or even language features--their previous employers may have banned using RTTI, exceptions, etc. in their coding standards. But it's not unreasonable to expect that you have an understanding of them and could use them if you needed to. Specific recall of library features isn't something I would require--I do have a copy of Josuttis for the STL and a collection of Meyer's books on my desk at all times since I can't remember a lot of it off the top of my head, so it would be unreasonable to expect it of another. But I would expect that you could explain the principles behind them e.g. containers, iterators, half-open ranges, algorithms etc.
On rare occasions, I'm amazed that some developers are still living in the '90s and are completely unaware of the last 20 years of language and library improvements. 'C++, I use "version 6.0"'. Sob. RAII, exception safety, RTTI, what are they?! These people would be actively hazardous to your code!
Not just learning to delete objects out of scope though. shared_ptr and unique_ptr also provides exception safety--using a bare new/malloc'd pointer is going to cause problems unless you're absolutely sure an exception will never throw in a given scope. In practice, that leaves the only place to use bare pointers in class members, and even there unique_ptr would be better. In my code, the rule is absolutely zero bare pointers, ever. If you're going to return allocated memory, use a unique_ptr which you can then assign to a shared_ptr. It avoids the overhead of shared_ptr while still having the convienience of automatically cleaning up, and also being moveable.
Sorry, I don't use linked.in; feel free to mail me if you like though!
A short summary would be running a general-purpose NAS system with FreeBSD 10.1 at home with ZFS, NFS4 serving homedirs and other storage and a bunch of jails running PostgreSQL, build environments, kfreebsd, etc. And my main desktop dual boots FreeBSD 10.1 and PC-BSD, both of which work just fine. The only minor niggle is the GPU fan speed which needs tweaking due to running at full speed, but I run kde4, i3, fluxbox without any trouble.
At work, we have a FreeBSD 10.1 jenkins build node to test our code against clang++ 3.4/3.5, and I currently run a set of VirtualBox VMs for local building and testing. I may possibly switch over to it for desktop use as well if it serves work needs (currently using Ubuntu)
"Spreading conspiracy theories." Please. I may be many things, but a conspiracy nut is not one of them; there is really no need to make such silly insinuations, it's not like the prior debate was any better. The number of people who pushed for this over the last few years was very small, in comparison to the total developer base, and the GR was irrelevant to that--that was only at the end stage of the process. I'd personally long since withdrawn from the "debate" at that point, because it was so nasty and unpleasant and I had better things to do with my time than be abused by my fellow developers. A win for rude, pushy and obnoxious people who shouted loudest and longest and ignored everyone else...
While I am missing Debian as a project to participate in after spending so long working on it, I am most certainly not missing participation on the lists due to the unnecessary amount of unprofessional vitriol and bile. I'll be looking for somewhere a bit more pleasant for my next project.
After using and developing Debian for 18 years, this is the first release I have no plans to use, all thanks to the gnome and systemd idiocy. It hasn't been a nice experience, seeing a system build up with loving care by so many people over so long being willfully trashed by a small handful of people. I for one have no interest in being RedHat's bitch; if I wanted to be, I'd be a suffering Fedora or CentOS user. Debian has lost its independence and freedom.
I've been using FreeBSD for nearly 18 months now, and rarely boot up Debian on my systems or VMs. Going back 5 years, I'd never have imagined this is the way things would play out. Tragic.
3D volume rendering and large scale 2D image rendering. Modern biological and medical imaging systems can create gargantuan datasets, and visualising them is computationally expensive. The largest single images I have are ~5GiB from tiled confocal z stacks (large 3D volume e.g. 4096x4096x64 with 4x 16-bit channels is 8GiB). Current lightsheet microscopes can acquire over 1TB *per sample* in just a few minutes, with the final processed/renderable volume still being many tens of GBs. MRI scans can also be very large.
Put it this way: a 512x512x512 volume at 8 bits per pixel is 128 MiB and that's pretty pedestrian 1024x1024x1024 at 32 bits per pixel/single precision float with 4 channels is 16.4GiB Current high-end CCDs are now 2048x2048; if I acquire with 16 bits per pixel, 128 planes and 4 channels, that's 32.8 GiB Slide scanners can also acquire very large 2D images, well over 100000x100000 with 3 8bpp channels; that's 28.6 GiB uncompressed, and I've seen far larger.
I hope this makes the point that 12GB video memory isn't just desirable, it's still way to small for many current imaging applications without pre-processing the data to filter/downsample/reduce the sample precision. I would really appreciate a GPU with this much VRAM, and still want more.
I use a smaller ISP (aaisp.net) which provides IPv6 natively. The router they provided, which is a fairly common technicolor model, does all the firewalling and port forwarding you could desire with both v4 and v6 addresses. In the case of v6 it's more a case of unblocking than forwarding ports, since the internal address is global, but the functionality is all there and it works. If you didn't want to run servers internally, everything worked out of the box for outgoing v6--totally plug and play which is how it should be.
I set up PostgreSQL in a FreeBSD jail last week. Total setup time, just a few minutes to create the jail and pkg install the latest PostgreSQL, and set up the db cluster. Added to DNS, and it's been working ever since without a hitch, all on top of ZFS. If you're not a slave to proprietary databases, it can be very simple and straightforward to migrate to FreeBSD.
I don't have the time to point to the specific issues, but if you look over the last 18 months of the buildd-tools-devel archives you'll find them. Most of these are due the same root cause that broke tmux and screen before they were specifically patched to work around systemd.
But the specific issues are no longer worth discussing. The breakage has already happened. Debian has been broken, both in terms of the trashing of its historical reliability and robustness and in terms of the fracturing of its community. It's now past time to plan to move on to systems which aren't broken by design. If I use the new Jessie release at all, it will likely be an interim measure while it still supports sysvinit, and is just a stopgap while migrating elsewhere. While staying on Linux would be nice, it's not clear that will be viable, so pre-emptively migrating to FreeBSD will provide some medium-term security and flexibility. I started planning for the possibility of migrating away over 18 months back, and I've spent the last 12 months porting code, removing Linux/glibc-isms, adding support for BSD features and libraries, migrating systems and services, setting up BSD autobuild/CI infrastructure etc. This is now largely complete, just need to finish ZFS snapshotting for schroot.
Never forget that Linux wasn't made by big companies pushing their agendas. They largely picked up what others had created before them. Big UNIX tools and programs are as a rule crude and less featureful and polished compared with their free software counterparts. Linux was made by the thousands of people who created and polished the free tools and programs to make them the most featureful, portable, useful and usable of their class. As a group, we've been collectively given the finger, and so many of us will take the message and move on. We'll see how well the latter day Big Linux companies do without us in the long term. They may well have killed the goose that laid the golden eggs.
The systemd debate reduced the Debian lists to an endless flamewar over three years long. debian-devel is just toxic; it's not useful for any constructive development discussion. I unsubscribed from almost all the lists a year back. I can't describe how wearing and demotivating this is. Reading the archives since then, it hasn't improved.
Most of the software I write for Debian is core systems programming stuff. Straight out of APUE (Stevens). Over the last year, I've had a stream of bug reports about things not working correctly under systemd. Some fairly fundamental POSIX syscalls and tools no longer have the same behaviour when running under systemd. By "design". That's a fairly huge compatibility break with every other UNIX-like system out there, and one which hasn't seen much attention. But I'm somehow expected to rework my code to work around the breakage systemd brought with it. Breakage which has nothing to do with me. Code which isn't even remotely anything to do with an init system and which is portable code running on many other systems. That's crossed a line. systemd can't and won't be supported.
I can work on sysvinit, openrc to a lesser extent. For several years it's been all take and no give with the systemd people. We can't do work on integrating openrc since this would require support for runscripts in systemd. What's the chance of that? Zero. Any changes, even minor ones, require superhuman effort to achieve. Essentially, it's an uphill battle to do anything and Debian is no longer a pleasant or productive environment to work in, primarily thanks to the horrible "our way or the highway" attitude of the systemd people. Since when was free software about dictating how everyone must do things? Silly me, I used to think it was about having the personal freedom to tinker with things as I liked to meet my needs. I'm a volunteer, and I give up vast amounts of my life to contribute to free software and Debian. This was previously a fun, collaborative, productive endevour for which my efforts benefitted many people. It's now deeply unpleasant and I don't like being abused, ridiculed and trodden on by the systemd people and their enablers. I'll move on to new and better things. I spent the last decade as the primary maintainer of the core Debian build tools, and later of sysvinit. I've been invested in and contributed heavily to Debian for the last 15 years. Not something easily let go.
We'll see how Devuan pans out. Until it does, I'll be carrying on the migration to FreeBSD.
This isn't strictly correct. They have been talking about their own equivalent of launchd.
Why is the distinction important? Unlike systemd it has a clearly-defined and limited scope. If systemd had stuck to doing this, it wouldn't have become the creeping mess it is today. So long as the FreeBSD implementation is limited and sane, I see no reason why it won't be a general improvement. And given the clean and generally machine-editable nature of rc.conf and the BSD init system, it will likely not be too challenging to make it backward-compatible, which is another area systemd failed in by not being fully LSB compatible.
I'm a Debian developer who has been moving slowly to using FreeBSD on more and more systems over the last year, displacing Debian use and development on those systems. I've started contributing in minor ways on the lists and the odd patch for the ports tree. I'll likely start packaging my stuff in ports and becoming increasingly more involved over time.
I contribute to things I'm actively using. For the past 15 years, that was Debian. Unfortunately due to the best efforts of the systemd people, it looks like that's unlikely to continue, though I very much wish this was not the case. But reality can't be avoided, and this is where things are today.
MacOS X and Windows are both second-class citizens. They work poorly and inconsistently, and are not well-maintained ports. You can't build a Windows or MacOS X version of a GTK+ application and expect it to work properly. With Qt, you can. Nowadays with GTK 3.x, even non-Linux and non-GNOME are no longer catered for properly. This isn't new. Windows support was mediocre back in 2004 and it's still mediocre today. MacOS X is arguably worse. Case in point: copy-paste was broken in Inkscape the last few times I've tried it on MacOS X, making it unusable. This is simply due to the primary upstream developers, those that are left at least, not caring at all about these platforms--they never have cared. Working "quite well" is a low bar; stuff needs to work all the time. It's true that it works for simple stuff--a few buttons and text entries. But at soon as you get to a more complex application that starts to use more functionality, you're in a world of frustration as you discover the extent of all the brokenness.
A decade back, GTK+ used to be my toolkit of choice, and I was using it for my day job for a while for use in actual products, writing tutorials and articles on it in professional publications etc. In retrospect, it wasn't that amazing then, the systemic issues it has were there since it began, but it's not even on the radar today for most developers. I'm now a Qt developer, like many others who had to get stuff done and found GTK+ sorely lacking. Building cross-platform OpenGL rendering stuff, it works on every platform without trouble and looks and behaves completely natively, and is a pleasure to work with rather than an exercise in masochism. In 2004 I was regularly filing bugs with patches against GTK+. A few months back, I saw some get closed/wontfix--10 years of tested, unreviewed patches fixing serious problems being ignored and abandoned. What a waste. If it was actually maintained properly, I might possibly still be using it. But if bugs which block your work don't get fixed, even if you put in the effort to fix, test and submit the patches yourself, you end up having to move to something which is actually maintained properly, such as Qt.
Slashdot Mirror
I don't think anyone claimed that new and delete were no longer *used*; the point is that *you* don't use them; they are safely wrapped and managed. In the code I work on, any PR containing new or delete would be rejected unless there was a strong and valid reason for making an exception.
And yes, my example was intentionally "super simple" because it was purely to illustrate how they can be used effectively. Creating complex stuff is obviously possible; and in fact easier than creating simple stuff. You can't create an intertwined spaghetti mess of cyclic references without having to manually cope with undoing the mess. So you need to factor that into your design; and let's be honest, it does in most cases constrain the developer to simpler acyclic structures, which is not a bad thing. If you were managing these structures manually with new and delete, the only change you'd need to make is putting a .reset() where you'd originally have the delete, so it's not like this is particularly burdensome. Also note that Java does also have weak references (WeakReference) and for largely the same reasons as weak_ptr.
Have you actually looked at what's going on over IPv6 on your local network right now? Lots of stuff will do autodiscovery and communicate over IPv6 link-local even if you don't have any outside connectivity or global addressing.
And for a local network, all-IPv6 is quite a bit nicer than NATed IPv4; and you can use NAT64/DNS64 to talk to the outside IPv4 world without having any IPv4 networking internally. Rather than being dual-stack, you can be IPv6-only and push IPv4 outside. My ISP explicitly supports this setup.
Well, the arguments to make_unique or make_shared are passed directly to the constructor, so it will call the appropriate constructor in the class. You are not limited to the default constructor.
And circular references aren't a big deal. In the rare event you have a data structure with cycles you can often use weak_ptr in place of shared_ptr (real example: an in-memory representation of an XML tree uses shared_ptr to implement a DAG of element objects and weak_ptr to implement arbitrary cross-references between elements, avoiding cycles of shared_ptr). If that's not possible, the worst case is that you have to manually reset() one or more of the pointers to break the cycles.
Now we have C++11 move constructors you should not need to worry about copying/destruction/throw on resize I would think.
Also, note that the make_unique will reduce to a single new at construction and a delete at scope exit, same as if you'd done it by hand (and possibly an additional one on unwind depending upon the implementation, which the old way doesn't cater for unless you explicitly add a try/catch). If you care about exception safety at all times, they make your code massively cleaner, more readable and more robust. And it's removed the possibility for me to lose track of anything.
I think you missed an important concept here: std::make_unique can never, ever ever leak. It returns a std::unique_ptr<T> which will free the allocation and/or transfer ownership to another unique_ptr instance (or to a shared_ptr). At no point can it lose track of the memory it is managing for you.
Forget about "focussing on things have an equivalent delete/free". Understand that unique_ptr does this for you. So does shared_ptr. Their whole point is to manage allocations for their whole lifetime. No more need for manual make-work or tedious checking; this ensures it's correct under every circumstance. If it's not correct it won't compile, end of story. Ownership transfer is explicit. Doing it by hand the old way is error prone because it's possible to forget; we see time and time again that programmers aren't perfect and do forget, or introduce leaks when refactoring, or misunderstand who is the owner. These smart pointers eliminate that entire class of bugs at a stroke. And they are not "new" by any means; they have been around for over 15 years in boost, in C++03 TR1 and in C++11.
I would highly recommend taking a read of Meyers' new Effective Modern C++ book, which covers all this in detail with really good examples.
{
Foo *f = new Foo();
f->bar();
delete f;
}
{
std::unique_ptr<Foo> f(std::make_unique<Foo>());
f->bar();
}
These are equivalent. Except: I didn't need to delete f in the second case; it happened automatically when f went out of scope. And if the bar() method threw an exception, it would automatically free the memory when the stack was unwound. There are other corner cases it also protects against. And this is about as trivial an example you can get; you can do much, much more with them.
Smart pointers, well shared_ptr, has an overhead on incrementing and decrementing the reference count due to the use of atomic inc/dec. It has no overhead for *use*, i.e. dereferencing.
At least in my own code, shared_ptr passing/copying is a rare event; that all happens during some setup phase; the real high-performance parts don't perform any allocation/deallocation/refcount operations. So as with everything, there are tradeoffs and design constraints to consider before blindly using it everywhere. (I actually *do* use it everywhere. But I also think about *how* I use it to avoid creating performance problems.)
And while I could use new and delete in constructors and destructors, why wouldn't I use unique_ptr here to have it done for me? For me, shared_ptr and unique_ptr are about *correctness* and *safety*, including exception-safety and thread-safety. The performance is a secondary concern which is also important, but which can be worked on in the knowledge that the logic is correct.
Well, rather than "not liking the sound of it", I would highly recommend you educate yourself about them. There's plenty of examples floating around. I've been using std::shared_ptr for well over a decade, first as boost::shared_ptr, later std::tr1::shared_ptr and today std::shared_ptr (they are all the same, just going to the final standard name with C++11). The number of memory leaks I've had in my released software over that period: zero, checked regularly with valgrind.
Smart pointers aren't magic. They are just an instance of RAII to acquire a resource (memory) upon construction of an object and release it upon destruction. For std::unique_ptr, there's only ever one instance, though you can transfer it. For std::shared_ptr the object can be referenced multiple times, handled with reference counting, so destruction decrements the shared count by one, and deletes the memory once the reference count reaches zero. The smart pointer can be a variable in a function or class method, a class member, static member or global variable. It's the same in all cases.
Think about how many bugs there are in C code due to malloc/free issues--double free, not freeing, and if using reference counting failure to increment or decrement where needed (just see how many times this crops up for GTK/GObject-based code). And no way to know who owns a pointer and who is responsible for freeing it--it's just a bare pointer. Smart pointers handle all of this for you, that is to say that the compiler does all the work automatically that you would have to do by hand *anyway*. And it's thread-safe and exception-safe. It makes it impossible to mess up memory management--if it's broken it won't compile. In terms of writing robust and reliable code, it's a world apart from plain C with malloc/free or old-style C++ with new/delete. It's vastly simpler for the programmer, too. There's little to dislike about this--IMO it's one of the most beneficial additions to best practices for C++ ever made.
While this is true, the value in github isn't in the git hosting alone. It's in the workflow it enables--PR submission, collaborative review, merging, and being able to hook the PRs into CI systems to test them prior to merging. These are unmatched by anything else. You could install gitlab as an alternative, but setting up all this stuff by hand and maintaining it can be a significant investment you might want to avoid.
I upgrade my system piecemeal over time as bits get too slow and/or fail. It's currently:
Case: Corsair Obsidian 550D
Mainboard: ASUS Sabertooth R2.0
CPU: AMD FX 8350
Memory: Crucial 16GiB ECC
GPU: AMD Radeon 6850 w/ 1GiB VRAM
Disks: 256GB Crucial M550 SSD (Windows 8.1), 120 GB Intel SSD (FreeBSD 10.1), 256GiB Seagate HDD (data)
(Important data is on a FreeBSD NAS w/ ZFS RAID)
Monitor: HP LP2475w
Keyboard: Kinesis Freestyle2
Primary use is software development and secondary is gaming. People criticise the AMD 8350, but with 8 cores it's a beast for parallel building; shared FPU isn't a big deal at all.
Planned upgrades:
New monitor; I'd like a 16:10 (or greater aspect ratio) at least 4K resolution with at least 10 bit depth (I do scientific imaging work). Might have to settle for the 5K Dell or similar if the ghastly 16:9 is all that's available.
New GPU: I'm waiting on the forthcoming AMD releases, probably wait until the new year for a reasonable deal; might have to wait on the monitor as well if I need a new one to drive a much bigger display.
That's a good question, and I'm not sure I have seen enough different employers to know what's typical here. I don't think we've specifically advertised a position as "entry level" or more advanced; that may be because we do expect some level of expertise, but that could have come from open source participation/contributions, and if the specific job criteria were met then you'd likely make the shortlist.
I may have inflated expectations. I taught myself C++ while also being a full time undergraduate molecular biologist, and then joined ACCU and became familiar with RAII, smartpointers etc. from following their mailing lists, monthly publications and comp.lang.c++, while in my first programming job after graduating. I was also busy being a Debian developer by this point as well, and made use of C++ writing tools for that which greatly expanded my understanding and appreciation of modern C++ programming techniques outside what's in the books. I guess what I'm trying to say is that anyone who is sufficiently motivated and enthralled by programming can pick this up outside of a formal degree programme without great effort, and I do have an expectation that people can proactively explore and stretch their abilities outside the confines of their course curriculum, particularly at university level. I don't know how reasonable that expectation is for the general case. As a scientist I was strongly encouraged to extensively read around the subject to broaden my knowledge and understanding at a theoretical level and also to spend time in labs e.g. over the summer holidays working on small research projects to expand my practical skills; is this not typical for CompSci also?
On my current team several of the team have CompSci degrees, but several of us have PhDs in completely different areas; one of the most senior people doesn't have any degree. While a CompSci degree is certainly useful to have, it's by no means required if you can demonstrate your competence--being a great computer scientist doesn't necessarily mean you're a great programmer as you say--and in many positions specific knowledge of the domain is just as important. For example, in my current position having expertise with many different forms of microscopy from my PhD is almost as desirable as 16 years of programming experience; and having a diverse mixture of backgrounds and skillsets on the team balances this out so that pure compsci people aren't disadvantaged by lack of domain knowledge, and others who are experts in other areas but weaker on the pure compsci theory can be supported by them, etc.
For all our job applications, it is very encouraging to see applicants who provide examples of what they have done in practice, e.g. links to git repos, github/bitbucket, open source project participation, etc.. For an entry level position where they might have trouble demonstrating experience in previous roles, this is a clear demonstration of what they can do and if they also had the right attitude and aptitude it could have a significant influence when comparing with otherwise similar applicants.
I was, by coincidence, on an interview panel for a developer position earlier this week. We were looking for someone with Java and C++ skills, but didn't fail them for specific gaps in their knowledge--general attitude, aptitude and competence were what we were really evaluating. Once they are on the team you can easily fill the gaps in with training, books, code review and team working. It's better to have someone competent you can work well with, but you need to be sure they are competent and capable of picking up new things effectively.
That said, if I was in a position to be specifically hiring a C++ developer I'd not really consider you if you didn't have a good grasp of the basic language and common idioms. That includes correct use of RAII and exceptions, and the understanding of when to pass by value, [const] reference or with shared_ptr or unique_ptr. These are essential to writing decent, robust code today. Under what circumstances would you consider it safe to use new and delete? If you haven't heard of smartpointers, I'd be very worried--have you been living under a rock? Likewise I'd also like to see that you are aware of C++11 and 14, and know a bit about them even if you haven't used them much yet--it shows you care about keeping up to date with the language and libraries. For my current work projects, we use C++11 library features where we can remain compatible with C++98 using Boost to provide missing types; i.e. we have an eye to selectively use features where we can remain backward compatible and move up to language features proper once our minimum compiler versions get bumped over time. I've been playing with writing examples to test each C++11/14 feature as GCC/clang has enabled them, to keep up to date and evaluate what would be useful for our projects; keeping up to date with this stuff is a fairly basic requirement if you want to do this professionally, IMO, and if you're not enthused by the language enough to care about doing this, why would we want to employ you? In the same vein, I'd expect you to know about Boost or an equivalent such as poco even if you've not used it in anger.
It's not realistic to expect someone to be experienced with all your pet library features, or even language features--their previous employers may have banned using RTTI, exceptions, etc. in their coding standards. But it's not unreasonable to expect that you have an understanding of them and could use them if you needed to. Specific recall of library features isn't something I would require--I do have a copy of Josuttis for the STL and a collection of Meyer's books on my desk at all times since I can't remember a lot of it off the top of my head, so it would be unreasonable to expect it of another. But I would expect that you could explain the principles behind them e.g. containers, iterators, half-open ranges, algorithms etc.
On rare occasions, I'm amazed that some developers are still living in the '90s and are completely unaware of the last 20 years of language and library improvements. 'C++, I use "version 6.0"'. Sob. RAII, exception safety, RTTI, what are they?! These people would be actively hazardous to your code!
Not just learning to delete objects out of scope though. shared_ptr and unique_ptr also provides exception safety--using a bare new/malloc'd pointer is going to cause problems unless you're absolutely sure an exception will never throw in a given scope. In practice, that leaves the only place to use bare pointers in class members, and even there unique_ptr would be better. In my code, the rule is absolutely zero bare pointers, ever. If you're going to return allocated memory, use a unique_ptr which you can then assign to a shared_ptr. It avoids the overhead of shared_ptr while still having the convienience of automatically cleaning up, and also being moveable.
That's an irrelevant, flippant answer. This has *absolutely* *nothing* to do with how easy it is to install KDE.
Sorry, I don't use linked.in; feel free to mail me if you like though!
A short summary would be running a general-purpose NAS system with FreeBSD 10.1 at home with ZFS, NFS4 serving homedirs and other storage and a bunch of jails running PostgreSQL, build environments, kfreebsd, etc. And my main desktop dual boots FreeBSD 10.1 and PC-BSD, both of which work just fine. The only minor niggle is the GPU fan speed which needs tweaking due to running at full speed, but I run kde4, i3, fluxbox without any trouble.
At work, we have a FreeBSD 10.1 jenkins build node to test our code against clang++ 3.4/3.5, and I currently run a set of VirtualBox VMs for local building and testing. I may possibly switch over to it for desktop use as well if it serves work needs (currently using Ubuntu)
"Spreading conspiracy theories." Please. I may be many things, but a conspiracy nut is not one of them; there is really no need to make such silly insinuations, it's not like the prior debate was any better. The number of people who pushed for this over the last few years was very small, in comparison to the total developer base, and the GR was irrelevant to that--that was only at the end stage of the process. I'd personally long since withdrawn from the "debate" at that point, because it was so nasty and unpleasant and I had better things to do with my time than be abused by my fellow developers. A win for rude, pushy and obnoxious people who shouted loudest and longest and ignored everyone else...
While I am missing Debian as a project to participate in after spending so long working on it, I am most certainly not missing participation on the lists due to the unnecessary amount of unprofessional vitriol and bile. I'll be looking for somewhere a bit more pleasant for my next project.
After using and developing Debian for 18 years, this is the first release I have no plans to use, all thanks to the gnome and systemd idiocy. It hasn't been a nice experience, seeing a system build up with loving care by so many people over so long being willfully trashed by a small handful of people. I for one have no interest in being RedHat's bitch; if I wanted to be, I'd be a suffering Fedora or CentOS user. Debian has lost its independence and freedom.
I've been using FreeBSD for nearly 18 months now, and rarely boot up Debian on my systems or VMs. Going back 5 years, I'd never have imagined this is the way things would play out. Tragic.
3D volume rendering and large scale 2D image rendering. Modern biological and medical imaging systems can create gargantuan datasets, and visualising them is computationally expensive. The largest single images I have are ~5GiB from tiled confocal z stacks (large 3D volume e.g. 4096x4096x64 with 4x 16-bit channels is 8GiB). Current lightsheet microscopes can acquire over 1TB *per sample* in just a few minutes, with the final processed/renderable volume still being many tens of GBs. MRI scans can also be very large.
Put it this way: a 512x512x512 volume at 8 bits per pixel is 128 MiB and that's pretty pedestrian
1024x1024x1024 at 32 bits per pixel/single precision float with 4 channels is 16.4GiB
Current high-end CCDs are now 2048x2048; if I acquire with 16 bits per pixel, 128 planes and 4 channels, that's 32.8 GiB
Slide scanners can also acquire very large 2D images, well over 100000x100000 with 3 8bpp channels; that's 28.6 GiB uncompressed, and I've seen far larger.
I hope this makes the point that 12GB video memory isn't just desirable, it's still way to small for many current imaging applications without pre-processing the data to filter/downsample/reduce the sample precision. I would really appreciate a GPU with this much VRAM, and still want more.
Regards,
Roger
I use a smaller ISP (aaisp.net) which provides IPv6 natively. The router they provided, which is a fairly common technicolor model, does all the firewalling and port forwarding you could desire with both v4 and v6 addresses. In the case of v6 it's more a case of unblocking than forwarding ports, since the internal address is global, but the functionality is all there and it works. If you didn't want to run servers internally, everything worked out of the box for outgoing v6--totally plug and play which is how it should be.
I set up PostgreSQL in a FreeBSD jail last week. Total setup time, just a few minutes to create the jail and pkg install the latest PostgreSQL, and set up the db cluster. Added to DNS, and it's been working ever since without a hitch, all on top of ZFS. If you're not a slave to proprietary databases, it can be very simple and straightforward to migrate to FreeBSD.
I don't have the time to point to the specific issues, but if you look over the last 18 months of the buildd-tools-devel archives you'll find them. Most of these are due the same root cause that broke tmux and screen before they were specifically patched to work around systemd.
But the specific issues are no longer worth discussing. The breakage has already happened. Debian has been broken, both in terms of the trashing of its historical reliability and robustness and in terms of the fracturing of its community. It's now past time to plan to move on to systems which aren't broken by design. If I use the new Jessie release at all, it will likely be an interim measure while it still supports sysvinit, and is just a stopgap while migrating elsewhere. While staying on Linux would be nice, it's not clear that will be viable, so pre-emptively migrating to FreeBSD will provide some medium-term security and flexibility. I started planning for the possibility of migrating away over 18 months back, and I've spent the last 12 months porting code, removing Linux/glibc-isms, adding support for BSD features and libraries, migrating systems and services, setting up BSD autobuild/CI infrastructure etc. This is now largely complete, just need to finish ZFS snapshotting for schroot.
Never forget that Linux wasn't made by big companies pushing their agendas. They largely picked up what others had created before them. Big UNIX tools and programs are as a rule crude and less featureful and polished compared with their free software counterparts. Linux was made by the thousands of people who created and polished the free tools and programs to make them the most featureful, portable, useful and usable of their class. As a group, we've been collectively given the finger, and so many of us will take the message and move on. We'll see how well the latter day Big Linux companies do without us in the long term. They may well have killed the goose that laid the golden eggs.
What stopped me? Many things. Here's a few.
The systemd debate reduced the Debian lists to an endless flamewar over three years long. debian-devel is just toxic; it's not useful for any constructive development discussion. I unsubscribed from almost all the lists a year back. I can't describe how wearing and demotivating this is. Reading the archives since then, it hasn't improved.
Most of the software I write for Debian is core systems programming stuff. Straight out of APUE (Stevens). Over the last year, I've had a stream of bug reports about things not working correctly under systemd. Some fairly fundamental POSIX syscalls and tools no longer have the same behaviour when running under systemd. By "design". That's a fairly huge compatibility break with every other UNIX-like system out there, and one which hasn't seen much attention. But I'm somehow expected to rework my code to work around the breakage systemd brought with it. Breakage which has nothing to do with me. Code which isn't even remotely anything to do with an init system and which is portable code running on many other systems. That's crossed a line. systemd can't and won't be supported.
I can work on sysvinit, openrc to a lesser extent. For several years it's been all take and no give with the systemd people. We can't do work on integrating openrc since this would require support for runscripts in systemd. What's the chance of that? Zero. Any changes, even minor ones, require superhuman effort to achieve. Essentially, it's an uphill battle to do anything and Debian is no longer a pleasant or productive environment to work in, primarily thanks to the horrible "our way or the highway" attitude of the systemd people. Since when was free software about dictating how everyone must do things? Silly me, I used to think it was about having the personal freedom to tinker with things as I liked to meet my needs. I'm a volunteer, and I give up vast amounts of my life to contribute to free software and Debian. This was previously a fun, collaborative, productive endevour for which my efforts benefitted many people. It's now deeply unpleasant and I don't like being abused, ridiculed and trodden on by the systemd people and their enablers. I'll move on to new and better things. I spent the last decade as the primary maintainer of the core Debian build tools, and later of sysvinit. I've been invested in and contributed heavily to Debian for the last 15 years. Not something easily let go.
We'll see how Devuan pans out. Until it does, I'll be carrying on the migration to FreeBSD.
Altruism only goes so far.
This isn't strictly correct. They have been talking about their own equivalent of launchd.
Why is the distinction important? Unlike systemd it has a clearly-defined and limited scope. If systemd had stuck to doing this, it wouldn't have become the creeping mess it is today. So long as the FreeBSD implementation is limited and sane, I see no reason why it won't be a general improvement. And given the clean and generally machine-editable nature of rc.conf and the BSD init system, it will likely not be too challenging to make it backward-compatible, which is another area systemd failed in by not being fully LSB compatible.
Really? I can.
I'm a Debian developer who has been moving slowly to using FreeBSD on more and more systems over the last year, displacing Debian use and development on those systems. I've started contributing in minor ways on the lists and the odd patch for the ports tree. I'll likely start packaging my stuff in ports and becoming increasingly more involved over time.
I contribute to things I'm actively using. For the past 15 years, that was Debian. Unfortunately due to the best efforts of the systemd people, it looks like that's unlikely to continue, though I very much wish this was not the case. But reality can't be avoided, and this is where things are today.
MacOS X and Windows are both second-class citizens. They work poorly and inconsistently, and are not well-maintained ports. You can't build a Windows or MacOS X version of a GTK+ application and expect it to work properly. With Qt, you can. Nowadays with GTK 3.x, even non-Linux and non-GNOME are no longer catered for properly. This isn't new. Windows support was mediocre back in 2004 and it's still mediocre today. MacOS X is arguably worse. Case in point: copy-paste was broken in Inkscape the last few times I've tried it on MacOS X, making it unusable. This is simply due to the primary upstream developers, those that are left at least, not caring at all about these platforms--they never have cared. Working "quite well" is a low bar; stuff needs to work all the time. It's true that it works for simple stuff--a few buttons and text entries. But at soon as you get to a more complex application that starts to use more functionality, you're in a world of frustration as you discover the extent of all the brokenness.
A decade back, GTK+ used to be my toolkit of choice, and I was using it for my day job for a while for use in actual products, writing tutorials and articles on it in professional publications etc. In retrospect, it wasn't that amazing then, the systemic issues it has were there since it began, but it's not even on the radar today for most developers. I'm now a Qt developer, like many others who had to get stuff done and found GTK+ sorely lacking. Building cross-platform OpenGL rendering stuff, it works on every platform without trouble and looks and behaves completely natively, and is a pleasure to work with rather than an exercise in masochism. In 2004 I was regularly filing bugs with patches against GTK+. A few months back, I saw some get closed/wontfix--10 years of tested, unreviewed patches fixing serious problems being ignored and abandoned. What a waste. If it was actually maintained properly, I might possibly still be using it. But if bugs which block your work don't get fixed, even if you put in the effort to fix, test and submit the patches yourself, you end up having to move to something which is actually maintained properly, such as Qt.