Jan 09

Assembly developer’s library

Every now and then, when coding in C++, I find myself needing to know some assembly to understand what’s going on. Sometimes, it’s because I am actually writing assembly code, such as when I was writing the new atomic classes for Qt. More often, it’s because I need to read the assembly generated by the compiler to figure out if it’s optimal or if it’s doing something weird.

So I often found myself downloading the same manuals over and over. I decided to put together a small library of manuals I use often and those I seldom use, but might want to some day. This is the list.

ArchitectureInstruction set manualABI description (calling convention)
i386 (IA-32)Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2traditional / many / varied (Wikipedia article)
x86-64 64-bit a.k.a. x64Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2System V ABI for x86-64 (LP64) and Windows x64 calling convention (LLP64)
x86-64 32-bit (ILP32) a.k.a. x32Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2x32 ABI
Itanium (IA-64)Intel® Itanium® Architecture Developer’s Manual, Vol. 3

Itanium® Software Conventions and Runtime Architecture Guide (both ILP32 and LP64)
ARM 32-bit (AArch32)ARM assembler referenceARM Architecture Procedure Call Standard (AAPCS)
ARM 64-bit (AArch64)ARMv8 Instruction Set (registration required)ARM 64-bit Architecture Procedure Call Standard (AAPCS64)
MIPS32The MIPS32® Instruction Set and The microMIPS32™ Instruction Set (registration required)o32 ABI, n32 and n64
MIPS64The MIPS64® Instruction Set (registration required)o64 ABI, n32 and n64
POWER Architecture (includes PowerPC)Power Instruction Set Architecture Version 2.06Power Architecture 32-bit ABI Supplement 1.0 Unified (applies to 64-bit too I think)
SPARCSPARC archictecture V9SPARC psABI 3.0

Of course there are more architectures. Those are just the ones that are (somewhat) relevant to me a Qt developer. Also, please note that I have not looked with detail into the POWER and SPARC manual, other than a cursory glance to ensure that they contained the relevant information. For example, one site I found says that Linux 32-bit on PowerPC uses an ABI different than that defined by power.org.

I have not listed quick reference guides, many of which exist. I don’t use them because I often need details of the instructions.

What do you usually use when you code in assembly?

Additional IA-32 and x86-64 resources

The IA-32 ans x86-64 architectures contain a very big number of extensions that are added in different generations of the processors, both by Intel and AMD. The manuals above include the main extensions: MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2 and AVX, plus the AES, FMA, F16C, RDRAND ones. It does not include extensions specific to AMD processors, like 3dNow! (effectively deprecated), SSE4a, FMA4 or XOP.

Other useful manuals:

Additionally, most of the non-general purpose instructions have intrinsic functions associated with them, so you can write really low-level code in C or C++ without actually having to write assembly. Unfortunately, I haven’t found a good, downloadable, and up-to-date intrinsics reference manual. The Intel(R) C++ Intrinsics Reference is the closest I’ve found, but it stops at SSE4 intrinsics, not including the AVX or AES ones.

If you know of one, please leave me a comment.

Glossary

ABI
Application Binary Interface
ILP32
int, long, pointer are 32-bit, virtually all 32-bit platforms (all of the ABIs listed here)
LP64
long and pointer are 64-bit, the 64-bit environment of all Unix platforms here
LLP64
long long and pointer are 64-bit, but long is 32-bit; the 64-bit environment of Windows

Dec 22

Winter is coming

Yeah, I know the title of this blog is mostly a cliché these days, but I feel like I am entitled to it. I am, after all, 75% done with the fifth book in the Song of Ice and Fire series, A Dance with Dragons. It’s also December 22, which is the first day of Winter in the Northern Hemisphere. But, as I told my friend Espen, I am spending most of this Winter in Summer, a feat accomplished by changing hemispheres and earning me a punch in the arm.

More to the point, Winter is also coming for Qt 5.0: we are approaching feature freeze. The exact date, I can’t tell you, because we don’t know yet. That’s actually the subject of this blog: we need to find a date and I need your help to get there.

