Jump to content
  • Advertisement
Sign in to follow this  
LostTime76

Who wants to see a C replacement?

This topic is 1178 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey all:

 

I am a software developer coming from a professional environment with quite a few years of experience in system and apps level programming. I just want to pose a question about a replacement for the C language.

 

I am sure there are hundreds of other topics that start the same way and there are also tons of languages that hope to displace C as the systems programming language. Believe me, I know how deep C reaches. My company uses C extensively. I am not here to actually start to implement anything, I just want to get a feel for what people think. Please spare the "This will never happen, it will be impossible to displace C" type of comments. That is not what my question is about. 

 

So from my standpoint it looks like there have been many attempts to create a language to replace C /C++ in the past or present. Some examples I guess are Rust, Go, D, etc.. However, it all comes back to low level ability. The thing that makes C so great for systems programming is the ability to really go down and touch the hardware in any way that you want. This is usually accomplished with pointers. Also, it is a fairly simple language in that to me, C is basically a set of functions with code inside them and that's it. There are not really classes and methods as far as the language is concerned; a C program is just a set of callable functions. Therefore it is simple.

 

One 'mistake' that I believe the languages that are trying to replace C are doing is that they are trying to do too much. For example: reducing the amount of typing in the language with clever keywords, removing pointers, making it seem like its so easy and abstracted to get something done, and adding garbage collection. Personally, the amount of typing in C never hurt me. I would like a language that looks a lot like C but with enhancements. I'm sure we have heard that one 100 times!

 

C++ is a whole different ballgame; however, there was one flaw that kept us from even considering it. We deal extensively with callback mechanisms. The fact that you cannot set a callback on a member function (an instance of an object) is ludicrous to me (us). I am not talking about all the magic they have come up with in the recent specs to try and mitigate that issue. It is fundamentally impossible to do it in the base C++ language. I guess now you can create a template class in C++ to allow you to do such a thing, but that is duplicated code for each callback you want to implement on a resource constrained system.

 

What I am getting at is that I still fundamentally want to have a "C" language. I want the power that C offers with pointers and I also want the simplicity of it. Additionally performance is paramount.

 

With that said, here is my wishlist for a C replacement.

  1. Pointers are key. Object / dynamic memory tracking depending on garbage collection mechanism.
  2. Heap compaction: Garbage collection in its current form is un-operable: However, we have come up with some ideas for heap compaction that would be very good, clean, and would not affect performance in our major use case. Essentially a heap compactor that only runs when you need it to (idle hook) and can be preempted (interrupted) at any time to process higher priority events. Once the system is idle again, the compactor resumes where it left off. This is actually possible. The major hurdle is that the C language does not support the reference tracking we need to implement it. I don't want to have to deal with the heap fragmentation issue.
  3. Get rid of header files. It is my understanding that headers files were from a previous era where code had to be made this way due to lack of compilation power? It is essentially a relic of the past. Languages such as C# do not have header files. Anything you write in a source file is automatically available externally to other files without having to "include" it. Namespaces and access modifiers aside. Get rid of the header file hell... circular dependencies... etc.
  4. Class model: Right now we employ a very simple class model using C. Basically we 'derive' from structures. This means you can cast any structure to any other structure as long as the structure derives from it. Deriving from a structure means that the first member of a new structure is always the base of another structure. Will need to expand upon this idea; however, the ability to have classes, member functions, etc.. 
  5. We don't need all the fancy stuff coming in the new specs of the C++ language: lambdas, generics, templates... unnecessary. KISS. Remember I think of C as just a giant set of functions. I want to keep it similar with some enhancements. No built in language features such as threads etc.. Remember the concept of 'doing too much'
  6. Easy to parse for all the fancy IDE features. My understanding is that C++ is an impossible language to make good IDE features for (intellisense).. but it looks like its super easy to make intellisense for C# type languages. Does this have to do with the header hell? Either way, the ability to provide easily implementable IDE features is a must. One of the things that has stopped me in the past from implementing IDE features is that C/C++ seem to be such hard languages to implement IDE features for.
  7. I'm not looking to reinvent the wheel on any formats. For example, in our system we compile C code for an ARM platform which then produces an ELF file with DWARF debugging. We are only concerned with the language / IDE here.

A lot of this stems from the current state of affairs with the coding world in terms of languages, features, and IDEs. Our company currently uses Eclipse but everybody is of the opinion that it a horrible platform. We have researched moving to visual studio; however, we can't integrate a custom project and or compiler easily. Also, both platforms are completely fragmented in their "extensibility" mechanisms. For example, the .NET portion of visual studio seems fairly extensible in an easy way. The C++ side on the other hand is a complete mess. Eclipse to me is just a complete mess from ground zero. 

 

We don't need an IDE that does everything. We need an IDE that is good for systems programming: building code, compiling, and debugging on a target. Building an IDE for the C or C++ language is a complete mess because of the language, plus C could use some enhancements as stated above.

 

This is purely a what if type of question. We have no plans at the current time to change our tool chain or work flow. Essentially if I could make C a better language type of question.

 

Opinions?

Edited by LostTime76

Share this post


Link to post
Share on other sites
Advertisement

 

 

You are incorrect in your understanding of why the C API (headers) is separate from its ABI (libraries).  It is not because in the 1960s computers were incapable of compiling the software available to them.  It's because you can take C code and recompile it  for a zillion different ABIs (different hardware, different OSes, different everything) in a modular fashion and it will work.  The separate compilation model (headers, compatibility at the API level) is integral for that.

 

Subtle distinction: What you told me is why it was separate in the past, it did not need to be this way. For instance, I can make a .NET library and reference it and I have all the type information available for my IDE, yet I do not have the source code. See? no headers. The library can contain the function prototypes and types without having to rely on headers. Also, a library in our field will typically work for a single processor architecture, for example, a Cortex M3. If the implementation changes, that library has to be recompiled; however, the type information available in that library does not have to change. I may not have to do update the header files, but I do have to drag in a new library. Having to potentially worry about 2 items compared to 1 is inherently worse. We run in to "did you update the header files with the library? Yeah, I changed a few things in that function prototype, so you have to update the headers as well." all the time. The point is, this can be done completely without headers. Whether that is 'slightly' less portable than the header model with the supposed API / ABI distinction does not matter much to me.

 

Edit:

Forgot an important point. No, I don't think that the header model is integral to that at all. The header model allows many different projects to not have to update their headers even if they are using completely different architectures and systems. In order to produce a library for a different architecture requires direct source code anyways for the system you are compiling for. You cannot compile without the source. We can do without the headers. Why do we care that we don't have to update our headers? Why does there need to be headers in the first place? 

 

That was rhetorical. The libraries themselves should include the interface definitions: function prototypes, types themselves, and size of structures. 

 

 

 

 

So, std::bind and std::function, then? If not those, then probably the impossibly fast C++ delegates. Additionally, the "code bloat" argument against templates does not generally hold up these days

 

Generally; however, in my field it does. The compiler we use implements the embedded C++ standard which is stuck at like the year 1999 or whatever. The feature set stops there and there are no plans to update it. Our compiler manual explicitly states to not use templates exactly for that reason. Templates seem to inherently generate code for each instantiation. Now granted, this won't matter much to systems programming on an x86. I work on chips with 64K of ROM and 16K of RAM. Every tiny piece of codes counts.

 

 

 

So, C++.

 

Exactly what I don't want. We have looked at C++. It is not modern and is a complete hack with severe shortcomings. 

 

 

It seems we have supporters of the header model to separate implementation from interface. I will tell you this. This is the way it has been done past till present. This does not mean it is the only way. It also does not mean that a new way will break that ability. Just because something works does not mean there is not a better way. Surely you do not mean to tell me having to track headers files as well as libraries is more 'readable' and easier than having to worry about only libraries. There must be a reason that modern languages have no headers. 

 

