On Wednesday 06 February 2002 15:39, Sean 'Shaleh' Perry wrote: > There has been some concerned raised and I want to discuss this on its own > thread so no one misses it. > > In the upcoming weeks there is going to be a major change in the blackbox > internals. Part of this is to remove the home brew linked list code and > use the STL. Part of this is to allow for support of the NET WM spec > (compliance with KDE and eventually GNOME). Part of the effort is simply > refactoring which happens to code every now and then as part of its life > cycle. >
I am assuming you have done some serious investigation into using the STL containers in Blackbox. I am quite unfamiliar with the BB code base, but I have a great deal of experience using the STL. My development experience has brought me to some opinions/realizations. The STL is slow. In all of my development experience, when speed and efficiency are heavy requirements, the STL is most like not the best implementation of a solution. Since speed is a major drawing point to blackbox users, how will a new implementation under the STL containers affect that? The STL is very bloated. No denying that. Since another drawing point to Blackbox is the small size, how will a new implementation with the STL affect that too? I know in my past experiences, that coding a solution where I based the design on the STL originally, ended up being scraped and a "home brewed" solution was created. In fact, it is mostly a linked list implementation(s) when speed is vital that I discovered this. Vectors are great containers, and easy to use when you just need a container, and don't care how slow things are (ie GUI). Maps are horendously slow in any case. Deques, and Queues fall in between somewhere IIRC. Maybe some more details on the specifics of the changes could be good. From the code I looked at it seems to only use lists? Which would be converted to vectors correct? I'm not throwing the sword down and saying _Don't_ by any means. I am just concerned to a major switch like this. I would fear that using the STL containers could possibly be a detriment. > This is one of those times in programming where everything stops because > one change breaks everything. The classes in blackbox are tightly > interwoven and a seemingly small change causes havoc everywhere. Also some > of the actions the net wm spec desires are not easily performed with the > current code. An example of this is the _NET_CLIENT_LIST. blackbox is > expected to return a list of every open window it manages. The only way to > implement this currently is to loop over each workspace requesting its > internal window list and make one long list. Then we convert this list to > the format the message must be sent back in. Rather than write more list > code I would like to use standard C++ style container classes. More C++ > people understand them which will allow for more people to hack on > blackbox. > Maybe I am missing something in the code I looked at, but as for the _NET_CLIENT_LIST. When a new window is created it is added into the workspace window list. Why not maintain a list of window pointers in the BlackBox class, and add the same pointer to that list as well. It is just a list of pointers right? It's small, maintains the speed, and no more code for a list. Am I missing something. For that matter, if Blackbox itself needs to know all of the windows it manages, shouldn't it keep the "master" list of windows so to speak, and then each workspace keeps track of which windows from the master it has? Maybe some redesign of the classes / interaction is more in order than re-doing the implementation. (No offense to the original designers and implementors) :-) As for a better understanding. Some will argue the point of STL/no STL. I personally feel if you can not figure out the LinkedList class from looking at the header file, you have no business being in the code anyways. It is a common, and straight forward class. I must say the BlackBox code in whole is very, very nice. Period. If you are not at a level where you can gain from reading the code base already there, then which implementation used will be of no benefit either way to you. I do not mean for this message to come off as anti-*, it is just my ponderances on a few things. That's all. Andy
