Your C++ preferences? - Developers

I am going to write a library for C++ for to be used in game development. Which will going to include everything from horseshoe to truck tire. So I am not going to write it just because I am going to use but I want other people to use it. Actually I had written one but I want to start from scratch and clean up everything and move to total test driven development strategy. Before starting anything I just want to ask you what is your opinions and what is your favorites about these stuff, which going to form the project: 1) Your naming convention. ( like UpperCamelCase, lowerCamelCase... ) 2) Namespace usage. 3) Development Strategy. 4) What would you wish that is included in a library? 5) Platform and compiler? 6) Safety or speed? 7) Prefixes or Affixes around classes and members. 8) License? 9) File naming convention? like ( allsmall.cpp, BigCapitals.cpp... ) 10) Maximum name length for classes and members? 11) Documentation; what kind of documentation would you like? machine generated from code comments? or written manually? 12) Folder structure 13) Other thoughts Example from myself: 1) I like UpperCamelCase 2) Like I am currently thinking put everything inside one namespace and one "using x;" will be include everything. 3) Obviously; Test Driven. Everything will be tested. It will even so you can recode everything from test project even if main project got lost. 4) In my mind there is Graphics, Mathematics, Networking, Encryption, Compression, File System stuff, GUI. 5) I am planning to support Linux, Windows platforms and GCC and MSVC compilers. 6) I like speed while I will add alternative classes for safety. 7) I don't like Prefixes or Affixes. String is String why name it as CString or something? 8) I am thinking about dual licensing it like free for free software, paid for paid software. It will be totally free if we became a group or something and find some sponsors to back us the development. 9) Planning to do BigCapitals.cpp because it was allsmall before I didn't like it now. 10) Have no idea. I used to name things to make it self describing. 11) Initially it may be generated but I would like it has some more insight than machines :) 12) Currently there is (bin, examples, projects, [nameoflib] and test) folders exists. 13) You may ask why I am doing this because there is already bunch of libraries out there supporting a lot of stuff; my purpose is simple, easy to use, fast, efficient and consistent library. Which I see a major problem in C++ world. Like people comparing c# with c++. Actually c++ is stronger than c# in all ways but c# had the .net backing it which makes it easy to use.

I use UpperCamelCase for types (be it classes/structs, enum, template parameters, ...) and members (functions and variables). Global functions and variables are lowerCamelCase. Local variables and parameters also. I don't use special naming for constants. I think having one single namespace for everything is fine. My personal taste in development strategy won't change anything for you I presume, especially since you've already decided on TDD, but I use some buttom-up like approach and wiggle around until I like the interface (with some manual testing) and then document it. Adding to what you've said, sound (think of 3D sound and plugging in effects), physics and HID. clang is pretty cool, too. I only develop on Linux, but I try to keep my code free of platform specifics and resort to cross-platform libraries for that. And I compile with both gcc and clang and a bunch of warning flags. I lean towards safety, though most checking only gets done in debug builds. That is sanity checks and stuff that I'd consider the developers fault. I don't use prefixes or suffixes or anything. I license most of my stuff under CC0 (public domain). I use allsmall.cpp (and .hpp, not .h). Not sure why. It works. I don't have maximum name length, maximum nesting depth or line width. I try to keep it reasonable, that's all. Reason is in the eye of the beholder of course. But I like to insert a couple of line-breaks in documentation. I use Doxygen-comments to document the interface. I think I'm a little sparse on implementation comments, but I try to comment that, too. I don't understand what you mean by you liking something with more insight. I'd do examples, include (public headers), src, test. I'm unsure what'd be the use for the bin-, projects- and [nameoflib]-directory. For the latter two - do you want to split the functionality into separate modules and provide some kind of "master-module"? If you want to split it into modules, I'd just have directories for each module and then the mentioned directories as sub-directories. It might be good to differentiate between the modules with a further namespace as well. Will you use C++11? Or perhaps conditionally include C++11 support? And do you plan on leveraging existing libraries, such as Boost, SDL, PhysicsFS, eNet, ..?

