> > 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? >
my initial experiments have not shown any large detriment to speed. My plan is to remove one list at a time and see how things get affected. Right now it is still in experimentation. This is another reason I have not asked for help. > 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 do not share the opinion of it being bloated. But again, we shall see. I am very much a fan of profiling tools as a guide. If the numbers go way off, another solution will be found. > 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? > Some of the blackbox internals are plain ugly. Try looking at the menu code sometime. Brad hardcoded magic numbers for each of the menu elements. it is truly disgusting. I have considered a map (or hash_map). > 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. > if STL ends up being the wrong choice, another choice will be found. Personally I can not stand the API of the current LinkedList so anything will be an improvement. > > 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. > no, this is kind of how I plan to implement it actually. One master list whihc is in charge of deleting items when the time comes and then the workspace lists as essentially "views" on the master list. > 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? > exactly. > Maybe some redesign of the classes / interaction is more in order than > re-doing the implementation. (No offense to the original designers and > implementors) :-) > Brad and I have discussed this on and off. He has some things he would go back and change. blackbox was one of his first major projects. It is simply showing its age. > 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. > I understand LinkedList and I have touched LinkedList. I simply do not like it. Little things like: LinkedListIterator<Window> it(windowList); ... // use iterator it.reset(); That is just not an API I like to play with. I much prefer the STL approach with iterators. As for the rest of Blackbox code, a lot of it is quite well thought out. However one of the big headaches as a maintainer is the tight coupling of the classes. BScreen does EVERYTHING. Want to know the Screen size ask BScreen. Want to know whether the toolbar is horizontal or vertical ask BScreen. Want to change your Style ask BScreen. Practically every file access methods from screen. One small change in that file breaks the whole window manager. This bothers me and I intend to fix it. Most of blackbox is not limited by the data containers. The functions in the Image class are the slowest functions by any profiling I run. Closely followed by the placeWindow code. > > I do not mean for this message to come off as anti-*, it is just my > ponderances on a few things. That's all. > Please, always ask questions. Always question my decisions. Hell complain every day (-: I like feedback and a good argument. You may not like my decision in the end but at least we discussed it. I try very hard to not make up my mind ahead of time. Intelligent arguments can win me over. Usually (-:
