Announcement

Collapse
No announcement yet.

Mono Developers Regret Doing Moonlight In C++

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Mono Developers Regret Doing Moonlight In C++

    Mono Developers Regret Doing Moonlight In C++

    Phoronix: Mono Developers Regret Doing Moonlight In C++

    Yesterday Phoronix was the first to widely report on the news this week that Cairo is being looked at for a potential 2D drawing C++ standard. It's still being evaluated by the ISO C++ standards committee but it's an interesting topic and already drew lots of feedback. Now Miguel de Icaza of Mono fame has chimed in on the matter...

    http://www.phoronix.com/vr.php?view=MTU1OTY

  • mrugiero
    replied
    Originally posted by curaga View Post
    It talks about both. Immutable variables, and pure functions. "Immutable function" does not make any sense.
    Yes, but look at the part I quoted. It's obvious, since I ommited (and outright took out) the part talking about immutable variables before commenting.

    And about immutable functions, I don't know where you get that from. I didn't talk about "immutable functions"...

    Leave a comment:


  • curaga
    replied
    Originally posted by mrugiero View Post
    So? The quoted post talks about pure functions, not about immutable variables. It's good to know, though, I haven't dive into attributes too much, I just read what seemed useful for writing pure functions, to try to refactor a bit a pet project.
    It talks about both. Immutable variables, and pure functions. "Immutable function" does not make any sense.

    Leave a comment:


  • pal666
    replied
    Originally posted by mrugiero View Post
    But then, as most containers, it's a template, and it adds to binary size, once per type, maybe once per object file too (I'm not sure, I should check that up again), the specialization of the functions, and since I don't use them it makes no sense to pay that small price.
    Also, as it still contains the array inside, it incurs in a (yeah, almost surely negligible, but unneeded in my case) overhead to access.
    unused template members are not instantiated. used functions will be inlined into same instruction sequences as hand-written replacement. you just don't have to write them over and over again. no overhead either way.

    Leave a comment:


  • pal666
    replied
    Originally posted by BlackStar View Post
    If you pass a utf8 string to third-party code chances are you are fucked.
    if you pass utf8 to some code, expecting ascii input and doing something non-utf8-safe, it will fail. but code, expecting ascii input, doesn't accept qt utf8 string either, so it won't help you anyway
    but i repeat, for overwhelming number of uses of strings, like concatenating some strings and sending them out, it does not matter

    Leave a comment:


  • erendorn
    replied
    Originally posted by mrugiero View Post
    Thanks, I didn't know that container. However, for fixed size arrays I don't think I'll ever need more than C arrays. Keep in mind I'm an amateur programmer, and I don't plan on going professional; maybe those extra features are really, really useful for a professional project (I don't really know), but the only benefit I see for the kind of use I do, is that it stores the size. But then, as most containers, it's a template, and it adds to binary size, once per type, maybe once per object file too (I'm not sure, I should check that up again), the specialization of the functions, and since I don't use them it makes no sense to pay that small price.
    Also, as it still contains the array inside, it incurs in a (yeah, almost surely negligible, but unneeded in my case) overhead to access.
    Unused template functions are probably not compiled, and if they are it will be only once per executable/dynamic library.
    Also, if you use iterators, they will compile to simple pointers in Release (while there are usually more checks in debug), so no overhead.

    You gain compatibility with std algorithms (sorting, pushing it back into an other container, etc..), and range checks while in debug. It depends what you're coding for (memory constrained platforms?), but it's probably worthwhile and good practice, even if just in your own projects.

    Leave a comment:


  • mrugiero
    replied
    Originally posted by GreatEmerald View Post
    "immutable" is more const then "const". D also has a "const" keyword that is less const than "immutable" (but it's different from the C++ "const"): http://dlang.org/const3.html
    I'm not arguing that, I was discussing a single point about pure functions. I think it might be useful to have immutables for it, though, but I'm not sure because I'm fairly new to pure functions approaches. However, my point was about the existence of a keyword (or attribute, in this case) to signal GCC there is a pure function, not about it providing all you need to write all kind of pure functions.

    Originally posted by gigaplex View Post
    With the minor distinction that you can't (easily) run OS X on generic Intel hardware.
    Still, you aren't relying on the hardware but on the OS. The fact the OS is hard to install in other hardware doesn't have anything to do with how reliable the hardware is, but with the fact they sell them together and because of this they don't implement proper support for other sets of hardware.

    Originally posted by pal666 View Post
    wrong. for fixed size arrays use std::array
    Thanks, I didn't know that container. However, for fixed size arrays I don't think I'll ever need more than C arrays. Keep in mind I'm an amateur programmer, and I don't plan on going professional; maybe those extra features are really, really useful for a professional project (I don't really know), but the only benefit I see for the kind of use I do, is that it stores the size. But then, as most containers, it's a template, and it adds to binary size, once per type, maybe once per object file too (I'm not sure, I should check that up again), the specialization of the functions, and since I don't use them it makes no sense to pay that small price.
    Also, as it still contains the array inside, it incurs in a (yeah, almost surely negligible, but unneeded in my case) overhead to access.

    Originally posted by curaga View Post
    There is no const attribute for variables: http://gcc.gnu.org/onlinedocs/gcc/Va...ble-Attributes
    So? The quoted post talks about pure functions, not about immutable variables. It's good to know, though, I haven't dive into attributes too much, I just read what seemed useful for writing pure functions, to try to refactor a bit a pet project.

    Leave a comment:


  • BlackStar
    replied
    Originally posted by bnolsen View Post
    Also for the immutability side there are times that needs to be overridden due to shared caches, etc. I suspect 'd' should have a 'mutable' type keyword as well which allows a const interface into thread safe managed cache pools, etc.
    Ocaml / F# are very nice in this regard, with let bindings being immutable by default unless you use the mutable keyword.

    Once you wrap your head around this concept, it's surprising how rarely you need mutable types. In most cases, you just need them when interfacing with the OS a third-party library. The rest of your code remains clean and thread-safe, as it should be.

    Same thing with nullable types. Remove 'null' from the type system and your code becomes cleaner and safer by default. No need to type assert(foo && "foo cannot be null") or if (foo == null) throw ArgumentNullException("foo") all over the place.
    Last edited by BlackStar; 01-06-2014, 08:50 AM.

    Leave a comment:


  • bnolsen
    replied
    Originally posted by GreatEmerald View Post
    That's one point where D is strongly pushing for. It's even safer there, with the immutable variable keyword (not only does it guarantee full immutability, but it even allows the compiler to optimise things since it knows it's not going to change in any way ever), pure functions (that guarantee that they will not change any global variables or use other functions that do that) etc.
    I'm not a huge fan of 'd' due to how tightly GC is integrated into the language, among some other over featurizations. c++'s biggest problem is parseability which would definitely make it easier for compiler writers. Part of the fun of writing a new language should also be to make it easier for clean room compilers to be written and automatic GC absolutely throws a gigantic wrench into that.

    Also for the immutability side there are times that needs to be overridden due to shared caches, etc. I suspect 'd' should have a 'mutable' type keyword as well which allows a const interface into thread safe managed cache pools, etc.

    Leave a comment:


  • curaga
    replied
    Originally posted by mrugiero View Post
    const attribute. Or you mean something that actually checks you are right about it?
    There is no const attribute for variables: http://gcc.gnu.org/onlinedocs/gcc/Va...ble-Attributes

    Leave a comment:

Working...
X