I use UpperCase for classes, structs, enums, methods and all that. I use lowerCase for variables. I don't use namespaces at all actually. My strategy is focusing on one thing at a time and not leaving half-finished methods laying around (classes are fine). The only libraries I've used are SFML and DirectX 9.0 with irrLicht (DirectSound is a pain in the ass) and they basically contain everything you need to develop games at various levels. When at the same time you can use them for things other than games. Windows 7, Visual Studio. Safety first. g_variable for global variables. m_variable for member/local and protected variables. _PrivateMethod for private/protected methods. I haven't ever released any of my work so I'm not sure about licensing. File names are UpperCase.cpp/h [i]except[/i] for main.cpp. I don't even know why. CSomeClass.cpp/h if the main purpose of the file is to define and handle a single class. As long as needed as long as it's not named after sentences. That's what comments are for. People tend to give more insight than machines when commenting, for example, methods. Every time I need information on anything regarding WinAPI I have to go to MSDN, since nothing is properly commentated. I usually put everything in the same folder since I've never worked with any big projects that exceed 20 files.

[QUOTE=ZeekyHBomb;41553903] snip [/QUOTE] bin folder will be used for output of compilations and [name of lib] folder will hold the source and projects will hold the project files for common IDEs like code:blocks, msvc and netbeans. I actually have a name for project but didn't want to disclose before getting a domain for it. Audio stuff was in my mind I just forgot to write it :) 3d stuff will be another project and will be build on top of this. So this will be like .net framework of c++ something like you can just include and go coding before worrying anything. Things are already modularized but I was keeping them in same folder.But separated with logical folders. I was using sub folders before but I later decided to keep them in same folder. So it will be easier to find files. Doxygen style comments are what I am using already and its cool :) I like C++11 and adapting new things earlier. So yeah it will be good. [QUOTE=Anven11;41554142] snip [/QUOTE] Yeah like you, I didn't publicized anything yet. This will be my first time and thats why I am asking about opinions of people :) And I am going to focus on base tool set which is cover of this project. When this one is mature enough, I will post about 3d engine stuff. I can show some stuff already done some time later.

[QUOTE=codetorex;41554450]bin folder will be used for output of compilations and [name of lib] folder will hold the source and projects will hold the project files for common IDEs like code:blocks, msvc and netbeans.[/QUOTE] You could look into makefile generators such as CMake. It can generate project files for some IDEs, some can directly work with a CMake-file and you can choose where to build to. It also makes it easier to look up dependencies. [QUOTE=codetorex;41554450]I like C++11 and adapting new things earlier. So yeah it will be good.[/QUOTE] Note that you limit your target audience with that. afaik the MS guys are a bit behind, and with clang or gcc you need a fairly recent version. I would still recommend going with C++11, but this is something you might want to keep in mind.

// 1) Your naming convention. ( like UpperCamelCase, lowerCamelCase... ) UpperCamelCase for types, lowerCamelCase for pretty much everything else. // 2) Namespace usage. Usually everything inside the "library-named" namespace. When I want to hide templates and other crap, I create a nested "Internal" namespace. // 3) Development Strategy. Write some code, try to compile, fix bugs, beautify, optimize. // 4) What would you wish that is included in a library? Docs. // 5) Platform and compiler? GNU/Linux and clang++3.4. // 6) Safety or speed? Speed, with as many zero-overhead abstractions as possible. // 7) Prefixes or Affixes around classes and members. Usually none. // 8) License? APL3.0. // 9) File naming convention? like ( allsmall.cpp, BigCapitals.cpp... ) UpperCamelCase, .h and .cpp // 10) Maximum name length for classes and members? None. // 11) Documentation; what kind of documentation would you like? machine generated from code comments? or written manually? Doxygen and comments where appropriate. // 12) Folder structure "project/src/project/..." "project/include/project/..." // 13) Other thoughts Use as much C++11 as possible - I'm already looking forward to C++1y implementations

[I]1) Your naming convention. ( like UpperCamelCase, lowerCamelCase... )[/I] UCC for classes, methods, types; lCC for variables. [I]2) Namespace usage.[/I] One single namespace for whole library. Use a simple short lowercase name (like [I]sf::[/I] is used by SFML). [I]3) Development Strategy.[/I] TDD [I]4) What would you wish that is included in a library?[/I] Inline documentation of everything, preferably XML style, so it can be parsed by both IntelliSense in Visual Studio and Doxygen. [I]5) Platform and compiler?[/I] G++ - And make it work on every platform you can think of. [I]6) Safety or speed?[/I] If it's a game library, speed is preferred. [I]7) Prefixes or Affixes around classes and members.[/I] No, please. That's why you use a namespace. [I]8) License?[/I] MIT [I]9) File naming convention? like ( allsmall.cpp, BigCapitals.cpp... )[/I] .h, .cpp - BigCapitals [I]10) Maximum name length for classes and members?[/I] As far as one can remember it, it's fine. [I]11) Documentation; what kind of documentation would you like? machine generated from code comments? or written manually?[/I] Obviously both of them. [I]12) Folder structure[/I] N/A [I]13) Other thoughts[/I] As others have already said, use C++11. [B]Good luck![/B]

Thanks for all these valuable inputs! I see common logic flowing through here because I see answers are mostly similar. Which are how I was already working, so not much deviation required from original plan. It helped me to verify myself. And interesting points are C++11, CMake, clang, and more commentation. I am going to investigate CMake stuff. Because currently I am using a plugin that I made for generating makefile, compiling stuff in linux over ssh and returning results. Which I am planning to release on github sometime later. Actually library is could be released at current state but I was watched a TDD video on youtube some time ago and when I see how it could be used as blueprint to the design, I wanted to follow that way and implement everything in TDD way. So it could be trustable library for everyone. Now first thing is setting up testing environment and letting test suite, test itself :) I will create another thread when I setup github repository and coded some bare bones. Then I may ask for code review and feedback from you guys :)

[url=http://www.codinghorror.com/blog/2013/07/rule-of-three.html]The Rule of Three[/url]. It's a good challenge but does it provide any practical benefit that something else doesn't already?

[QUOTE=andersonmat;41561069][url=http://www.codinghorror.com/blog/2013/07/rule-of-three.html]The Rule of Three[/url]. It's a good challenge but does it provide any practical benefit that something else doesn't already?[/QUOTE] Well I already have a codebase of 50klocs. Maybe not much but provides most of solutions I needed. My purpose is making it easy to program with c++. I don't know how much people will use it, thats what I am wondering and thats why I am going to release it :) Because all this time I was writing code alone, for only myself. I am like father of the marty mcfly who writes books but was too afraid to release them. So I hope this may help me to break my chains too. So I am planning to learn a lot from this whole experience. I want to provide fast, light and understandable library for general purpose and game programming uses. Where you can include a file and start coding without thinking about anything else other than your own solution. If I succeed to provide this, I think people will use it. Current code base is based upon knowledge and necessities I accumulated over years. So I know I will use this in my projects :) And what does this count as? rule of one? :)

-snip-

I usually name the classes with a capital letter followed by generally lower case then upper case functions (ex: XWindow::setVisible(false)) I usually don't use namespaces unless the std library comes into play. When I develop, I start out with a basic structure in my head, then use trial and error to work my way up. I wish there was a library that could have several handy GUI/3D complex functions. I develop on VS 2010 and try to make programs cross platform if possible. I try to achieve as much speed in the program while trying to make sure I don't have dangling pointers or memory leaks. I usually put the first letter or two of a program name in front of class functions. For licenses, I look carefully for ones that allow commercial usage in case my programs get popular (which will be never... ) I keep all my files lower case named, and I try to avoid functions named like reallyLongNamethatDoesRendering(). I add comments on some spots to make sure I don't get lost on what I'm doing or achieving. Some days I have a programming "vibe" which drives me to write software, but I can't really write it on days where I'm tired as hell.

[I]1) Your naming convention. ( like UpperCamelCase, lowerCamelCase... )[/I] UpperCamelCase for types, functions, namespaces, enum types (but not its contents). UpperCamelCase with g_ prefix for global variables (used sparingly). UpperCamelCase with m_ prefix for class variables. UpperCamelCase with abbreviation prefix for struct variables (e.g. VectorComponent::vc_X). lowerCamelCase for function arguments and in-function variables. All caps for defines. [I]2) Namespace usage. [/I] A project-wide namespace (e.g. Raptor) and additional namespaces to categorize (e.g. Graphics). [I]3) Development Strategy.[/I] Create a skeleton of the basic functionality first. Put down on paper or make a mind note of what needs which resources. Prototype functions and classes and afterwards fill them. Expand as needed for new functions and classes. [I]4) What would you wish that is included in a library?[/I] Documentation including acknowledgement of any bugs. [I]5) Platform and compiler?[/I] Windows 8, MSVC110 and MSVC100 (that's VS2012 and VS2010). [I]6) Safety or speed?[/I] Speed where possible, but not sacrificing readability or safety. [I]7) Prefixes or Affixes around classes and members.[/I] See 1. [I]8) License?[/I] Apache, LGPL Hasn't been much of an issue for me so far, as I haven't released any code into the public domain. [I]9) File naming convention? like ( allsmall.cpp, BigCapitals.cpp... )[/I] .h and .cpp, both in UpperCamelCase. Except for main.cpp. [I]10) Maximum name length for classes and members?[/I] There's no real maximum length. Use common sense. Use abbreviations where logical. [I]11) Documentation; what kind of documentation would you like? machine generated from code comments? or written manually?[/I] Both are fine. On a side-note, I really prefer self-documenting code. My biggest issue and goal at the moment is commenting my own code, I tend not to do it. [I]12) Folder structure[/I] For small projects, all the code files may be in one directory, but for bigger projects they should be categorized into folders. [I]13) Other thoughts[/I] I am not using C++11 at the moment for compatibility issues, but I am eager to explore it sometime soon.

I've been working on something like this for over a year now. We haven't bothered mentioning it around facepunch because it's largely incomplete, but we're still actively working on it. [url=https://github.com/Zethes/Jatta]We have it on github if you want to check it out[/url], but again it's not in a usable state just yet. As for your questions, I am going to try to play devils advocate a bit... there's a reason these things don't have a simple answer. [b]1) Your naming convention. ( like UpperCamelCase, lowerCamelCase... )[/b] The important thing here isn't how you do it, just that you're smart about it. Use different casing for different things. * Constants are usually uppercase in C++ because they are #define'd, which in C++ can be very dangerous. It's basically a find and replace. You don't want to become Windows.h and find and replace things that would interfere with other people. * Variables are created everywhere and they use a lot of different names. It's smart to use a different convention for variables than anything else. Use prefixes or different casing for them. [b]2) Namespace usage. [/b] Deep namespaces are bad. C++ namespaces are used to avoid conflicts, but to completely do that you need to write the namespaces out a lot (particularly in header and implementation files). There are cases where "using" will cause you issues. It's wise to only go 2 namespaces deep with a third level for enums or something, but nothing beyond that. The top namespace should be consistent throughout your library so someone can simply do "using MyLib;" and get the whole package, with certain features being namespaced on their own. For instance "MyLib::Audio." [b]5) Platform and compiler?[/b] As already discussed, CMake is your best bet. While you still need to add support for different generators yourself it eases the burden of porting your code. [b]6) Safety or speed?[/b] Whatever makes sense for the problem. There is no correct answer here. [b]7) Prefixes or Affixes around classes and members.[/b] [QUOTE=codetorex;41553353]g_variable for global variables. m_variable for member/local and protected variables. _PrivateMethod for private/protected methods.[/QUOTE] Conventions like this are great because someone not familiar with the code has more context on the situation. However I don't use them, personally. While they provide context to those who understand the convention, they are not necessary. If two variables exist with the same name in different scopes, they can be resolved. [cpp] ::variable // global variable this->variable // member variable variable // local variable [/cpp] [b]8) License?[/b] The license you use depends on your stance of free software. If you like the idea of free software and the user is most important, use LGPL. If you REALLY REALLY believe the user is far more superior than the developer, use GPL. If you believe the developer is more important, use BSD/MIT. Please research these yourself. [b]10) Maximum name length for classes and members?[/b] Consistency matters most. If your convention causes lengthy names you either stick to your guns or revisit your convention. Personally I try to write things out. Writing shorthanded code is confusing to those looking in. For example, if you see the variable "col," what does that mean? Column? Color? In context it might make sense. It's largely preference on this one. [b]11) Documentation; what kind of documentation would you like? machine generated from code comments? or written manually?[/b] As already mentioned, Doxygen is the best of both worlds. [b]13) Other thoughts[/b] [QUOTE=ZeekyHBomb;41553903]Will you use C++11? Or perhaps conditionally include C++11 support?[/QUOTE] Conditionally checking for C++11 in a library you want to be portable is a good idea. C++11 introduces a lot of new features and some very powerful optimizations, but is largely unsupported[i]*[/i]. Conditionally checking for them can become tedious. Personally I use CMake for this task, as it can test compile code before you compile the main application. For instance, [url=https://github.com/Zethes/Jatta/tree/master/src/Config]here's how I'd do it[/url]. [i]* Yes GCC and Clang are hard at work supporting C++11, but even they don't provide full support. Also, most devs don't run the latest and greatest and you shouldn't expect them to if you want your library to reach as many devs as possible.[/i] [QUOTE=ZeekyHBomb;41553903]And do you plan on leveraging existing libraries, such as Boost, SDL, PhysicsFS, eNet, ..?[/QUOTE] Please, please, please, don't reinvent the wheel. Any well-known library out there is infinitely more stable than anything you would work up yourself. Libraries that have been around for years have been constantly improved, tested by millions of people, and receive a lot of industry support. If you really want to tackle a difficult task, you're better off doing it as a standalone to later tag into a project like this. Nobody wants a full package of junk that's half-functional. Sorry for the info dump. [b]edit[/b] By the way, anyone with questions can add me on Steam.

1) Your naming convention. ( like UpperCamelCase, lowerCamelCase... ) Upper camel for classes, structs and enums. Lower camel for variables, functions and such. 2) Namespace usage. I use namespaces for things that are too small to be it's own class, but big enough to be it's own thing. An example would be something like graphics instructions. 3) Development Strategy. I generally separate the main parts into different classes and tackle issues as they come while also actively testing each step. 4) What would you wish that is included in a library? Clear and simple documentation is one thing I look for when searching for a library. 5) Platform and compiler? When I'm on Linux, I use vim and g++. When I'm on Windows, I use Codeblocks and MSVC. 6) Safety or speed? I generally do both. If I've found a quicker way to do something, I'll test it and if it's safe, I commit it. 7) Prefixes or Affixes around classes and members. For class names themselves, I don't have prefixes or affixes. For private members, I do _var. 8) License? I don't often release my projects, but when I do, they don't really have a license attached. 9) File naming convention? like ( allsmall.cpp, BigCapitals.cpp... ) UpperCamelCase.cpp 10) Maximum name length for classes and members? I don't really have a specified length, but if it looks ridiculously long, I shorten it. 11) Documentation; what kind of documentation would you like? machine generated from code comments? or written manually? written manually with examples of usage. 12) Folder structure I've never really gone for a folder structure except when I add images, in which case, they generally go into a separate folder.

