Slashdot Mirror


User: julesh

julesh's activity in the archive.

Stories
0
Comments
8,446
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 8,446

  1. Re:C++ Viability on Stroustrup on the Future of C++ · · Score: 1

    It's getting hard to get that kind of degree today. I'd argue that language exposure isn't what makes CS CS though: it's learning the mathematical underpinnings that separates CS from Software Engineering courses. Complexity analysis, discrete maths, logic, semantics -- these are the courses that distinguish CS from other subjects.

  2. Re:C++ Viability on Stroustrup on the Future of C++ · · Score: 1

    I know most game programming is still done in c++, but if the universities have moved on, the industry won't be far behind.

    I think the universities have jumped the gun on this one. Yes, they've just about all moved to a java-centric syllabus. Mine only teaches Java and a functional language now -- not sure which one -- I was in the last year that was taught Pascal, C, Miranda, a bastardised version of Pascal with concurrent programming structures hacked in and C++: it's just Java and a functional language these days. I can understand why, too -- that was a lot of languages to teach people over 3 years. But, I learned important things:

    * I learned how to learn languages quickly
    * I learned a wide variety of different language styles
    * I learned to use the best tool for the job (witness my final year project, which included a programming language interpreter written in C/flex/bison, with a GUI written in Java)
    * I learned that low level programming is hard, but that when you work it out it is manageable

    Current students are coming out with CS degrees and no idea how explicitly managed memory should work. That's just wrong: memory management is an important CS subject, if only because *somebody* has to write the memory managers.

  3. Re:Multiple return values on Stroustrup on the Future of C++ · · Score: 1

    And using a map (or a tuple as the other poster suggested) requires allocating and initializing variables, and deallocating and deinitializing them on end of use. A lot of overhead (especially on a map/list, less on a tuple). I'd prefer to see it built in and go with a very low overhead solution, probably just writing them to the stack (or registers) and then reading them out rather than involving objects at all.

    When you return a statically allocated tuple, it is stored on the stack. No allocation overhead, no nothing. Tuple constructor call gets inlined. It's as efficient as you could hope for, as long as the compiler's got a good optimizer.

  4. Re:Dogma on Stroustrup on the Future of C++ · · Score: 1

    I mean as part of the compiler - built in option to not care about collecting your own garbage.

    Well, what's wrong with having to use an external GC? It's not a lot extra work: a little time to download and install, then just include its header file, add its library file to the link command line, and use "new (GC) Object" instead of "new Object" where applicable. Not exactly rocket science.

  5. Re:How about a module system? on Stroustrup on the Future of C++ · · Score: 1

    Stroustrup says you shouldn't use the "using namespace" statement anyway

    Are you sure? Here's an example from his web site's technical FAQ:


    #include<vector>
    #include<string>
    #include<ios tream>
    #include<algorithm>
    using namespace std;

    int main() // small program messing around with strings
    { ....

  6. Re:C++0x? D! on Stroustrup on the Future of C++ · · Score: 1

    D is a beautiful, well-appointed systems programming language.

    Yeah, right. Just looking at it now, as I've been meaning to for a while. Its memory management facilities just aren't up to C++'s. E.g., if you want to allocate an object on the stack, you have to declare that in its class, so all objects of the same class are stack allocated! And stack-allocated objects never have their destructors called.

    Looking at the changelog, core runtime functions have been removed and replaced with equivalents with different interfaces recently.

    Templated functions have a bizarre syntax: you have to name the function as well as the template.

    The only things I've seen so far that I like is the garbage collector (although you can use a C++ one, it's not quite as efficient as a proper GC) and the fact that objects are passed to their constructors with the vtbl filled in (one of the most annoying things about C++: you can't call overridden virtual functions from a superclass constructor).

    When it has matured, it might be an interesting language. At the current rate, I'd say it needs another 2 or 3 years.

  7. Re:a 'few' rough edges on Stroustrup on the Future of C++ · · Score: 1

    What has that got to do with GC implementations?

    The general problem with GC when not part of the language itself is that you have two choices:

    1. There must be some way of telling the collector exactly what is a pointer and what isn't (in a GC language, the language environment takes care of this for you).

    2. Alternatively, the collector must assume that everything that might be a pointer is a pointer. This is not efficient; the collector will probably end up scanning more memory than it needs to and keeping objects that should be discarded.

    How does something like GCC's intrinsic functions help with this problem?

  8. Re:a 'few' rough edges on Stroustrup on the Future of C++ · · Score: 1

    There is no additional code or hooks placed in compiled Java to allow introspection, so there is no additional performance, memory or disc cost if you don't use it.

    Actually, there is: along with each clss is stored a copy of its name, the name of its superclass, the names of the interfaces it implements, the names and types of all its member variables, the names and types of all its methods and details of the exceptions they throw.

    In an average class, that takes up more space than the bytecode. A version of Java that didn't support introspection would probably be half the size, start about 20% faster, and use about 10% less memory.

  9. Re:Syntactic candy. on Stroustrup on the Future of C++ · · Score: 1

    No, they're following a couple (at least) decade old convention. Standards are described by the standard name followed by the year.

    Algol 58 is the earliest example I know of. AFAICT the first non-Algol language to use the convention was FORTRAN 66; then lots of others started doing it.

  10. Re:Features I want... on Stroustrup on the Future of C++ · · Score: 1

    How about taking a paremeter that's a reference to an int and storing an error code in there.

    Although throw & catch probably generates better code when its compiled, so I've no idea why you'd want to do it that way.

  11. Re:Features I want... on Stroustrup on the Future of C++ · · Score: 1

    class Delegate { public: virtual void operator() = 0; }
    class T { public: virtual void f() { ... } };

    class T_f_Delegate : public Delegate {
    private:
    T * target;
    public:
    T_f_Delegate(T * t) { target = t; }
    virtual void operator() { return target->f(); }
    };

    T t_instance;
    ...
    T_f_Delegate delegate (t_instance);
    ...

    Not the easiest setup in the world, but it can be improved substantially by using a few templates.

  12. Re:A better wheel on Stroustrup on the Future of C++ · · Score: 1

    What about writing something quickly that I can just run outright on another machine?

    You know, without having to install 30MB of toolkit/libraries/VM shit just to run the program./i.

    Then you're looking for something with a smaller runtime, possibly which can build an encapsulation of runtime & program. Python is good for this.

  13. Re:A better wheel on Stroustrup on the Future of C++ · · Score: 1

    Refcounts can't cope with cyclical structures without serious hacks. C++ garbage collectors are useful, but the fact that they can't tell pointers from binary data that happens to resemble a pointer is a serious problem for some applications.

  14. Re:Kieren McCarthy is clue-less on EU Domain Registries & ICANN · · Score: 1

    they represent their members, around 50 TLD's (http://www.centr.org/members/) - that's not even a simple majority of TLD

    True. But they do represent the vast majority of ccTLDs by total number of registrations.

  15. Re:Sounds Like Good News on EU Domain Registries & ICANN · · Score: 1

    BTW, anybody else annoyed that all these news articles on this keep confusing DNS with "The Internet?"

    Frankly it's so much better than confusing the web with the Internet that I'm not saying anything. At least DNS is a core technology that the Internet couldn't function without.

  16. Re:To bad.. on Harry Potter's 'Half Blood Prince' Leaked · · Score: 1

    Its a real shame, there doesn't seem to be a bittorrent for physical objects...

    But there is! It's called SecondHandBookshop. You see, what happens is that somebody goes to a bookshop and buys a book. Then, after they've read it, the "upload" it to SecondHandBookshop, and then a "downloader" comes along and buys it from there, reads it, and "uploads" it back again...

    I get all my books from SHB these days. I've saved a fortune.

  17. Re:Um... on Harry Potter's 'Half Blood Prince' Leaked · · Score: 1

    it could be argued the store sold "stolen" goods. The consumer then would have no right to such goods even if purchased in good faith.

    I don't know about Canadian law, but I do know that under UK law if you buy stolen goods in good faith they generally cannot be recovered from you (except in a few specific cases). It would (I believe) be up to the seller to provide replacements to the original owner.

  18. Re:Um... on Harry Potter's 'Half Blood Prince' Leaked · · Score: 1

    Am I missing something, or does that seem even more retarded than something our court systems would do?

    You're missing something: this is a temporary injunction, granted only until the court has enough time to have a hearing on the matter. This is pretty much standard practice for any such case that doesn't seem to be taking the piss.

    ISTR a US case where a man was temporarily ordered not to publish information about his ex-girlfriend on his web site briefly. Of course when the court sat, the order was reversed.

  19. Re:It's actually more stupid than that... on Harry Potter's 'Half Blood Prince' Leaked · · Score: 0

    A work is not considered published until it has been published in some form.

    Err, if you say so. ;)

    That it has been printed with the intent to publish is not sufficient.

    No. But distributing to bookshops is probably enough.

  20. Re:Frostbitten laws on Harry Potter's 'Half Blood Prince' Leaked · · Score: 1

    How do we as a nation, any nation balance the rights of competing interests? In this case the interest of free speech versus Rowling and her publisher's right to IP.

    The same way everyone else does: with fair use laws. One of which is the right to discuss the work, and publish small excerpts of it for the purpose of doing so. If you want to prevent someone doing this, get them to sign an NDA before showing them the work.

    No NDA? Out of luck, sorry.

    The store that "accidentally" sold these (how do you accidentally sell copies of the biggest book launch this year? what's the bets a backhander was involved?) should be under NDA, and if it were, could be sued for any losses that Ms Rowling suffers because of this.

    Not that I expect there will be any.

  21. Re:Spoilers! on Harry Potter's 'Half Blood Prince' Leaked · · Score: 1

    Nothing described there was magic.

    No, the magic's described inside the book. /me ducks

  22. Re:So much for the DRM on Harry Potter's 'Half Blood Prince' Leaked · · Score: 1

    You think more than one person is involved in the chain of editing a slashdot article? Please. Sometimes I have my doubts over whether they're seen by a human at all, not some kind of slahshdot-editor-AI bot.

  23. Re:Not complex on Zlib Security Flaw Could Cause Widespread Trouble · · Score: 1

    That's a terrible benchmark. They've not even tried to be fair -- I can see no other reason why you'd see results like this:

    Language / time / mem usage
    (binary-trees)
    C gcc 5.95 4,496
    C++ g++ 18.71 16,176

    (count-words)
    C gcc 0.18 260
    C++ g++ 1.31 744

    I mean, you pay a slight penalty for using c++, sure, but it doesn't make your code 3 times (or even 6 times) slower, and use 4 times as much memory. That's bullshit if ever I saw it.

    I mean look at the code for the count-words test. Here's the C++:

    OK. I don't get to paste the code in, case /.'s lameness filters are rejecting it. You can look at it yourself if you like.

    It's a reasonable implementation. I'd optimise it by not using a streambuf (I don't know whether the 'bumpc()' method will be inlined or not, so I'd rather not chance it), but just read data into a character array and use that. I'd also use unsigned characters and check "c Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted.

    Yeah, fuck you too. Anyone'd think this wasn't a site where programmers regularly tried to discuss coding techniques.

  24. Re:very complex code on Zlib Security Flaw Could Cause Widespread Trouble · · Score: 1

    That's an answer to a different question ("Could the Common Lisp version possible be written to the same performance constraints as the C one?") not the question originally asked: is it?

    The main reason for zlib's apparent complexity is that it is an optimization of the traditional deflate algorithm that uses less memory than most other implementations. I would guess that this Lisp version may run as quickly as zlib (although on a modern processor it's unlikely to make a lot of difference -- both will be IO bound by a substantial degree), but probably it uses a significant amount more memory to do so.

    Zlib is designed to be useful for embedded systems.

  25. Re:A case for packaging systems on Zlib Security Flaw Could Cause Widespread Trouble · · Score: 1

    I think what he meant is that packaging means it is possible for a program on Linux to use a shared library even if it is not part of the base system.

    This is equally true on Windows. There are many installation programs that will check for the presence of a non-core DLL in %WINDIR% and install it if it is not present. It doesn't happen enough though, largely because there's a culture of putting DLLs in a private directory, and many open source packages don't have a standardised naming convention for a DLL file on windows (e.g. the makefiles distributed with zlib just produce a "zlib.dll" file, which is next to useless: you wouldn't be able to tell if you were overwriting a different (potentially incompatible) version when you installed a replacement). Also, people still remember windows 3, where if two applications had a DLL with the same filename, the second to load would actually be linked to the DLL from the first to load.