Announcement

Collapse
No announcement yet.

Mono Developers Regret Doing Moonlight In C++

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

  • here is an example of utf8 working with std::string
    http://ideone.com/xm1Cq0

    Comment


    • Originally posted by pal666 View Post
      search, concatenate and iostreams work just fine. even splitting works when you know where to split(for example after search).
      advanced tools are needed when you want to change case or do some other character-level work.
      Thank you for proving my point. std::string + utf8 kind of works except when it doesn't.

      If you pass a utf8 string to third-party code chances are you are fucked.

      Comment


      • 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

        Comment


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

          Comment


          • 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; 06 January 2014, 08:50 AM.

            Comment


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

              Comment


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

                Comment


                • 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

                  Comment


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

                    Comment


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

                      Comment

                      Working...
                      X