Platform independency

Let's talk about [b]standard C++[/b]. By definition, there should be no problems compiling the same piece of code on an ymachine that a compiler is created for.

Now, we can make things much more funny and use specialized libs for this or that platform. Is there any particular reason (besides pure stupidity and thoughtlessness) for which the methods in, let's say graphical libraries, aren't called the same?

As i see it, we'd get platform independency of the uncompiled code if it was so. Have i missed something?


Kind Regards
Konrad
----------------------------
(+46/0) 708-70 73 92
chamster@home.se
http://konrads.webbsida.com
«1

Comments

  • This post has been deleted.
  • This post has been deleted.
  • : Let's talk about [b]standard C++[/b]. By definition, there should be no problems compiling the same piece of code on an ymachine that a compiler is created for.
    :
    : Now, we can make things much more funny and use specialized libs for this or that platform. Is there any particular reason (besides pure stupidity and thoughtlessness) for which the methods in, let's say graphical libraries, aren't called the same?

    You can't control what other people do. If I want to make my own Java graphics library that has some crackheaded interface then that's my choice. However, that forces no one to use my crackheaded library.

    : As i see it, we'd get platform independency of the uncompiled code if it was so. Have i missed something?

    You've missed who's going to enforce this or before even THAT who's going to decide what this interface will be. That, and the fact that different libraries oftentimes have different interfaces for a reason, for example, a 3D graphics library that's meant for CAD and doesn't strive for real-time performance but instead high-accuracy may have a more usable but refined interface than a 3D graphics library meant for real-time performance. I.e. they are domain-specific libraries they aren't meant to be cross-compatible because they aren't meant to be used outside of their domain.

    So, I'm going to expand what I believe you are driving at: why not have the C++ standard define standard graphics libraries (etc)? Well, that just wouldn't make too much sense. C++ is used in such a variety of places that adding a bunch of standard libraries would be meaningless. What does a microwave microcontroller need with a TCP/IP Socket library or a 3D graphics library, or a database connectivity library? Anyways, this would put an unreasonable burden on the compiler developer as THEY will need to be the ones that provide those libraries (one way or another) or THEY will be non-compliant. If you notice, the libraries that C++ (and C) define as standard are fairly abstract and computer-science oriented, not domain specific. They could be implemented on any hardware. You can use an STL list in just about ANY application, while a graphics library isn't going to be anywhere near that universal. Okay, now you may be thinking, why not just modularize the standard, if you make a microwave microcontroller C++ compiler (C would be more likely), you don't have to support anything but a core set of libraries to be compliant, and then you can optionally support other libraries (similar to the way XHTML is modularized). That would hardly be helpful, your code would then be standard, but wouldn't be guaranteed to compile everywhere, and anyways that's, in effect, how it IS setup now, only the compiler-vendors are spared. All standards are de facto (at least in the global context). Standard C++ is only standard because the majority of people accept it as so and follow that standard. That's how there are "standards" even before there are standards committees. In this case, there are de facto (or close to it) standards for many things, for example, OpenGL for graphics. Then there are cross-platform libraries that will compile on any standards-compliant compiler that will also work on several architechtures. If I want to do cross-platform GUI in C++, I use Gtkmm. It's standard C++ (I'm pretty sure) and it's cross-platform. I write my code once and anyone can compile it all they need to do is get the Gtkmm libraries. Usually cross-platform runtime libraries (at least) are available readily and freely. In the case of Gtkmm EVERYTHING about it is available readily and freely (it's open source). Therefore, the only thing limiting the compatibility of my source is the compatibility of Gtkmm, I write once, and my code will run "everywhere" Gtkmm is supported, which being a cross-platform library is usually the majority of relevant platforms.

    Notice the following points about that last sentence: the compiler and language was in no way related to it, compilers and language designers shouldn't have to worry about what graphics capabilities to support and how to define and implement them; and _relevant_.

    Anyways, what does using a standard library do for you? It keeps YOU from having to rewrite a bunch of code for a bunch of platforms, but someone (or ones) WILL have to do that rewriting, however why should it be the compiler-vendors? Why not the experts in that area?

    Then of course what do you do when the "standard" library doesn't fit your domain of programming? What if Standard C++ defined a GUI library, however for me it's useless because it has too much baggage, I'm designing for a PDA and need just a simplified light-weight GUI library. Now I'm back to square one of rewriting for all the PDA platforms I intend to support, my interface will definitely be different because I only want a subset and anyways I'm going to tailor it to the way I like to setup things. This is why Standard C++ avoids domain-specific libraries.

    How does Java get away with it? First off, it isn't platform-independent it targets the JVM. The JVM writers now are in the position of the compiler-vendors, the JVM writers need to provide all the necessary support. Java is somewhat domain-specific, it was meant to be an internet language, not a systems programming language, you are very unlikely to use Java to program a microwave microcontroller. Java to a degree can take somethings for granted, like graphics support. However, it does have the problem that sometimes it's domain-specific libraries are specific to a different domain than the one you are programming, and hence there are specialty libraries that are not platform independent. For example, before there was the Fullscreen API what would you do if you wanted to make a fullscreen Java application?

    "We can't do nothing and think someone else will make it right."
    -Kyoto Now, Bad Religion

  • : You've missed who's going to enforce this or before even THAT who's going to decide what this interface will be.

    That's a practical problem. Nothing that can't be solved if we want to. I don't see any real reason why somebody would be oposed to it.

    : That, and the fact that different libraries oftentimes have different interfaces for a reason...

    What's keeping us from designing different libs for different purposes?

    : C++ is used in such a variety of places that adding a bunch of standard libraries would be meaningless. What does a microwave microcontroller need with a TCP/IP Socket library or a 3D graphics library...

    You don't have to use all the libs. A microwave oven can be programmed in C(++) - it doesn't mean it has to use I/O-libs...

    : Anyways, this would put an unreasonable burden on the compiler developer...

    OK, so the compiler-makers will be spared. Still, somebody [b]has[/b] to do it. And as it is now, the compiler makers are the ones who provide the "bunch of standard libraries". There wouldn't be so much difference, just more order.

    : ...a graphics library isn't going to be anywhere near that universal...

    You don't have to use it just because it's there.

    : Standard C++ is only standard because the majority of people accept it as so and follow that standard.

    One can also see it as that people accept it because it is ISO-standard.

    : Anyways, what does using a standard library do for you? It keeps YOU from having to rewrite a bunch of code for a bunch of platforms, but someone (or ones) WILL have to do that rewriting, however why should it be the compiler-vendors? Why not the experts in that area?

    Why not expect the vendors to hire the experts. As i see it, it can only bring them to a closer cooperation which only can bear good results.

    : Then of course what do you do when the "standard" library doesn't fit your domain of programming?

    Well, the same as now :-). Less frequently, though...

    : you are very unlikely to use Java to program a microwave microcontroller.

    JavaME?


    Kind Regards
    Konrad
    ----------------------------
    (+46/0) 708-70 73 92
    chamster@home.se
    http://konrads.webbsida.com

  • This post has been deleted.
  • : The formatting in my email to you is what some refer to as MS
    : garbage. Everything else was written by me.

    Do you mean i formated my post badly? In that case i'd like to appologize :-)...



    Kind Regards
    Konrad
    ----------------------------
    (+46/0) 708-70 73 92
    chamster@home.se
    http://konrads.webbsida.com

  • Great Topic!! :)


    : : You've missed who's going to enforce this or before even THAT who's going to decide what this interface will be.
    :
    : That's a practical problem. Nothing that can't be solved if we want to. I don't see any real reason why somebody would be oposed to it.

    Well, it adds more to what a conforming implementation has to provide. There are two forms of execution environments that C++ supports. Hosted, which is with an OS (file system, etc.), and Freestanding (no OS). Do all OS's have support for graphics?


    : : That, and the fact that different libraries oftentimes have different interfaces for a reason...
    :
    : What's keeping us from designing different libs for different purposes?

    Nothing, but I don't see how that fits the domain of standard C++. IMHO, those rightfully belong in the domain of platform dependence.


    : : C++ is used in such a variety of places that adding a bunch of standard libraries would be meaningless. What does a microwave microcontroller need with a TCP/IP Socket library or a 3D graphics library...
    :
    : You don't have to use all the libs. A microwave oven can be programmed in C(++) - it doesn't mean it has to use I/O-libs...

    Don't most microwaves have some sort of character display where you enter the time to cook, the temperature range, etc.? That's I/O.


    : : Anyways, this would put an unreasonable burden on the compiler developer...
    :
    : OK, so the compiler-makers will be spared. Still, somebody [b]has[/b] to do it. And as it is now, the compiler makers are the ones who provide the "bunch of standard libraries". There wouldn't be so much difference, just more order.
    :
    : : ...a graphics library isn't going to be anywhere near that universal...
    :
    : You don't have to use it just because it's there.

    True, you don't. But the standards committee is probably not going to adopt a graphics library until the industry can standardize on a common technology. For example, are all systems going to be required to support 3000 X 2000 resolution? As long as we are making a wish list, I want a standard analog-to-digital input library. Do all systems have analog capability? Can C++'s abstract machine be required to have them? How many systems are now rendered non-conforming with that requirement?


    : : Standard C++ is only standard because the majority of people accept it as so and follow that standard.
    :
    : One can also see it as that people accept it because it is ISO-standard.

    Absolutely, ISO standards are the only contract we as programmers have with compiler vendors to make sure that our code always works. Without them, we are at the whim of the vendors to change the libraries whenever it suits them (cough, cough...okay I won't point fingers) ;).


    : : Anyways, what does using a standard library do for you? It keeps YOU from having to rewrite a bunch of code for a bunch of platforms, but someone (or ones) WILL have to do that rewriting, however why should it be the compiler-vendors? Why not the experts in that area?
    :
    : Why not expect the vendors to hire the experts. As i see it, it can only bring them to a closer cooperation which only can bear good results.

    It's not going to happen until graphics become at least a de facto standard, and only then, maybe. To add this would seriously restrict C++'s scope, this is why it has always shied away from even mentioning the words "screen", "keyboard", and "mouse" in the entire standard (go ahead, grep for them, they aren't there!). Those have been around much longer than graphics.


    : : you are very unlikely to use Java to program a microwave microcontroller.
    :
    : JavaME?

    I can't see how a microwave manufacturer could possibly justify the 32-bit CPU and 2MB of RAM that the JavaME system requires just to run itself for a microwave. They would be laughed out of the design meeting.


    HTH,
    Will
    --
    http://www.tuxedo.org/~esr/faqs/smart-questions.html
    http://www.eskimo.com/~scs/C-faq/top.html
    http://www.parashift.com/c++-faq-lite/
    http://www.accu.org/


  • As other posters said, what you are suggesting just is not practical. The graphics capabilities of different OSs are just too different -- Microsoft Windows has one set of graphics functions while Unix X?? has another. There are some 3d party libraries that attempt, quite successfully I might add, to be platform independent. So instead of calling platform functions directly, your code calls this libraries functions.


  • : Do all OS's have support for graphics?

    No, only the cool ones :-). Seriously - i get your point.

    : Don't most microwaves have some sort of character display where you enter the time to cook, the temperature range, etc.? That's I/O.

    OK, let me then turn the issue and question wheter there should be std.libs for string managment. Not all tasks will use strings. Maybe we should let the programmers desing their own (very well fitted) methods for that? Of course we shouldn't but why is the line drawn right there not somewhere else?

    : For example, are all systems going to be required to support 3000 X 2000 resolution? As long as we are making a wish list, I want a standard analog-to-digital input library. Do all systems have analog capability?

    I think i'm starting to see very clearly the answer to my original wondering here... Anyway, point taken!

    : : Why not expect the vendors to hire the experts. As i see it, it can only [green]bring them to a closer cooperation which only can bear good results[/green].
    : It's not going to happen...

    OK, i'm buying that it's probably not going to happen. Yet, i say that it [b]would[/b] bring them + (see green above).

    : I can't see how a microwave manufacturer could possibly justify the 32-bit CPU and 2MB of RAM that the JavaME system requires just to run itself for a microwave.

    Is it really that much? I haven't checked that myself, i've just assumed that it should be more "micro"-competitive than that... In that case i was wrong - it's not very likely to see a Java-driven microwave :-).



    Kind Regards
    Konrad
    ----------------------------
    (+46/0) 708-70 73 92
    chamster@home.se
    http://konrads.webbsida.com

  • : As other posters said, what you are suggesting just is not practical.

    Yes, i'm starting to realize how strong opposition that thought might see.

    : The graphics capabilities of different OSs are just too different -- Microsoft Windows has one set of graphics functions while Unix X has another.

    Actually, something hit me, as you mentioned Windows. Graphics capabilities of different computer running the same OS may be very different as well but that didn't stop MS from creating a kind-of-standard-grx-lib, did it? (I'm not 100% sure about this since i'm a PLONK when it comes to MS-graphics.)



    Kind Regards
    Konrad
    ----------------------------
    (+46/0) 708-70 73 92
    chamster@home.se
    http://konrads.webbsida.com

  • : Microsoft Windows has one set of graphics functions while Unix X has another.

    We're not talking MFC and GUI here, right? By graphics i ment images and drawings. Just to be sure that somebodys (mine?) bad english won't be a reason to a fight, here :-)...


    Kind Regards
    Konrad
    ----------------------------
    (+46/0) 708-70 73 92
    chamster@home.se
    http://konrads.webbsida.com

  • : : Microsoft Windows has one set of graphics functions while Unix X has another.
    :
    : We're not talking MFC and GUI here, right? By graphics i ment images and drawings. Just to be sure that somebodys (mine?) bad english won't be a reason to a fight, here :-)...
    :
    :

    It doesn't matter -- drawing anything on M$ Windows is a lot different than on other OSs. Even bitmap files may, or may not, be portable, and the methods used to display then is certainly not portable unless you use one of those 3d party libraries that hides all the OS-specific functions from you.
  • : It doesn't matter -- drawing anything on M$ Windows is a lot different than on other OSs. Even bitmap files may, or may not, be portable, and the methods used to display then is certainly not portable unless you use one of those 3d party libraries that hides all the OS-specific functions from you.

    That's what i ment. I'd like to see some methods like, let's say,
    [blue]
    setColor (red, gre, blu);
    drawShpere (centerPoint, radius);
    throwLight (fromPoint, atPoint);
    [/blue]

    And as long as i see what i want to see on the screen, i wouldn't really care that it's totally different code that actually is executed under the "cover". Do i think too abstract for standard C++? It feels so...


    Kind Regards
    Konrad
    ----------------------------
    (+46/0) 708-70 73 92
    chamster@home.se
    http://konrads.webbsida.com

  • : : Don't most microwaves have some sort of character display where you enter the time to cook, the temperature range, etc.? That's I/O.
    :
    : OK, let me then turn the issue and question wheter there should be std.libs for string managment. Not all tasks will use strings.

    Indeed not. However, there is a clear difference here in that a string is a data type. A graphics library is not a data type.


    : Maybe we should let the programmers desing their own (very well fitted) methods for that?

    That is built into the language already. After all, std::string is simply a typedef for std::basic_string. If you want a different behavior, just provide a different char_traits template! :)


    : : : Why not expect the vendors to hire the experts. As i see it, it can only [green]bring them to a closer cooperation which only can bear good results[/green].
    : : It's not going to happen...
    :
    : OK, i'm buying that it's probably not going to happen. Yet, i say that it [b]would[/b] bring them + (see green above).

    I'm sure it would, and if I were using a compiler that targeted a specific platform and I needed the graphics, then that's exactly what I would want! That still doesn't mean that I think it should be part of the C++ language. Then again, it's just not up to me. Have you tried researching the Google archives for comp.std.c++? I bet this has been discussed before.


    : : I can't see how a microwave manufacturer could possibly justify the 32-bit CPU and 2MB of RAM that the JavaME system requires just to run itself for a microwave.
    :
    : Is it really that much?

    According to their product brochures, yes. I have looked at it, but there is no way I could sell that to my boss. :(


    Will
    --
    http://www.tuxedo.org/~esr/faqs/smart-questions.html
    http://www.eskimo.com/~scs/C-faq/top.html
    http://www.parashift.com/c++-faq-lite/
    http://www.accu.org/


  • : : It doesn't matter -- drawing anything on M$ Windows is a lot different than on other OSs. Even bitmap files may, or may not, be portable, and the methods used to display then is certainly not portable unless you use one of those 3d party libraries that hides all the OS-specific functions from you.
    :
    : That's what i ment. I'd like to see some methods like, let's say,
    : [blue]
    : setColor (red, gre, blu);
    : drawShpere (centerPoint, radius);
    : throwLight (fromPoint, atPoint);
    : [/blue]
    :
    : And as long as i see what i want to see on the screen, i wouldn't really care that it's totally different code that actually is executed under the "cover". Do i think too abstract for standard C++? It feels so...

    No, that's not too abstract for ISO C++, that's too specific. As Darius pointed out, platform independence is not Java, etc. Those are platforms themselves.

    Perhaps the difficulty you are having, is understanding the difference between a language definition, and a language implementation. The ISO standard simply states what certain constructs, expressions, declarations, ... mean in the context of a program. If std::cout happens to be a console "screen", then that is implementation dependant. std::cout could also be a printer for a mainframe, or a serial port for an embedded processor, or whatever. These are abstractions that the implementation defines for itself. The language merely specifies behaviors that it must adhere to, and that is what keeps us portable. If the language itself specifies coloration, then too many potential platforms will be excluded. Does that make any more sense?


    HTH,
    Will
    --
    http://www.tuxedo.org/~esr/faqs/smart-questions.html
    http://www.eskimo.com/~scs/C-faq/top.html
    http://www.parashift.com/c++-faq-lite/
    http://www.accu.org/


Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories