Visual Studio 2005 provides a very decent IDE to work with (if you overlook the crashing and disappearing into black holes). There hasn't been much focus on the native C++ side of the IDE for a while, which means it does lack some useful features.
One of those tools available for free on the internet is CodeWiz2 providing a number of very quick and simple additions to the IDE which makes coding a bit easier. Friend File lets you switch between header and implementation and Friend Member lets you switch between declaration and definition for a single function. I did have a script that did it, but this works much better (and will at least work on Vista as well since the Macro Explorer was broken last time I tried).
It is also scriptable in a manner of speaking meaning you can get common code structures or comments at the tap of a button. Oh yeah, did I mention it is free?
Another free tool available for Visual C++ is Refactor! which you will be surprised to hear offers refactoring for C++. Only the simplest functionality is available in the free version but it is quite interesting. I tend to refactor by hand myself, but one useful side-effect of this plug-in is when it highlights all instances of a variable which helps make the code a bit easier to navigate (and should really be a basic feature of the IDE).
This is somewhere to dump what I learn about programming as I go along. Currently I'm a developer working for Bromium in Cambridge. There'll be lots of Python and lots of Linux.
27 September 2007
26 September 2007
GUI Toolkits - The Forgotten Part Of My Blog
I have been doing this blog nearly a year now and certainly in 2007 I have neglected GUI coverage. The main problem is that there hasn't been a huge amount of impressive work on the open-source front and those libraries that showed the most promise are languishing in Sourceforge hell.
Maybe Winforms has caught on big-style? Maybe, but as far as I can tell when you get down to the OS level it still amounts to Win32 function calls, it is just the framework is built on top of that. Also, many more applications can now be run as web-based applications, with its own plethora of GUI toolkits.
Qt is obviously the leader but is only open-source for open-source applications unfortunately (and quite rightly as they do deserve to make money off it). wxWidgets is not making as massive strides as many would have hoped in order to have really good looking native Windows applications. The most recent substantial addition was wxAUI that added lots of good stuff like docking. None of the ideas floating around Boost got off the ground unfortunately, and Win32GUI Generics and Notus and many others are mothballed. Maybe there needs to be a "State Of The GUI Union" post...
I am thinking of doing a small GUI toolkit just to test out the theories and get a better appreciation of the difficulties involved in design and implementation. It would also mean I could play around with some of my memory allocation and multithreading ideas as part of it. I've been trying to pull together as much information about Win32 as posible and I'll definitely put them all together in one article.
Maybe Winforms has caught on big-style? Maybe, but as far as I can tell when you get down to the OS level it still amounts to Win32 function calls, it is just the framework is built on top of that. Also, many more applications can now be run as web-based applications, with its own plethora of GUI toolkits.
Qt is obviously the leader but is only open-source for open-source applications unfortunately (and quite rightly as they do deserve to make money off it). wxWidgets is not making as massive strides as many would have hoped in order to have really good looking native Windows applications. The most recent substantial addition was wxAUI that added lots of good stuff like docking. None of the ideas floating around Boost got off the ground unfortunately, and Win32GUI Generics and Notus and many others are mothballed. Maybe there needs to be a "State Of The GUI Union" post...
I am thinking of doing a small GUI toolkit just to test out the theories and get a better appreciation of the difficulties involved in design and implementation. It would also mean I could play around with some of my memory allocation and multithreading ideas as part of it. I've been trying to pull together as much information about Win32 as posible and I'll definitely put them all together in one article.
ACCU Cambridge Talk - October
It's hard to believe it is nearly October. The bad part is getting older, the better part though is that the ACCU talk is coming up. See the website here.
This month is about dynamic languages and is called "Closing the Case for Groovy (and Ruby, and Python)" by Russel Winder. And apparently there will be a related book that may or may not be out in time for it.
Hopefully the week after will have the first BCS SPA Cambridge meeting since the summer as well.
This month is about dynamic languages and is called "Closing the Case for Groovy (and Ruby, and Python)" by Russel Winder. And apparently there will be a related book that may or may not be out in time for it.
Hopefully the week after will have the first BCS SPA Cambridge meeting since the summer as well.
11 September 2007
ACCU Cambridge Talk - The Missing Link
This month's ACCU Cambridge "The Missing Link" talk was held at the DisplayLink offices on the 6th of September. Presenting the talk was Peter Smith who is part of the linker team at ARM.
The Missing Link talk was about the role of the linker in software development. The talk detailed the history, the design of, and the use of linkers. The talk was about an hour long but could easily have gone on longer. Certainly from the tak I got the impression that the linker is a rather unloved part of the compilation process. In fact there is really only one book about linkers called "Linkers and Loaders" which is available online from this link.
The talk itself was entertaining and was at a suitably high level for everyone to understand. The actual architecture of compilation and linking really has not changed to much throughout its history. Some of the more interesting parts of the talk were the discussions about name mangling and the reasoning behind it, and the caveats that need to be implemented to get around things like templates in C++.
I think there is a plan for the slides to be available online via the ACCU website.
As always though after the event you can learn lots more by going to the pub. A good turnout for the pub was the icing on the cake.
The next talk will be about dynamic languages and will be held on the 4th October. Keep an eye on the .
The Missing Link talk was about the role of the linker in software development. The talk detailed the history, the design of, and the use of linkers. The talk was about an hour long but could easily have gone on longer. Certainly from the tak I got the impression that the linker is a rather unloved part of the compilation process. In fact there is really only one book about linkers called "Linkers and Loaders" which is available online from this link.
The talk itself was entertaining and was at a suitably high level for everyone to understand. The actual architecture of compilation and linking really has not changed to much throughout its history. Some of the more interesting parts of the talk were the discussions about name mangling and the reasoning behind it, and the caveats that need to be implemented to get around things like templates in C++.
I think there is a plan for the slides to be available online via the ACCU website.
As always though after the event you can learn lots more by going to the pub. A good turnout for the pub was the icing on the cake.
The next talk will be about dynamic languages and will be held on the 4th October. Keep an eye on the .
10 September 2007
EASTL And Allocators
A few months back a document appeared on the Internet about EASTL. It details alterations to the STL that Electronic Arts implemented (as well as their own version of the STL) to meet its requirements for standard containers and algorithms. It has been published on the C++ standardisation website as a reference paper.
Some of the ideas in it are very interesting and some are a little naive and lack generality, but the document itself is thoroughly worth it. The main thrust of the document is efficiency in terms of memory and speed. This amounts to better allocators, better control of low-level memory (alignment and so on) and intrusive type containers.
It covers the deficiencies of std::allocator for EA's requirements like the copy semantics and the lack of alignment controls. It has got me thinking there is a lack of a generic allocator framework that makes it easier for writing pluggable allocators that could be thread local, or global, or thread-safe, or instance-based. But I'll come back to that later.
vector bool is not a bit-based array but there is an implementation of a bitvector that gives the same behaviour. That makes sense to me!
The ability to resize a containers capacity to a smaller size and for the storage to respect that as most STL implementations do not do this. Means memory can be returned back to the system.
Apparently the implementation is easy to debug through a simple debugger with no overhead. I don't know whether that is the case in reality but it certainly has its appeal, but I'm sure it would make plenty of sense in open-source implementations meaning there would be more people able to contribute.
Apparently some compilers struggle with inlining so the implementation reduces code complexity to allow less able compilers to inline more.
A lot of the motivation behind this is cross-platform in nature and part of that is that the platforms can be limited in memory and processing power. Some of the ideas brought up are possible in the current STL framework with some minor jumping through hoops, fortunately EA expended the manpower on implementing exactly what they want.
Now back to the allocators... The ideas make a lot of sense in this document and I wonder how many are available to coders from the current STL framework. One thing that requires clarity is what the alignment needs in order to align, by this I mean is it easily determined from the type you are using or is it a combination of that and the machine type. If so some of the work could be done via type traits like those available through Boost.
A lot of the allocator type suggestions do not even have an easy to use reference implementation in the open-source world. Allocators are so important but there is a lack of availability of those apart from simple HOWTOs for writing allocators.
This has got me thinking about actually writing some. Coming up with a good framework has lead me to reading big stacks of articles online about allocators, and I think there is a good way forward but 'll leave that to another post.
And there is some additional discussion on the Ogre forums here and here.
Some of the ideas in it are very interesting and some are a little naive and lack generality, but the document itself is thoroughly worth it. The main thrust of the document is efficiency in terms of memory and speed. This amounts to better allocators, better control of low-level memory (alignment and so on) and intrusive type containers.
It covers the deficiencies of std::allocator for EA's requirements like the copy semantics and the lack of alignment controls. It has got me thinking there is a lack of a generic allocator framework that makes it easier for writing pluggable allocators that could be thread local, or global, or thread-safe, or instance-based. But I'll come back to that later.
vector bool is not a bit-based array but there is an implementation of a bitvector that gives the same behaviour. That makes sense to me!
The ability to resize a containers capacity to a smaller size and for the storage to respect that as most STL implementations do not do this. Means memory can be returned back to the system.
Apparently the implementation is easy to debug through a simple debugger with no overhead. I don't know whether that is the case in reality but it certainly has its appeal, but I'm sure it would make plenty of sense in open-source implementations meaning there would be more people able to contribute.
Apparently some compilers struggle with inlining so the implementation reduces code complexity to allow less able compilers to inline more.
A lot of the motivation behind this is cross-platform in nature and part of that is that the platforms can be limited in memory and processing power. Some of the ideas brought up are possible in the current STL framework with some minor jumping through hoops, fortunately EA expended the manpower on implementing exactly what they want.
Now back to the allocators... The ideas make a lot of sense in this document and I wonder how many are available to coders from the current STL framework. One thing that requires clarity is what the alignment needs in order to align, by this I mean is it easily determined from the type you are using or is it a combination of that and the machine type. If so some of the work could be done via type traits like those available through Boost.
A lot of the allocator type suggestions do not even have an easy to use reference implementation in the open-source world. Allocators are so important but there is a lack of availability of those apart from simple HOWTOs for writing allocators.
This has got me thinking about actually writing some. Coming up with a good framework has lead me to reading big stacks of articles online about allocators, and I think there is a good way forward but 'll leave that to another post.
And there is some additional discussion on the Ogre forums here and here.
04 September 2007
Upcoming Computing Talks In Cambridge
There are a couple of talks coming up in Cambridge in the next couple of weeks. We're lucky here in Cambridge that there is anything like this to go to as I can't find many instances of this throughout the country.
First up we have ACCU a group striving for professionalism in programming (and there is a fair amount of emphasis on C++). They have journals released regularly throughout the year which makes membership pretty worthwhile (also membership gives you access to the entire archive online).
7:00pm Thursday 6th September 2007 - Peter Smith: The Missing Link, the role of a linker within a software development. You can sign up to the talk at this link.
Next up is the BCS SPA are going to start there monthly talk programme again after a summer break. At the moment the talk next week is not known but you can keep an eye out here.
Interestingly there will be a talk from Ian Griffiths about WPF (Windows Presentation Foundation) on the 14th November. He is one of the architects behind the whole new graphics interface in Vista.
First up we have ACCU a group striving for professionalism in programming (and there is a fair amount of emphasis on C++). They have journals released regularly throughout the year which makes membership pretty worthwhile (also membership gives you access to the entire archive online).
7:00pm Thursday 6th September 2007 - Peter Smith: The Missing Link, the role of a linker within a software development. You can sign up to the talk at this link.
Next up is the BCS SPA are going to start there monthly talk programme again after a summer break. At the moment the talk next week is not known but you can keep an eye out here.
Interestingly there will be a talk from Ian Griffiths about WPF (Windows Presentation Foundation) on the 14th November. He is one of the architects behind the whole new graphics interface in Vista.
Subscribe to:
Posts (Atom)