Simple question. What practically annoys you on a regular basis in the programming languages your are using?

For example; lack of builtin vector and matrix types, undecipherable template syntax, inconsistently utilized exception handling, irrational type names for primitives, ...

1. Too much low-level grinding.

I have a class with 3 fields. Why do I have to write a class definition, default constructor, constructor taking the 3 fields, destructor (remembering virtual if it's a base class), copy constructor or move constructor? If I want equality on that class, I need to spell out when an object is equal. If I want ordered, I need to tell exactly how to compute order. If a field is a vector, I have to do the above for a vector of things. So that's soon 150-200 lines of code for a class with 3 fields and something basic like order. Why? Yes you could possibly want to do it in that detail in about 1 in a 1000, but for the other 999 classes???

2. Too simple to make a convoluted mess.

Some people completely reject OO, as it is too complicated, and stick with C style coding. While I disagree with their solution, they do have a point, OO makes it extremely simple to merge different but related pieces of code into the same object, or setup references to other objects etc. It's very simple to make a huge mess by connecting stuff that shouldn't be connected in that way, and nothing prevents that from happening. You can see it by the difficulties that beginners have in using inheritance correctly. I recently figured out that getting an object from a collection by equality may be a bad idea too, at least it is from a math point of view.

3. Too many things at the same time.

When we design a program, we use a divide and conqueror approach in the design. Yet when we code, we code all concerns at the same time. How I write a class definition wrt the order of fields has impact on the performance of the system. The type of container affects performance and memory footprint as well.

Why is there no implementation path from logic design to dealing with timing, memory, and performance?

As a relative newbie, i am not at all done with C or C++. I have recently tinkered with templates and i think i got the basics, meaning that the compiler doesn't complain and the outcome is as expected, after help from this forum ?

I think i understand why linear algebra isn't part of the core language, for a similar reason why i decided to brew my own despite an overwhelming base of 2nd, 3rd and fourth party libraries. They probably would never satisfy everybody and the outcome would be an overblown "one fits all" library with a jungle of operators and methods to equally satisfy graphics, physics with different performance and precision variants and whatnot.

I recently discovered that some of the above complaints may be addressed with D, that still has the ability to use C apis but offers some of the relaxing features. What do you guys think, can D have a future, besides C++ ?

I don't have particular beefs with any programming language, just some of the people that do the programming.

1) Everything must be Object Oriented / everything is an object.  Stop trying to model the real world in your code.  All software does is transform data from one form to another, the CPU doesn't care about clever static structures. y = f(x): your code is the 'f' part.  Make those transformations as tight and performant as possible.

2) Interface classes everywhere.  This code doesn't really do anything useful except provide more indirection for data transformations.

3) You are only agile if you do SCRUM.  I guess the SCRUM consultants have really excelled with their marketing efforts.  Every project is unique, adapt your development process to the project rather than being dogmatic about your process.  THAT is being agile!

1. Convinience: I agree that sometimes one would like to have some kind of convinience for creating the class body instead of just the whole class. This is something that C# does but not well sometimes.You end up writing your equality camparer anyways because the generic solution is to just compare object references. You dont want this, you want something usefull. But on the other hand you would end up with another level of inheritance and this isn't helpfull nor performance improving and absolutely not usefull when declaring stuff on the stack racther than new-ing anything.
2. The overuse of new: In many cobe bases you always have the new keyword, anything gets new-ed especially in C# but also in C++. You don't want to new everything rather than put it onto the heap or stack for reasons. I'm missing this feature in C# so it isn't possible to just put a class temporary onto the stack.
3. Objects Everywhere: In C# anything has to be an object so anything needs to stay in a class. You can't globally declare methods. I would like to have the same capabilities as C++ offers to declare a function in the global namespace or a derived namespace and have it be static by default instead of tangling arround with pure static classes.
4. Better Templates: Again C# and their generic types are just the bare of a subset of the capabilities C++ offer. I whished so many times for having C++ templates in C#. I love using templates, they may make life very easy if you master them properly but are a nightmare on the other hand.
5. Delegates: I also whished to have C# like delegates and multicast delegates in C++. In C++ you need to define the exact signature of the function you want a pointer for, so mixing instance and non-instance functions isn't possible or at least possible without some tricks (using templates *.*). It would be nice to have something generic like C# offers in C++ by default.
6. RTTI/Reflection: Very usefull feature I also added into my game engine, at least for the editor logic. With RTTI/C# Relfection, it is possible to dynamically call functions (which is quite usefull for in-game command line), you can determine the type and size at runtime (usefull to select a serializer for example) and also can make use of the dynamic engine C# offers. I sometimes whished for something like the dynamic C# keyword in C++ so I again built my own one. The dynamic or flex type I declared it to, is used in my game editor to have any instance be used if it contains certain methods.As far as I use them very rare, for this purpose some kind of dynamic interfaces like in typeScript could be usefull. This way my editor could decide which type of interface the flex implements and how to handle it without deep knowledge about the udnerlaying class.
7. Attributes: Something that might be an extension of C++ are C# style attributes. I use them in C# alltogether with reflection to determine stuff at runtime when my assembly loads. An example for this is a factory class I use in my HTML parser. HTML tokens are declared using attributes on classes so my initialization code knows which types to grab for the factory. Unfortunately, this isn't possible that easy in C++ so one needs to have a custom solution here too.
8. Macro Engine: A C++ feature is the preprocessor which I would like to have in C# also.Sometimes it is simply usefull to have the chance to define a macro rather than solve something with classes and generics but on the other hand the risk is still there to end up in a mess of non-readable code

10 minutes ago, bioglaze said:

My annoyances with C++:

• Using Standard Library makes compile times very slow and its code looks messy in the debugger.
• Variables aren't initialized by default (I don't forget to initialize them often, but I see lots of code that forgets)
• The whole #include system is archaic and easily slows down compile times.
• Unwanted implicit type conversion that could cause bugs.
• enum values can't be printed without macro magic.
• No standardized ABI.

 

An ABI would be amazing!

4 hours ago, Shaarigan said:

The overuse of new: In many cobe bases you always have the new keyword, anything gets new-ed especially in C# but also in C++. You don't want to new everything rather than put it onto the heap or stack for reasons. I'm missing this feature in C# so it isn't possible to just put a class temporary onto the stack. 

I hate "new" in C# too, but not really for whether or not things really got put on the stack or not (structs are probalby being put on the stack despite having to be newed), but rather for the verbosity it inquires. Initializing variables in C++ is so much less hassle:

//C++

std::map<std::string, std::pair<int, bool>> mValues;

// C#

Dictionary<String, KeyValuePair<int, bool>> values = new Dictionary<String, KeyValuePair<int, bool>>();

Its like, cmon, I even omitted namespaces for C# but not C++ and still... (and no, "var" doesn't help much for member variables unfortunately). There are many more examples, like with vectors:

//C++
CalculateSomething2D({256.0f, 128.0f}); // takes a Vector2

//C#
CalculateSomething2D(new Vector2(256.0f, 128.0f));

Not a fan.

11 hours ago, ChaosEngine said:

In C#, you'd use a value type for that. 

That in itself is one of the things I hate about C# - the idea that the type of the object dictates where it gets stored. I often need an object to be a class type, e.g. because I need inheritance, but I may also want to store a cheap temporary, or to have a ton of them allocated quickly and close together in a memory-efficient data structure.

I hate micro-optimisations but as a game developer I need the language to help me with the more trivial optimisation decisions rather than forcing me through gymnastics to avoid the memory allocator.