* Re: Java vs. Eiffel vs. C++ in realtime applications [not found] ` <34131554.73F2310E@roda.roc.servtech.com> @ 1997-09-09 0:00 ` James Yang 1997-09-11 0:00 ` Robert Dewar [not found] ` <34157696.16620299@nntp.interaccess.com> 1 sibling, 1 reply; 31+ messages in thread From: James Yang @ 1997-09-09 0:00 UTC (permalink / raw) In article <34131554.73F2310E@roda.roc.servtech.com>, Mike Roda <mike@roda.roc.servtech.com> wrote: >I would say C++ would have the edge right now for performance reasons >even though Sun is coming out with some real-time extensions I think. > >You gotta be kidding about fortran! As the oldest high-level language >in existance, it is archaic, primitive, and hard to find people who want >to touch it anymore. > >And Ada is a overloaded school bus that nobody would have ever used if >it weren't for the DOD pushing it on everyone. Get real. > Mike, Your statement about Ada tells us you know nothing about Task and concurrent programming in Ada. I hope the people who use Ada would share some lights for you. Comp.Lang.Ada added to the following thread. James -- My employer and I work together in the office. Nevertheless, we never speak on each other's behalf in term of political issues. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Java vs. Eiffel vs. C++ in realtime applications 1997-09-09 0:00 ` Java vs. Eiffel vs. C++ in realtime applications James Yang @ 1997-09-11 0:00 ` Robert Dewar 1997-09-11 0:00 ` Ralph Paul 0 siblings, 1 reply; 31+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) Mike Roda (who I assume is a current or recent product of CS education says) <<Mike Roda <mike@roda.roc.servtech.com> wrote: >I would say C++ would have the edge right now for performance reasons >even though Sun is coming out with some real-time extensions I think. > >You gotta be kidding about fortran! As the oldest high-level language >in existance, it is archaic, primitive, and hard to find people who want >to touch it anymore. > >And Ada is a overloaded school bus that nobody would have ever used if >it weren't for the DOD pushing it on everyone. Get real.>> The Ada nonsense is not unexpected, there are far too many faculty members around who know nothing about Ada spouting such junk. But the Fortran nonsense is surprising. Are we really teaching out students these kind of silly attitudes and misinformation? I must say, the idea that French defence companies are using Ada because the US DoD is pushing it on them is most amusing -- *most* amusing :-) :-) (not to mention outfits like Reuters in London, or ....) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Java vs. Eiffel vs. C++ in realtime applications 1997-09-11 0:00 ` Robert Dewar @ 1997-09-11 0:00 ` Ralph Paul 0 siblings, 0 replies; 31+ messages in thread From: Ralph Paul @ 1997-09-11 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Mike Roda (who I assume is a current or recent product of CS education says) > > <<Mike Roda <mike@roda.roc.servtech.com> wrote: > >I would say C++ would have the edge right now for performance reasons > >even though Sun is coming out with some real-time extensions I think. > > > >You gotta be kidding about fortran! As the oldest high-level language > >in existance, it is archaic, primitive, and hard to find people who want > >to touch it anymore. > > > >And Ada is a overloaded school bus that nobody would have ever used if > >it weren't for the DOD pushing it on everyone. Get real.>> > > The Ada nonsense is not unexpected, there are far too many faculty members > around who know nothing about Ada spouting such junk. But the Fortran > nonsense is surprising. Are we really teaching out students these kind > of silly attitudes and misinformation? > > I must say, the idea that French defence companies are using Ada because > the US DoD is pushing it on them is most amusing -- *most* amusing :-) :-) > (not to mention outfits like Reuters in London, or ....) I think the Russians also started using Ada (:-) during the cold war. I am certain fairly that they really didn't care about the US DoD mandate. But then again C++ and Java are going to safe the day anytime now (:-). At least that's what Sun, Microsoft have been promising us for 1.5 years (:-) . ( Oh, last but not least let's just shove all those Fortran code out the door. You would be surprised how few engineering companies/shops would still be able to operate without them. (:-) ) Sorry couldn't resist this guys uninformed comments . Regards, Ralph Paul ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <34157696.16620299@nntp.interaccess.com>]
[parent not found: <JTV2J.97Sep9170655@cobra.cs.virginia.edu>]
[parent not found: <3415CE44.3BD531@calfp.co.uk>]
[parent not found: <341644F2.763D@BZZvnet.ibm.com>]
* Re: Java vs. Eiffel vs. C++ in realtime applications [not found] ` <341644F2.763D@BZZvnet.ibm.com> @ 1997-09-11 0:00 ` Mike Rubenstein 1997-09-11 0:00 ` Fergus Henderson 1997-09-11 0:00 ` Volker Hetzer [not found] ` <199709110220.VAA24841@manifold.algebra.com> ` (4 subsequent siblings) 5 siblings, 2 replies; 31+ messages in thread From: Mike Rubenstein @ 1997-09-11 0:00 UTC (permalink / raw) "Igor Chudov @ home" <ichudov@algebra.com> wrote: > > Brian Thomson <thomson@vnet.ibm.com> wrote: > * Nick Leaton wrote: > * > John Viega wrote: > * > > Anyway, I know tons of mechanical engineers and other types of > * > > engineers, and I can tell you that Fortran is still considered by many > * > > people to be the only appropriate language for much of the work that > * > > they do. > * > > * > But then, one always wonders how much experience most of them have with > * > some of the better alternatives that are available. > * > > * > * Nick, John was right that the FORTRAN language has properties that > * enable it to perform better than C++ in certain situations. This is > * particularly true for programs that manipulate large matrices, which is > * a significant piece of what scientific programming is about. > > Thank you for your interesting comments, Brian. I would like to argue > that while it is easy to write inefficient code in C++, it is also > possible to write code as efficient as in Fortran. > > An example follows below. > > * If I write a subroutine to manipulate matrices, its parameters in > * C or C++ will probably be pointers to double. In FORTRAN they would be > * double precision arrays. > > That is not completely informative because internally, parameters of > FORTRAN subroutines are passed by pointer also. So both in C++ and fortran > we deal with pointers. > > * The FORTRAN language specifies that if one of > * those arrays is modified by the subroutine, it may not overlap any of > * the other arguments or global data. In compiler-speak it is > * guaranteed not to be "aliased" with anything else used in the > * subroutine. > * > * This property may not sound like much, but it allows FORTRAN > * optimizers to optimize more fully than is possible in C/C++. > * Eg. if I write > * C[I] = A[I] + B[I] > * D[I] = A[I] - B[I] > > Well, C++ has a good recipe to deal with this important problem. In > C++, you can declare A and B to be "const" pointers to double and that > would tell the compiler that A[i] abd B[i] can be reused after assigning > C[I]. > > Like this: > > void foo( double * C, double * D, > const double * A, const double * B, > int N ) > { > for( int I = 0; I < N; I++ ) > { > C[I] = A[I] + B[I]; > D[I] = A[I] - B[I]; > } > } Only if the compiler is broken. Declaring A and B const does not tell the compiler that the values cannot change -- it tells it that it cannot change using that pointer, unless the pointer is cast to a pointer to nonconst. In particular, the compiler may not assume that C is different from A. It would be legal to call this function as double x[2] = { 1.0, 2.0 }; foo(x, x, x, x, 2); Michael M Rubenstein ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Java vs. Eiffel vs. C++ in realtime applications 1997-09-11 0:00 ` Mike Rubenstein @ 1997-09-11 0:00 ` Fergus Henderson 1997-09-11 0:00 ` Volker Hetzer 1 sibling, 0 replies; 31+ messages in thread From: Fergus Henderson @ 1997-09-11 0:00 UTC (permalink / raw) miker3@ix.netcom.com (Mike Rubenstein) writes: >"Igor Chudov @ home" <ichudov@algebra.com> wrote: > >> Brian Thomson <thomson@vnet.ibm.com> wrote: >> * The FORTRAN language specifies that if one of >> * those arrays is modified by the subroutine, it may not overlap any of >> * the other arguments or global data. In compiler-speak it is >> * guaranteed not to be "aliased" with anything else used in the >> * subroutine. >> * >> * This property may not sound like much, but it allows FORTRAN >> * optimizers to optimize more fully than is possible in C/C++. ... >> Well, C++ has a good recipe to deal with this important problem. In >> C++, you can declare A and B to be "const" pointers to double and that >> would tell the compiler that A[i] and B[i] can be reused after assigning >> C[I]. > >Only if the compiler is broken. Declaring A and B const does not tell >the compiler that the values cannot change -- it tells it that it >cannot change using that pointer, unless the pointer is cast to a >pointer to nonconst. Yes, `const' doesn't promise that things won't be aliased. The next revision of the C standard, C9X, will have a new keyword "restrict" for that purpose, although it will probably be at least a few years before many C or C++ compilers really support it. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Java vs. Eiffel vs. C++ in realtime applications 1997-09-11 0:00 ` Mike Rubenstein 1997-09-11 0:00 ` Fergus Henderson @ 1997-09-11 0:00 ` Volker Hetzer 1997-09-11 0:00 ` Mike Rubenstein 1 sibling, 1 reply; 31+ messages in thread From: Volker Hetzer @ 1997-09-11 0:00 UTC (permalink / raw) Mike Rubenstein wrote: > > "Igor Chudov @ home" <ichudov@algebra.com> wrote: > > > > > Brian Thomson <thomson@vnet.ibm.com> wrote: > > Like this: > > > > void foo( double * C, double * D, > > const double * A, const double * B, > > int N ) > > { > > for( int I = 0; I < N; I++ ) > > { > > C[I] = A[I] + B[I]; > > D[I] = A[I] - B[I]; > > } > > } > > Only if the compiler is broken. Declaring A and B const does not tell > the compiler that the values cannot change -- it tells it that it > cannot change using that pointer, unless the pointer is cast to a > pointer to nonconst. What about void foo(vect<double> &C, vect<double> &D, const vect<double> &A, const vect<double>&B) ? Volker ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Java vs. Eiffel vs. C++ in realtime applications 1997-09-11 0:00 ` Volker Hetzer @ 1997-09-11 0:00 ` Mike Rubenstein 0 siblings, 0 replies; 31+ messages in thread From: Mike Rubenstein @ 1997-09-11 0:00 UTC (permalink / raw) Volker Hetzer <hetzer.abg@sni.de> wrote: > > Mike Rubenstein wrote: > > > > "Igor Chudov @ home" <ichudov@algebra.com> wrote: > > > > > > > > Brian Thomson <thomson@vnet.ibm.com> wrote: > > > Like this: > > > > > > void foo( double * C, double * D, > > > const double * A, const double * B, > > > int N ) > > > { > > > for( int I = 0; I < N; I++ ) > > > { > > > C[I] = A[I] + B[I]; > > > D[I] = A[I] - B[I]; > > > } > > > } > > > > Only if the compiler is broken. Declaring A and B const does not tell > > the compiler that the values cannot change -- it tells it that it > > cannot change using that pointer, unless the pointer is cast to a > > pointer to nonconst. > What about > void foo(vect<double> &C, vect<double> &D, > const vect<double> &A, > const vect<double>&B) ? I don't know what vect is, so I'll assume you mean vector. I don't see how that is any different. The const still doesn't guarantee that A or B won't be changed -- only that they won't be changed using that reference. At least I cannot find anything in the draft that would preclude calling such a function with vector<double> x; // ... foo(x, x, x, x); Michael M Rubenstein ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <199709110220.VAA24841@manifold.algebra.com>]
* Re: Java vs. Eiffel vs. C++ in realtime applications [not found] ` <199709110220.VAA24841@manifold.algebra.com> @ 1997-09-11 0:00 ` Mike Rubenstein 1997-09-12 0:00 ` Valentin Bonnard 1 sibling, 0 replies; 31+ messages in thread From: Mike Rubenstein @ 1997-09-11 0:00 UTC (permalink / raw) [Moderator's note: This article is crossposted to many groups. I have added a Followup-to line directing followups to go by default to comp.std.c++ only. If you respond to this article, you should think about what group(s) your response is appropriate for. mha] "Igor Chudov @ home" <ichudov@algebra.com> wrote: > [to comp.std.c++ readers: please correct me if I am mistaken. Thanks - Igor] > > miker3@ix.netcom.com (Mike Rubenstein) wrote: > * "Igor Chudov @ home" <ichudov@algebra.com> wrote: > * > * The FORTRAN language specifies that if one of > * > * those arrays is modified by the subroutine, it may not overlap any of > * > * the other arguments or global data. In compiler-speak it is > * > * guaranteed not to be "aliased" with anything else used in the > * > * subroutine. > * > * > * > * This property may not sound like much, but it allows FORTRAN > * > * optimizers to optimize more fully than is possible in C/C++. > * > * Eg. if I write > * > * C[I] = A[I] + B[I] > * > * D[I] = A[I] - B[I] > * > > * > Well, C++ has a good recipe to deal with this important problem. In > * > C++, you can declare A and B to be "const" pointers to double and that > * > would tell the compiler that A[i] abd B[i] can be reused after assigning > * > C[I]. > * > > * > Like this: > * > > * > void foo( double * C, double * D, > * > const double * A, const double * B, > * > int N ) > * > { > * > for( int I = 0; I < N; I++ ) > * > { > * > C[I] = A[I] + B[I]; > * > D[I] = A[I] - B[I]; > * > } > * > } > * > * Only if the compiler is broken. Declaring A and B const does not tell > * the compiler that the values cannot change -- it tells it that it > * cannot change using that pointer, unless the pointer is cast to a > * pointer to nonconst. > * > * In particular, the compiler may not assume that C is different from A. > * It would be legal to call this function as > * > * double x[2] = { 1.0, 2.0 }; > * foo(x, x, x, x, 2); > > I disagree with your statement. The compiler is free to optimize > accesses to objects through const references, and is free to assume that > the referenced contents do not change. The following provision of the > C++ Standard Draft (http://www.setech.com/c++access.html) specifically > addresses this issue: > > Draft> 3 A pointer or reference to a cv-qualified type need not actually point > Draft> or refer to a cv-qualified object, but it is treated as if it does; a > Draft> const-qualified access path cannot be used to modify an object even if > Draft> the object referenced is a non-const object and can be modified > Draft> through some other access path. [Note: cv-qualifiers are supported by > Draft> the type system so that they cannot be subverted without casting > Draft> (_expr.const.cast_). ] > Draft> > Draft> 4 Except that any class member declared mutable (_dcl.stc_) can be modi- > Draft> fied, any attempt to modify a const object during its lifetime > Draft> (_basic.life_) results in undefined behavior. > Draft> > Draft> 5 [Example: > Draft> > Draft> _________________________ > Draft> 76) There is no special provision for a decl-specifier-seq that lacks > Draft> a type-specifier or that has a type-specifier that only specifies cv- > Draft> qualifiers. The "implicit int" rule of C is no longer supported. > Draft> > Draft> const int ci = 3; // cv-qualified (initialized as required) > Draft> ci = 4; // ill-formed: attempt to modify const > Draft> int i = 2; // not cv-qualified > Draft> const int* cip; // pointer to const int > Draft> cip = &i; // okay: cv-qualified access path to unqualified > Draft> *cip = 4; // ill-formed: attempt to modify through ptr to const > Draft> int* ip; > Draft> ip = const_cast<int*>(cip); // cast needed to convert const int* to int* > Draft> *ip = 4; // defined: *ip points to i, a non-const object > Draft> const int* ciq = new const int (3); // initialized as required > Draft> int* iq = const_cast<int*>(ciq); // cast required > Draft> *iq = 4; // undefined: modifies a const object > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Look here > > The last line of the example shows us that we should not expect that > modifications of const objects through non-const access paths would > correctly change them. > > To be sure of that *iq changes, we'd have to use a "volatile" qualifier > to define ciq > > const volatile int * ciq = ... ... ... OK. You are mistaken. Note that 3. specifically says a const-qualified access path cannot be used to modify an object even if the object referenced is a non-const object and can be modified through some other access path. That says you can't change the object using the const pointer, but you can change it through a different one ("through some other access path"). Look at the example again. It shows a case in which an object that is referenced by a const pointer is changed: // ... int i = 2; // not cv-qualified const int* cip; // pointer to const int cip = &i; // okay: cv-qualified access path to // unqualified // ... int* ip; ip = const_cast<int*>(cip); // cast needed to convert const // int* to int* *ip = 4; // defined: *ip points to i, a non-const // object cip is a pointer to const, but the object it points to has been changed. Whether an object is const is determined by its definition, not by the declaration of a pointer that is used to access it. If an object is defined as const, the compiler may assume that it will not change, even if you access it through a pointer to non-const. If an object is not defined as const, the compiler may not assume that it will not change, even if you access it through a pointer to const. Obviously, in the case of the function foo you gave, the compiler has no way of determining (in general) whether the objects pointed to were defined as const. Michael M Rubenstein --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Java vs. Eiffel vs. C++ in realtime applications [not found] ` <199709110220.VAA24841@manifold.algebra.com> 1997-09-11 0:00 ` Mike Rubenstein @ 1997-09-12 0:00 ` Valentin Bonnard 1 sibling, 0 replies; 31+ messages in thread From: Valentin Bonnard @ 1997-09-12 0:00 UTC (permalink / raw) [Note: followup set to comp.std.c++] Igor Chudov @ home <ichudov@algebra.com> writes: > [to comp.std.c++ readers: please correct me if I am mistaken. Thanks - Igor] You are > miker3@ix.netcom.com (Mike Rubenstein) wrote: > * "Igor Chudov @ home" <ichudov@algebra.com> wrote: > * > * The FORTRAN language specifies that if one of > * > * those arrays is modified by the subroutine, it may not overlap any of > * > * the other arguments or global data. In compiler-speak it is > * > * guaranteed not to be "aliased" with anything else used in the > * > * subroutine. > * > * > * > * This property may not sound like much, but it allows FORTRAN > * > * optimizers to optimize more fully than is possible in C/C++. > * > * Eg. if I write > * > * C[I] = A[I] + B[I] > * > * D[I] = A[I] - B[I] > * > > * > Well, C++ has a good recipe to deal with this important problem. In > * > C++, you can declare A and B to be "const" pointers to double and that > * > would tell the compiler that A[i] abd B[i] can be reused after assigning > * > C[I]. > * > > * > Like this: > * > > * > void foo( double * C, double * D, > * > const double * A, const double * B, > * > int N ) > * > { > * > for( int I = 0; I < N; I++ ) > * > { > * > C[I] = A[I] + B[I]; > * > D[I] = A[I] - B[I]; > * > } > * > } > * > * Only if the compiler is broken. Declaring A and B const does not tell > * the compiler that the values cannot change -- it tells it that it > * cannot change using that pointer, unless the pointer is cast to a > * pointer to nonconst. > * > * In particular, the compiler may not assume that C is different from A. > * It would be legal to call this function as > * > * double x[2] = { 1.0, 2.0 }; > * foo(x, x, x, x, 2); You are correct; a pointer (or a reference) can be 'cv T*', in this case cv is the qualification of the view of a T, not of T itself. int i; const int* pi = &i; Here we view a non-const int as a const int; i can change, but not trough '*pi = 4' (this statement is ill-formed). > I disagree with your statement. The compiler is free to optimize > accesses to objects through const references, and is free to assume that > the referenced contents do not change. That's wrong > The following provision of the > C++ Standard Draft (http://www.setech.com/c++access.html) specifically > addresses this issue: > > Draft> 3 A pointer or reference to a cv-qualified type need not actually > Draft> point or refer to a cv-qualified object, but it is treated as if it > Draft> does; a const-qualified access path cannot be used to modify an > Draft> object even if the object referenced is a non-const object and > Draft> can be modified through some other access path. It's clear that 'the object referenced' 'can be modified through some other access path' > Draft> [Note: cv-qualifiers are supported by the type system so that > Draft> they cannot be subverted without casting > Draft> (_expr.const.cast_). ] BTW, this note is a lie, as it has already been pointed out > Draft> 4 Except that any class member declared mutable (_dcl.stc_) can be > Draft> modi- fied, any attempt to modify a const object during its > Draft> lifetime (_basic.life_) results in undefined behavior. This is about const objects, not a view of a const objects, so it's irrelevant here. > Draft> 5 [Example: [...] > Draft> const int* ciq = new const int (3); // initialized as required > Draft> int* iq = const_cast<int*>(ciq); // cast required > Draft> *iq = 4; // undefined: modifies a const object > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Look here > > The last line of the example shows us that we should not expect that > modifications of const objects through non-const access paths would > correctly change them. You are right; it means that access to a const object can be optimised; example: const int size = 100; foo (&size); b = size; // can compile as 'b = 100' directly, we know that foo // didn't changed size through a const-casted pointer > To be sure of that *iq changes, we'd have to use a "volatile" qualifier > to define ciq > > const volatile int * ciq = ... ... ... volatile or not, you don't have the right to change a const object (but if you have a magic to do so, then you are right, volatile means that const applies to the view, not the object) A consequence of the way const works is that it offers no optimisations except for object of dynamic type const (in other words, declared const). To have the optimisation, C9X has some keyword 'restrict' (I think, comp.std.c is the place to ask). -- Valentin Bonnard mailto:bonnardv@pratique.fr http://www.pratique.fr/~bonnardv --- [ comp.std.c++ is moderated. To submit articles: try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ] [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ] [ Comments? mailto:std-c++-request@ncar.ucar.edu ] ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Java vs. Eiffel vs. C++ in realtime applications [not found] ` <341644F2.763D@BZZvnet.ibm.com> 1997-09-11 0:00 ` Mike Rubenstein [not found] ` <199709110220.VAA24841@manifold.algebra.com> @ 1997-09-12 0:00 ` Joachim Durchholz 1997-09-12 0:00 ` Paul Johnson ` (2 subsequent siblings) 5 siblings, 0 replies; 31+ messages in thread From: Joachim Durchholz @ 1997-09-12 0:00 UTC (permalink / raw) Igor Chudov @ home wrote: > Well, C++ has a good recipe to deal with this important problem. In > C++, you can declare A and B to be "const" pointers to double and that > would tell the compiler that A[i] abd B[i] can be reused after > assigning > C[I]. > [I am wondering what can Eiffel offer for such optimizations.] Such declarations exist. Just say "a = old a" in the routine's postcondition. If a contains references, it is even possible (and easy) to specify shallow or deep comparison, so the language has some additional flexibility over just specifying a parameter const. However, I don't know wether any Eiffel compiler is already sophisticated enough to make use of such things. I believe other stuff has been on the agenda until recently, like making dynamic dispatch as efficient as C++ with mostly nonvirtual functions, and getting array access efficient (standard Eiffel arrays are resizable, and every array access goes through a function call which must be optimized away - lots of work for a compiler, but highly programmer-friendly). Regards, Joachim -- Please don't send unsolicited ads. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Java vs. Eiffel vs. C++ in realtime applications [not found] ` <341644F2.763D@BZZvnet.ibm.com> ` (2 preceding siblings ...) 1997-09-12 0:00 ` Joachim Durchholz @ 1997-09-12 0:00 ` Paul Johnson 1997-09-12 0:00 ` Pavel 1997-09-12 0:00 ` Fortran vs C++ vs. etc (has little to do with realtime anymore) Jeffrey Templon 5 siblings, 0 replies; 31+ messages in thread From: Paul Johnson @ 1997-09-12 0:00 UTC (permalink / raw) In article <341644F2.763D@BZZvnet.ibm.com>, "Igor Chudov @ home" <ichudov@algebra.com> writes On the subject of array optimisations where a compiler knows that data is non-aliased, and so optimises reads and writes: >[I am wondering what can Eiffel offer for such optimizations.] Its a good question. Eiffel complicates things hugely for the optimizer by having all arrays resizable. This means that the ARRAY object just holds size information and a reference to another object (typically of class SPECIAL) that actually holds the information. Since arrays are not defined as part of the language, the most obvious implementation is a double-indirection with a matching pair of procedure calls: the application calls ARRAY.item, which calls SPECIAL.item. However the compiler knows about ARRAY, and can optimise it. The obvious thing to do is to optimise the statement x := array.item(n) into something like x = array->store[n] If the same array is referred to repeatedly then the compiler can also say l_store = array->store; x = l_store[n] y = l_store[n+1] which is not far off the most efficient way to do it. The only way to do better would be to translate 'n' into a pointer into the middle of the array and do pointer arithmetic. Hmmm. Tricky, but it might be possible. As for the optimisation of multiple reads and writes to the same address, the compiler can be sure that the store of an array is not aliased by another array because arrays never allow that. This of course leaves the problem of aliased arrays. If I wrote local foo: ARRAY[INTEGER]; bar: ARRAY[INTEGER]; !!foo.make (1, 10); bar := foo; then not only could I write via the alised path, but I could also trigger a redimension, and hence move the store. So everything written above goes out of the window unless the compiler can prove that the array is not accessed via an alias. Or you can just recode your matrix multipler in C. In fact I'm planning to do exactly that RSN. Paul. --------------------------------+--------------------------------- Paul Johnson | You are lost in a maze of twisty Email: Paul@treetop.demon.co.uk | little standards, all different. paul.johnson@gecm.com | ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Java vs. Eiffel vs. C++ in realtime applications [not found] ` <341644F2.763D@BZZvnet.ibm.com> ` (3 preceding siblings ...) 1997-09-12 0:00 ` Paul Johnson @ 1997-09-12 0:00 ` Pavel 1997-09-12 0:00 ` Fortran vs C++ vs. etc (has little to do with realtime anymore) Jeffrey Templon 5 siblings, 0 replies; 31+ messages in thread From: Pavel @ 1997-09-12 0:00 UTC (permalink / raw) Igor Chudov @ home wrote:<skipped> > void foo( double * C, double * D, > const double * A, const double * B, > int N ) > { > for( int I = 0; I < N; I++ ) > { > C[I] = A[I] + B[I]; > D[I] = A[I] - B[I]; > } > } > > > * a FORTRAN optimizer knows that A and B cannot be modified by > the > * first assignment, and so it can reuse the already loaded > values > * of A[I] and B[I]. > > .. and so does the C++ compiler in the example above. Does it? Who can told it that C does not overlap A or B? > INTEGER K,IUNIT,NDAYS > real matr1(100,100), matr2(100,100), matr3(100,100) > DATA IUNIT /1/ > > do 1 iter = 1, 200 > C ########################### so i set matr1 and matr2 to > something > do 2 i = 1, 100 > do 3 j = 1, 100 > matr1(i,j) = i+j > matr2(i,j) = i-j > 2 continue > 3 continue > > do 12 i = 1, 100 > do 13 j = 1, 100 > r = 0 > do 14 k = 1, 100 > r = r + matr1(i,k) * matr2(k,j) > 12 continue > matr3(i,j) = r > 13 continue > 14 continue > > STOP > END Nobody worrying about efficiency works with matrices in this manner in Fortran. General structure matrices are stored in 1-dimensional arrays by column from sixties. BTW It makes Fortran matrix libraries so compatible and long living comaring with such C++ classes as your SquareMatrix. Every Fortran software may use the following matrix multiplying program (and program from other package for other operation with general matrices. For your SquareMatrix -- what if your customer wants to do one more operation which is already implemented in other package on some SqMtx?). This is an example. Because of copyright considerations I cannot give here the subroutine for general matrix multiplication I use (it is not mine, it has been written several tens years ago and I had never reasons to write my own!). The following subroutine is mine own and it implements one very common matrix primitive R = R + transpose(A) * A where A is M*N rectangular matrix and R is N*N symmetric matrix (so only upper triangle of it is stored 'by column' as usual) in usual Fortran manner. Try to beat it with your C++ compiler! SUBROUTINE MTSATA(A,R,M,N) IMPLICIT REAL*8(A-H,O-Z) DIMENSION A(1),R(1) IR=1 IA1=0 DO 3 J=1,N IA2=0 DO 2 I=1,J DO 1 K=1,M R(IR)=R(IR)+A(IA1+K)*A(IA2+K) 1 CONTINUE IR=IR+1 IA2=IA2+M 2 CONTINUE IA1=IA1+M 3 CONTINUE RETURN END Pavel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Fortran vs C++ vs. etc (has little to do with realtime anymore) [not found] ` <341644F2.763D@BZZvnet.ibm.com> ` (4 preceding siblings ...) 1997-09-12 0:00 ` Pavel @ 1997-09-12 0:00 ` Jeffrey Templon 1997-09-13 0:00 ` Joseph M. O'Leary 5 siblings, 1 reply; 31+ messages in thread From: Jeffrey Templon @ 1997-09-12 0:00 UTC (permalink / raw) "Igor Chudov @ home" <ichudov@algebra.com> writes: > Brian Thomson <thomson@vnet.ibm.com> wrote: > * a FORTRAN optimizer knows that A and B cannot be modified by the [ ... ] > * In C++ there is no such guarantee (unless you supply one > * outside the language via a #pragma), and it makes a noticeable > * difference in these matrix algorithms that are a big part of > * scientific programming. > > Well, the programmer of a Matrix class has to know what he is doing. > Making C++ code efficient may be harder than writing efficient fortran > code, but it is not impossible. This is a good point, but perhaps not in the way that Igor intended. One of the main reasons I tend to push Fortran (or something similar, like Ada or Python ... although maybe not everyone would see what I mean by "similar" here ;-) is that with stuff like C++, you *do* have to know what you are doing, or you will make a mess of it. The fact remains (and will for some time) that many scientific programmers are scientists FIRST and programmers SECOND. Turning the average physicist/programmer (at least in my field) loose with a C++ compiler is like giving your car keys to your eight-year-old. A few of them would actually be able to drive, but most of them would cause big damage trying. So one of my reasons for Fortran still being around: you can write a reasonable program which runs reasonably efficiently just by more or less typing in an expression of a simple algorithm. Fortran's "mental model" of the computer is very simple. JAT ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-12 0:00 ` Fortran vs C++ vs. etc (has little to do with realtime anymore) Jeffrey Templon @ 1997-09-13 0:00 ` Joseph M. O'Leary 1997-09-16 0:00 ` James F Cornwall 0 siblings, 1 reply; 31+ messages in thread From: Joseph M. O'Leary @ 1997-09-13 0:00 UTC (permalink / raw) Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article <m34t7q3bcc.fsf_-_@studbolt.physast.uga.edu>... > One of the main reasons I tend to push Fortran (or something similar, > like Ada or Python ... although maybe not everyone would see what > I mean by "similar" here ;-) is that with stuff like C++, you *do* > have to know what you are doing, or you will make a mess of it. > The fact remains (and will for some time) that many scientific programmers > are scientists FIRST and programmers SECOND. Turning the average > physicist/programmer (at least in my field) loose with a C++ compiler > is like giving your car keys to your eight-year-old. A few of > them would actually be able to drive, but most of them would cause > big damage trying. > > So one of my reasons for Fortran still being around: you can write > a reasonable program which runs reasonably efficiently just by more > or less typing in an expression of a simple algorithm. Fortran's "mental > model" of the computer is very simple. I agree with you. I spent the first 4 years of my professional career working a large scale VAX/VMS Over-the-Horizon Radar project that was written almost totally in FORTRAN. When I say large scale, I'm talking about something that required 2 VAX 6000/430 mainframes and, employed about 70 or 80 concurrent processes Then I spent about a year and a half working on a Visual C++/Windows NT project that replaced a large portion of the older project -- mainly the UI code. The difference between the 2 software development styles was like night and day. In the old system, you had to know beforehand exactly how much memory your app (or process) required. It was all allocated when the process started. If you data outgrew that size, the process crashed. Also, since it was in FORTRAN, the code read like...well like BASIC. It was very easy to pick up and very straightforward. All code paths were very structured, hierarchical, and BIG. (Huge). I think we documented very well what we did and wrote some very clean code. We didn't try to force old, procedural programming techniquest on to an object-oriented langauge. We accomplished the same task with probably less than one-third as many lines of code as the FORTRAN. Still, I don't envy the long-time FORTRAN programmer who has to switch from maintaining the old code base to maintaining the new one, even if it is much less code to look at. It requires quite a philosophical shift. Joe O' ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-13 0:00 ` Joseph M. O'Leary @ 1997-09-16 0:00 ` James F Cornwall 0 siblings, 0 replies; 31+ messages in thread From: James F Cornwall @ 1997-09-16 0:00 UTC (permalink / raw) Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote: : Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article : <m34t7q3bcc.fsf_-_@studbolt.physast.uga.edu>... : > One of the main reasons I tend to push Fortran (or something similar, : > like Ada or Python ... although maybe not everyone would see what : > I mean by "similar" here ;-) is that with stuff like C++, you *do* : > have to know what you are doing, or you will make a mess of it. : > The fact remains (and will for some time) that many scientific : programmers : > are scientists FIRST and programmers SECOND. Turning the average : > physicist/programmer (at least in my field) loose with a C++ compiler : > is like giving your car keys to your eight-year-old. A few of : > them would actually be able to drive, but most of them would cause : > big damage trying. : > : > So one of my reasons for Fortran still being around: you can write : > a reasonable program which runs reasonably efficiently just by more : > or less typing in an expression of a simple algorithm. Fortran's "mental : > model" of the computer is very simple. : I agree with you. I spent the first 4 years of my professional career : working a large scale VAX/VMS Over-the-Horizon Radar project that was : written almost totally in FORTRAN. When I say large scale, I'm talking : about something that required 2 VAX 6000/430 mainframes and, employed about : 70 or 80 concurrent processes Oh, God - I spent more time than I care to remember working on the OTH-B project, too. My aspect was sending the ionospheric "weather" forecasts to your system (using an ancient Univac terminal protocol <U200> bastardized to talk to a VAX...). Our code was a hodgepodge of Fortrans (IV, V, & 77) and assmbler code, much of it created by scientist/programmers as described above. Given a choice between any flavor Fortran and any flavor of C, FORTRAN wins hands down for me and my style of thinking. The language does what it needs to do and still keeps things simple enough to be usable for those of us below the stratosphere..... Just my $0.02 worth, YMMV. :-) Jim Cornwall (ex-USAF, now working on groundwater modeling...Using Fortran!) : Then I spent about a year and a half working on a Visual C++/Windows NT : project that replaced a large portion of the older project -- mainly the UI : code. The difference between the 2 software development styles was like : night and day. In the old system, you had to know beforehand exactly how : much memory your app (or process) required. It was all allocated when the : process started. If you data outgrew that size, the process crashed. : Also, since it was in FORTRAN, the code read like...well like BASIC. It : was very easy to pick up and very straightforward. All code paths were : very structured, hierarchical, and BIG. (Huge). I think we documented : very well what we did and wrote some very clean code. We didn't try to : force old, procedural programming techniquest on to an object-oriented : langauge. We accomplished the same task with probably less than one-third : as many lines of code as the FORTRAN. : Still, I don't envy the long-time FORTRAN programmer who has to switch from : maintaining the old code base to maintaining the new one, even if it is : much less code to look at. It requires quite a philosophical shift. : Joe O' ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) @ 1997-09-13 0:00 Dr. Krishnan Chittur 1997-09-15 0:00 ` Area Industrial y Electromec�nica ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Dr. Krishnan Chittur @ 1997-09-13 0:00 UTC (permalink / raw) Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote: : Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article : > The fact remains (and will for some time) that many scientific : programmers : > are scientists FIRST and programmers SECOND. ........ : > So one of my reasons for Fortran still being around: you can write : > a reasonable program which runs reasonably efficiently just by more : > or less typing in an expression of a simple algorithm. Fortran's "mental : > model" of the computer is very simple. Well said! ... I still have to find an environment that will allow me to develop a GUI as simply as I can write Fortran Code to do calculations ... if there is one, please let me know. There is this debate in the Chemical Engineering Community about whether we should teach Fortran at all ... We are currently on the side that says "yes" we should. More than Fortran itself, what we are trying to do is to teach the elements of programming ... the idea that you should plan the project, have an idea of what you want the program to do, design the "structure" ... and then write the code ... when you want to say "calculate the square root" ... find out if you need to write the program or use something that is supplied by compiler or perhaps a set of callable routines written by someone else ... In a programming course, students also learn how to develop a "set of routines" .. one problem is that at the time they are learning to program, often they do not have the background in math ... for example it is difficult at the freshman level to have students attempt to write Fortran Code to solve say linear algebraic problems ... Anyway ... Fortran is still around, will be around for a while ... students MUST know how to deal with it's many strange properties ... 4 to 6 weeks exposing them to elements of fortran 77 is worth the time ... Fortran 90 and F are I think a step in the right direction, let's see how it develops ... ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-13 0:00 Dr. Krishnan Chittur @ 1997-09-15 0:00 ` Area Industrial y Electromec�nica 1997-09-16 0:00 ` Vanesch P. 1997-09-16 0:00 ` Rick Hawkins 2 siblings, 0 replies; 31+ messages in thread From: Area Industrial y Electromec�nica @ 1997-09-15 0:00 UTC (permalink / raw) To: chitturk I agree with you completely Jose Jimenez, msme ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-13 0:00 Dr. Krishnan Chittur 1997-09-15 0:00 ` Area Industrial y Electromec�nica @ 1997-09-16 0:00 ` Vanesch P. 1997-09-16 0:00 ` Jeffrey Templon 1997-09-16 0:00 ` Rick Hawkins 2 siblings, 1 reply; 31+ messages in thread From: Vanesch P. @ 1997-09-16 0:00 UTC (permalink / raw) Dr. Krishnan Chittur (chitturk@email.uah.edu) wrote: : Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote: : : Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article : : > The fact remains (and will for some time) that many scientific : : programmers : : > are scientists FIRST and programmers SECOND. : ........ : : > So one of my reasons for Fortran still being around: you can write : : > a reasonable program which runs reasonably efficiently just by more : : > or less typing in an expression of a simple algorithm. Fortran's "mental : : > model" of the computer is very simple. : Well said! ... I still have to find an environment that will allow : me to develop a GUI as simply as I can write Fortran Code to : do calculations ... if there is one, please let me know. I think this is an essential point. FORTRAN is well-suited to do calculations and hard-core scientific computation. But more complex structures (a GUI is program-wise a lot more complicated than a scientific calculation) are not dealt too well with in fortran I think. I've seen this in the high-energy community. Both elements are present there: complex software systems and hard-core scientific computing. Well, I've seen quite a mess in the FORTRAN implementation (rather ad hoc) of the complicated datastructures that had to be manipulated. It would have been much better done (and the tendency now is - finally - to switch to things like C++) in a language suited for the task. On the other hand, I've also seen the opposite. A collegue of mine wrote a MONSTER program in C++ to do some straightforward matrix manipulations. The graphical user interface launches tens and tens of windows in which one can manipulate parameters, look at graphs etc... He worked for almost a year on the thing. He is a computer scientist, btw, I'm not. I'm an engineer and physicist. It takes about 10 minutes to even start up the thing, getting your X-terminal cluttered with all those windows. I've done the same thing in F77, but with an ASCII steering file, in about a month... and guess what ? my program tackles systems he can't even dream of handling in just a few hours (his can't do it, it just runs out of 1 GB swap space !!) I get a nice ASCII file with my results. For smaller systems, my program is about 20 times faster, with less memory, than his, on the same system. I think every language has its uses. FORTRAN is old and very elementary on the conceptual level. For most modern computing applications (graphics, process steering, multi-user things etc) it is simply too elementary. But for applications where these elementary concepts are sufficient (such as scientific computing - which is usually advanced on the scientific level and very simple on the computational level) it allows indeed to write a reasonably simple program that behaves resonably well by someone who has some reasonable knowledge of computers but is not a computer scientist, without involving a lot of abstract computer-think. But if the project is too ambitious, and the abstract computer think is really needed, well... I don't think it is a good idea to do it in FORTRAN. cheers, Patrick. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-16 0:00 ` Vanesch P. @ 1997-09-16 0:00 ` Jeffrey Templon 1997-09-16 0:00 ` Gary L. Scott 0 siblings, 1 reply; 31+ messages in thread From: Jeffrey Templon @ 1997-09-16 0:00 UTC (permalink / raw) pvanesch@vub.ac.be (Vanesch P.) writes: > I think this is an essential point. FORTRAN is well-suited to do > calculations and hard-core scientific computation. But more > complex structures (a GUI is program-wise a lot more complicated > than a scientific calculation) are not dealt too well with in > fortran I think. I've seen this in the high-energy community. > Both elements are present there: complex software systems and > hard-core scientific computing. Well, I've seen quite a mess > in the FORTRAN implementation (rather ad hoc) of the complicated > datastructures that had to be manipulated. It would have been > much better done (and the tendency now is - finally - to switch > to things like C++) in a language suited for the task. I agree that there are problems that get too complex for Fortran, at least for Fortran-77. I'm not sure these limitations apply to Fortran-90, given the appearance of derived types and allocatable arrays. Perhaps F90 is not enough, but I think C++ is not the answer for people who aren't professional programmers. Ada looks like it might be easier for a normal human to work with and read, but I haven't spent much time playing with it. JAT ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-16 0:00 ` Jeffrey Templon @ 1997-09-16 0:00 ` Gary L. Scott 1997-09-17 0:00 ` Jenn-Ching Luo 0 siblings, 1 reply; 31+ messages in thread From: Gary L. Scott @ 1997-09-16 0:00 UTC (permalink / raw) The problem of developing a GUI in Fortran is one of designing an appropriate API for Fortran. This used to be done quite commonly (language-specific API bindings). I have developed "graphical user interfaces" in Fortran that were highly functional (a little slow, it was 10 years ago) and very easy to develop because the API was designed "appropriately". The problem is really one of UNIX/Windows APIs being "low-level" C-oriented APIs. It is great that Fortran is being extended in ways which allow it to be able to call other languages and APIs designed for other languages, however, I shouldn't have to. OS or compiler vendors should supply language tailored API bindings. It's more work for them, but a lot less work for me, as an application developer who just wants to produce a useful product without the hassle of inter language communication which requires me to essentially know two (or more) languages, usually one of which has an appalling syntax that makes me cringe). I vote for a reduction in complexity (the K.I.S.S. principle) in the area of OS API calls from Fortran (or PASCAL or COBOL or PL/1 or <insert legacy language here>. Is anybody listening? Come on, there's only 1500 or so WIN API calls, how much work could that be...). Jeffrey Templon wrote: > pvanesch@vub.ac.be (Vanesch P.) writes: > > > I think this is an essential point. FORTRAN is well-suited to do > > calculations and hard-core scientific computation. But more > > complex structures (a GUI is program-wise a lot more complicated > > than a scientific calculation) are not dealt too well with in > > fortran I think. I've seen this in the high-energy community. > > Both elements are present there: complex software systems and > > hard-core scientific computing. Well, I've seen quite a mess > > in the FORTRAN implementation (rather ad hoc) of the complicated > > datastructures that had to be manipulated. It would have been > > much better done (and the tendency now is - finally - to switch > > to things like C++) in a language suited for the task. > > I agree that there are problems that get too complex for Fortran, at > least for Fortran-77. I'm not sure these limitations apply to > Fortran-90, given the appearance of derived types and allocatable > arrays. > Perhaps F90 is not enough, but I think C++ is not the answer for > people who aren't professional programmers. Ada looks like it might > be easier for a normal human to work with and read, but I haven't > spent > much time playing with it. > > JAT ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-16 0:00 ` Gary L. Scott @ 1997-09-17 0:00 ` Jenn-Ching Luo 1997-09-17 0:00 ` Gary L. Scott 0 siblings, 1 reply; 31+ messages in thread From: Jenn-Ching Luo @ 1997-09-17 0:00 UTC (permalink / raw) Gary L. Scott <scottg@flash.net> wrote in article <341F22C2.C46CE5F4@flash.net>... > The problem of developing a GUI in Fortran is one of designing an > appropriate API for Fortran. ..... > .................................................. > however, I shouldn't have to. OS or > compiler vendors should supply language tailored API bindings. It's > more work for them, but a lot less work for me, as an application > developer who just wants to produce a useful product without the hassle > of inter language > Just like most of developers, I started programming Windows Applications in C++ for a short period. I personal like to use Fortran, and I gave up C++ for Windows programming. There is no trouble and problem to call WIN API from Fortran. If compiler (i.e. Fortran) vendors can provide more info, examples, or documents for programming Windows applications (not quick win) in Fortran, that certainly may help Fortran programmers. Jenn-Ching Luo http://www.Equation.com/People/Luo.htm ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-17 0:00 ` Jenn-Ching Luo @ 1997-09-17 0:00 ` Gary L. Scott 0 siblings, 0 replies; 31+ messages in thread From: Gary L. Scott @ 1997-09-17 0:00 UTC (permalink / raw) Jenn-Ching Luo wrote: > Gary L. Scott <scottg@flash.net> wrote in article > <341F22C2.C46CE5F4@flash.net>... > > The problem of developing a GUI in Fortran is one of designing an > > appropriate API for Fortran. ..... > > .................................................. > > however, I shouldn't have to. > OS > or > > compiler vendors should supply language tailored API bindings. It's > > > more work for them, but a lot less work for me, as an application > > developer who just wants to produce a useful product without the > hassle > > of inter language > > > > Just like most of developers, I started programming Windows > Applications in > C++ for a short period. I personal like to use Fortran, and I gave up > C++ > for Windows programming. There is no trouble and problem to call WIN > API > from Fortran. > > If compiler (i.e. Fortran) vendors can provide more info, examples, or > > documents for programming Windows applications (not quick win) in > Fortran, > that certainly may help Fortran programmers. > > Jenn-Ching Luo > http://www.Equation.com/People/Luo.htm This is highly dependent upon your compiler's support for extensions to the standard call syntax. If you're calling Windows APIs, you're probably not programming in "standard compliant" Fortran (when you use these extensions). Some people don't mind or require this. I prefer the simpler call syntax of "standard" Fortran. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-13 0:00 Dr. Krishnan Chittur 1997-09-15 0:00 ` Area Industrial y Electromec�nica 1997-09-16 0:00 ` Vanesch P. @ 1997-09-16 0:00 ` Rick Hawkins 1997-09-18 0:00 ` Oleg Krivosheev 2 siblings, 1 reply; 31+ messages in thread From: Rick Hawkins @ 1997-09-16 0:00 UTC (permalink / raw) In article <5ve7c6$f4m$1@info.uah.edu>, Dr. Krishnan Chittur <chitturk@email.uah.edu> wrote: >Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote: > >: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article >: > The fact remains (and will for some time) that many scientific >: programmers >: > are scientists FIRST and programmers SECOND. >........ >: > So one of my reasons for Fortran still being around: you can write >: > a reasonable program which runs reasonably efficiently just by more >: > or less typing in an expression of a simple algorithm. Fortran's "mental >: > model" of the computer is very simple. >Well said! ... I still have to find an environment that will allow >me to develop a GUI as simply as I can write Fortran Code to >do calculations ... if there is one, please let me know. yes!!! learning c++ after not using c for ten years took some work. Fortran after 12 years didn't; I could sit back donw and code. I'm not going to knock c++; it's wonderful for where it belongs. But for my fairly simple models that just need numbers pounded into submission, and which won't be reused, Fortran is *much* easier, if for no other reason than high-level I/O. I was spending 2/3 of my time in c++ either writing pieces builit into fortran, or looking for libraries with the pieces. I think I switched when i couldn't find a max(), and couldn't figure out the single example of writing a function with variable number of arguments (actually, i used smalltalk for a while in between, but that's another story). Also, the bit on needing to define new classes for array bounds checking, rather than a compiler switch, was maddening . . . rick -- R E HAWKINS rhawkins@iastate.edu These opinions will not be those of ISU until they pay my retainer. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-16 0:00 ` Rick Hawkins @ 1997-09-18 0:00 ` Oleg Krivosheev 1997-09-19 0:00 ` Rick Hawkins 0 siblings, 1 reply; 31+ messages in thread From: Oleg Krivosheev @ 1997-09-18 0:00 UTC (permalink / raw) Hi, rhawkins@iastate.edu (Rick Hawkins) writes: > > In article <5ve7c6$f4m$1@info.uah.edu>, > Dr. Krishnan Chittur <chitturk@email.uah.edu> wrote: > > >Joseph M. O'Leary (NOSPAMjmoleary@earthlink.net) wrote: > > > >: Jeffrey Templon <templon@studbolt.physast.uga.edu> wrote in article > >: > The fact remains (and will for some time) that many scientific > >: programmers > >: > are scientists FIRST and programmers SECOND. > >........ > >: > So one of my reasons for Fortran still being around: you can write > >: > a reasonable program which runs reasonably efficiently just by more > >: > or less typing in an expression of a simple algorithm. Fortran's "mental > >: > model" of the computer is very simple. > > >Well said! ... I still have to find an environment that will allow > >me to develop a GUI as simply as I can write Fortran Code to > >do calculations ... if there is one, please let me know. > > yes!!! learning c++ after not using c for ten years took some work. > Fortran after 12 years didn't; I could sit back donw and code. well, if you're talking about F77, yes. FYI, there are already F90 and F95 here. I doubt you can program in F95 without learning - just as you did with C++. > I'm not going to knock c++; it's wonderful for where it belongs. But > for my fairly simple models that just need numbers pounded into > submission, and which won't be reused, Fortran is *much* easier, if for > no other reason than high-level I/O. I was spending 2/3 of my time in > c++ either writing pieces builit into fortran, or looking for libraries > with the pieces. I think I switched when i couldn't find a max(), and > couldn't figure out the single example of writing a function with > variable number of arguments (actually, i used smalltalk for a while in > between, but that's another story). hmm... cannot find max() in c++? couldn't figure how to write function with variable numbers of arguments? there is something wrong with your C++ installation or with your C/C++ book. OK ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-18 0:00 ` Oleg Krivosheev @ 1997-09-19 0:00 ` Rick Hawkins 1997-09-23 0:00 ` Oleg Krivosheev 0 siblings, 1 reply; 31+ messages in thread From: Rick Hawkins @ 1997-09-19 0:00 UTC (permalink / raw) In article <vi8k9ge42bw.fsf@drabble.fnal.gov>, Oleg Krivosheev <kriol@fnal.gov> wrote: >rhawkins@iastate.edu (Rick Hawkins) writes: >> yes!!! learning c++ after not using c for ten years took some work. >> Fortran after 12 years didn't; I could sit back donw and code. >well, if you're talking about F77, yes. FYI, there are already >F90 and F95 here. I doubt you can program in F95 without >learning - just as you did with C++. I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20 back then. >> I'm not going to knock c++; it's wonderful for where it belongs. But >> for my fairly simple models that just need numbers pounded into >> submission, and which won't be reused, Fortran is *much* easier, if for >> no other reason than high-level I/O. I was spending 2/3 of my time in >> c++ either writing pieces builit into fortran, or looking for libraries >> with the pieces. I think I switched when i couldn't find a max(), and >> couldn't figure out the single example of writing a function with >> variable number of arguments (actually, i used smalltalk for a while in >> between, but that's another story). >cannot find max() in c++? I tried. I looked. I'm convinced it must be there, but . . . >couldn't figure how to write function with variable numbers >of arguments? In the two books that I had, there was a single example, whihc managed not to explain. I wasn't just the issue of variable number of arguments, but of arbitrarily large variable numbers (i wanted my max()! :) >there is something wrong with your C++ installation >or with your C/C++ book. I assume it's the books; the compiler was either DEC cc or gcc; i forget now. rick -- R E HAWKINS rhawkins@iastate.edu These opinions will not be those of ISU until they pay my retainer. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-19 0:00 ` Rick Hawkins @ 1997-09-23 0:00 ` Oleg Krivosheev 1997-09-23 0:00 ` Gary L. Scott ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Oleg Krivosheev @ 1997-09-23 0:00 UTC (permalink / raw) To: rhawkins Hi, Rick rhawkins@iastate.edu (Rick Hawkins) writes: > > > In article <vi8k9ge42bw.fsf@drabble.fnal.gov>, > Oleg Krivosheev <kriol@fnal.gov> wrote: > > >rhawkins@iastate.edu (Rick Hawkins) writes: > > >> yes!!! learning c++ after not using c for ten years took some work. > >> Fortran after 12 years didn't; I could sit back donw and code. > > >well, if you're talking about F77, yes. FYI, there are already > >F90 and F95 here. I doubt you can program in F95 without > >learning - just as you did with C++. > > I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20 > back then. well, that's exactly what i was asking about - there were NO F90/F95 twelve years ago ! If you're using F90 now, you learned it somehow. Either i misunderstood something or our claim "> >> Fortran after 12 years didn't; I could sit back donw and code." is wrong. > >cannot find max() in c++? > > I tried. I looked. I'm convinced it must be there, but . . . > > >couldn't figure how to write function with variable numbers > >of arguments? > > In the two books that I had, there was a single example, whihc managed > not to explain. I wasn't just the issue of variable number of > arguments, but of arbitrarily large variable numbers > (i wanted my max()! :) sorry, i have only min ;) well, try example below for min with arbitrary larger number of arguments. Hope it can help #include <assert.h> #include <stdio.h> #include <stdarg.h> double dmin( int nofargs, ... ) { double res = 1.0e+38, arg; int j; va_list ap; assert( nofargs > 1 ); va_start(ap, nofargs ); for( j = 0; j < nofargs; ++j ) { arg=va_arg( ap, double ); if ( arg < res ) { res = arg; } } va_end(ap); return res; } int main( void ) { printf( "%e\n", dmin( 2, 1.0, 2.0 ) ); printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) ); printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) ); return 0; } > >there is something wrong with your C++ installation > >or with your C/C++ book. > > I assume it's the books; the compiler was either DEC cc or gcc; i forget > now. code above works fine with gcc on Sparc/Solaris 2.5 box regards OK ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-23 0:00 ` Oleg Krivosheev @ 1997-09-23 0:00 ` Gary L. Scott 1997-09-24 0:00 ` Rick Hawkins 1997-09-25 0:00 ` const 2 siblings, 0 replies; 31+ messages in thread From: Gary L. Scott @ 1997-09-23 0:00 UTC (permalink / raw) Oleg Krivosheev wrote: > Hi, Rick > > rhawkins@iastate.edu (Rick Hawkins) writes: > > > > > > > In article <vi8k9ge42bw.fsf@drabble.fnal.gov>, > > Oleg Krivosheev <kriol@fnal.gov> wrote: > > > > >rhawkins@iastate.edu (Rick Hawkins) writes: > > > > >> yes!!! learning c++ after not using c for ten years took some > work. > > >> Fortran after 12 years didn't; I could sit back donw and code. > > > > >well, if you're talking about F77, yes. FYI, there are already > > >F90 and F95 here. I doubt you can program in F95 without > > >learning - just as you did with C++. > > > > I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops > 20 > > back then. > > well, that's exactly what i was asking about - there were NO > F90/F95 twelve years ago ! If you're using F90 now, you learned > it somehow. Either i misunderstood something or our claim > > "> >> Fortran after 12 years didn't; I could sit back donw and code." > > is wrong. However, a very large percentage of Fortran 90 features (even some of the new intrinsics) have been in some FORTRAN 77 compilers for minicomputers as extensions since the late 70's/early 80's. The main exceptions being array syntax and "non-sequence" derived types. So some of us have had a long time to learn them. I've used the following since around 1981: block do/end do (also for/end for, loop/end loop) ! comment free form source (almost identical to the current standard) variable # calling arguments (not F90/not keyword arguments/kinda messy) "Purdue" bit manipulation intrinsics direct physical memory address access ("Cray pointer" substitute?/not F90) ; record separator I'm sure others that I can't recall right now... That's why I have such a hard time believing how long it took to get some of them standardized and why some of them are still not in the standard (but are rumored). > > > > >cannot find max() in c++? > > > > I tried. I looked. I'm convinced it must be there, but . . . > > > > >couldn't figure how to write function with variable numbers > > >of arguments? > > > > In the two books that I had, there was a single example, whihc > managed > > not to explain. I wasn't just the issue of variable number of > > arguments, but of arbitrarily large variable numbers > > (i wanted my max()! :) > > sorry, i have only min ;) > > well, try example below for min with > arbitrary larger number of arguments. Hope it can help > > #include <assert.h> > #include <stdio.h> > #include <stdarg.h> > > double > dmin( int nofargs, ... ) { > > double res = 1.0e+38, arg; > int j; > va_list ap; > > assert( nofargs > 1 ); > > va_start(ap, nofargs ); > > for( j = 0; j < nofargs; ++j ) { > arg=va_arg( ap, double ); > if ( arg < res ) { > res = arg; > } > } > va_end(ap); > return res; > } > > int > main( void ) { > > printf( "%e\n", dmin( 2, 1.0, 2.0 ) ); > > printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) ); > > printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) ); > > return 0; > } > > > >there is something wrong with your C++ installation > > >or with your C/C++ book. > > > > I assume it's the books; the compiler was either DEC cc or gcc; i > forget > > now. > > code above works fine with gcc on Sparc/Solaris 2.5 box > > regards > > OK ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-23 0:00 ` Oleg Krivosheev 1997-09-23 0:00 ` Gary L. Scott @ 1997-09-24 0:00 ` Rick Hawkins 1997-09-24 0:00 ` Xingzeng Liu 1997-09-25 0:00 ` const 2 siblings, 1 reply; 31+ messages in thread From: Rick Hawkins @ 1997-09-24 0:00 UTC (permalink / raw) In article <vi8oh5keyy1.fsf@drabble.fnal.gov>, Oleg Krivosheev <kriol@fnal.gov> wrote: >Hi, Rick hi >rhawkins@iastate.edu (Rick Hawkins) writes: >> In article <vi8k9ge42bw.fsf@drabble.fnal.gov>, >> Oleg Krivosheev <kriol@fnal.gov> wrote: >> >rhawkins@iastate.edu (Rick Hawkins) writes: >> >> yes!!! learning c++ after not using c for ten years took some work. >> >> Fortran after 12 years didn't; I could sit back donw and code. >> >well, if you're talking about F77, yes. FYI, there are already >> >F90 and F95 here. I doubt you can program in F95 without >> >learning - just as you did with C++. >> I'm using F90; It was Fortran IV on a pr1me and almost-f77 on tops 20 >> back then. >well, that's exactly what i was asking about - there were NO >F90/F95 twelve years ago ! If you're using F90 now, you learned >it somehow. Either i misunderstood something or our claim Back then I used F77 and almost F77 (seems to me that DEC FORTRAN on TOPS 20 was somewhere between 66 and 77. But hey, we had a preproccessor fof this c++ thing :). That was about 83-84. I used some c back then, too. Rolling ahead to 95, learing c++ took work. I recoded a summer's worth of c++ and smalltalk to fortran 77 in a day and a half, not having looked at fortran since 84. Roll ahead to a couple of weeks ago, i picked up a F90 book, read a couple of chapters, and am happily using lots of it. >sorry, i have only min ;) > >well, try example below for min with >arbitrary larger number of arguments. Hope it can help I'm definitely saving this one. Thanks. There's a coupel of future pojects that will need objects, which will probably mean some c++. -- R E HAWKINS rhawkins@iastate.edu These opinions will not be those of ISU until they pay my retainer. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-24 0:00 ` Rick Hawkins @ 1997-09-24 0:00 ` Xingzeng Liu 0 siblings, 0 replies; 31+ messages in thread From: Xingzeng Liu @ 1997-09-24 0:00 UTC (permalink / raw) It should be known that C++ and C are totally different languages. I think for every one, to learn C++ is much more difficult than to learn others. If you can learn C, FORTRAN, or PASCAL with 2 weeks, then I think to learn C++ at least needs you 1 month. And you still need more than 1 month to practice it, to know the real style of C++. I use C++ for 5 years. I think C++ is a very good language. It is much suitable to do large complex simulations. It is reported in CERN that their large C++ simulation software (transfered from their original FORTRAN code) is faster than FORTRAN code. But for some small problem, C++ is not so good. And the depency of the non-standard library is also a big problem for C++. The super point in C++ is their ability to reuse. And there are so many different library of the basic object library. You may find you loss yourself when work in another platform. It is also very weak in numerical computation. So now I try to use FORTRAN 90. In my point of view, the new features such as Module, type etc. much improve the convenice in writing programs. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-23 0:00 ` Oleg Krivosheev 1997-09-23 0:00 ` Gary L. Scott 1997-09-24 0:00 ` Rick Hawkins @ 1997-09-25 0:00 ` const 1997-09-25 0:00 ` Oleg Krivosheev 2 siblings, 1 reply; 31+ messages in thread From: const @ 1997-09-25 0:00 UTC (permalink / raw) Oleg Krivosheev wrote: > > [skipped] > > sorry, i have only min ;) > > well, try example below for min with > arbitrary larger number of arguments. Hope it can help > > #include <assert.h> > #include <stdio.h> > #include <stdarg.h> > > double > dmin( int nofargs, ... ) { > > double res = 1.0e+38, arg; > int j; > va_list ap; > > assert( nofargs > 1 ); > > va_start(ap, nofargs ); > > for( j = 0; j < nofargs; ++j ) { > arg=va_arg( ap, double ); > if ( arg < res ) { > res = arg; > } > } > va_end(ap); > return res; > } > > int > main( void ) { > > printf( "%e\n", dmin( 2, 1.0, 2.0 ) ); > > printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) ); > > printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) ); > > return 0; > } > > [skipped] > OK, just to be pedantic, the previous example shows very fine the difference between fortran and C in computations. Since min/max are standard fortran functions, it can be supposed they are maximally optimized with no regards to number of their arguments (just because the compiler takes care of them). In the contrary, in the example, we have overhead of the arguments number evaluation and overhead of implementation (not necessarily this one, generally almost any non-trivial non-built-in operation has some overhead - there has been some reason to add into C libraries memcpy, memcmp and so on functions). Moreover the idea of such an implementation contains two great places to make bugs and definitely any user of such an implementation will be doing the bugs endlessly. Firstly, it is the programmer who should worry about conformity of the declared number of arguments to the actual one. In such cases, generally, adding or removing actual arguments, people tend to forget to correct the declared number. Secondly, there is no way for type checking and for type conversions, usage of 1 instead of 1.0 in the arguments list will cause very nasty problems. Using C++ and not C, most probably, I would try to implement the min function in the following way: inline double min(double v1, double v2) { return v1<v2 ? v1 : v2; } inline double min(double v1, double v2, double v3) { double v=min(v1,v2); return v<v3 ? v : v3; } inline double min(double v1, double v2, double v3, double v4) { double v=min(v1,v2,v3); return v<v4 ? v : v4; } inline double min(double v1, double v2, double v3, double v4, double v5) { double v=min(v1,v2,v3,v4); return v<v5 ? v : v5; } // and so on Such a way doesn't seem elegant enough and it only emulates arbitrary number of min-function arguments but it solves the types and the number-conformity problems. Trying to use non-defined min(huge-arguments-number), a programmer just gets compilation error and can easily extend the set of his min-functions. And the last but not least: the following example compiled with -O3 option with Sparc C++ 4.2 patch 104631-03 and started on SunOS 5.5.1 SUNW,Ultra-2 produces dmin: 3.04 seconds overloaded min: 1.11 seconds started on SunOS 5.5.1 SUNW,SPARCstation-4 produces: dmin: 9.32 seconds overloaded min: 4.89 seconds and compiled with -O option with HP C++ A.03.72; and started on HP-UX A.09.05 9000/715 produces: dmin: 4.63 seconds overloaded min: 1.58 seconds #include <sys/times.h> #include <limits.h> #include <iostream.h> extern double dmin(int, double, ...); //------------------------------------------------------ inline double min(double v1, double v2) { return v1<v2 ? v1 : v2; } inline double min(double v1, double v2, double v3) { double v=min(v1,v2); return v<v3 ? v : v3; } inline double min(double v1, double v2, double v3, double v4) { double v=min(v1,v2,v3); return v<v4 ? v : v4; } inline double min(double v1, double v2, double v3, double v4, double v5) { double v=min(v1,v2,v3,v4); return v<v5 ? v : v5; } //------------------------------------------------------ int main(void) { struct tms ts; clock_t clk, start; unsigned loop_len=6000000; unsigned loop; double dummy=0; start=times(&ts); loop=loop_len; while (loop--) dummy=dmin(5,1.0,2.0,3.0,dummy,(double)loop); clk=times(&ts)-start; cout << " dmin: " << double(clk)/CLK_TCK << " seconds" << endl; start=times(&ts); loop=loop_len; while (loop--) dummy=min(1.0,2.0,3.0,dummy,loop); clk=times(&ts)-start; cout << " overloaded min: " << double(clk)/CLK_TCK << " seconds" << endl; return 0; } //------------------------------------------------------ #include <stdarg.h> double dmin(int nofargs, double d, ...) { va_list ap; va_start(ap,d); while (--nofargs) { double v=va_arg(ap,double); if (v<d) d=v; } va_end(ap); return d; } //----------------------------------------------------- // End of File //----------------------------------------------------- //------------------------------------------------------------------ // Opinions expressed here are my own only // // Constantine Antonovich, Tel. : ++972-8-942-3819 // software engineer, Fax : ++972-8-942-3955 // Orbotech Ltd., P.O.Box 215, Email: const@orbotech.co.il // Yavne 81102, Israel //------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Fortran vs C++ vs. etc (has little to do with realtime anymore) 1997-09-25 0:00 ` const @ 1997-09-25 0:00 ` Oleg Krivosheev 0 siblings, 0 replies; 31+ messages in thread From: Oleg Krivosheev @ 1997-09-25 0:00 UTC (permalink / raw) To: const Hi, Constantine Antonovich: <const@orbotech.co.il> writes: > > Oleg Krivosheev wrote: > > > > [skipped] > > > > sorry, i have only min ;) > > > > well, try example below for min with > > arbitrary larger number of arguments. Hope it can help > > > > #include <assert.h> > > #include <stdio.h> > > #include <stdarg.h> > > > > double > > dmin( int nofargs, ... ) { > > > > double res = 1.0e+38, arg; > > int j; > > va_list ap; > > > > assert( nofargs > 1 ); > > > > va_start(ap, nofargs ); > > > > for( j = 0; j < nofargs; ++j ) { > > arg=va_arg( ap, double ); > > if ( arg < res ) { > > res = arg; > > } > > } > > va_end(ap); > > return res; > > } > > > > int > > main( void ) { > > > > printf( "%e\n", dmin( 2, 1.0, 2.0 ) ); > > > > printf( "%e\n", dmin( 3, 0.0, 1.0, 2.0 ) ); > > > > printf( "%e\n", dmin( 5, 0.0, 1.0, 2.0, 7.0, -0.2 ) ); > > > > return 0; > > } > > > > [skipped] > > > OK, just to be pedantic, the previous example shows very fine > the difference between fortran and C in computations. Since gu ? > min/max are standard fortran functions, it can be supposed they > are maximally optimized with no regards to number of their > arguments (just because the compiler takes care of them). well, FYI, being standard means only that - being standard. Compiler is free to optimize or to insert 5min loop into min/max function. > In the contrary, in the example, we have overhead of the > arguments number evaluation sure... if you know how do not evaluate number of arguments for functions (not min/max in particular) with arbitrary number of arguments, please share your knowledge with us. > and overhead of implementation (not > necessarily this one, generally almost any non-trivial > non-built-in operation has some overhead - there has been some > reason to add into C libraries memcpy, memcmp and so on > functions). what do you mean "overhead"? Can you clarify ? > Using C++ and not C, most probably, I would try to implement > the min function in the following way: > > inline double min(double v1, double v2) { > return v1<v2 ? v1 : v2; > } > inline double min(double v1, double v2, double v3) { > double v=min(v1,v2); return v<v3 ? v : v3; > } > inline double min(double v1, double v2, double v3, double v4) { > double v=min(v1,v2,v3); return v<v4 ? v : v4; > } > inline double min(double v1, double v2, double v3, double v4, double v5) > { > double v=min(v1,v2,v3,v4); return v<v5 ? v : v5; > } please, don't change the nature of the problem - Rick was asking about min/max function with ARBITRARY number of arguments. > Such a way doesn't seem elegant enough and it only emulates > arbitrary number nope. it's not. If the problem is to provide function which can handle arbitrary number of arguments, it cannot be solved by providing function(s) which can handle limited number of arguments. Try to reread logic textbook next time. > started on SunOS 5.5.1 SUNW,Ultra-2 produces > dmin: 3.04 seconds > overloaded min: 1.11 seconds > started on SunOS 5.5.1 SUNW,SPARCstation-4 produces: > dmin: 9.32 seconds > overloaded min: 4.89 seconds > and compiled with -O option with HP C++ A.03.72; and started on > HP-UX A.09.05 9000/715 produces: > dmin: 4.63 seconds > overloaded min: 1.58 seconds well, you compare apples and oranges. You provided solution for related but another problem than Rick was asking for. still, you know better way to handle functions with arbitrary number of arguments (using C++, templates, exceptions whatever), please, share it with us. OK ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~1997-09-25 0:00 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <199709070005.TAA23336@manifold.algebra.com> [not found] ` <5utbth$rdi@snews2.zippo.com> [not found] ` <34131554.73F2310E@roda.roc.servtech.com> 1997-09-09 0:00 ` Java vs. Eiffel vs. C++ in realtime applications James Yang 1997-09-11 0:00 ` Robert Dewar 1997-09-11 0:00 ` Ralph Paul [not found] ` <34157696.16620299@nntp.interaccess.com> [not found] ` <JTV2J.97Sep9170655@cobra.cs.virginia.edu> [not found] ` <3415CE44.3BD531@calfp.co.uk> [not found] ` <341644F2.763D@BZZvnet.ibm.com> 1997-09-11 0:00 ` Mike Rubenstein 1997-09-11 0:00 ` Fergus Henderson 1997-09-11 0:00 ` Volker Hetzer 1997-09-11 0:00 ` Mike Rubenstein [not found] ` <199709110220.VAA24841@manifold.algebra.com> 1997-09-11 0:00 ` Mike Rubenstein 1997-09-12 0:00 ` Valentin Bonnard 1997-09-12 0:00 ` Joachim Durchholz 1997-09-12 0:00 ` Paul Johnson 1997-09-12 0:00 ` Pavel 1997-09-12 0:00 ` Fortran vs C++ vs. etc (has little to do with realtime anymore) Jeffrey Templon 1997-09-13 0:00 ` Joseph M. O'Leary 1997-09-16 0:00 ` James F Cornwall 1997-09-13 0:00 Dr. Krishnan Chittur 1997-09-15 0:00 ` Area Industrial y Electromec�nica 1997-09-16 0:00 ` Vanesch P. 1997-09-16 0:00 ` Jeffrey Templon 1997-09-16 0:00 ` Gary L. Scott 1997-09-17 0:00 ` Jenn-Ching Luo 1997-09-17 0:00 ` Gary L. Scott 1997-09-16 0:00 ` Rick Hawkins 1997-09-18 0:00 ` Oleg Krivosheev 1997-09-19 0:00 ` Rick Hawkins 1997-09-23 0:00 ` Oleg Krivosheev 1997-09-23 0:00 ` Gary L. Scott 1997-09-24 0:00 ` Rick Hawkins 1997-09-24 0:00 ` Xingzeng Liu 1997-09-25 0:00 ` const 1997-09-25 0:00 ` Oleg Krivosheev
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox