Page 8 of 12 FirstFirst ... 678910 ... LastLast
Results 71 to 80 of 112

Thread: Mono Developers Regret Doing Moonlight In C++

  1. #71
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by AnonymousCoward View Post
    With JIT cache startup times would be history but oracle focuses more on the server side and there it does not matter.
    I doubt they would add this feature anytime soon, if ever.
    That's something that should be always there, I don't know how it didn't came from day zero. What's the point on compiling everytime you run the program?
    Does it at least profile the program so you can get better optimization everytime?

    Quote Originally Posted by AnonymousCoward View Post
    prefer vectors over arrays
    While I do agree in most cases, I think for fixed size arrays, a C array is better. Why? Because most of the extra features a vector provides has no real use, and the C array uses less memory and probably incurs in slightly less overhead. For all other uses, yeah, stick to vectors, or the equivalent of the project you are working on (some projects in C++ use custom containers instead of the STL, SCUMMVM for example; they do provide a substitute for vectors).

  2. #72
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,149

    Default

    Quote Originally Posted by Apopas View Post
    It sucks nevertheless.
    True.

    WTF, man the guy is confusing RAII with RTTI I think...
    s/RAII/RTTI

    My point is still valid: RTTI is a piss-poor substitute for proper reflection.

  3. #73
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,149

    Default

    Quote Originally Posted by mrugiero View Post
    While I do agree in most cases, I think for fixed size arrays, a C array is better. Why? Because most of the extra features a vector provides has no real use, and the C array uses less memory and probably incurs in slightly less overhead.
    However, with C arrays you need to store a length parameter explicitly and pass it around in function arguments. So the memory angle does not hold in practice, plus you incur the burden of maintaining the length manually.

  4. #74
    Join Date
    Jan 2014
    Posts
    1

    Default Have you seen their code base?

    I did it and what I found is horrible. Here my analysis:

    http://cpp-today.blogspot.it/2014/01...his-tools.html

    his regret has to be read like this:

    "We regret to have chosen C++ without having a deep knowledge of it and without any best practice to follow".

  5. #75
    Join Date
    Mar 2008
    Posts
    210

    Default

    Quote Originally Posted by AnonymousCoward View Post
    It's obvious that the C++ haters use C++ like a glorified C (or never even used it properly), well guess what it isn't! If you use C strings and arrays or pointers in C++ (unless absolutely neccessary, which should be almost never) then you are doing it WRONG.

    In C++:
    prefer vectors over arrays
    string over c strings
    references over pointers
    exceptions over error return codes
    classes over structs
    And the point I made earlier. There's no set of "best practices" for c++ that people agree on.

    std::vector<> is mostly fine but std::array<> is a simple way to make sure your iterative recursive algorithm keeps its storage on the stack.

    std::string over cstring, generally agree although I think std::string's api is lame and archaic, not matching the other std:: collection apis and is a total mismatch with utf8.

    exceptions? a big gun to shoot yourself with and a way to make your code hard to trace due to call stack blowing. Too many folks treat normal bad data as exceptional. Our nicest compromise has been to have isValid() checks on important state stuff, allowing computations to go on even with bad data to be checked when convenient.

    In some rare cases passing by pointer instead of by reference can make the code easier to understand at the caller. It's a weakness of c++ not knowing if a function parameter is pass by ref or pass by const ref.

    pure classes are almost always overkill, over encapsulation requiring too much boilerplate accessors. We find that allowing direct access to some data members, then checking current state with isValid() to be reasonable, reducing a bunch of boilerplate.

    the absolute biggest gain we've seen with c++ has been const correctness and making things as immutable as possible. Frankly I don't see how its possible to do safe thread coding any other way. Yes that's what I mostly do, highly threaded computational workloads, 64+ core stuff, linux and windows (although windows still doesn't seem to be as stable as linux).

  6. #76
    Join Date
    Aug 2009
    Location
    south east
    Posts
    342

    Default Best Practices

    Well actually there are a set of C++ best practices. You just have to know where to look.
    Of course all best practices are contingent on the agreement of the majority.

    Some books, 2 by Bjarne Stroustrup originator of the language
    Programming Principles Practice using C++
    Coding Standards Rules Guidelines Practices
    C++ Programming Language 4th Edition

    Miguel de Icaza proably wants to express how easier it is to just write everything in C#. But even C# has best practices and hidden caveots. If the MONO team is having a hard time with C++ I can only imagine their ordeal with C#.

    It's been said before that those guys farted to try and get Microsoft to take a whif. Unfortunately nobody over at the Redmond campus cares about GNU/Linux other than what Google is selling. They're currently engagued in damage control over Windows RT/8.1 and how to hook customers on Server 2012. Let's not forget SharePoint ladies!

    Besides, if you're developing C# solutions under Linux you're probably doing so from within Virtualbox, Vmware, or KMS.

    Smoke a kipper or something.

  7. #77
    Join Date
    Jun 2013
    Posts
    20

    Default

    Quote Originally Posted by kalman View Post
    Here my analysis:

    http://cpp-today.blogspot.it/2014/01...his-tools.html

    his regret has to be read like this:

    "We regret to have chosen C++ without having a deep knowledge of it and without any best practice to follow".
    Read your blog post: spot on mate!

  8. #78
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,635

    Default

    Quote Originally Posted by bnolsen View Post
    the absolute biggest gain we've seen with c++ has been const correctness and making things as immutable as possible. Frankly I don't see how its possible to do safe thread coding any other way. Yes that's what I mostly do, highly threaded computational workloads, 64+ core stuff, linux and windows (although windows still doesn't seem to be as stable as linux).
    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.

  9. #79
    Join Date
    Oct 2012
    Posts
    297

    Default

    Quote Originally Posted by mrugiero View Post
    JDownloader was pretty responsive, AFAIR. Its only problem was the time it took to start, but after that, it was snappy enough.
    then you should run it on low end hardware. is sluggish and slow and often unresponsive as hell. jdownloader is a great example for the VERY slow java gui rendering. just look at the cpu usage.
    I am kind of a Java hater (although, contrary to most haters, I acknowledge I am and that it is irrational; I don't make futile attemps to make it look like there are real reasons to discard a language independently of the context),
    i'm no java hater. until a few years i didn't acutally cared much about it now i'm coding professionally with it. though java has (from an informatics point of view) some very bad design fails. though these are issues 99% of the programmers either wont encounter or simply won't miss as they never made the experience how you could do things right if java would allow it.

    for me personally the most annoying thing is how the java designers actually made one of the basic and most importants datastructzures of informatics more or less useless: lists.
    and not enough, the fact that the list interface also includes access by index makes it practice nearly impossible to know and rely on some performance assumptions.

    it is funny to see how much work has been put into various VMs just to compensate for the lack of this.

    also, i'm often missing polimorfic heritence and real generics (i.e. suppoting primitive types).

    there is really a lot broken by design in java that won't ever be fixed without totally braking compatibility.
    when ever i run into such a design flaw i think the designer just were some experienced coders but none had a clue about informatics.

    during my science time many of mates used java but they all had to code their own version of the standard datastructures just because with the javas way you fail to implement a lot of algorithms efficiently. now since i am now working in the reseatch and dev of big enterprise i already had to do this myself. and it is damn annoying not to be able to use primitive types with generics when doing so.

  10. #80
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,269

    Default

    Quote 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.
    GCC has supported pure functions since version 2.96. But I really would like to have a really-const keyword, yeah.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •