This technical article covers a subtlety in C++ array allocation and how we changed the GNU C++ compiler to deal with it properly. When a programmer writes
T *p = new T;
the C++ compiler allocates room for at least three copies of objects of type T on the heap. These objects require 3 * sizeof(T) bytes. For this example, assume sizeof(T) is 12, then it is straightforward to allocate 36 bytes (for example, using malloc). But what happens if the array length is 3937053355 (or 16909515400900422315 on a 64-bit architecture)? Then 47244640260 bytes are required. This number cannot be expressed in 32-bits, so if 32-bit arithmetic is used to perform the multiplication, the result is a mere 4. Unless special care is taken, a C++ implementation will provide a pointer to a heap area that is much too small for holding the requested number of objects (4 bytes instead of 47244640260 bytes).
Continue reading “Array allocation in C++”
Are you missing out on opportunities to increase your applications’ performance? As an application developer building on Red Hat Enterprise Linux, you invest a lot of time and effort into making your applications compelling and useful for your users. You probably also want to see good performance. But beyond good design, careful algorithm selection and compiler optimizations, what can a developer use to boost their application performance?
1. The latest GCC release and associated tools
The very first thing a Red Hat Enterprise Linux developer should be aware of is the availability of Red Hat Developer Toolset. I described the content and architecture of this new offering from Red Hat in my last blog post. Developer Toolset 1.x gives you the gcc-4.7 toolchain, which, at the time of writing, is the current upstream major release.
Continue reading “7 ways to improve your application’s performance with the new Developer Toolset 1.1 release”
While Red Hat Enterprise Linux is known for its stability and flexibility, you might not think of it first when looking for the latest version of your web application framework. If you’re a developer working with Ruby and Ruby on Rails, you probably want to take advantage of their new features. Sure, you can use RVM, but sometimes you just want to get supported system packages.
Software Collections (often abbreviated as SCL) allows you to run more recent versions of software than what ships with your current version of Red Hat Enterprise Linux. This article will show you how to start development of a Rails 3.2 application running on Ruby 1.9.3 – all on RHEL 6, using only RPM packages, alongside your default Ruby installation. This tutorial assumes that you are familiar with Ruby on Rails basics, such as creating a new application and using bundler. It is also beneficial (although not necessary) to understand how Software Collections work in general.
Continue reading “Ruby on Rails 3.2 on Red Hat Enterprise Linux 6 with Software Collections”
Did you ever wish you had newer versions of the software on your Red Hat Enterprise Linux machines? You are probably not alone. Providing new versions of software in rpm is hard, because rpm supports only one version installed on your computer at a time. Multiple versions on one machine can conflict with each other or create unpredictable behaviour in applications that you might not have considered dependencies.
Last year, we developed Software Collections to allow you to install newer versions of software in rpm safely into /opt and switch between new and old releases. This allows your Red Hat Enterprise Linux system applications to continue to run with the old version, while new apps can work with the new version. A good example of this is Python; many essential packages are written in Python. How can you update to the latest release of Python without causing half your system to break? Through Software Collections, you can install a newer version of Python – for example python-3.3 – into /opt avoiding conflicts in files and strange behaviour of apps that depend on an older version of Python.
Continue reading “Software Collections on Red Hat Enterprise Linux”
Today Red Hat announces the general availability of version 1.1 of Red Hat Developer Toolset through Red Hat Enterprise Linux Developer Subscriptions. For developers, having ready access to the latest, stable development tools is key to taking advantage of open source innovation. Red Hat Developer Toolset 1.1 bridges development agility with production stability by delivering the latest stable versions of essential C and C++ development tools. By employing Red Hat Developer Toolset, organizations can significantly increase developer productivity and improve deployment times.
Red Hat Developer Toolset helps to reduce development and deployment time by allowing users to compile once for multiple versions of Red Hat Enterprise Linux and more easily diagnose and debug applications in development. Using Red Hat Developer Toolset, software developers can develop applications that run on multiple versions of Red Hat Enterprise Linux. Applications developed on Red Hat Enterprise Linux 5 can run on both Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6.
Red Hat Developer Toolset 1.1 delivers the following significant enhancements:
Continue reading “Red Hat Developer Toolset 1.1 Now Available through Developer-focused Subscriptions”
Wouldn’t it be nice if your software development team could use one common set of development tools based on the latest, stable upstream versions for your Red Hat Enterprise Linux development? Think of all the extra years of open source innovation – the features, optimizations and new standards support it would allow your team to build into your products. That would be great, wouldn’t it?
Fortunately, this is already available to you today, and in this blog post I’ll explain how it works and how you can get it. Red Hat Developer Toolset provides a set of additional tools installed in parallel with those delivered as part of Red Hat Enterprise Linux itself. Currently featuring the GCC C/C++ compiler and GDB debugger and backed up by Red Hat’s solid customer support, Red Hat Developer Toolset 1.0 is a great way to unlock performance in your team and your software very easily.
And if you’re already a Red Hat Developer Program subscriber, you can install the tools right now. The Red Hat Developer Toolset version 1.1 Beta, released in October 2012,
showcased a good number of additional performance analysis tools. We’re just getting started with this new offering and have plans to include other tools in the future.
Continue reading “Is your C++ development team missing out? Developer Toolset: newer tools on and for multiple RHEL releases”
I’m writing this first entry at about 30,000 feet on my way back from Red Hat’s North American Partner Conference in San Diego, California. It’s rather appropriate to be typing this out at that altitude, as that is the way I felt for the entire conference after having the opportunity to meet with some amazing ISV, Systems Integrator, VAR and Solution Builder partners who have been building some incredibly powerful solutions using Red Hat technologies. The consistent theme across all of these conversations was making sure that the developers within these organizations had a deep relationship with Red Hat, an understanding of our technology and architecture roadmap as well as the chance to provide more input into how we can all work together.
Continue reading Welcome to the Red Hat developer blog!
This is part four in our “Golden Rules for Great APIs” series (see links at the end of the article), and it tackles a subject which is very easy to pay lip service to but very difficult to deliver on:
Continue reading Building great APIs, part IV: Great developer support
Last week’s “Building Great APIs” article covered two of John Musser and Adam Duvander’s 5 Key Elements of great APIs: providing value and having a business model. In this post, we’ll tackle the next topic:
- Make it simple, flexible, and easily adopted.
The three statements seem obvious until you begin to unpick what they mean–and they might even seem contradictory. Making an API simple seems like a noble goal but it can easily be thwarted by complex edge use cases, existing legacy code and a tendency on the part of some API designers to expose underlying data models in raw form. Flexibility often breeds complexity as the API becomes overloaded to meet many use cases. We’ll take each topic in turn and finish up with an all-important metric: TTFHW (Time To First Hello World).
Continue reading “Building great APIs, part II: Simplicity, flexibility, and TTFHW”
Back in July, John Musser wrote an excellent post over at ProgrammableWeb on what it takes to build great APIs (also check out his OSCON slides on Slideshare). John boils what’s needed down to five key elements—value, plan and business model, flexibility, good management, and great support.
Together with perhaps just one more–stability (an unreliable API is as good as unusable)–these points arguably should represent an “API Gold Standard” for almost any API program. Getting these right goes a long way to running a great API program and we advise anybody running an API to think about them.
Continue reading “Building great APIs, part I: The gold standard”