[QUOTE=ZeekyHBomb;41587758]This is basically "all rights reserved". Is this your intention?[/QUOTE] This. By not specifying a license, you are not giving anyone the right to redistribute your code. Using unlicensed code is a liability, since the original author can come after you for copyright infringement. This P.SE question explains it pretty well: [url]http://programmers.stackexchange.com/questions/148146/open-source-code-with-no-license-can-i-fork-it[/url]

I honestly don't care about your naming convention, as long as its consistent thorough the whole library. [quote]Actually c++ is stronger than c# in all ways but c# had the .net backing it which makes it easy to use. [/quote] Bullshit.

What I really like about C# is that it can do very common things without much hassle. I haven't worked with C# a lot yet, but writing loader code for XML files was a lot easier with C# than it was with C++. I think C# can do anything C++ can do, if not more, however, I like C++'s syntax better (but I guess I am just used to it).

[QUOTE=gparent;41589782]I honestly don't care about your naming convention, as long as its consistent thorough the whole library. Bullshit.[/QUOTE] I would be happy if you explain why you think its bullshit :) I have a lot of words to say why I think C++ is better than C#, but I would like to see your hands first.

[QUOTE=codetorex;41596219]I would be happy if you explain why you think its bullshit :) I have a lot of words to say why I think C++ is better than C#, but I would like to see your hands first.[/QUOTE] Natrox already answered you: [QUOTE=Natrox;41590932]I think C# can do anything C++ can do, if not more, however, I like C++'s syntax better (but I guess I am just used to it).[/QUOTE] I agree that C# can do anything C++ can, and if you have a specific thing you believe C# can't, please, tell us. You're like comparing two foods and saying A is better than B, while it's up to others what tastes them better. You can't really compare it like that.

Well, they're both turing complete.

I am surprised so many people like camel case, I'm not a fan because capital letters can be used for more things than just word separation and if you're using underscores for that job then lower case is just a bit more easy. Also matching the style of the standard library is useful for stl functionality that relies on various functions. For example a container would be really awkward if half the functions are in a different style. I spose you could just forgo it for that one class and other more general functions, but it might still be kind of annoying. I guess it depends how much of a problem you think this is, a lot of people don't seem to use this kind of thing.

[QUOTE=khuba;41599225]Natrox already answered you: I agree that C# can do anything C++ can, and if you have a specific thing you believe C# can't, please, tell us. You're like comparing two foods and saying A is better than B, while it's up to others what tastes them better. You can't really compare it like that.[/QUOTE] As a language basis what you say might true and I understand every language has pros and cons. But there is obviously some stuff C# can't do and C++ can. Thats why all AAA games and software made with C++. And if you look at the current implementation; C# can't even compile to native code and has nearly no difference from Java other than better windows stuff support and some added stuff. And it was actually going to be J++ until Sun sued Microsoft. It has no specification other than Microsoft on versions 3.0, 4.0 and 5.0. It's managed so you can't manage memory on your own. It doesn't supports multiple inheritance. It's platform depended and you can only break this by 3rd party stuff. And at this stage while I see C++ is dominated world and used by every professional on real deal software, I see C# is just used for making skins to databases. Because when you don't need what C++ can do and what C# can't, it means you going to make a skin to a database. Also it is so easy to decompile, I am not happy giving out the source code bundled in the binary. C# is only good for RAD. It has replaced good old Visual Basic which is something good and I appreciate it. When I am going to code something that is not serious I just go with C#. It's time saving because of it's framework. But when you remove framework from C# its nothing more than a scripting language. It just has this simple rule to follow if you don't need "performance" and you going to make a GUI app, go with C#. For the rest, answer is C++. And my purpose is coding a framework like .NET that made in C++, which is cross-platform so I hope it will make C++ easier to start new project, so people will prefer it over C# for even easy tasks.

[QUOTE=codetorex;41602195]As a language basis what you say might true and I understand every language has pros and cons. But there is obviously some stuff C# can't do and C++ can. Thats why all AAA games and software made with C++. - snipped timecube-esque rant - It just has this simple rule to follow if you don't need "performance" and you going to make a GUI app, go with C#. For the rest, answer is C++. And my purpose is coding a framework like .NET that made in C++, which is cross-platform so I hope it will make C++ easier to start new project, so people will prefer it over C# for even easy tasks.[/QUOTE] The only reason C++ is used in AAA games is because existing infrastructure uses it, and it's backwards compatible with C. You're making something new, so that doesn't apply here. Your post boils down to 'I want C#', in which case you should probably just save yourself the effort and use C#. Remember, you can always drop down to C if you need more control.

[QUOTE=Jookia;41602456]The only reason C++ is used in AAA games is because existing infrastructure uses it, and it's backwards compatible with C. You're making something new, so that doesn't apply here. Your post boils down to 'I want C#', in which case you should probably just save yourself the effort and use C#. Remember, you can always drop down to C if you need more control.[/QUOTE] It doesn't changes "everything that made professionally uses C++" statement. C++ was doing good for 30 years there was lot of "something new" invented that came and gone but C++ is there staying stronger and gets even stronger. And you didn't said anything about removing .net from c# and see what happens. Edit: Java is something C# based on, and it is around here what 20 years? And I don't see any AAA software or game made with Java. Therefore your statement about infrastructure is wrong. 20 years is enough time to setup some infrastructure. But people didn't choose it. Those reason is same with why people not chooses C# over C++. C# is a "popular" thing but it doesn't means best solution. Yes there is good games made with both Java and C#, I did played them too but when you going to do stuff needs raw power, you gonna need something serious like C++.

[QUOTE=codetorex;41602195]C# can't even compile to native code[/QUOTE] I assume you have not heard of [URL="http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.100).aspx"]Ngen (Native Image Generator)[/URL] [QUOTE=codetorex;41602195]and has nearly no difference from Java[/QUOTE] C# does run on the CLR so thats a plus. [QUOTE=codetorex;41602195]It's managed so you can't manage memory on your own.[/QUOTE] Incorrect. [URL="http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.aspx"]Marshal [/URL] Allows you to Alloc Unmanaged and Managed memory and what you do with that is entirely up to you. As a Added bonus here's a set of functions I wrote that allows me to generate VTables on the fly in C# [URL]http://pastebin.com/vgPuG9Py[/URL] [QUOTE=codetorex;41602195]It doesn't supports multiple inheritance.[/QUOTE] This is commonly debated and in truth C# half supports it using interfaces. But honestly most people don't see the point in multiple inheritance and personally I have never came across a case where I absolutely needed it. [QUOTE=codetorex;41602195]It's platform depended and you can only break this by 3rd party stuff.[/QUOTE] C# was built a open standard. It's like calling GCC or Clang a third party tool. It's just another library used to run .net programs on other platforms and honestly it does a damn good job. [QUOTE=codetorex;41602195]I see C# is just used for making skins to databases. Because when you don't need what C++ can do and what C# can't, it means you going to make a skin to a database.[/QUOTE] I'm sorry what? This is kinda confusing since IIRC MSSQL Managment Studio and MYSQL workbench are both coded in C++ so wouldn't that mean C++ is used to "skin databases". [QUOTE=codetorex;41602195]Also it is so easy to decompile, I am not happy giving out the source code bundled in the binary. [/QUOTE] You can use packers and "code fuckers" to make it harder to decompile code. But when it comes down to it C++ is just as easy to decompile if your good with ASM. [QUOTE=codetorex;41602195]C# is only good for RAD. It has replaced good old Visual Basic which is something good and I appreciate it. When I am going to code something that is not serious I just go with C#. It's time saving because of it's framework. But when you remove framework from C# its nothing more than a scripting language.[/QUOTE] Well if you took away C++'s standard library and all the other supporting librarys like boost... "its nothing more than a scripting language.". [QUOTE=codetorex;41602195]It just has this simple rule to follow if you don't need "performance" and you going to make a GUI app, go with C#. For the rest, answer is C++.[/QUOTE] I'm sorry to ruin your fun, but the performance differences are hardly noticeable outside benchmarks. There is no winner here simply because in the end it's all up to the developers preference.

1) Your naming convention. ( like UpperCamelCase, lowerCamelCase... ) Same as everyone else, really. Upper for types, namespaces and methods, lower for pretty much everything else. 2) Namespace usage. Depends on the scope. Separate library? Separate function of the application? If your project is the Body, maybe you want to lump all digestive functions into a DigestiveTract namespace. DigestiveTract.Poop() is a very descriptive function and it's unlikely you'll have conflicts as of such. 3) Development Strategy. Bottom up. UI comes last. If the program doesn't function then the UI is a confusion layer. Do you build your Body project first, or make sure that DigestiveTract.Poop() works? 4) What would you wish that is included in a library? For a game library? Core would be graphics and sound. Having a default UI library is very convenient, and having physics and networking available if you need it is always great. 5) Platform and compiler? Agnostic on this issue. Platform is (generally) resolved to whichever IDE you like to use. Most C++ compilers are platform agnostic anyway - see G++. 6) Safety or speed? Safety first. It's always easier to go back and optimize for speed. 7) Prefixes or Affixes around classes and members. The only prefix I use is an underscore for private members, but those are usually in C# for me when using properties in classes and C# is only syntactically similar. 8) License? I have no experience with this. 9) File naming convention? like ( allsmall.cpp, BigCapitals.cpp... ) UpperCamelCase always. Suffixed with type if necessary. PoopController.cpp, for example. 10) Maximum name length for classes and members? Reasonable length. PoopController.cpp is pretty explanatory in what it does. ThisFileContainsAllFunctionsRelatedToPooping.cs is not reasonable and is way verbose - the kind of verbosity you need for non-programmers. 11) Documentation; what kind of documentation would you like? machine generated from code comments? or written manually? Written manually for user-facing code. 12) Folder structure Same as project structure. 13) Other thoughts I would use C++ 11. It's still somewhat infantile, but it gives you a *lot* of gimmes. It's also more futureproof.

