Like Tree31Likes

Let's talk about Rust!

This is a discussion on Let's talk about Rust! within the General Discussions forums, part of the Community Boards category; Originally Posted by Elkvis There still needs to be some run-time checking. If they guarantee pointer safety, then they have ...

  1. #16
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elkvis View Post
    There still needs to be some run-time checking. If they guarantee pointer safety, then they have to check for valid pointers on every access.
    No, a borrowed reference to a value can never live longer than the value itself, this is enforced at compile time. At runtime, everything just lines up because if it didn't, then the program wouldn't have been succesfully compiled.

    See:
    Featherweight Musings: Rust for C++ programmers - part 5: borrowed references

    Quote Originally Posted by Elysia
    You have to consider the fact that new languages need to mature, too. C++ is a big language. How long is it going to take Rust to get to the same point while fixing the fundamental weaknesses? I don't think C++ is fundamentally broken and needs fixing. I also don't see what Rust truly offers that makes it "so much better" that it warrants replacing other "mature" languages.
    There are plenty of advantages, if better type-safety and memory-safety without the massive performance-hit and loss of control you get with GCs are not enough to convince you, then i'm not entirely sure anything actually could?

    Rust fixes many of the fundamental weaknesses of C++, for example, it doesn't contain the entirety of C within the core language.
    Last edited by Neo1; 06-13-2014 at 09:26 AM.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  2. #17
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    No, but i _did_ expect a reasonable awareness of the weaknesses of C/C++. I don't think that is what i got.
    O_o

    Well, there I am your man!

    C++ is an ugly piece of ........; C++ is a massive, complex parse language with a bloated, inconsistent--by intent no less--library having no truly complete implementations, and every change happens a good few years after necessary.

    I'm not exaggerating; I'm not playing games for the sake of this thread. I do indeed feel exactly as described.

    So why would I use such a language? Simple. I can do what I want, how I want, where I want, and C++ will mostly stay out of my way so that I can solve my problems. I neither need nor want my language to "babysit" if that means getting in my way. Don't get me wrong; I like a language who calls me out on my stupid behavior, but if I am deadset on something stupid, I fully expect the language to stay out of my way so that I can go about my business. I have work to do, and I don't have time to ask permission from my language to do something I need to do. I just need my problems solved.

    [Edit]
    I now realize that the reference to "hoops" below is ambiguous at best.

    I'm referring, for the sake of comparison, to what I would need to do in Rust such as prolific use of "unsafe".
    [/Edit]

    So why not use assembler if I'm so "I know what I'm doing."? I despise assembler. In my youth, I knew the "ticks" for dozens and dozens of x86 instructions. My productivity simply isn't good enough. I have to jump through too many hoops to get the job done. The hoops are different, but I still have hoops.

    So what about C as a "middle ground"? I love that C stays out of my way. I LOVE being able to manage almost every little thing, but C simply does not have the expressiveness to accomplish things the way I'd like to see them accomplished. I again just see different hoops such as using designs I find repellant.

    What about all the other languages? I used to be a great LISP programmer, and I still Scheme from time to time. I'm more likely to reach for Python for those tasks these days because Python is "almost there" as a language. However, Python isn't "there" yet, and I doubt Python will ever get to that point because I am the minority of Python.

    So what about Rust? My first true love was compiler theory. My first ever program, printing a dirty word, was awesome. I could not imagine how the computer translated from my code to execute the program. I thought it was magic. Now, I know the science. I can look very hard at a language. I can see that Rust is making the same mistakes every other language makes, and Rust particularly makes several of the same mistakes C++ made. One day, Rust may be great. Eventually, the problems I see will be solved. (Of course, many problems I didn't see will also come to light and be solved.) Will Rust though ever be "there" for me? No. Rust is moving away from "stay out of the way" and into "babysit" territory. Obviously, you and other people who look at Rust like that sort thing. I do not. I like being able to choose "babysit" or "stay of the way" exactly as C++ allows.

    I see the same problems as Elysia. (Totally to brag, I probably see much more than Elysia.) Rust is doomed to go through the same "teething" problems as every other language. Like almost every other language since C++ became a thing, Rust also has to deal with C++ problems because the designers looked to C++ for a template in a few cases. Rust already has further to come than C++ because Rust has new Rust problems. No one even knows what problems Rust may have today. We do know many of the problems C++ has so we, at least, have that going for us. (Which is nice. ^_^) Rust may get "there", but you aren't going to see Rust "there" anytime soon.

    So I am completely aware of "weaknesses of C/C++", and I see that Rust is fixing some of those problems.

    I also see that Rust is making many of the same mistakes which prevents it from being anything other than "yet another post C++ language".

    You may see Rust "boxing"/similar as solutions to `std::unique_ptr<???>'/similar, but I only see a different flavor of the same mistakes.

    Yes. The model is broken. You aren't wrong about C++ having a lot problems which will not be fixed, but Rust is not solving those problems. Rust is just a different model. Rust is still broken. The problems Rust has will also not be fixed for the same reason C++ will not be fixed. The people who made those bad decisions aren't ever going to be able to say "We made a serious mistake." because those decisions were purposefully made.

    *shrug*

    That didn't go the way you expected did it?

    I'll gladly be called a yahoo if it means i no longer have to deal with such runtime errors!
    O_o

    Please see my edit to that post which I'm sure were not available until after you posted.

    Soma
    Last edited by phantomotap; 06-13-2014 at 10:11 AM.
    Elkvis and stahta01 like this.
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  3. #18
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,021
    Quote Originally Posted by Neo1 View Post
    There are plenty of advantages, if better type-safety and memory-safety without the massive performance-hit and loss of control you get with GCs are not enough to convince you, then i'm not entirely sure anything actually could?
    Where does it say C++ uses garbage collection? If you are referring to C#, Java, etc, then I see an alternative to those languages if you absolutely must not have garbage collection: C++.
    I saw few examples: no implicit casts of built-in types (I'd consider no implicit downcasts and signed/unsigned casts to be advantages; anything else is probably mostly noise) and more compile-time memory safety. That's great. But is it enough? My answer is a deterministic: no.

    Rust fixes many of the fundamental weaknesses of C++, for example, it doesn't contain the entirety of C within the core language.
    That a subset of C is still part of C++ is not a fundamental weakness because you don't need to use it. Sure, you could argue that because it is there, other problems arise, such as the need for compatibility, making sure that new stuff works with the C subset, etc. However, even so, I do not consider it a fundamental weakness. Every language that evolves has some old, deprecated style, libraries, classes, etc. You need to make sure you don't break compatibility with such code, and you need to make sure new stuff works with old stuff because that's what compatibility is all about. If you don't have that problems, then your language is broken because software stays around for a long time. Rust may not have it yet, but it will. So if you, give some other example. I will not cede to that one you gave.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #19
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elysia
    Where does it say C++ uses garbage collection? If you are referring to C#, Java, etc, then I see an alternative to those languages if you absolutely must not have garbage collection: C++.
    I'm well aware C++ does not use garbage collection. The point is that Rust gives you many of the advantages of garbage collection, without imposing many of the disadvantages of having a GC, of which there are many.

    That a subset of C is still part of C++ is not a fundamental weakness because you don't need to use it. Sure, you could argue that because it is there, other problems arise, such as the need for compatibility, making sure that new stuff works with the C subset, etc. However, even so, I do not consider it a fundamental weakness. Every language that evolves has some old, deprecated style, libraries, classes, etc. You need to make sure you don't break compatibility with such code, and you need to make sure new stuff works with old stuff because that's what compatibility is all about. If you don't have that problems, then your language is broken because software stays around for a long time. Rust may not have it yet, but it will. So if you, give some other example. I will not cede to that one you gave.
    Having the entire C language contained within C++ is a fundamental weakness for other reasons than those you mention:

    1. A proficient C++ programmer needs to be (nearly) fluent in C to be able to write and read good C++ code, even though the overlap between good C++ code and good C code is at this point nearly inexistant.
    2. The presence of C discourages new C++ programmers from properly adopting the object oriented mindset.
    3. Many of the flaws and inconsistencies of the language is directly due to the C legacy, silly things like arrays decaying to pointers for no good reason.
    4. Even though the presence of many C features does not force a programmer to use them, their presence still means that somebody will choose to use them. If there is never any good reason to use C-style casts or void pointers, then why are they in the language? Oh, because they have to be, because they are in C.

    I also consider the size and complexity of C++ to be a weakness. I don't know if i'd call it a fundamental weakness but it certainly doesn't seem like something that is fixable.
    1. The larger the language is, the longer it will take to learn and get comfortable with.
    2. Even though a newcomer to C++ does not plan to make use of some of the more esoteric features of the language, he will still have to learn them if he wants to be able to read and understand code that does use those features. The argument that you don't need to learn it all is not sound IMO.
    3. The complexity of the language is showing in the syntax. The grammar is so huge and unwieldy that we need to put 'typename' or 'template' everywhere for the compiler to be able to comprehend what our intentions are. Let that sink in, C++ forces us to make our code less humanly readable so the compiler actually knows what we're talking about. This is the exact opposite of what a programming language is supposed to do: Make code _more_ humanly readable while still being machine comprehensible. Look at the '...' operator in C++11, it has a million different uses. Parameter packs (both unpacking and packing depending on the context), C-style variadic functions, catch-all notation for exceptions. No wonder the compiler vendors are having a hard time with the language. How long did it take for us to not have to put a space between the greater than operators in std::vector<std::vector<int>>?
    4. A large and complex language means large and complex compilers, which means more proneness to errors and security flaws, longer compilation times, fewer standard compliant compilers available and so on and so forth. You all know why it is advantageous to have _less_ code. Somehow most C++ enthusiasts fails to make the connection that less complexity in the language is equally advantageous.

    Heck, even the standards committee finds that the language has become to complex, but they can do nothing about it for backwards compatibility reasons.

    Phantomotap:

    That is a good post, and it deserves a better answer than what i have time for at the moment :-)
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  5. #20
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,021
    Quote Originally Posted by Neo1 View Post
    I'm well aware C++ does not use garbage collection. The point is that Rust gives you many of the advantages of garbage collection, without imposing many of the disadvantages of having a GC, of which there are many.
    So how is this different from the C++ model?

    1. A proficient C++ programmer needs to be (nearly) fluent in C to be able to write and read good C++ code, even though the overlap between good C++ code and good C code is at this point nearly inexistant.
    No.

    2. The presence of C discourages new C++ programmers from properly adopting the object oriented mindset.
    No.

    3. Many of the flaws and inconsistencies of the language is directly due to the C legacy, silly things like arrays decaying to pointers for no good reason.

    4. Even though the presence of many C features does not force a programmer to use them, their presence still means that somebody will choose to use them. If there is never any good reason to use C-style casts or void pointers, then why are they in the language? Oh, because they have to be, because they are in C.
    Backwards compatibility. The bane of any language. Just wait. Rust will get there.

    Having the entire C language contained within C++ is a fundamental weakness for other reasons than those you mention:
    So no, it is not a fundamental weakness. It is a fundamental practical limitation. It does not simply extend to C++: it extends to all languages, sooner or later. As thus, I don't classify it as a fundamental weakness of C++.

    I also consider the size and complexity of C++ to be a weakness. I don't know if i'd call it a fundamental weakness but it certainly doesn't seem like something that is fixable.
    1. The larger the language is, the longer it will take to learn and get comfortable with.

    2. Even though a newcomer to C++ does not plan to make use of some of the more esoteric features of the language, he will still have to learn them if he wants to be able to read and understand code that does use those features. The argument that you don't need to learn it all is not sound IMO.

    3. The complexity of the language is showing in the syntax. The grammar is so huge and unwieldy that we need to put 'typename' or 'template' everywhere for the compiler to be able to comprehend what our intentions are. Let that sink in, C++ forces us to make our code less humanly readable so the compiler actually knows what we're talking about. This is the exact opposite of what a programming language is supposed to do: Make code _more_ humanly readable while still being machine comprehensible. Look at the '...' operator in C++11, it has a million different uses. Parameter packs (both unpacking and packing depending on the context), C-style variadic functions, catch-all notation for exceptions. No wonder the compiler vendors are having a hard time with the language. How long did it take for us to not have to put a space between the greater than operators in std::vector<std::vector<int>>?

    4. A large and complex language means large and complex compilers, which means more proneness to errors and security flaws, longer compilation times, fewer standard compliant compilers available and so on and so forth. You all know why it is advantageous to have _less_ code. Somehow most C++ enthusiasts fails to make the connection that less complexity in the language is equally advantageous.

    Heck, even the standards committee finds that the language has become to complex, but they can do nothing about it for backwards compatibility reasons.
    Backwards compatibility. The bane of any language. Just wait. Rust will get there.
    This is not something Rust can and will fix. When it becomes mature enough, it will have the same problems.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #21
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elysia View Post
    So how is this different from the C++ model?
    In every way? Have you not been following the thread?

    Say you allocate some memory and assign a Rust unique_ptr to maintain ownership of this memory. There is no way for the programmer to explicitly state when this memory should be freed, it is freed when the unique_ptr drops out of scope. This means the compiler knows the lifetime of the memory, and thus all references to this piece of memory (what Rust calls borrowing references) must have a lifetime equal to or less than this, if not, a compilation error is issued. The lifetime is, as i understand it, actually part of the type of the references and can be explicitly stated by the programmer or left out to be inferred by the compiler.

    C++ gives no such guarantees at all! Everything is left up to the programmer, who is given some tools to ease this task (unlike in C). I can still dereference a std::unique_ptr after the contents have been moved to another unique_ptr and the compiler will gladly oblige me.

    So the way i see it, the Rust approach is the best of both worlds. You get fine grained control of pointers and memory, yet you will not have to worry about dereferencing a dangling pointer or leaking memory.

    No.
    It's fine to disagree, but don't expect me to lend any credence to your POV when you fail to argue why it is correct.

    Backwards compatibility. The bane of any language. Just wait. Rust will get there.
    No other programming language has ever had to be backwards-compatible with C. Most programming languages try to maintain backwards-compatibility with older versions of itself, C++ takes this to the extreme.

    Backwards compatibility. The bane of any language. Just wait. Rust will get there.
    This is not something Rust can and will fix. When it becomes mature enough, it will have the same problems.
    Most other programming languages reach maturity way way before they reach the levels of complexity that C++ has now. I don't see why Rust would be any different. Many programming languages are mature enough to see very widespread use yet none are as complex as C++. You make it sound like all languages have this problem, they don't, many languages are complex and large, none as much as C++!
    Last edited by Neo1; 06-13-2014 at 12:18 PM.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  7. #22
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,021
    Quote Originally Posted by Neo1 View Post
    In every way? Have you not been following the thread?
    I have. I see what you mean, but it's not at all dissimilar to C++'s model. They're pretty much the same, except Rust gives you better compile-time enforcement, which is nice.

    It's fine to disagree, but don't expect me to lend any credence to your POV when you fail to argue why it is correct.
    Alright, fine. I would think it would be obvious, but I guess not. So...

    1. A proficient C++ programmer needs to be (nearly) fluent in C to be able to write and read good C++ code, even though the overlap between good C++ code and good C code is at this point nearly inexistant.
    Completely and utterly false. C != C++. Modern C++ does not resemble C in any way. Yes, you may have to be good at C to ready legacy C++ code, though. But that does not make the point any more valid. C is not a requirement to read and write good C++ code.

    2. The presence of C discourages new C++ programmers from properly adopting the object oriented mindset.
    Again, I am going to disagree. What makes a good programmer and not is how they're taught. If you're a C programmer and goes to C++, chances are you are going to use its imperial subset. If you're taught C++ the C way, then again, you're going to mostly use the C subset. But if you're taught the modern way, then you are not going to do that. It's all about education and any big language--object-oriented or not--faces the same problems.

    No other programming language has ever had to be backwards-compatible with C. Most programming languages try to maintain backwards-compatibility with older versions of itself, C++ takes this to the extreme.
    But they have to be backwards compatible with themselves. C++ may take it to the extreme in many ways, but it doesn't mean Rust is immune to the problem. Throwing in another language just to solve this "problem" won't solve anything. Rust will become complicated itself as it matures and face the same problems.

    Most other programming languages reach maturity way way before they reach the levels of complexity that C++ has now. I don't see why Rust would be any different. Many programming languages are mature enough to see very widespread use yet none are as complex as C++. You make it sound like all languages have this problem, they don't, many languages are complex and large, none as much as C++!
    Most other programming languages aren't 20 years old. Programming languages and source code written in it will be around for a long time. How will Rust look in 20 years time? Will it fare better than C++? If not, then it's a waste of time.

    Again, my point is just that designing another language for reducing the complexity of the language usually is not a valid reason for making a new language as the problems will just resurface down the road.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #23
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Phantomotap:

    I disagree that marking potentially unsafe code as 'unsafe' is the same as making the programmer jump through hoops. It informs the compiler that it should not issue errors or warnings about potentially dangerous instructions in the code and it tells humans reading the source code that here is something which is known to be unsafe, yet necessary, and that (hopefully) care has been taken to cover all possible points of failure manually.

    If you want to do silly type conversions or dereference dangling pointers, you are free to do so. I feel like you're saying that all of the added correctness and abstraction that the Rust memory management system affords the programmer, is collectively worth less than the ability to write unsafe code without the hassle of having to mark it unsafe. I'm not quite sure that's what you meant, but that is kind of what i picked up from some of what you write.

    As far as Rust making mistakes, i'm positive that you are right. The way i see it, our tools will never improve if we are not willing to make mistakes. C++ no longer represents the best we can do when it comes to systems programming languages, let us reiterate, make some mistakes and hopefully end up with a better tool in the end. Whether that is Rust or a succesor to Rust which attempts to fix the mistakes made by Rust (and likely introduce some new flaws of its own) remains to be seen, but we will forever be stuck with buffer overflows, memory leaks, ASLR and format string exploits if we insist on sticking with C.

    You may see Rust "boxing"/similar as solutions to `std::unique_ptr<???>'/similar, but I only see a different flavor of the same mistakes.
    What mistakes are these?

    What i see is a third option, somewhere between the C approach and the GC approach, where the language is designed in a way to make the compiler help us avoid memory flaws in the program.

    You should join the bandwagon, we have a great view and cocktails with little umbrellas in them! :-)

    Quote Originally Posted by Elysia
    Again, my point is just that designing another language for reducing the complexity of the language usually is not a valid reason for making a new language as the problems will just resurface down the road.
    I must say i find this to be an exceptionally cynical point of view. Not all languages succumb to insurmountable complexity. The better the starting point is, the less problems will surface as the language matures. I think Rust has a significantly better starting point than C++ had, which is not strange given that Rust is brand new and thus can enjoy all the advances made in the field of programming language theory (and practice) since C++ was concieved. C++ can at this point only really make additions to the language, but all the past mistakes are unfixable. Time for a clean slate!
    Last edited by Neo1; 06-13-2014 at 12:46 PM.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  9. #24
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,283
    CPU languages are overdone. Why no new GPU languages?

  10. #25
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,021
    Quote Originally Posted by Neo1 View Post
    I must say i find this to be an exceptionally cynical point of view. Not all languages succumb to insurmountable complexity. The better the starting point is, the less problems will surface as the language matures. I think Rust has a significantly better starting point than C++ had, which is not strange given that Rust is brand new and thus can enjoy all the advances made in the field of programming language theory (and practice) since C++ was concieved. C++ can at this point only really make additions to the language, but all the past mistakes are unfixable. Time for a clean slate!
    And in 20 years, Rust will be the next C++ - a complex beast. Don't make a new language unless the old language's complexity is severely hampering its progress. I don't think C++ is there yet. Besides, instead of creating a new language, you can put those resources into evolving the C++ language instead! There is great interest in C++ and apparently it's increasing because the world has such a huge stake in it. And yet, the standards committee is mostly run by volunteers with limited free time. Imagine how much better C++ could become if you just put the time and effort you put into Rust into C++ instead.

    Clean slates are overrated. You need a really good reason to do that. As far as I see, there is not good enough reason to do that.

    Quote Originally Posted by MutantJohn View Post
    CPU languages are overdone. Why no new GPU languages?
    GPU languages are bound to become doomed. Why are there no sufficient amount of features in existing languages that can offload things onto the GPU/APU?
    Hint: The future of computing is not a GPU. It's mostly useless outside of gaming. Waste of resources and computing power.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #26
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,283
    Yes, I'm sure the people at nVidia are like, "Hmm... Let's waste a lot of money and time today with a useless project. Who would ever need GPGPU computing?"

    Pfft.

    I'm not saying GPUs are better than CPUs in every context but they have a place in the world. And that's basically at the point where it's faster to do 10,000 things slower all at once vs 4 things much faster.

    It mostly has use in scientific applications which is good. A project was launched that achieves a 5x speed-up over CGAL for a type of mesh generation and that's being modest. The site claims one implementation is 10x faster. Now, I'm not sure what those words mean but I think it means they use a massively parallel algorithm to speed up a computation. GPUs have also been used in biological research as well, even helping to advance HIV/AIDS research (HIV structure cracked using GPU-based simulations | ExtremeTech) but nah, man, those things aren't important.

    I will say this though : I think you're right, Elysia, in the sense that quantum computers will eventually make it outdated but one step at a time.

  12. #27
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,021
    It's not useless, but the fact remains that GPUs often aren't as good at computing tasks as they are at doing computer graphics. The problem is that there just aren't so many programs that are extremely parellizable to fully take advantage if the GPU. Now, parallel computing is important. But GPUs are the extreme end of it - tons and tons of small, simple cores that are good at floating point math. Most programs don't need that much. Most programs can't use that much. Most programs also need to do the heavy lifting the CPU is good at. And that, my friend, is why GPUs are not the future. The APUs are - a mix of CPU and GPU architecture that takes properties of both. Less cores and more complex cores. This will likely be much more suitable for most programs.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #28
    Registered User
    Join Date
    Oct 2006
    Posts
    2,590
    Out of curiosity, is Neo1 the author of Rust? He/she seems to be defending it quite strongly. I understand that new things can be exciting, but I don't get the rather obstinate defense of said new thing.
    Code:
    namespace life
    {
        const bool change = true;
    }

  14. #29
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,283
    So basically, the answer is to use both...

    You can already do that though, just not in one single unit. Eliminating memory transfer latencies is a good idea though.

    Isn't this idea already done through chips with integrated graphics? Or are integrated chips like a weird Frankenstein creation?

  15. #30
    Epy
    Epy is online now
    Fortran lover Epy's Avatar
    Join Date
    Sep 2009
    Location
    California, USA
    Posts
    999
    Quote Originally Posted by Neo1 View Post
    Forgive me, but this smells a bit like something an old and dusty C++ programmer would say. We'd still be using FORTRAN if this was the prevalent frame of mind.
    As previously mentioned, people (myself, for one) still do use Fortran. Fortran didn't stop at the 77 standard, since then there have been many revisions to the standard: 1990, 1995, 2003, 2008, 2015 (coming soon).

Page 2 of 12 FirstFirst 1234567891011 ... LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Do I talk too much?
    By GoodStuff in forum A Brief History of Cprogramming.com
    Replies: 11
    Last Post: 05-20-2003, 11:45 PM
  2. Who wants to talk on AIM?
    By Death Wish in forum A Brief History of Cprogramming.com
    Replies: 0
    Last Post: 07-05-2002, 07:29 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21