There are two competing directions for setting the feature freeze date. The first, which pushes it forward, is the need to complete the features that can only be done in 5.0 — features that, if they fail to enter 5.0, cannot be added to a 5.x release and would need to wait for 6.0. The other is the direction set by Lars, our Chief Maintainer, that we want to release 5.0 by mid-2012, before the Summer break. We know, from past experience, that the quality control a Qt release undergoes is no trivial task, so the more time we give us, the better the result will be.

Therefore, working backwards from a (gold) release date in late June, we need a feature freeze and alpha release sometime in January. In fact, given that this is a major release, with binary compatibility breaks, rearchitecturing of the core GUI functionality, replacing all the ports with QPA, we should have already frozen three months ago.

What we need to do now is to determine what needs to be in Qt 5.0. What are the features need to be complete by the time we freeze? And who’s working on them? For that reason, we have created a wiki page to list such features. Update the wiki page if you know of a project that must go into 5.0, but please include the state of completeness of that item. If you don’t know who’s working on it or if no one is, make that explicit. You can also leave your comments in the blog or post to the development mailing list.

Note that all the features listed in the page may not get into 5.0. This is just the first step in setting the feature freeze date: judge what’s needed and how ready it is, then make a decision on when we can freeze so we most likely can get the wanted features in. Features that are not being worked on or are late may not go in, or exceptions may be granted.

Finally, if you have some spare brain cycles during the holiday season, help in completing the features listed in the wiki is most welcome. Help us make a great Qt 5.0!

Dec 15

Qt 4.8 released

Sinan is writing on the Qt Labs blog that Qt 4.8.0 is released. I won’t duplicate the entire contents of his post, so I’ll just give you the information you’re looking for: the download link.

You can download it from the Download Page:

Happy hacking!

Oct 21

Qt-Project.org is live

As you may have noticed in Lars’s blog the new Qt Project website and organisation is live! Yeah! It’s the product of many people’s work over the course of a year and a half, changing the way how over 200 engineers work on their daily lives.

The change is just in time for the Qt Developer Days event in Munich, which starts next Monday with a Qt Contributors’ Unconference Day. I’ll be there and we’ll be discussing how to get started. It’s also just soon after Research In Motiion opened up its Native BlackBerry SDK with support for Qt.

Here are some resources you may want to get started with:

  • Mailing lists: Subscribe at http://lists.qt-project.org/mailman/listinfo to the mailing lists that might be of your interest. There’s no description available now for them, but you can guess what they are as per the name.
  • Bug tracking: If you don’t have an account yet, create one by singing up at the Qt Bugreports website, which is still in a .nokia.com domain but should change hopefully soon
  • Code review: sign up first for the Bugrepotrs account above, then head to Codereview website and log in with the same credentials. There, set your real name and add one or more email addresses you’re known by.

The Codereview website is where the reviews and approvals will all happen, and the Development mailing list is where all discussions will happen. If you plan on being involved, you should be on both.

In order to contribute a code change to Qt, you’ll need to provide an SSH public key in order to authenticate yourself and you’ll need to agree to the terms of the terms of the Qt Contribution Agreement, now on version 1.1. If you choose not to do that, you won’t be able to contribute code, but you can of course contribute in many other ways, including reviewing and offering advice on how to improve other people’s code.

You may want to add this to your ~/.ssh/config


Host codereview.qt-project.org
‍‍Port 29418
‍‍User insert-username-here
‍‍IdentityFile insert-path-to-ssh-key-here

And this is the SSH key and fingerprint for the website:

Fingerprint: 11:24:25:51:5d:ab:4f:b1:15:49:10:3a:68:6d:ec:0f
[codereview.qt-project.org]:29418,[87.238.53.162]:29418 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCvXdApmCFiAyXDiYU5+z6762Qv8+vrmM3+9YrxDKByyphaxblLJC9txPv3D/w7rzSyiMMHL/5ssCemwz+6QBqnemFl4B+FNv81fpZFsqCg5afrTi62WFllGWIQAiYb2JZmkmSAbxm+sAxLE1ritp+Syxz8Gb8WR27G/3TSHerdBQ==

Oct 18

QUrl in Qt 5: woes of hostname validity

A couple of days ago I posted on Google+ a comment when I was frustrated trying to update the QUrl hostname-parsing code. Turns out that rewriting the parser wasn’t that difficult for QUrl, but dealing with hostnames is very much so. The old code in QUrl simply deals with it directly, even what’s supposed to be IPv4 and IPv6 addresses.

Trying to validate them according to the Augmented Backus–Naur Form grammar found in Appendiix A of RFC 3986 is a extremely difficult. What’s more, the grammar is very strict and doesn’t allow for common forms of v4-compat and v4-mapped IPv6 addresses (that is, “::192.88.99.1″ and “::ffff:10.0.0.1″).

So I took it upon myself to rewrite the IP-parsing and reconstructing routines, which were previously in src/network/kernel/qhostaddress.cpp. I wrote a lot of unit tests for it and tried to match the behaviour of inet_aton(3) for IPv4 and of inet_pton(3) for IPv6. That means accepting some non-standard, old behaviour like an IP address of “127.1″ or “2130706433″ for “127.0.0.1″.

Why am I accepting that? Well, when I talked to Adam Barth on IRC, he pointed me to his result list of comparing broken URLs found in the wild and how different browsers handled them. QUrl in Qt 4 probably fails or has broken behaviour for most, if not all, of the entries in the “LayoutTests/fast/url/host.html” section.

So when rewriting the parser, the first thing I noticed is that the hostnames may come in percent-encoded form, so we need to decode them to find a proper address that may fit the rules. For example:

InputDecoded asType
%31%39%32.%30%2e%32%2E1192.0.2.1IPv4Address
%5b%66f02%3a%3a1][ff02::1]IPv6Address
%65%78%61%6d%70%6c%65%2e%63%6f%6dexample.comreg-name

Table 1. Percent-encoded hostnames

The next thing I noted from the tests is this particular URL: "http://0Xc0.0250.01/" (I used a fixed-width font here so you can see the difference). This particular URL is using characters found in Fullwidth Latin Latters range of Unicode (from U+FF00 to U+FFEF). They are exactly the same letters and numbers as found in the regular range, but they occupy one full width, like the ideographs in the CJK block. The regular codepoints used in mostly Latin text, like this blog, is considered halfwidth in Unicode parlance.

What’s interesting about that URL is that when you apply the rules of the ToASCII transformation of the IDNA process, the step called Nameprep (described in RFC 3491), the fullwidth forms are transformed into their halfwidth counterparts. So the URL above, after going through the ToASCII process, becomes simply “http://0xc0.0250.01″ and, despite having non-digits, the new IPv4 address parser accepts as “192.168.0.1″. So let’s add to our table:

InputDecoded asType
0Xc0.0250.01192.168.0.1IPv4Address
Example.comexample.comreg-name

Table 2. Unicode latin fullwidth hostnames

(note that IPv6Address is not on the table, it will be important later)

In other words, a hostname can be encoded in either the percent-encoded form or in Unicode and still be a regular IPv4 address. To make matters worse, it can be encoded in both!

The RFC describing URIs and URLs (RFC 3986) has a companion describing IRIs (Internationalised Resource Identifiers): RFC 3987. The IRI spec requires that a Unicode codepoint be equivalent to its percent-encoded UTF-8 form. That is, the letter “é” (U+00E9 LATIN SMALL LETTER E WITH ACUTE) is equivalent to “%C3%A9″. If that is so, then the Unicode fullwidth forms can be encoded in UTF-8 percent encoded too. If we encode the hostnames found on table 2 above, we get:

InputDecoded asType
%ef%bc%90 %ef%bc%b8 %ef%bd%83 %ef%bc%90 %ef%bc%8e %ef%bc%90 %ef%bc%92 %ef%bc%95 %ef%bc%90 %ef%bc%8e %ef%bc%90 %ef%bc%91 192.168.0.1IPv4Address
%ef%bc%a5 %ef%bd%98 %ef%bd%81 %ef%bd%8d %ef%bd%90 %ef%bd%8c %ef%bd%85 %ef%bc%8e %ef%bd%83 %ef%bd%8f %ef%bd%8d example.comreg-name

