Linux-Advocacy Digest #350, Volume #30 Tue, 21 Nov 00 19:13:06 EST
Contents:
Re: Uptime -- where is NT? (Giuliano Colla)
Re: Another happy Linux user ([EMAIL PROTECTED])
Re: OT: Could someone explain C++ phobia in Linux? (Russ Lyttle)
Re: OT: Could someone explain C++ phobia in Linux? (The Ghost In The Machine)
Re: OT: Could someone explain C++ phobia in Linux? (Russ Lyttle)
Re: OT: Could someone explain C++ phobia in Linux? (The Ghost In The Machine)
Re: OT: Could someone explain C++ phobia in Linux? (The Ghost In The Machine)
Re: OT: Could someone explain C++ phobia in Linux? (The Ghost In The Machine)
Re: OT: Could someone explain C++ phobia in Linux? (Russ Lyttle)
Re: Linux for nitwits ("Clifford W. Racz")
Re: OT: Could someone explain C++ phobia in Linux? (Russ Lyttle)
yo ([EMAIL PROTECTED])
Re: OT: Could someone explain C++ phobia in Linux? (Russ Lyttle)
Re: OT: Could someone explain C++ phobia in Linux? (Russ Lyttle)
Re: OT: Could someone explain C++ phobia in Linux? (mlw)
Re: Of course, there is a down side... (Gary Hallock)
----------------------------------------------------------------------------
From: Giuliano Colla <[EMAIL PROTECTED]>
Crossposted-To: comp.os.os2.advocacy,alt.destroy.microsoft
Subject: Re: Uptime -- where is NT?
Date: Tue, 21 Nov 2000 23:13:29 GMT
"." wrote:
>
> > Unix had a 10 ms counter, and they judged that a range of
> > over one year and a half was enough, so they didn't bother.
> > MS roughly 30 years later had a 1 ms counter and didn't
> > bother either. Judging apparently that a range of one month
> > and a half was enough.
>
> You are, of course, making the assumption that MS did this deliberately.
> For all we know it could have been any kind of cockup... the same kind of
> cockup that produced 95 in the first place?
I have the bad habit of crediting MS people of some thinking
capabilities. Usually further evidence proves me wrong.
However I can't help trying to work out the rationale of how a thing is
done, because, except for MS case (which luckily for me is just an
annoying side issue), it helps a lot to figure out how it works, and
either exploit it at best, or fix it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Another happy Linux user
Reply-To: [EMAIL PROTECTED]
Date: Tue, 21 Nov 2000 23:13:46 GMT
The truth can sometimes be painful Frank.
BTW why didn't any of you Penguinista's complain when Jaques"le-foot"
the bare foot pirate (a linonut par excellance) kept posting Windows
user troubles for me to fix. Which I did.
claire
On Tue, 21 Nov 2000 22:54:18 +0100, "Frank Van Damme"
<[EMAIL PROTECTED]> wrote:
>CL,
>
>didn't _someone_ or maybe even more people draw your intention on the
>fact that ngs are not made to manually transfer the contents of one to
>another? This is the most idiot way of illustrating Linux' 'bad' quality.
>
>Try discussing broad topics instead of bombing these ng with junk. we
>know you aren't satisfied with Linux, others are. We know you just love
>Windows, I don't, so be it.
------------------------------
From: Russ Lyttle <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 23:20:39 GMT
mlw wrote:
>
> Russ Lyttle wrote:
> >
> > Donovan Rebbechi wrote:
> > >
> > > On Mon, 20 Nov 2000 12:17:52 -0500, mlw wrote:
> > > >Russ Lyttle wrote:
> > >
> > > >If one were to time the execution of the code, it is possible that the
> > > >C++ example will be faster because printf and its varients parse strings
> > > >one character at a time, where as iostreams will accept a string
> > > >parameter. Still, the end result is that the code snippet you present
> > > >has nothing to do with C++, but of different designs. There was no
> > > >reason one should have to code the C++ example any differently than the
> > > >C example.
> > >
> > > There's a bunch of other points the example doesn't address:
> > >
> > > (*) The iostreams do much more than printf. The difference would decrease
> > > somewhat if the C program used more of the functionality that iostreams
> > > and strings make trivial.
> > >
> > iostreams are C++. printf is C. You can't use iostreams in a C program
> > and you can't use printf in C++ program. You can use printf in a C
> > program disguised as a C++ program though.
>
> Where do you get that? printf is very much part of C++, if you think
> otherwise, you are very very confused.
>
Not really. Until recently you had to include <stdio.h>. Now it is
<cstdio.h>. Why do you think the new name has the "c" prefix? It
indicates that you are doing C style programming, not C++. This is,
IMHO, a bad feature of C++. The mixing of C style with C++ style is nice
for bringing up old C programmers, but it makes for bad code on real
projects.
> > .
> > > (*) The difference does not increase proportional to program size. In fact
> > > the fact that C++ has destructors and a bunch of useful functionality
> > > in the string and stream classes could result in less code that is
> > > "inlined-by-hand". In any case, it seems doubtful that the size
> > > difference in favour of C would outweigh the safety of iostreams
> > > in a nontrivial program (unless size is *extremely* critical)
> > >
> > Depends. In a kernel, the speed trade off is critical. In the TV
> > example, size is critical with speed a close second. In both, safety is
> > better in C due to tigher control over the compiler.
>
> Suffice to say, I have made mention of much C++ code I have done in
> kernel space. Often code can be tighter and more efficient with a
> virtual function than with a switch table. C++ can make more efficient
> code. For instance:
>
> switch(object->type)
> {
> case TYPE_PCIDMA:
> ...
> case TYPE_ISADMA:
> ...
> case TYPE_ISABUS:
> ...
> }
>
> vs
>
> DmaObject->HandleEvent(...)
>
> --
> http://www.mohawksoft.com
Care to post a little more of the overall code so I can check it out? If
you have a way of improving interupt handlers, I'm willing to learn.
68HC08, 68HC16, 8502 and similar targets would be nice. I don't have a
C++ compiler for the targets, so if you could post the *.s file
(assembly code) generated by your compiler for one of those, it would be
helpful.
--
Russ Lyttle, PE
<http://www.flash.net/~lyttlec>
Not Powered by ActiveX
------------------------------
From: [EMAIL PROTECTED] (The Ghost In The Machine)
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 23:21:31 GMT
In comp.os.linux.advocacy, mlw
<[EMAIL PROTECTED]>
wrote
on Thu, 16 Nov 2000 09:15:30 -0500
<[EMAIL PROTECTED]>:
>Donovan Rebbechi wrote:
>>
>> On 16 Nov 2000 10:04:05 +0200, Michael Livshin wrote:
>> >[EMAIL PROTECTED] (Donovan Rebbechi) writes:
>> >
>>
>> >it depends on what you consider the issue. if your issue is "but C++
>> >is better than C" then sure.
>>
>> Fair enough. I understand your "issue" now.
>>
>> Your points about lacking memory management are well taken, and I agree that
>> there are certainly advantages to using a GC language. However, there are
>> issues including performance, and toolkit availability. THese are the
>> main two reasons why I use it. If performance wasn't an issue, I'd move
>> to python or possibly java at the drop of a hat.
>
>Maybe I'm just old school here, if I don't have a full understanding
>about how the code I write translates to actual machine instructions, I
>find it difficult to work in the environment.
>
>For instance:
>
>for(int i=0; i < 100; i++)
> ;
Just to make things interesting... :-)
Try this example.
class Int
{
public:
Int();
Int(int);
Int(Int const &);
~Int();
Int& operator++();
Int& operator++(int);
Int& operator=(Int const &);
bool operator<(int) const;
/* ... */
};
for(Int i=0; i<100; i++)
;
:-) :-) :-)
[rest snipped, although I do agree with the notion that kids don't
understand assembly, having never seen it; of course there is the issue
that old time assembly ran with clock speeds <= 1 Mhz.. :-) ]
--
[EMAIL PROTECTED] -- insert random misquote here
------------------------------
From: Russ Lyttle <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 23:30:15 GMT
mlw wrote:
>
> Russ Lyttle wrote:
> >
> > mlw wrote:
> > >
> > > Russ Lyttle wrote:
> > > >
> > > > Andy Newman wrote:
> > > > >
> > > > > mlw wrote:
> > > > > >Show me, for instance, some sort of object oriented technique in C that
> > > > > >can't be written better in C++.
> > > > >
> > > > > There very likely isn't one as C++ directly supports the programming
> > > > > constructs whereas C only allows their implementation (and with enough
> > > > > discipline, adherence to convention and some macros to hide things you
> > > > > can make it work reasonably well but it's no replacement for direct support).
> > > >
> > > > What you say is true and correct. The only reason for using OOP in C is
> > > > to gain some of the benefits of OOP without the penalties of C++.
> > >
> > > You keep saying this, but have failed to show a single one.
> > >
> > > >You
> > > > trade programming ease for runtime speed/size.
> > >
> > > Show me one instance where an OOP design in C would take up less memory
> > > than in C.
> > >
> > Didn't I just give you one? Wasn't your only response to propose an
> > non-oop C as C++ alternative?
>
> No, you gave me an OOP (a bad one) example compared to a procedural C
> example. When equivilents are compared, C++ wins.
>
So? Want to compare procedural C++ with procedural C? OOP with
procedural? If the program is to be procedural why use C++ at all? The
fact is that, in general, procedural languages/designs produce faster
tighter code than OOP languages/designs. There are advantages to OOP.
Run time speed and size aren't included.
> >
> > > > OOP in C isn't easy. If
> > > > you *need* strong OOP and can sacrifice a bit of runtime speed and code
> > > > size, use C++.
> > >
> > > Again, there is NO runtime speed loss for the simplicity of C++, plus
> > > code size is an interesting aspect which you probably have wrong.
> > >
> >
> > > struct _bogus
> > > {
> > > void (*function)(struct _bogus *, ...);
> > > };
> > >
> > > vs
> > >
> > > class sweet
> > > {
> > > protected:
> > > void function(...);
> > > };
> > >
> > > The C++ class call will actuall cost an extra (on a pentium) one extra
> > > "mov" instruction to get the vtable pointer, but the C structure will
> > > have an extra 32 bits for each function for each instance of the class.
> > >
> > > If you have 10,000 instances of struct _bogus, that is an overhead of
> > > 320,000 bytes per function. Where as one static read-only instance of
> > > the vtable is created for the C++ class. So C++ will be more efficient
> > > with memory.
> > >
> > > However, if you use a vtable sort of thing for bogus, as:
> > >
> > > struct _bogus;
> > >
> > > struct _bogus_vtable
> > > {
> > > void (*function)(struct _bogus *, ...);
> > > };
> > >
> > > struct _bogus
> > > {
> > > _bogus_vtable *vtable;
> > > ...
> > > };
> > >
> > > struct _bogus *b = CreateBogus(...);
> > >
> > > b->vtable->function(b,...);
> > >
> > > Then you have that extra "mov" instruction, and all the crap of trying
> > > to do it in C.
> > >
> > > >Then you would gain lots of programmer productivity. I
> > > > would prefer Ada, but thats me.
> > > > That is the point that started this thread. Kernel programmers don't
> > > > have a phobia about C++. It just isn't the right tool for that job.
> > >
> > > But, as it has been exampled, there is no speed penalty for using C++
> > > (and proper OOP design in C++ can be much faster and easier to maintain
> > > than in C). So oop in C is pointless. And that is the point of this
> > > thread.
> > >
> > > And BTW I am a kernel guy, I have written drivers for a few operating
> > > systems, including Windows 9x and NT as well as Linux. C++ is actually a
> > > very good way to develop NT drivers becuase it is inherently object
> > > oriented. I have a library of things like IRQ and DMA objects which
> > > abstrct the differences between NT and 98 interrupts, ISA DMA, ISA DMA
> > > bus mastering, and PCI bus mastering.
> > >
> > > >
> > > > --
> > > > Russ Lyttle, PE
> > > > <http://www.flash.net/~lyttlec>
> > > > Not Powered by ActiveX
> > >
> > > --
> > > http://www.mohawksoft.com
> >
> > --
> > Russ Lyttle, PE
> > <http://www.flash.net/~lyttlec>
> > Not Powered by ActiveX
>
> --
> http://www.mohawksoft.com
--
Russ Lyttle, PE
<http://www.flash.net/~lyttlec>
Not Powered by ActiveX
------------------------------
From: [EMAIL PROTECTED] (The Ghost In The Machine)
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 23:32:15 GMT
In comp.os.linux.advocacy, Erik Funkenbusch
<[EMAIL PROTECTED]>
wrote
on Mon, 20 Nov 2000 01:03:06 -0600
<p%3S5.9185$[EMAIL PROTECTED]>:
>"The Ghost In The Machine" <[EMAIL PROTECTED]> wrote in
>message
>> I think part of the problem is bad implementations of C++ in other
>> systems; for example, Microsoft has the interesting notion of
>> putting the VTBL pointer at the *top* of the root class, rather than
>> at the bottom. I don't know what does to multiple inheritance and
>> memory layout issues, but it's just -- different. (If one uses
>> pure virtual base classes, it doesn't make much difference, I
>> would think.) I've also caught Microsoft VC++ in at least one
>> strange memory corruption bug, although I forget the details now.
>
>Virtually every windows compiler also implements their vtbl at the top.
>But, this is language dependant.
Or maybe OS dependent. I dunno; as long as it works, it's probably
not a big issue unless someone's trying to get *real* funky.
>
>> There are also some not-so-pretty issues regarding STL on Microsoft.
>> I think Microsoft C++ is the only one where one has to use
>> 'std::map', 'std::vector', etc., whereas everyone else is more
>> or less sensible -- although part of that sensibility is because G++
>> didn't get around to implementing namespaces until rather recently. :-)
>
>You're complaining because VC++ follows the standard in this regard?
Heh...you're probably right! And yet...I've not seen too many
other compilers require the 'std::' prefix everywhere.
It's a pain to have to type that in, although it does make
the namespace slightly cleaner. (I suspect it makes the
identifiers for the linker slightly longer, though - and it's
already bad enough that VC++ complains about truncating things
at 255 characters whenever I even *think* about using STL. :-/ )
>
>And MSC is not the only compiler that requires this. Borland C++,
>MetroWerks, etc... all do.
>
>> (Side point: Microsoft's C++ implementation of ostrstring sucks eggs:
>> O(N^2) time problem because of the way it allocates memory. I've
>> seen this in no other system, and it's had me do some ugly workarounds.)
>
>strstring is deprecated. stringstream is the standard object.
Whoops, typo. I meant ostrSTREAM. But I think that's deprecated also
(replaced by osstream? ostringstream?) I'd have to look.
>
>> And then there are the operator overloads, requiring one to think
>> as to what it really means when one writes a + b. Not quite
>> as bad as C#, perhaps ('a.x = 1' can be translated into a
>> function call?) but it can get confusing if a and b have many
>> casts, subclasses, superclasses, or what not.
>
>Borland does this as well. C# was designed by Anders Hejlsberg who also
>designed Delphi.
>
I haven't used either Delphi or C#, so I wouldn't know.
>> One other issue involves virtuals. A poorly designed system with
>> many virtuals might start doing very odd things, as a derived class
>> might be doing something in its implementation that the base class
>> never expected, or it forgot to call its base class prior to doing
>> its thing, or it's skipping a class calling its grandfather
>> (I've seen that in at least one project!), and so on.
>> There are also issues regarding assignment operators and copy
>> constructors; if done right, they work well, but if not, well,
>> they don't. :-)
>
>Kind of like memory management in C ;)
Which is also a bit of a pain, admittedly.
struct duh { char *p ; };
struct duh a;
struct duh b;
a.p = malloc(6); strcpy(a.p, "Hello");
b = a;
free(a.p);
uh oh...
--
[EMAIL PROTECTED] -- insert random misquote here
------------------------------
From: [EMAIL PROTECTED] (The Ghost In The Machine)
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 23:34:51 GMT
In comp.os.linux.advocacy, Donovan Rebbechi
<[EMAIL PROTECTED]>
wrote
on 20 Nov 2000 17:16:53 GMT
<[EMAIL PROTECTED]>:
>On Mon, 20 Nov 2000 01:30:48 GMT, The Ghost In The Machine wrote:
>
>>There are also some not-so-pretty issues regarding STL on Microsoft.
>>I think Microsoft C++ is the only one where one has to use
>>'std::map', 'std::vector', etc., whereas everyone else is more
>>or less sensible --
>
>Wrong. The way VC++ (and practically every other compiler) does this
>is right. g++ does it wrong. This is very annoying because it makes
>it easy to write nonportable code in g++.
Indeed.
>
>Get yourself an up-to-date reference (like Stroustrup's latest)
>
>> although part of that sensibility is because G++
>>didn't get around to implementing namespaces until rather recently. :-)
>
>And they still haven't got around to conforming to the standard wrt the
>standard namespace.
Pity.
>
>>(Side point: Microsoft's C++ implementation of ostrstring sucks eggs:
>>O(N^2) time problem because of the way it allocates memory. I've
>>seen this in no other system, and it's had me do some ugly workarounds.)
>
>If you're talking about ostrstream (there's no ostrstring), it's obsolete.
Yep, typo on my part.
>
>ostringstream (int the <sstream> header) should be used instead. This is
>another flaw in g++ (which doesn't ship this header, though you can download
>it)
Not sure if this is a flaw in g++ or libstdc++.
(ObGNU: at least I have a chance at fixing it, since it's Open Source. :-) )
>
>--
>Donovan Rebbechi * http://pegasus.rutgers.edu/~elflord/ *
>elflord at panix dot com
--
[EMAIL PROTECTED] -- insert random misquote here
------------------------------
From: [EMAIL PROTECTED] (The Ghost In The Machine)
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 23:36:36 GMT
In comp.os.linux.advocacy, Donovan Rebbechi
<[EMAIL PROTECTED]>
wrote
on 21 Nov 2000 15:44:05 GMT
<[EMAIL PROTECTED]>:
>On Tue, 21 Nov 2000 03:54:10 -0600, Erik Funkenbusch wrote:
>>While I agree with you, that's actually a bit unfair. cout.write() is
>>equivelant to puts() rather than printf().
>
>Just tried it using puts(), and write(). It's still slower than
>cout.write() on my system.
Bizarre.
Is (FILE *) stdout unbuffered for some reason?
>
>--
>Donovan Rebbechi * http://pegasus.rutgers.edu/~elflord/ *
>elflord at panix dot com
--
[EMAIL PROTECTED] -- insert random misquote here
------------------------------
From: Russ Lyttle <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 23:37:12 GMT
mlw wrote:
>
> Russ Lyttle wrote:
> >
>
> >
> > If you think writing a kernel in C++ is easy why don't you do it? Even a
> > simple version of something like Micro-C OS would be a valuable
> > contribution to the community if you made it.
> > > --
>
> I actually published an article on just that for Keithly Metrabyte
> several years ago. It was about how to design kernel drivers for Windows
> NT and Windows 98 using the same source, and C++ classes to abstruct
> things like DMA, bus mastering, IRQs, etc. The source is (AFAIK) still
> being used at Keithley, and probably still available on the web.a
> --
> http://www.mohawksoft.com
I didn't say write a driver for NT, I said write an OS! Big differnce.
Micro-C/OS is pretty simple. Much simpler than Linux. It should be
pretty simple to do the class diagram, use cases, and time lines.
--
Russ Lyttle, PE
<http://www.flash.net/~lyttlec>
Not Powered by ActiveX
------------------------------
From: "Clifford W. Racz" <[EMAIL PROTECTED]>
Subject: Re: Linux for nitwits
Date: Tue, 21 Nov 2000 18:37:49 -0500
> First, I too am a Linux nitwit, but unfortunately
> your solution to install Linux on your laptop is
> already supported by Windows 9x. "Direct Cable
> Connection" uses the parallel port to directly
> connect computers together in Windows, thereby
> allowing the same procedure to work in Windows as
> it did in Linux.
A "direct cable connection" is the biggest PITA I have ever dealt with wrt
Windows. I have yet to get 1 to work. I would rather use Linux than rely
on that.
------------------------------
From: Russ Lyttle <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 23:44:24 GMT
Erik Funkenbusch wrote:
>
> "Russ Lyttle" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > But if you write the C++ code like the C code, then you aren't writing
> > C++ code, but C code, so why do C++ or use a C++ compiler? The sample
> > posted was selected to be simple and use "true" C++ and C. Your logic is
> > common : "Post samples", "But you could do that aother way". Any real
> > program is simply to big to post (I don't think the group would like 2
> > files of several meg each attached). So read it an weap : The C++
> > program, a proper C++ program, not a C program in C++ disguise is bigger
> > and slower.
>
> Since C++ includes the majority of the C language, writing code that
> compiles under a c++ compiler *IS* c++, even if it also might be C. There
> are some subtle difference between the same program compiled under C and C++
> though.
>
OK, So why should I call it C++ if it is only C?
> Additionally, you've not posted any timings for the executed code.
I deliberately did not post timing data. Everyone in this group should
have a C and a C++ compiler to use for compairson on their system. That
way we don't get into "my AMD is better than your Pentium" arguments.
Use your own system for timing tests.
--
Russ Lyttle, PE
<http://www.flash.net/~lyttlec>
Not Powered by ActiveX
------------------------------
Subject: yo
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Tue, 21 Nov 2000 23:48:35 GMT
i like linux
------------------------------
From: Russ Lyttle <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 23:49:43 GMT
Erik Funkenbusch wrote:
>
> Jim Richardson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > >I haven't run your code yet. That will be delayed for a bit. But the
> > >point is whether on something as complex and time critical as an OS
> > >kernel, C++ (or even OOP) will perform satisfactorily. Take a look at
> > >Jean Labrosse's "Micro-C/OS" and see if you can implement it as a C++
> > >design that runs faster. That is a fairly simple kernel. The final
> > >project should run on a 68HC08 in 16k ROM.
> > >--
> >
> > Isn't BeOS written in C++ ?
>
> At least the API is. I suspect the kernel also is very OO, since the device
> drivers are also written in C++.
Those questions would be intersting to answer. API and device drivers
are separate issues from the kernel code. If they wrote the kernel in
C++, how did they build it? Certainly not with VC++! Unix bootstrapped
itself first off of B then C. i.e. a little B, then a little Unix than a
little C then a little more Unix...
Linux started with crossplatform gcc.
--
Russ Lyttle, PE
<http://www.flash.net/~lyttlec>
Not Powered by ActiveX
------------------------------
From: Russ Lyttle <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 23:57:13 GMT
Erik Funkenbusch wrote:
>
> "Russ Lyttle" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > > That's because you don't know what you're doing.
> > >
> > > http://support.microsoft.com/support/kb/articles/Q156/5/13.asp
>
> > I won't tell that to my customer because I don't want him to take his
> > millions and go home. Everything that is part of a build gets checked in
> > and controlled. MS may think that there is no need to put the
> > autogenerated files under source control, but they aren't paying me to
> > develop software. We even have to save the compiler used to make the
> > build!
>
> You're a moron then.
I'm the one with the 8 figure contract. I only do this in case I can
pass on something useful to someone else.
>Do you save the temp files generated by the compiler
> in the Temp directory as well? That's what these are. Hell, the temp files
> are even more relavant than the ones listed in the knowledge base article
> because the temp files are actually generated code, while the the
> autogenerated files are things to do with Intellisense and the class
> browser.
>
What can I say. The customer only permitted VC++ under those conditions.
Besides, I can't do any trouble shooting/ modifications if the class
browser isn't working. At least it becomes difficult..
> In other words, they have nothing to do with either the code generated, or
> the source code in any way. They're to do with the IDE as temp files.
The project won't build without them. If a version 3.0 is released, then
it is required to build a new version 3.0 with exactly the same code,
i.e. diff returns no differences!
--
Russ Lyttle, PE
<http://www.flash.net/~lyttlec>
Not Powered by ActiveX
------------------------------
From: mlw <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Tue, 21 Nov 2000 19:03:29 -0500
The Ghost In The Machine wrote:
>
> In comp.os.linux.advocacy, mlw
> <[EMAIL PROTECTED]>
> wrote
> on Thu, 16 Nov 2000 09:15:30 -0500
> <[EMAIL PROTECTED]>:
> >Donovan Rebbechi wrote:
> >>
> >> On 16 Nov 2000 10:04:05 +0200, Michael Livshin wrote:
> >> >[EMAIL PROTECTED] (Donovan Rebbechi) writes:
> >> >
> >>
> >> >it depends on what you consider the issue. if your issue is "but C++
> >> >is better than C" then sure.
> >>
> >> Fair enough. I understand your "issue" now.
> >>
> >> Your points about lacking memory management are well taken, and I agree that
> >> there are certainly advantages to using a GC language. However, there are
> >> issues including performance, and toolkit availability. THese are the
> >> main two reasons why I use it. If performance wasn't an issue, I'd move
> >> to python or possibly java at the drop of a hat.
> >
> >Maybe I'm just old school here, if I don't have a full understanding
> >about how the code I write translates to actual machine instructions, I
> >find it difficult to work in the environment.
> >
> >For instance:
> >
> >for(int i=0; i < 100; i++)
> > ;
>
> Just to make things interesting... :-)
>
> Try this example.
>
> class Int
> {
> public:
> Int();
> Int(int);
> Int(Int const &);
> ~Int();
> Int& operator++();
> Int& operator++(int);
> Int& operator=(Int const &);
> bool operator<(int) const;
> /* ... */
> };
>
> for(Int i=0; i<100; i++)
> ;
>
> :-) :-) :-)
>
> [rest snipped, although I do agree with the notion that kids don't
> understand assembly, having never seen it; of course there is the issue
> that old time assembly ran with clock speeds <= 1 Mhz.. :-) ]
Well, the above is one of my problems with C++. C++ is by no means
perfect, but like sharp knives and chain saws, care must be used. I
would rather have a sharp ax and have to be careful, than to try to cut
down a tree with a butter knife. Overloading operators, while a neat
thing, and useful at times, seems like one of those very sharp knives
that must be used with care.
I generally have a problem with people that point to a misuse of a
powerful feature and disparage the environment for providing it. I would
rather have a powerful environment which requires skill and care, than a
straight jacket to protect me from myself.
I guess when all is said and done in this thread, it comes down to that.
I am smart enough to write code and make a prudent use of an
environment's features. Others seem to think features which can be
misused make a bad environment.
>
> --
> [EMAIL PROTECTED] -- insert random misquote here
--
http://www.mohawksoft.com
------------------------------
Date: Tue, 21 Nov 2000 19:00:42 -0500
From: Gary Hallock <[EMAIL PROTECTED]>
Subject: Re: Of course, there is a down side...
[EMAIL PROTECTED] wrote:
>
>
> It made me ill just trying to find all the different keys on the
> keyboard.
You seem to have no problem finding all of the keys to post to c.o.l.a.
Gary
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
