>> That's not even parsable. (Indentation is significant, remember?)
>
> Yuck - I hate it when languages do that.

I thought I would hate it... but when not used in insane ways, it 
actually works quite well. I mean, most programmers indent stuff 
sensibly /anyway/, so having it be significant just means that you can 
avoid having to type a few extra delimiters.

...except in those handful of cases where how /you/ want to indent 
doesn't match what the compiler wants. /Then/ it becomes annoying.

>> Darren claims they committed to a feature freeze too soon. I don't know
>> about the low-level details of the JVM. But I gather that, say, adding
>> Java generics required lots of ugly hacks so it didn't break
>> compatibility.
>
> Guess how many ugly hacks C++ relies on to not break compatibility with
> classic library formats...

Well, yeah. But nobody tries to claim that C is a good programming la... 
oh, wait.

>> I hear there are other languages that target the JVM. Presumably you
>> still can't use any of the existing libraries though. (Not that any of
>> them are much good.)
>
> The fun is that you can. The bane is that you might have to.

LOL!

>> Oh, Haskell? Yeah, I gather a few people have tried to target the JVM
>> with it. Nothing production-grade currently exists, however.
>
> Is there any such thing as a production-grade Haskell implementation?

Sure. Several companies are using GHC to produce mission-critical (and 
often security-critical or even safety-critical) production code.

Post a reply to this message

>> Anyway, I personally stick to IDEs developed by software development
>> companies (and I mean companies that develop other stuff besides
>> programming languages and IDEs).
>
> Indeed. Or use an IDE by a group that actually has a CHI/UI expert on
> board.

You know, I spent an entire semester studying "human-computer 
interaction" without once comprehending WTF the subject was supposed to 
be about. Perhaps if they'd made us use NetBeans and then compile a list 
of all the things that are wrong with it, /then/ we would have understood...

Although... Zimin Wu /did/ look like he was actually a stage magician. I 
kept expecting him to be like "and, arh, here we have arh typocarh 
usarh, and arh, here we have A FLOWER!" and rip a big bunch of paper 
flowers out of his sleeve. But, weirdly, he never actually did this...

Post a reply to this message

On 14/03/2012 07:14 AM, Darren New wrote:
> On 3/13/2012 3:11, Invisible wrote:
>> just runs the downloader for the /real/ installation program.
>
> At least MS gives you a choice. They do that because you can pick to
> download C++, C#, the IDE, and the SQL server, and it'll download just
> the parts you need without duplicating them. Plus it downloads the right
> version for your OS, etc.

Usually if you hunt around the MS site, you can find the "network 
administrator" download, "for IT professionals", which /actually/ 
downloads enough data for offline installation. Because, let's face it, 
only an IT professional would have the technical skill to know that 
there's a difference between downloading an installer and downloading a 
downloader for an installer... oh, wait.

> Only 200? I think the Eclipse at work takes 550M to 600M to start up.

> Try Eclipse. Try pasting a comment from one part of the file to the
> other making it go "unresponsive" long enough that Gnome asks if you
> want to kill it.

Oh, that's cute. No wonder I hear nothing but good things about 
Eclipse... I gather there's even a Haskell plugin for it. (I bit it 
doesn't /do/ anything though.)

>> (Apparently there's an Ant
>> script somewhere too... whatever the hell that is.)
>
> It's an attempt at improving Make without actually fixing the major
> problems with Make.

Well, they fixed /one/ major problem: Text processing tools which turn 
tabs into spaces. ;-)

> Wait until you get into the generics

Uh, yeah.

It seems either they implemented everything twice (once with, and once 
without generics), or it's actually legal to not specify type parameters 
and then they default to Object. Which, either way, is highly 
counter-intuitive...

> It was like surfacing from under quicksand to use VS
> instead of Eclipse. I hadn't realized just *how* much Eclipse kills me
> at work compared to something designed by CHI experts instead of hackers.

I don't know about CHI experts - more like unpaid beta testers. ;-)

> I have a big text file with all my Eclipse hates on my desktop, just
> keeping track for a good rant some day.

And by "rant" you of course mean "shotgun rampage"? ;-)

>> So there we are. I doubt I'd remember much about the AWT (although,
>> didn't they deprecate that in favour of Swing?),
>
> Yes, in spite of promising on day 1 that they'd never do that.

Ah, but did they formally deprecate it, or just "strongly encourage you 
not to use it"? ;-)

Post a reply to this message

On 14/03/2012 05:48 AM, clipka wrote:

> (For non-virtual classes it is good practice to define a protected
> non-virtual destructor instead, just to be sure.)