Table 3. Hostnames in Unicode fullwidth latin letters and percent-encoded
(spaces are for legibility purposes only)

Could it get any uglier? I thought it could. If there are fullwidth characters that transform to regular numbers and letters, is there one that transforms to the percent sign? Well, turns out that there is: “%”. If we apply NKFC to that, we obtain a regular ‘%’. And if you pay close attention to Adam Barth’s list, you see it being used (lines 39-47): “http://%ef%bc%85%ef%bc%90%ef%bc%90.com/” and http://%ef%bc%85%ef%bc%94%ef%bc%91.com/” (the fullwidth percent is “%ef%bc%85″).

At this point, I was about to pull my hair out (thankfully, I had a haircut last week, so I can’t get a grip on my hair). Which operation should I do first: decoding the percent-encoding or applying Nameprep (ToASCII)? Moreover, what’s stopping me from writing “%ef%bc%85″ (the percent-encoded representation of the fullwidth percent) in its fullwidth form (“%EF%BC%85”)? And then encoding that in percent-encoding (“%ef%bc%85 %ef%bc%a5 %ef%bc%a6 %ef%bc%85 %ef%bc%a2 %ef%bc%a3 %ef%bc%85 %ef%bc%98 %ef%bc%95″)? And then repeating the process ad nauseam?

If you’re still with me, we’ve just found a problem: this is infinite recursion. We have to put a stop to it.

Then I remembered another detail: there are also a fullwidth character for slash (“/”), question-mark (“?”) and hash (“#”), all of which are special in URL encoding. Those characters, especially the slash, were the source of a security problem a year or two ago, in which you could hide it in a specially-crafted domain name: for example, in “www.bank.com.xn--6g7c.com”, a blind ToUnicode operation results in “www.bank.com./.com”. Since this attack appeared, QUrl enforces strict STD 3 compliancy. After the Nameprep operation, QUrl will apply these steps from RFC 3490 Section 4.1:

(a) Verify the absence of non-LDH ASCII code points; that is, the
absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.

(b) Verify the absence of leading and trailing hyphen-minus; that
is, the absence of U+002D at the beginning and end of the
sequence.

With this, the “%” and the “[” charactery are rejected and the hostname is considered invalid. For that reason, a hostname containing “%” or its UTF-8 percent-encoding is never valid and we put a stop to the iteration.

That also means the hostname field of QUrl will continue to reject anything that doesn’t conform to the rules above (an exception was made for accepting the underscore character), even if the ABNF for URIs would otherwise accept them. In particular, none of the “sub-delims” or non-URL characters are permitted, either in decoded or percent-encoded forms. That’s why “ed2k://” URLs are not allowed: they use the pipe character (“|”) in the hostname and that fails to comply with STD 3.

I’m almost done with QUrl. Yesterday, after completing the code, I started to run the Unit tests, which are down to 87 failures (from 269 the first time I ran, after fixing the crashes). I should finish with 90% of the failures by tonight, by a mix of fixing the code that isn’t correct and fixing tests that are now wrong.

Oct 12

QUrl in Qt 5: validity

In the previous blog about QUrl in Qt 5, Kenneth suggested I talk to Adam Barth about the issues with URLs in WebKit. So I went to the #webkit channel on Freenode, pinged him and we discussed a bit. He pointed me to a lot of unit tests that WebKit runs related to URL parsing and interpreting, including some of his own results about the acceptance of different browsers (using WebKit and not) to some of the garbage we find out there.

Turns out he has a very extreme view on the subject of URLs and URIs. His position was that there is no standard for what a URL truly is and the RFCs trying to define it (RFC 3986 and RFC 3987) are to be ignored. My position — which matters to you because I’m doing QUrl for Qt 5 — is that the RFC standards are valid and specify how to handle those URIs. Everything else is undefined behaviour and could be rightfully rejected, but we won’t because there’s just too much out there.

RFC 3986 defines an ABNF grammar in Appendix A for parsing of URIs. Qt 4′s QUrl followed this grammar strictly. If you look at the source code, you’ll find matches for exactly the same terms as defined by the grammar. I’m not sure if this is fast, however: could the parser be faster if we had coded it differently? We’ll soon find out, as I’m about to rewrite it.

As a turn of events, however, QUrl started not from the URI but instead from a broader definition of URI-reference which can be either the URI as we’re used to or a relative-ref. The latter is what you usually find in fields where URLs are expected, like the HREF attribute for the A element or the SRC attribute for the IMG element in HTML. That meant that the QUrl::isValid() function was mostly useless, as most inputs were considered valid. What people expected to be invalid did match the relative-ref part of the grammar and the data ended up in the URL’s path component.

So despite being strictly-conforming, the parser was actually quite liberal. Couple that with the QUrl::TolerantMode parsing which corrected mistakes in the percent-encoding, QUrl almost never rejected a URL. The only thing it started to reject were bad hostnames because I considered them a security issue (homograph attacks). QUrl started to apply strict STD 3 conformance and rejected anything malformed there.

For Qt 5, I will relax the parser even further and I’ll accept some of the really strange inputs that I found in WebKit’s unit tests. QUrl in Qt 5 will accept strictly-conforming URLs as expected and will only produce standards-compliant URIs and URLs. The new parser I’ll write is actually closer to what people expect a URL to be. Take this example from the QUrl documentation:

Instead of following the grammar to parse it, I’ll just delimit at the expected boundaries and then try to correct the components as extracted. I mean, I’ll try — we’ll see if I manage or if I need to scrap this method. Hopefully, this will be a faster algorithm.

What does this mean to you? If you were passing QUrl some strict-conforming URIs and URLs, nothing will happen. In fact, it should be 1:1 and give you exactly the same as you gave it. If you had URLs that decoded some percent-encoded characters or UTF-8 sequences without causing it to become ambiguous, QUrl will also still accept your input.

If you had really broken URLs which QUrl accepted and corrected in Qt 4, there’s a good chance that QUrl in Qt 5 will continue to accept and interpret the same way. That’s because the set of unit tests for QUrl is quite extensive and I’ll do my best to keep compatibility.

Finally, if you had really really broken URLs, specially those with broken hostnames, I haven’t decided yet. I will accept some more URLs but, as I said, I consider them undefined behaviour. They may be accepted or they may be rejected — what’s more, the behaviour might change in new versions of Qt.

If your application breaks because of parsing of URLs, please report the bug. I will pay attention to each report. If we can prove that QUrl is failing to comply with the RFC, then the bug is proven and we’ll need to fix Qt. If your input fails to comply, I’ll need convincing arguments why QUrl should accept and correct your input.

PS: ed2k URIs will never be accepted.

Oct 10

Making a Qt Developer Days presentation

First of all, my apologies for not continuing the blog onQUrl yet. For a couple of reasons, I have not been able to continue the work there yet. I will get to it soon.

One of those reasons is the subject of this blog: my Qt Developer Days presentation. This year, the organisers decided to make one double session for all things related to the Qt Project and roadmap, presented by Lars Knoll, Marius Storm-Olsen and myself. With the Munich event is only 2 weeks away from now, the past week and this week has been dedicated mostly to finishing it.

Qt Developer Days is a very high-level event with very good presentations and presenters. Usually the presenters are the trolls: the people actually working on Qt come to present the work they’ve been doing and the technologies they’ve developed and are maintaining. In the past, these people invariably were working for Trolltech or Nokia, but there have always been speakers from other companies like KDAB or ICS. This year, reflecting the opening up of the Qt Project, there will be an unprecedented number of companies and other affiliations represented. My friends at Cutehacks, Woboq, and INdT will be coming.

One of those presenters is me. This will be my fifth year attending and the fourth presenting. Going to Developer Days is a blast, as I get the opportunity to talk not only to other Qt developers, whom I see only a few times a year, but also to customers and users of Qt. Most of the time, people come very open-minded and are eager to learn, so they will pay a lot attention to you. More than that, they try to squeeze every bit of information from you. In 2009 and 2010, I spent my time outside of my presentations basically going around and talking to people, answering their questions or introducing them to others who would have the information they needed.

Dev Days isn’t all joy though: the hardest part is making the presentation. Every year it’s like that: I look forward to Dev Days for about 11 months, then get stressed in the month leading to Munich, which is when I have to make the presentations. For 2008, I had two technical presentations; for 2009 I had one technical and one Qt in Use (Business) presentation. Last year, I had it easy: one co-presentation with my (now) colleague Rusty Lynch and a session discussing the Open Governance, which required only 5 slides. This year, it’s going to be different: it’s a double session, so we have to talk for 2×55 minutes. And coordinating three presenters, living in two different continents, is not easy.

The first thing we did was to figure out what we wanted to talk about, which is when we wrote our abstract. Next, we tried to identify our audience: the people who go to Qt Developer Days are very often commercial customers, who in their majority are writing desktop applications for in-house use. There’s also a good portion of embedded systems developers. And due to Nokia and MeeGo, a growing number of mobile developers. Most importantly for our purpose, the average Dev Days attendee is very interested in upcoming technologies, but not so much in actually contributing. Since we have a double session, we’ve thought of dividing according to such an audience: the average attendee for the first part, pitching a little about contributing, then dedicating the second part to the contribution process and the structure of the Qt project.

That is our current thinking, but with more than two weeks until the actual presentation, we can still change. (Yes, I know the deadline for the presentation was last Friday…)

Personally, the way I do presentations is to create a “wireframe:” I open LibreOffice in the Outline mode and start typing the slide titles, given the abstract and theme of the presentation. I try to apply a couple of techniques I’ve learnt during the years: one is to have the “red thread” — and no, it has nothing to do with multithreading. The idea is to have one common theme that is always present in every slide, building up to compose the bigger picture. Another is called MECE: Mutually Exclusive, Complementary Exhaustive. It means each slide does not overlap with the others in terms of ideas (or worse, contradict), but the grouping of slides forms a whole, with nothing forgotten. Finally, there’s the Pyramid Principle, in which you structure your ideas hierarchically: you construct your argument by having supporting ideas, each with supporting ideas, then you simply “trasverse the graph”.

With your presentation in mind, then you have to put yourself in the audience’s place and mindset. The audience comes to your presentation with a preconception of what you’re going to talk about, which might be right or wrong. In the first few slides, you have to answer the question “What’s in it for me:” why should the audience pay attention to the presentation. If you fail to explain that in the first few slides, when people are still quite attentive, the attention might wander away.

There are techniques to regain the audience’s attention, though. Be very attentive to your voice: do not speak in a monotone. Every now and then, break the cycle, by either blanking the projector or by doing something in which the audience needs to pay attention to you, not the slides. In fact, it’s a good idea not to have much text in your slides because of that: you didn’t come to read the slides to the audience and not having something to drone on, you’re forced to think. If you can, add images, graphs or code to your presentation, but don’t overdo it.

Most importantly, engage with the audience. Make the audience feel that they’re part of the session. So ask questions which cannot be answered by “yes” or “no” — questions starting with “what” or “how” are usually good ones — and give some time to think. And also ask a question before closing a topic and moving on to the next one, to make sure you leave no stragglers behind. If you need to stop, go back, and repeat something, so be it.

Questions during the presentation are usually a matter of taste of the presenter. I prefer to have the questions asked whenever they are most relevant, so I instruct the audience to interrupt me and ask when they feel they need to. I recommend doing that, but paying attention that you don’t spend too much time addressing one person’s needs and lose 99%+ of your audience in the process. Be sure to thank the person for questions (“I’m glad you asked”). If you’ve made a good use of the Pyramid Principle, you’ll probably get questions you’re about to answer anyway.

And at the end, make sure you have left enough time for questions and that your audience knows where to find more information, by repeating links and email address that you might have mentioned during the body of the presentation. Usually, time for questions is not a problem in Dev Days, as a 75-minute slot is quite long and talking for 55 minutes is very hard. But it’s good to plan ahead anyway. And in case there are no questions at the end, you should have one or two up your sleeve that you can ask and answer, or have a ringer do it for you.

I strongly recommend rehearsing with some colleagues a week or two before the event, so you catch opportunities for improvement, where to ask questions, interact, etc. On the actual day of the presentation, make sure your laptop works with the projector, the slides can be read from the back of the room and arrive a few minutes early, to put yourself in the right mind. And then relax and let the presentation speak for itself.

Sep 30

The future of moc

Two days ago, on his blog on some Qt Creator news, Christian wrote:

We’re currently prototyping what would happen if we replaced our own C++ code model with clang’s.

The first comment in the blog was praising that research, but that got me thinking: what do we gain from it? Qt Creator already has a full C++ code model, so what’s the advantage of replacing that with clang’s?

The first thing I thought was reduced maintenance: by using clang’s code, we don’t have to maintain ours. Is that all? What else can we gain from having this code, or the experience in writing it?

Read the rest of this entry »

Sep 20

C++11 support in Qt 5

Marc Mutz posted today a blog calling for immediate support of C++11 in C++-based projects. He also linked to Herb Sutter’s blog saying the standard was unanimously approved in the ISO voting. In his blog, Marc calls for Qt 5 and KDE 5 to require C++11 in the compilers.

I agree with the principle and I’d love to take up on what he’s asking for. But it’s unrealistic for Qt 5.0. Requiring C++11 will take at least one or two more years, when compiler support is a little more widespread. For KDE 5 (or KDE Frameworks), support may come sooner, as the need to support older compilers is smaller.

That said, last month I posted an update to the qt5-feedback mailing list a proposal to update Qt’s use of STL. In particular, I called for the decoupling of the language features from the use of the C++ standard library, putting the emphasis on the embedded systems and cross-compiler compatibility.

I also proposed completely dropping support for compilers that don’t support C++98, especially support for pre-C++98 STL. Of course, we have to be pragmatic, as even in 2011 some mainstream and widely-used C++ compilers fail to support certain advanced C++98 features like template-template parameters (not supported on Sun CC last I checked) or template friends (no support outside of GCC). And, of course, there are compiler bugs or shortcomings we sometimes have no choice but to work around.

STL cannot be used in Qt’s API in a way that it changes the binary compatibility guarantees, but it can be used with Qt as well as used internally. For example, it’s fine to have template code in QVector that supports std::vector and it’s fine to use std::thread (C++11) internally. My submission for the new atomic classes even uses std::atomic where it’s available.

When it comes to C++11 support, I proposed using it to provide access to new / advanced functionality, provided it still respected the limitations above (cannot affect binary compatibility). That is, if you have a C++11 compiler, you’ll get more features, but not having it will not impede your use of Qt. And you’ll be using the same Qt build that someone with an older compiler uses. At least, for the time being.

One feature I’d like to see supported only in C++11 is the new signal-slot connection syntax. C++11 allows us to properly write perfect-forwarding of an arbitrary number of parameters, whereas C++98 requires putting an upper limit on the parameter count and jumping through hoops for those few. Trust me, I’ve done the research and you can read the works of others who have tried to do perfect forwarding in C++98.

If we can find a couple more such interesting features, our users will start using C++11 and start requiring those features from their compiler vendors. In summary, I don’t think we can mandate C++11 just yet, but we can make it attractive enough that people will want it. So let’s not be afraid of C++11, let’s drive its adoption!

Sep 19

QUrl in Qt 5: encoding

One of the classes I used to maintain in Qt was QUrl and I had worked quite extensively with KUrl previously, so I knew what was wrong with the current API. And during the Contributor Summit in Berlin, I volunteered to rewrite QUrl, to add some features KUrl needed.

I described the original goals of the change in the “QUrl in 5″ thread in the qt5-feedback mailing list. After I had done that, I began working on implementing them. This blog is a status update. As I’m not done yet, things might change a bit until the end and the code is accepted into QtCore.

This is the first part and I’ll write more later.

Read the rest of this entry »

Older posts «

» Newer posts

Page optimized by WP Minify WordPress Plugin