I'm using slides as a primary resource to assemble my own presentation. Reading the slides has raised questions, and I have no direct way of answering them. I'm beginning to detect the faint aroma of Engineering by PowerPoint.
--
comp.lang.c++ occasionally poses C++ questions I haven't been able to answer. This is concerning.
I suppose I consciously avoid facing some of these issues by my design and development style. I cite this phenomenon as the big reason why C++ amateurs stay amateurs and don't necessarily realize it. That said, I've never worked on a "big" C++ project that required things like overriding new and delete operators, passing custom allocators to STL objects, or doing anything that really required virtual base classes and multiple inheritance. Having never faced those issues, I haven't been exposed to the sort of deep and nuanced language and implementation issues, and haven't received the educational benefit of trying to solve them.
--
I want to setup an installation of TRAC or some similar bug tracking resource. It'd be a good way to organize thoughts and fix other people's bugs. Ahem.
--
Whatever happened to Linkwell?
2 comments:
Have you seen the second to last thing on linkwell? thats what killed it. oh, and josh never having the program running and letting it die.
heh, comp.lang.c++ got you? better brush up on your c++. you never did get that last book, did you? I'll have to go back to the meeting about c++ when they were defining it and get a real good one for you to figure out.
I think that some of those issues should go away if they just thought about the problem in a different manner. Multiple inheritance sounds awesome, but I have never actually used it in anything. I am becoming less and less sold on OOP. I bet they have a large project with high turnover. In the end, it doesn't matter if you pass the function an object to modify, or if you call the function from an object... It is nice to be able to know what functions and attributes an object can have, but I have never seen that in c++, it is very easy in python though, with a dir([object]). (without looking at source...)
I knopw oop has more than that, but most people only use the encapsulation/abstraction part.
TRAC works fairly well, we are using it for one of our projects. It is nice to be able to assign people bugs, and to have a list of things that need to get done. You get accountability and also a way of tracking who does things and when they do them. This can remove probably a meeting a week, where people are just catching everyone else up on what they are working on. If its on TRAC, you see it as they check it in, or you see tickets getting done. It comes with a wiki, so you also get to have discussions about things, and then see the code right from the same interface. It is not perfect, but its a step up.
I'm not sure what "last book" you're referring to. If it's The C++ Programming Language: Special 3rd Addition, then yes I do have it. It's within arm's reach now, actually.
Many freely acknowledge that C's declarative syntax has resulted in a number of rough edges in C++. Whole keywords were introduced to resolve ambiguities *after people started using the language* but before it was standardized. A number of books were written to cover pitfalls that C++ programmers unwittingly got themselves into.
This is why I started reading comp.lang.c++; it's like doing a morning crossword puzzle.
As for multiple inheritance, you've probably used a fraction of it unwittingly. The Java concept of an "interface" captures the easy parts: runtime type information used to accomplish dynamic binding. You get into real trouble when the base classes have data members, and when the same class is inherited multiple times.
Post a Comment