# Tuesday, 24 January 2006

The word is starting to spread about the concurrency skills we are all going to need sooner rather than later. And work is underway at dev-tool-makers to offload some of that work to the "system" -- maybe the language, the compiler, a library, the framework, the operating system -- anything other than the programmer because most of us are even worse at threads-and-locks than we were at malloc-and-free or new-and-delete or any other kind of memory management.

If you were wondering about Microsoft's committment to this (and the PDC talks on the topic weren't enough to convince you) then read Kang Su's latest blog entry about the new Bay Area Office they are establishing for this sort of progress... and wait till you see who's going to be working there...


Tuesday, 24 January 2006 12:42:33 (Eastern Standard Time, UTC-05:00)  #    Comments [3]
Saturday, 28 January 2006 03:45:00 (Eastern Standard Time, UTC-05:00)
Hopefully, they'll get some c++ people this time. Maybe the next IDE version/successor to .NET won't be so screwed up then.
Tuesday, 31 January 2006 14:32:06 (Eastern Standard Time, UTC-05:00)
This is very interesting (and encouraging) for the C++ developer in all of us. I remember reading a quote from Stroustroup (sp?) regarding threading & C++. (When the article was written) Stroustroup didn't agree with implementing threading (and concurrancy) within the C++ language itself, since C++ was designed as a language which would/could be extended via the use of libraries, and not language extensions.

Then the Boost::Thread library came along, and it seemed like the C++ standards commitee started to debate adopting the Boost way of doing threads as the native C++ way of doing things. (The C++ committee already seemes pretty excited about Boost since they've implemented some of the Boost templates with std::tr1/std::tr2 ).

I don't really care about how intuitively the IDE makes concurrant programming, as long as there's a platform independant interface/contract with threads that works (well) over all platforms. Take MacOS X's implementation of the posix-thread API. They've included it with 10.3(?) but it runs much slower than most of Unix(-like) implementations because of the way in which Apple's microkernel handles message-passing between threads. If C++ can force the hand of Kernel/compiler creators to adopt a standard API then they should be nominated for the Nobel Peace Prize.

Let's just hope that Microsoft doesn't decide to "go it alone" and develope a standard that won't be adopted outside of their beta-testers' development-style culture. No one needs another DCOM.
Tuesday, 31 January 2006 16:54:27 (Eastern Standard Time, UTC-05:00)
(While I'm ranting..)

I'd like to see a "property" keyword added to C++0x/C++09, but *not* implemented like http://msdn2.microsoft.com/en-us/library/es7h5kch.aspx

Although the argument can be made that such property accessors/mutators are redundant (why not implement "const & T get() const" & "void set( const & T )" methods ) they do offer a more readable/writable aspect to the language.

And as a developer, isn't language expressability one of the most important features of a language?

As an afterthought to this (afterthought) post, a class called "std::property" would be nice, and have "=" operators that are used to get/set the property-instance. Kinda like this:

typedef (callback_t*)( void * );

template < tyname T >
class property
private: T _data;
private: callback_t _cb;
property( callback_t cb ) : _cb( cp ) { };
operator=( const T & rhs )
_data = rhs;
_cb( & _data );

const T & operator=() const
return( _data );

}; // class property

class foo
int _data;
property< int > PROPERTY( setCallback );
static setCallback( void * d ){ /* somehow call *this instance */ };

This was all written in the blog post entry, so I'm sure that it doesn't compile, but the idea is there.
Comments are closed.