Oh, okay. You're right about that, but I still claim it's not proper inheritance in terms of C++ (for instance, baz doesn't automatically get all the methods of foo and bar), which was the point I wanted to bring forward. I take it on trust that you're right about CFront, but... isn't that frozen in time inside a blob of amber or something like it?

You're right that it isn't automatic. OOP isn't automatic either. You still have to pass in the context object to any "member" functions. Let's add a member function that is like the C++ example.
When baz #includes foo.h, it gets member function f. It can be called by doing "f(baz.foo)".
All not-so-recent features of C++ had to have been implemented somehow in C when it was only a preprocessor.

Yes they are. I'm using Firefox from a package on the Slackware install CDs, not from the FF website. And LimeWire has many "branch-offs" (such as AquaLime and FreeWire) of its code, probably created by Windows users who didn't like it being bundled with adware and/or wanted their "pro" features but didn't want to pay money.

In any case, I'm pretty sure both are free/libre.
1. What good is bugzilla if it doesn't give the developer a trace, or at least some sort of log of what went wrong to go by?
2. Who do you want to help other than the developer fixing the bug? If they're not fixing the bug, what good does the bugzilla info do them anyways?

No doubt bugzilla can help, but if I don't put some sort of backtrace in my program then it'll be that much harder to diagnose my users' problems. In Java it's already there; in C++ you have to go build it yourself. Of course, you might want to take that a step further in whichever language you choose, but at least in Java you start with something already there.

Meh... you're right about limewire being free (it's even GPL, kudos to them). I was fooled by their website, which in my eyes very much looks like LimeWire is proprietary. Anyways, I still haven' tried it, so I can't comment.

Bugzilla is to post steps to reproduce, which are indirectly way more valuable to developers than a trace. The trace is generated by reproducing the bug, so it is not needed in the bug report. The only person who is interested in the trace wants to generate it himself. If a bug is not consistently reproducible, it is unfixable.

I don't agree. There may be other mitigating factors, such as the environment, which may have caused the bug. The bug reporter may be unaware of this fact and a trace would potentially help resolve this issue.

I know - they really push their "LimeWire Pro" so it might appear to be closed-source. But it's not - I started using it before they had "LimeWire Pro".
A trace works backwards from the error. It catches an error and works backward to find out what line and in which class. It may not tell the direct cause of the error, but it will tell what line of code caused the error.

If you're suggesting keeping a log of the program's every action. . . that could potentially slow things down quite a bit. And, from your description, it sounds like that's what bugzilla is doing.

Unless you're expecting the user to post their steps to reproduce the error, which, as I said before, is only helpful if the user both knows how to do this, and decides to do it. With an automatic trace, you already eliminate one of those prerequisites - now all the user has to do is tell you what error it spit out.

Or you might be able to make your program so that it'll automatically notify you of errors by sending you these bugtraces. That might sound hard to do, but I don't think it'd be too difficult - Java does have methods to catch at least certain types of errors, and I bet if you had one class (the "safety net") launch the other (the actual program), when the actual program crashes the "safety net" could retrieve the bugtraces it spits out, and then it could send them to you.

If a bug cannot be reproduced by a developer, it cannot be fixed. The *only* information a developer needs are consistent steps to reproduce. Think about it in terms of "Give a man a fish and he eats for a day. Teach a man to fish and he eats for a lifetime." Anything a program sends back would ultimately be not very useful. I also consider any program that calls home to be spyware.

Unless it asks you whether or not to let it call home. That's what LimeWire does when it has an error - it comes up with a dialog with the error and asks you whether or not to let it phone home and tell the developers.

I would like to stress very stongly that a backtrace is emphatically NOT the same as "step to reproduce", which is what you seem to be saying here.

Consider the following code:

Now, if some method e calls d then c and you can't determine the value of (n >= 7) from the calling context, the backtrace gives you no clue why the bug is produced.

If on the other hand, the user had said "I click on `increase n' seven times, then click `exhibit bug', then your program crashes. It also consistenly crashes if I click on it eight, nine or ten times, but not for four, five and six times. Here's a backtrace: (in c, called by e, called by ...)" you would have something to work with.

I'm with Vagrant on this. If you have a stand alone application that doesn't rely on any external software or environmental conditions to operate, steps to reproduce can be straightforward.

But in many cases, steps to reproduce are "Set up an office environment. Put together 3 servers with NT, XP, and 2003 server. Install Citrix Metaframe XP with the following service packs: ..... Use the following print applications. Buy and set up the following printers: .... Install an SAP application on the XP server. Use Cisco 910 switches for the entire office. Set up your Windows Domain with Active Directory and the following settings.... Okay, now when you use print program X through an RDP connection from machine Y to server Z, and run such and such batch file in the background, the HP Printer works fine but the Canon printer gets black lines on every page past the fifth."

I had problems like that at my last job, and until you've experienced it you can't imagine all the weird ways that software apps unintentionally interact with each other. That's true for a complex Unix/Linux environment as much as it is for Windows. Every single day we would have customers calling in with bugs that we could not reproduce in our home office. 75% of the time it was user error, but the other 25% of the time one of our developers would travel to their site and see the problem.

I'm not saying all of the features of the office environment contributed to the problem. It's likely that 99% are unrelated. But in many cases, you won't know which pieces are causing the problem and which are unrelated.

That's probably the most irrelevant analogy one could think of. It is not a necessity for the developer, herself, to reproduce the error. If one can look at a trace and discover the problem, especially if it is obviously an environmental issue. I agree that reproducibility has its place but you seem to be in some sort of strange idealist land. Its like developer Twilight Zone in which the only possible bugs to fix are ones which have detailed steps to reproduce.

I have to reproduce a bug in order to know whether or not I've fixed it. I have to reproduce it once as a control to know *exactly* what happened. The backtrace is not useful because it will be generated when I reproduce the bug. Analogy translated: "Give me a backtrace and I can know where it crashed. Give me steps to reproduce and I can know anything."

That wasn't what I meant.

What I meant is that the user has to write down the "steps to reproduce" if they want to tell you the steps they took to reproduce the error. But with a backtrace - even though it doesn't tell you how to reproduce the error - all the user has to do is send you the results and that'll at least tell you something. It might not be as good as the user telling you the steps to reproduce the error, but it's much easier for the user to do.
If you're the programmer, you should know how to test whether or not you fixed the bug. . .

In fact, a lot of times developers come up with "test data" they can enter. They run the program a few times, each time with different test data, knowing what the outcome of the program should be, and then if the test data doesn't produce the correct outcome, they can figure out what went wrong.

Are you suggesting that you don't understand your own code?

by reproducing it or not.

Test data and bugs are not the same. Test data are initial attempts to see whether it mostly works. Bugs are errata that you may or may not have caught in your initial testing. Clear box testing vs. Black box testing. In the former case, I have steps to reproduce cause I generate them myself. In the later, somebody else needs to provide them.

A lot of times, it isn't my code.