[QUOTE=anthonywolfe;41602841]I assume you have not heard of [URL="http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.100).aspx"]Ngen (Native Image Generator)[/URL] C# does run on the CLR so thats a plus. Incorrect. [URL="http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.aspx"]Marshal [/URL] Allows you to Alloc Unmanaged and Managed memory and what you do with that is entirely up to you. As a Added bonus here's a set of functions I wrote that allows me to generate VTables on the fly in C# [URL]http://pastebin.com/vgPuG9Py[/URL] This is commonly debated and in truth C# half supports it using interfaces. But honestly most people don't see the point in multiple inheritance and personally I have never came across a case where I absolutely needed it. C# was built a open standard. It's like calling GCC or Clang a third party tool. It's just another library used to run .net programs on other platforms and honestly it does a damn good job. I'm sorry what? This is kinda confusing since IIRC MSSQL Managment Studio and MYSQL workbench are both coded in C++ so wouldn't that mean C++ is used to "skin databases". You can use packers and "code fuckers" to make it harder to decompile code. But when it comes down to it C++ is just as easy to decompile if your good with ASM. Well if you took away C++'s standard library and all the other supporting librarys like boost... "its nothing more than a scripting language.". I'm sorry to ruin your fun, but the performance differences are hardly noticeable outside benchmarks. There is no winner here simply because in the end it's all up to the developers preference.[/QUOTE] I am agree it is a preference, but I has the standing point about "people that makes professional software prefers to use C++ more than C#" and I am trying to investigate their reasons for this. Other than that; Ngen is just a cache for avoiding JIT recompiling everytime you trying to run a program. It doesn't produces any executable that can run on platforms that doesn't have .net. Yeah you can allocate unmanaged memory and use even pointers, but why use C# then, these are only good things about C# which makes it "easy" also which kills its performance. By calling "database skin" I meant web development and GUI based apps that heavily relies on databases. And the software you are listed maybe made in C++ but my point is, it is easier to made them with C#. Because .net framework and visual studio just supports superior support on GUI and some stuff on windows. Packers and code fuckers isn't a solution but more problem. They tend to fuck binaries beyond usable. And still they can be decompilable. Only you have to rename stuff. But you can still see the algorithms easier than just reading x86 assembly. And reading assembly is not an easy task, because it needs lots of experience which is something most programmers doesn't have. Also you have more software protecting options that works on native binaries. About the libraries, thats the point. When you remove all libraries from C++ you can still compile a working executable and you can do anything. But when you remove .net framework from C# it compiles to a bytecode that can't run anywhere natively. Thats what I meant by scripting language. When both doesn't had any libraries at all, C++ will have more features than C# and still will be preferred by professionals.

[QUOTE=codetorex;41603335]Ngen is just a cache for avoiding JIT recompiling everytime you trying to run a program. It doesn't produces any executable that can run on platforms that doesn't have .net.[/QUOTE] Well Ngen does use x86 ASM over MSIL. (I beleive, I have only read about it and never tried it for myself) Plus I don't see why still requiring .net is a downside. It's not gonna magically lose reference requirements because it was moved to asm. [QUOTE=codetorex;41603335]Yeah you can allocate unmanaged memory and use even pointers, but why use C# then, these are only good things about C# which makes it "easy" also which kills its performance.[/QUOTE] Personally, I choose to because C++ was always a pain for me to use and I'm not the biggest fan of the syntax. So I wrote my library in C# and when injected, even with hooks in main loops like d3d draw or the keyboard handling I didn't see any loss in performance. Infact when profiling with VisualStudio it showed me that PInvoke was hardly taking up any time at all. [QUOTE=codetorex;41603335]Packers and code fuckers isn't a solution but more problem. They tend to fuck binaries beyond usable. And still they can be decompilable. Only you have to rename stuff. But you can still see the algorithms easier than just reading x86 assembly. And reading assembly is not an easy task, because it needs lots of experience which is something most programmers doesn't have. Also you have more software protecting options that works on native binaries.[/QUOTE] I've spent a lot of time reverse engineering both C++ and .net programs and with the right resources and tools you can easily pull understandable code out of asm without needing a understanding of asm, even though understanding asm will help a lot in the long run. Really the best defense against RE is packers and obfuscation but it still gets you only so far. Sad truth is no matter how good your defenses are there is someone out there that can break em. [QUOTE=codetorex;41603335]C++ will have more features than C# and still will be preferred by professionals.[/QUOTE] Good thing I'll have my trusty [Dllimport]. :dance: I'm not gonna bring up your point about striping each bare since that's not one of my points of expertise. Regardless good luck with your library. I hope I didn't come off as bitter before. Just hoping to clarify on a few points you had. I won't trying to start a argument or derail your thread. EDIT: Seems I was wrong about Ngen, but there is something packaged with mono called mkbundle that compiles to a standalone native executable, Though it will require the mono library.