Jump to content
  • Advertisement

LostTime76

Member
  • Content Count

    16
  • Joined

  • Last visited

Everything posted by LostTime76

  1. 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. Pointers are key. Object / dynamic memory tracking depending on garbage collection mechanism. 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. 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. 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..  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' 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. 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?
  2. LostTime76

    Who wants to see a C replacement?

    Haha, you are exactly right. After last night I realized that I might actually just want to let this thread quietly die. I am not getting anywhere. That or I was going to request a mod to close it.    I found out very quickly that this was the wrong forum to post this in. That was my mistake. A lot of the responses from people are completely and utterly incorrect, but I realize that is only because they don't finely understand my problem space. Then if you apply my responses to the fact that you are talking mostly to game programmers (more generally programmers who are working on systems with tons of RAM, MMU, etc..), it makes perfect sense why I am getting a lot of the responses I am.   I will make a final statement on the heap compaction and C++ member function issue. The heap compaction and member function issue are two separate problems.   "If I have the memory to support heap compaction, then I must be able to support std::bind, because it takes less memory". I am sitting here listening to a bunch of people on this forum telling me "this is going to happen" or, "it won't work" To that, I will concede that in your eyes and with the information I am giving you, you have made a valid statement on the operation of such a heap. Unfortunately, I will not go any further in giving out information on the implementation. It does actually work very well, it does not fail. The issue lies within the manual calls to do the reference tracking. With regards to performance, allocations and de allocations are O(1). Heap compaction happens while the system is idle and therefore has no performance penalty. The compactor is incremental. This is not up for discussion. It works, period, end of story. How you 'try' and reason out the implementation because I have not given you that information is up to you. Lastly, our system does do a lot of multi threading, just on a single core at the current time.   With regards to one member who thought it necessary to write out code to show me how member functions can be used by providing a data member inside the class: Yes, this not is not a new concept to me. However, doing it that way defeats the simplicity of doing "pObj->callback = whatever. If my classes have to provide a wrapper for each and every callback like that, it is a very useless feature to me. Having to do extra tracking like this, no matter how trivial it is not an option that I can give my end users. It does not work like that where I am.   I now would like to request that this topic either be closed or deleted by a mod. This was the wrong forum to post the topic in, and I apologize for it.   Thank you
  3. LostTime76

    Who wants to see a C replacement?

      The only viable argument I see is the type safety, which does not matter much to most of our team.  Function overloading is just a syntactic sugar, because under the hood separate functions do get mapped out.    I honestly see where people come from when they say you can pick and choose the language features. The only one that really mattered was the callback mechanism though. I actually toyed with the idea of getting around this by analyzing the mangled function prototypes for the compiler. I could then produce what the compiler thought was a static function call but was actually the address of a member function. Of course, it was shot down by myself and my team fairly quickly. That was an ugly language extension. Now "you can just use C for that." Yes we can, and then one of the classic use cases of our application model does not fit within c++. What we wanted to be able to do is 'derive' from the application class similar to what you do in an android app. The application then picks up all of the overridable functions to get stuff like events. Since the 'application' was the core of our system, if it did not use C++, then there is not a whole lot of use in making everything else c++.   The other issue is with consistency. We place a lot of emphasis on consistency. We also have a lot of older developers who do not adapt very well. It becomes a battle with them. If half of your API set is C like while the other half is class based C++, it is a huge problem with them. I personally do not like the inconsistency either. If we are going with C++, then the entire shabang should be C++, not half and half.   I mean there are some benefits, which would have to weighed and considered. Function overloading is an interesting feature, but I don't know if we have enough functions to overload. We seem to be doing fine without it.     If you don't use the feature, you don't pay for it. In the type of system I am speaking of, you generally compile a static library with or without certain features. There is no reason the reference tracking cannot be turned off. I find this comment slightly odd, because I am the one advocating the resource constrained system, why are you, when it seems not many care about it in this topic? Are you complaining about the reference tracking overhead of garbage collection in .NET as well or are you saying that in a C only language it should be bare metal and there should not be any such facility because that is what people have come to expect from it?   Also let me question you again, because I am curious. "For most people that work with C" It seems the majority of people here are advocating using C++. Do you use C for your game programming or whatever on a daily basis? Do most people here use C on a daily basis? If you do use C, pardon the intrusion, but can you definitively state that for most C users it would not be useful? Remember the usage scenario, from my point of view everyone here uses C++, C developers are embedded developers like myself. You might argue that you are a C developer because you use C++ but only the C subset. I am going to disagree. There seems to be a huge distinction in the embedded world. To most of us, C++ is a completely separate language even if you do use the C subset. The embedded compiler manufacturers sure as heck make a distinction, let me tell you.
  4. LostTime76

    Who wants to see a C replacement?

    Yes? I made the statement that the compacting heap is a one time fee, whereas template instantiation might not be. I am not just talking about data requirement (RAM), but ROM also (code).   The constraints placed on the compacting heap are not known to you. For all you know, it could take a lot of memory for reference tracking, and then again it might not. I have not made that information available. 
  5. LostTime76

    Who wants to see a C replacement?

    @ Juliean   The features that I suggest are not for my own benefit at all. And I believe it apparently more so in your response of why you are thinking that way. This might have been the wrong forum to post such a question on. I am a hardcore embedded programmer, and the features I suggest for the C language would make many of us if not my entire team salivate. Mainly the header file hell and the compacting heap. Those are extremely huge in my field due to maintainability and operation. The entire heap usage and its implementation is a huge contention point for many embedded developers. We went through a huge phase in our own development of costing out various designs all around heap usage. I can see from the perspective of a game developer and one who programs on systems with massive amounts of RAM every day where the mindset is coming from. "Real world environment" for me is completely different from yours. I don't have many options available that others have suggested. Again, sorry, wrong forum.     Also, that was not about personal qualification. I am very clear that in their respective field on this forum, everybody is at the top of their game. I have no assumptions about people's qualifications, which means it take a lot for me to lash out at anybody. The reason it happened on that post, was because his statements were taken as extremely sarcastic by me. Additionally, it really looked like he did not read any of the posts yet posted on old information. 
  6. LostTime76

    Who wants to see a C replacement?

      Not sure I understand your reasoning here. The code and data required for a compacting memory store is a one time fee, whereas the number of template instantiations require for all possible callbacks is unbounded. You mean to tell me std::bind will compile down to a single void* of storage?    Also, MSVC doesn't count, because I don't think it can compile Cortex M profile for ARM. I would assume as a matter of ocurse the MSVC compiler would beat everything though. The compiler we are using beats gcc by at least 15% in terms of speed and size optimization. If you can save 50 cents on a microcontroller because you can get a chip that has 32K less ROM, do the math for about one million units... The cost of the compiler for about 10 developers.. (10 x 1K).. Seems worth it. Yes, those are ballpark numbers.
  7. LostTime76

    Who wants to see a C replacement?

      So you mean just stick with C? Can someone confirm he told me to stick with C please!?   If I am not using THE major feature(s) of the language, the reason for switching to it in the first place, tell me pratel: why would I switch to it?
  8. LostTime76

    Who wants to see a C replacement?

      Ask the .NET developers the same thing, rather the Mono developers since they had a static compilation option for .NET where you could compile things into a static exe. Seriously? At the time of compilation, all information required is in the library. The library contains metadata, function prototypes and the structure declarations. The library becomes just another input to the compiler just as it is for other module based languages. How do you access functions without function definitions? .NET does it fairly well with its module model.      So what you mean is why not have a tool that 'documents' my source code? Doesn't doxygen already do that? A header file is essentially documentation at this point.
  9. LostTime76

    Who wants to see a C replacement?

    Oy, how long ago did you write that response? I even went and updated my OP like half an hour or more ago, yet you still glean incorrect information from it.   No misconception. What you meant to say is your misconception for 1. Not reading all of the posts where I say what I want is not actually GC and 2. for not looking at the latest OP where I corrected some of my wording.     No, I am merely stating the addition of a class model, I do not know what it would entail which is why I said it would need to be expanded. It could be similar to any of the numerous languages out there picking from a single one or several. Never did I state it was something new. ASSuming based on the limited information in my original statement makes an a** out of you and ..... you.     Let me rephrase what I think you meant to say here: "What? I really don't understand what you meant by not having callbacks." That is what you meant to say, because I know for a fact you could not be as simple minded to assume lambdas are the only way to implement callbacks. It's called C linkage. You know.. that thing we put on some C++ member functions to make them conform to the cdecl model or whatever so that they have C linkage and therefore can be specified as callbacks to many C libraries? My gripe is the fact that the way most implementations are done you cannot specify a member function as a callback for something in a C library.    I like the closed mindedness spewing from this statement. Remember I am using C. We do have a linked list implementation that uses something called a void pointer. Yeah? We have to cast it when retrieving data, but it beats the hell out of manually rewriting our linked list for every type that could be stored in it! 
  10. LostTime76

    Who wants to see a C replacement?

    No, you don't have to distribute source files at all. All you have to do is distribute a library in the same way you would distribute a .NET library. There is no source code attached to it. It's a single file.   So basically what you are saying is that if C doesn't meet your needs, just move to a different higher level language that can meet your needs? C meets our needs 90% of the way. Moving to another language will not solve the other 10%. In fact, it would make us go backwards. Let's take a prime example of moving to a higher level language. C -> C#. I lose pointers. Nope, can't do that. C -> Java, same thing. C -> just about any high level language you lose pointers. That fact alone makes those moves not viable. The only logical choice then is moving to C++. C++ does not solve the header issue, but the other higher level languages do. Its a unique problem space that is not solved currently that I can see.   The power of C with regards to pointers A heap that can be defragmented but does not require garbage collection. Therefore manual memory management. Garbage collection requires many many more performance critical steps Performance of C Module based compilation ( no headers )   The spur of these suggestions might have been from the situation in my company. However, let me ask you: Would not any one of those features be beneficial to the C language as it is? You can argue "Oh, if you move to xx language, you get this and that" all you want. I can also argue that you lose one thing or another from that list. I am not looking for a trade off.        You mention some nice IDE features for doing certain things. What about the IDE feature of an outline view? Eclipse and VS both have it. I don't need an extra header file to look at the interface in a consolidated list. If there is any information that is available in a header file, it can just as easily be made available in an outline view.
  11. LostTime76

    Who wants to see a C replacement?

    I like Ada's version, where the header contains only the interface. Not so much the C/C++ version where the decision of what goes into the header file isn't logical, but is instead a consequence of technical details regarding translation units.   So it really looks like we have some contenders for header files here. Huh, I did not know that many people existed that liked them. It's all about efficiency from where I come from. Having to maintain an extra file for every implementation file is more work. Another point is that why should I have to write the 'prototype' for a function in two places? Once in the header file and once in the source file? Is there a reason why the function declaration can't be in one spot like C#? What is there to actually gain by having it two spots and having to be maintained in two spots? Just so that we can explicitly say that this is the interface? See, I don't understand that point at all.   Having to maintain a single file versus 2 is clearly less typing and more efficient. I guess that old saying comes up where C++ programmers are masochists for typing   Just a joke, please don't hurt me.    Personally, I don't mind the extra typing, what I mind is the extra file I have to maintain for not much gain.
  12. LostTime76

    Who wants to see a C replacement?

    Definately not, I was going to say the same thing. I actually enjoy having only the declaration of my classes in the header, which makes reading much easier for me subjectively. I even miss the separation when working with templated classes which I'm used to writing inline.   So I take it you guys are not building platforms here? Let me give you some background on where I am coming from with the headers. I am what we call a platform developer on my team. Essentially what I do is define the interface in header files that gets exposed as an API set to the end user. The end user is another group on my team. As someone in this position, I can tell you that having to deal with header files is a huge mess. If you are a one off developer, I can see it not being so much of an issue. However, when you are the one who has to maintain those header files across versions and the platform, it becomes ugly. Not only do I have to worry about our libraries getting distributed, but I need to make sure everyone has the correct header files. If I make one small change in a header, that becomes a nice change in terms of the interface and possibly a big documentation artifact. Since our code base is getting ever bigger, we run into the situation where I forget to distribute some new headers I changed or somebody forgot to update them. This causes issues when people are trying to run their code. Sometimes it won't compile, or sometimes I just changed a structure definition and the code fails. It wouldn't be caught in compilation for this last point.   As a one man show who does not need to manage all of this on a constant basis, I can see headers being alright. I personally have to manage headers on a daily basis. I am not sure if this is anything like your situation.   I am also spoiled by .NET and C# in which sometimes I write win32 applications. I can write a giant library with a huge interface and then all I have to do is distribute the library. The IDE takes care of the rest and I can also produce documentation from the source code.
  13. LostTime76

    Who wants to see a C replacement?

    Did you read what I stated twice previously? I stated that what I wanted was not garbage collection, but a compacting heap. We have a very efficient mechanism for achieving this that fits within our RAM budget.       Same question: Did you read what I stated previously?  std::bind -> C++[11]? Templates , etc.. Who said I was throwing out solutions? The only solution I threw out was C++. With the current technology at our disposal, RAM / ROM budget, and C++ feature set, it does not meet our needs.       Let me ask everyone who 'seems' to be viewing this topic. Did I once state that I was going out and implementing a new language? Did my OP say this? What my OP says is that I have a wish list for a replacement and or enhancements for C. I wanted a discussion. I am not looking for options.   Here is the bottom line. We (my company) are not changing anything in the way we do things today: the compiler, tool chain whatever. I have no plans to go and write a new language at this time. All I wanted to do was start a topic on a C wish list with some ideas. I am not looking for suggestions on changing our tool chain or work flow. There are other languages that meet the requirements of different situations. In our current situation the only language that meets our requirement is C. We are under a severely resource constrained system. As a developer using the C language, there are some features that I would like to change or enhance. That's it. If there was a language that met my specifications exactly, I wouldn't have put up the topic.
  14. LostTime76

    Who wants to see a C replacement?

      Before I do anything, I want to make sure that I am not crazy. That and I wanted to get some input from people who are more experienced than I am. Rolling my own solution would require much more planning than just this forum topic and much more work. I am in an information gathering stage.     Looking at this guy     I don't like Rust. It formulates on my vehicle.    I will take a look       Should have clarified, my mistake. I am not looking for a garbage collector but rather a compacting heap. Some of the inner workings of a garbage collector help in implementing a compacting heap. I am not trying to get rid of memory management and in fact I'm not trying to make it easier. However, I do want to fix a problem with the standard heap which is fragmentation. In many embedded applications you run on the bare metal layer (no MMU). This means for us that the heap is a single entity available for public use by any module. Fragmentation is literally not an option, because we cannot "restart" our system. The heap has to be defragmentable down to exactly 0% fragmentation. Currently we have an allocator that has a configurable number of bins. This requires the programmer to configure the bins and sizes up front. This allows for zero fragmentation. The bin allocator is good, but ideally we just want to be able to specify a heap size for the application just like anybody else and not have to configure bins.   Also, we have a method for building an incremental compacting heap that is actually very good. We can interrupt it at any time and it just picks up where it left off when we give it more processor time. It does not take more time for compaction just because we interrupted it. Think of it in this simplified way. If the compactor has 100 (N) items to compact and we give it processor time, it will compact (1 - N) items on the first pass. If we interrupt it at item 10, the second pass will only have 90 items to compact. The process repeats. This assumes that more items to compact were not added during the interruption. Also, each pass, the compactor will complete a minimum of a single compaction before it can be interrupted. It cannot be interrupted during a compaction.   The issue that is holding us back is the reference tracking. In order to compact, you obviously need to update referenced memory. We have a good idea about how to do this; however, this type of tracking is generally done in the language itself where the compiler would produce the neceessary "glue" to make the tracking happen so that the programmer does not have to worry about it. For instance, I read an article about how C# references actually worked. I think it came down to the fact that C# object references were actually 4 bytes of a pointer and 4 bytes of a type or something. So the object reference variable did not just contain a 'plain' pointer. Do not correct me on this, I do not really care about the actual implementation. I am only expressing a point that the language seemed to implement 'behind the scenes glue' to make the tracking happen.       C++ is not an option due to the object instance member function issue. Believe me, this is a monumental issue for us. Our entire application model depends on events and callbacks. Not being able to set callbacks on "application classes" would be devastating.   We won't be switching to another compiler as nothing can comes close to the compiler we are using in terms of optimization. This means whatever subset of C++ supported in our compiler is the feature set we get to choose from. As stated previously, this compiler seems content with the C++ features available circa 1999, which means basically classes, inheritance, and polymorphism to name a few.     Header file hell constitutes about half of my wish list  That in itself is a massive wish / feature change. Besides, I am not going off and inventing a language anytime soon. I know what an enormous task that is just to get something simple running. I would rather spend my time writing code for the products my company produces so that the consumer is more happy.       Last time I tried, I could not for the life of me get a custom compiler / linker / tool chain to work inside visual studio. That was either due to my inexperience or it could be as I surmised at the time, which was that VS was so heavily integrated with the MS tools it couldn't care less about anything else.    Do you mean to tell me that I can take any old command line compiler, linker, and assembler and hook it into visual studio with some custom property pages without having to write an entire project system plugin? Please enlighten me more wise sage, because I spent many weeks and months trying to do this. I am not talking about a makefile project either, but a full fledged custom tool chain integration.    From what I can tell, VS has only integrated 'cross platform' tool chain stuff because of android (gcc, clang, etc.) This does not help me. I am not an Android developer.
  15. LostTime76

    Who wants to see a C replacement?

    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. 
  16. LostTime76

    Who wants to see a C replacement?

      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.        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.     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.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!