Is it wrong that whenever I read a sentence like this, I can hear a 
voice say "nuke it from space - it's the only way to be sure"?

Post a reply to this message

>> That's all fine and logical and everything, but there's a nasty snag:
>> Now you have to care about memory management. And there's no way
>> around it.
>
> Forget all you know about classic C pointers;

That shouldn't take long. :-P

> Note that the dispose is gone for good. Shared pointers use reference
> counters to accomplish this feat.

Every time I hear somebody say this, a part of me wants to scream "you 
/do/ understand that reference counting doesn't actually work, right?"

> There's nothing "incorrect" about that way of placing braces, even in
> C++. It's syntactically correct, so say what you will.

Writing the entire program in one source file on a single 435,235,342 
character line is "syntactically correct". But no sane programmer would 
ever do such a horrifying thing. :-P

> The JAVA API has a rich history of deprecating interfaces, deprecating
> interfaces designed to replace deprecated interfaces, and un-deprecating
> deprecated interfaces. I wouldn't be surprised if AWT was among the latter.

Oh yes. I don't remember the names exactly, but I can clearly remember 
how one release of Java had BufferedInputStream and friends. And then in 
the next release, they deprecated that and gave you BufferedReader 
instead. And then in the next release, they deprecated BufferedReader 
and UNdeprecated BufferedInputStream again. (Pro tip: You should /never/ 
need to UNdeprecate something!)

Of course, when I was using Java, it was still quite new. I'd be 
interested to know whether the libraries eventually settled down and 
they stopped doing crap like this, or... ?

> Try Eclipse. Somehow it seems to be the unofficial standard IDE. (Never
> tried it myself in depth though; it has that very special
> Open-Software-Project air about it that somehow makes my skin crawl ever
> since I tried OpenOffice for real.)

Hahaha. "That special OSS air". Yep, NetBeans has that. I don't know 
whether it's the cute but poorly-drawn icons that seem bigger than 
necessary. Or the slightly odd grouping of user preferences. Or the way 
that different parts of the IDE contradict each other as to the current 
status of the code, because each part is out of date by a different 
amount...

> Anyway, I personally stick to IDEs developed by software development
> companies (and I mean companies that develop other stuff besides
> programming languages and IDEs). So far the best IDE experience has been
> Visual Studio for C#. One might snarl at the company's marketing
> strategies, but they seem to know what helps software developers to be
> productive.

I don't know about "what helps software developers to be productive"... 
How about "what makes software developers buy our product rather than 
somebody else's"? Or even "what makes software developers develop for 
our platform rather than somebody else's"? ;-)

The entire MS business model fundamentally depends on getting everyone 
to use the MS platform, and then be locked in. Well, if your platform 
has naff-all software for it, nobody will buy it. But if your platform 
has all the best stuff, people will pay. And then be trapped. So it pays 
(literally) to make it easy for people to write code for your platform 
and only your platform. >:-D

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On 13/03/2012 17:31, Warp wrote:
> > Warp<war### [at] tagpovrayorg>  wrote:
> >>    The first problem is: How should the object be copied? There are many
> >> possibilities:
> >
> >    If you are wondering which solution the STL data containers use,
> > it's usually just a simple deep-copy whenever the container is copied
> > or assigned.

> Just to be picky: I'm presuming that it's a "deep" copy as far as 
> copying the container itself. Presumably what happens to the elements 
> depends on what their copy constructor implements. (?)

  The container object manages dynamically allocated memory, and such
objects can be copied. Naturally I was referring to what type of copying
they perform in that case.

  The elements themselves use whatever copying mechanism they have been
defined to have.

-- 
                                                          - Warp

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> So 16 bytes of space overhead per node is worth it if you can avoid one 
> indirect jump instruction?

  No, it's worth it if you can avoid one extraneous memory allocation
(or having to manage the allocated memory manually).

  A memory allocation will easily consume those 16 bytes of extra space
anyways (the memory allocator bookkeeping, memory alignment, and the pointer
used to refer to the allocated object), so it's not like you are gaining
anything.

> Mmm, I hadn't even thought of using an /array/. I suppose the upper 
> bound on the tree size is statically known, so why not?

  The array doesn't necessarily have to be fixed in size.

> >    It's sometimes quite a bummer, but when writing efficient C++ you have
> > to always think "how many memory allocations will this perform?"

> Right. So what you're saying is that it's not dynamic binding /itself/ 
> which is slow, but rather the dynamic allocations which necessarily go 
> with it. (?)

  Calling a virtual function is in practice not any slower than calling
a regular function.

  Calling 'new', however, can be really slow (comparatively speaking).

  If you can reduce x millions of 'new' calls into eg. log(x millions) of
