Categories
Uncategorized

Further Netbeans notes

Netbeans is working out well as an IDE. I was able to build a static library for RakNet in about 20 minutes including the learning curve. The UI is intuitive and I didn’t experience any bugs. It also automatically creates makefiles and is the first GUI based tool I have found that does so. I […]

Netbeans is working out well as an IDE. I was able to build a static library for RakNet in about 20 minutes including the learning curve. The UI is intuitive and I didn’t experience any bugs. It also automatically creates makefiles and is the first GUI based tool I have found that does so.

I did experience a few design problems. The first is that the C++ project settings don’t expose the C++ compiler settings the way Visual Studio does. Instead, you can pass command line options to GCC. Of course you could do that with Visual Studio too, but nobody I know does. Second, it makes a project directory, rather than a project file. This is bad because you can ignore files with unknown extensions, but directories you have to look at because directory names are not standardized. Lastly, it doesn’t have the concept of solutions with many related and interdependent projects. Because it uses project directories with a fixed name, you can only have one project per directory. The best you can do to emulate a solution is to make a bunch of subdirectories under a common parent directory, have each subdirectory contain a project file, and to just assume people will search for and find the project directories.

Other than this Netbeans is good, doubly so when compared to KDevelop and Eclipse. I’m going to try building the Galactic Melee server on Linux using Netbeans.

One reply on “Further Netbeans notes”

hi!

sorry, no comment to netbeans, but to the btree-source you’ve released 🙂

I’m in the process to write me a library like the stl, but with better performance and better customization (via policy-based design and stuff like that). While I’ve included your code to benchmark it the first thing I’ve found out is, that your algorithm uses extensivly the constructor for the key! Here are some numbers (I’m adding 10 element per run and your btree is used with order=2):

running counting tests with 10 elements

rbtree counted 0.0160s(0.00008000s)
ConstructKey 11 CopyConstruct 10 DestructKey 21
ConstructValue 11 CopyConstruct 10 DestructValue 21

stl::map counted 0.0780s(0.00039000s)
ConstructKey 10 CopyConstruct 30 DestructKey 40
ConstructValue 10 CopyConstruct 30 DestructValue 40

BTree counted 0.0470s(0.00023500s)
ConstructKey 74 CopyConstruct 14 DestructKey 82
ConstructValue 42 CopyConstruct 0 DestructValue 36

BTreeDyna counted 0.0150s(0.00007500s)
ConstructKey 47 CopyConstruct 0 DestructKey 47
ConstructValue 20 CopyConstruct 0 DestructValue 20

crisscross::map counted 0.0160s(0.00008000s)
ConstructKey 21 CopyConstruct 10 DestructKey 31
ConstructValue 21 CopyConstruct 0 DestructValue 21

(rbtree is taken from stdcxx and don’t look at the times, it’s from a debug-build). so you could optimise your algorithm heavily (especially on expensive-to-construct keys)…

keep up your good blog!

Leave a Reply

Your email address will not be published. Required fields are marked *