My last statement was rhetorical. I argue that we can produce something without headers that is just as portable with interface and implementation as C.

Edited by LostTime76

Share this post


Link to post
Share on other sites

selective use of c++ syntax with a c++ compiler will get you much of what you desire, pretty much everything except garbage collection (which in a serious game you'd probably be handling yourself), and ease of parsing for making IDE plugins.  and building IDE plugins is not exactly standard operating procedure for building your typical game. such code processing is usually done with some sort of in-house stand alone command line utility, simply because its usually faster and easier to write a command line utility than it is to try to write a plugin for an IDE.

 

my personal solution to the "i want a better language" issue was to write my own macro processor that generates c++ code. I decided this was easier than writing a full blown compiler.  Now i code exclusively in the macro processor language, which can be mixed with c++ code in the same file. any line beginning with a macro language keyword is translated to c++, all other lines are assumed to be c++, and are simply copied "as is" to the output file, which is a .cpp source code file. i can run the macro processor as an external command from visual studio with one click. translation speeds are on the order of 200,000 lines per second.  running the macro processor can also be made a custom pre-compile step via the IDE or a makefile. so integrating it into the build workflow is not hard, and adds almost zero time to a build.

 

i use procedural code, and plain old data types, not OO syntax. i don't use anything like exceptions or any of the rest of that fancy "late model BS" stuff.  I use a C++ compiler for what is essentially C code, for the stronger compile time checking.  and since i'm working in C++, i can have classes, objects, inheritance, composition, and polymorphism if and when its appropriate.

 

re: header files...

you have to recall that the original purpose of header files was to define the public API for a code module - nothing more. with the advent of OO, apparently its not uncommon to use a separate header for each class declaration. IE each class is implemented in a separate module, which i would think would tend to get ugly as the number of classes increased - lots of files - increased compile times - that sort of thing. 

Share this post


Link to post
Share on other sites

 

re: header files...

you have to recall that the original purpose of header files was to define the public API for a code module - nothing more. with the advent of OO, apparently its not uncommon to use a separate header for each class declaration. IE each class is implemented in a separate module, which i would think would tend to get ugly as the number of classes increased - lots of files - increased compile times - that sort of thing. 

Well, you are correct for the type of programming you are doing. In my field, it does not matter so much at the current time. My issue is of a different matter. I argue that header files are useless. Modern languages do not have them. The ABI issue I think can be solved even if the interface resides inside the libraries themselves. The major issue I have with headers is that updates to them have to be tracked. If I change a function prototype, I have to change that in two spots and then I have to copy and paste the new header into our distribution. If headers did not exist, I would only have to distribute a final library and not have to deal with headers. Believe me, this is a huge point. I am a platform developer on our team and half my time is spent updating header files and redistributing them because of minor changes. Also, I know this was posted in a gaming forum, but this is not for game programming. I am a systems programmer.

 

What I want is actually a compacting (non fragmenting) heap, not exactly garbage collection. We essentially require a heap that does not fragment. Its a subtle distinction. We do not want our objects to be collected manually. We can take care of the memory management. The issue is that when using a heap, it fragments. For safety critical systems, you cannot have that. I have spent some time trying to come up with a non fragmenting heap, and I have succeeded. However, there is a lot of manual labor required, which would typically be done in the language itself. 

Edited by LostTime76

Share this post


Link to post
Share on other sites


think a pretty good indication of that fact is that the only languages on the planet with the notion of separate header files are C, C++ and COBOL, of all things. Hardly role-models for modern language design...

 And Ada! :D

Share this post


Link to post
Share on other sites

With that said, here is my wishlist for a C replacement.


You seem to know exactly what it is that you want and why. So... what's stopping you from rolling your own solution?

think a pretty good indication of that fact is that the only languages on the planet with the notion of separate header files are C, C++ and COBOL, of all things. Hardly role-models for modern language design...

 And Ada! biggrin.png


And some versions of structured BASIC, like QBASIC. Edited by Oberon_Command

Share this post


Link to post
Share on other sites

This topic is 1178 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!