'new' calls, your program will probably become much faster.

> Out of curiosity, if /you/ were writing a piece of code that's supposed 
> to take a text string, parse it as an expression, and then execute the 
> resulting expression, how would you implement that?

  You mean like this? http://warp.povusers.org/FunctionParser/

> The most obvious way 
> is to make every valid kind of expression be a different class, and have 
> an abstract base class with an "execute this" method, which gets 
> implemented differently for each type of expression. But this 
> necessarily involves dynamic binding and dynamic allocation, which you 
> seem to make out is the Ultimate Evil to be avoided at all costs. So how 
> would you do it?

  If the parser consists of some dozens expression parsers which are added
to the core module once at program start, then the slowness of memory
allocation becomes completely irrelevant. You are not performing millions
of 'new' operations, only a few dozen of them. The virtual function calls
themselves are pretty efficient. (What you *should* avoid is calling 'new'
and 'delete' during the parsing, if you want it to be as fast as possible.)

  The major design issue becomes the management of those dynamically
allocated objects. (Smart pointers may be a good solution to this.)

  Of course there are other approaches which are more efficient in terms
of memory usage, but they are usually less flexible (in that it's harder
to add new expressions to the parser from the outside without modifying
the source code of the parser module).

> OK, well, if there is a single TreeNode class, I could write something like

>    TreeNode(TreeNode t0, TreeNode t1)
>    {
>      child0 = new TreeNode;
>      child1 = new TreeNode;
>      *child0 = t0;
>      *child1 = t1;
>    }

  Since TreeNode there is managing dynamically allocated memory, you'll
have to write a proper copy constructor and assignment operator or else
you have a leak and/or accesses to deleted memory. (And as I said in my
previous post, that's not trivial because of all the options you have.)

> If, however, the TreeNode class is abstract, obviously this won't work 
> at all. I now need to know what the /actual/ type of t0 is before I can 
> allocate sufficient space for it.

  Well, that's easy. You should do this:

    class TreeNode
    {
     protected:
        virtual TreeNode* clone() const = 0;

     public:
         TreeNode(const TreeNode& t0, const TreeNode& t1):
             child0(t0.clone()),
             child1(t1.clone())
         {}

         // Implement destructor, copy constructor and assignment
         // operator appropriately here.
    };

  Then every inherited class implements that 'clone()' method like:

    class FancyNode: public TreeNode
    {
     protected:
        virtual TreeNode* clone() const
        {
            return new FancyNode(*this);
        }
    };

> (I'm also fuzzy on what happens when 
> you try to delete a pointer - does it know what the "real" size of the 
> object is, or does it use the declared type of the pointer?)

  If the pointer is handling a dynamically bound object, then the
destructor of the base class has to be virtual. Then 'delete' is able
to destroy the object appropriately.

-- 
                                                          - Warp

Post a reply to this message

Am 14.03.2012 10:26, schrieb Invisible:

>>> (Last time I looked at Java, all anyone ever used it for was pointless
>>> Tic-Tac-Toe applets. Nobody ever wrote actual large applications with
>>> it, just small toy examples.)
>>
>> You've never heard of Java enterprise application servers, have you?
>
> I've heard of them - but I have no idea what the hell they are. Last
> time I checked, "enterprise" refers either to NCC-1701-D, a galaxy-class
> starship of the United Federation of Planets, or to a piece of software
> which is pointlessly over-engineered, over-complex, over-priced, and
> sold by pushy over-paid salesmen in bad suits.

It's essentially a framework for companies to code business logic. 
Complete with mechanisms for transparently referencing (and accessing) 
data objects that currently don't reside in main memory (because e.g. 
they haven't been queried from the database yet, or they reside on some 
different server farm somewhere across the atlantic). Transaction-safe 
of course.

Post a reply to this message

Am 14.03.2012 10:43, schrieb Invisible:
> On 14/03/2012 05:48 AM, clipka wrote:
>
>> (For non-virtual classes it is good practice to define a protected
>> non-virtual destructor instead, just to be sure.)
>
> Is it wrong that whenever I read a sentence like this, I can hear a
> voice say "nuke it from space - it's the only way to be sure"?

Yeah, that would solve the problem, too :-P

Post a reply to this message

Am 14.03.2012 10:55, schrieb Invisible:

>> Note that the dispose is gone for good. Shared pointers use reference
>> counters to accomplish this feat.
>
> Every time I hear somebody say this, a part of me wants to scream "you
> /do/ understand that reference counting doesn't actually work, right?"

Which is because...?

Post a reply to this message