At 9:17 PM +0200 on 6/12/99, M. Uli Kusterer wrote:

>Yeah, something like that. wx has a cool string class that looks almost
>like ANSI's.

Why not the ISO's classes?

>There are possible workarounds. E.g. some German apps have:
>
>Beim Kompilieren der Datei "script.txt" ist ein Fehler aufgetreten:
>Es ist nicht gen�gend RAM verf�gbar.
>
>I'm sure something like that would work in any language.

I think we'd best find out from people who speak the other languages. But
more importantly, lingual hacks are no basis for a system of sound error
messages!


>A cross-platform routine in the same nature as ParamText or vsprintf(), yes.

Hmmm... I think we're looking for "[s]printf".

>
>>I'd think that every C++ compiler does; it's been there for quite some
>>time. And it's the only way to initialize classes (within the class) inside
>>a constructor.
>
> Oh? Great! That was in none of my books.

Aha! You need better books!

>Good technique, leave it in
>there. But we should make it a convention not to mix and mingle member
>initializing and constructor calls, i.e.
>
>MyClass::MyClass( p1, p2 )
>       : subClass(p1), subClass(p2)
>       mMemberVar(p1), mMemberVar(p2)
>
>a second line for those.

I normally seperate them by use -- e.g, i'd put all the "valid"'s in OTVar
together. I may not of, though.

>
>>It is a function being called. (You didn't expect me to say that now, did
>>you?) It's a constructor call.
>
>Well, it's in a mamber variable, and not one of the parents of our class.
>We should make sure we separate that so people can immediately discover
>missing constructor calls

The lack of one is not a missing constructor call; it is merely an implicit
call to the default constructor. I should of been more clear. It's the only
way to call a non-default constructor for a class within a class. BTW: If
there is no default constructor, one gets an error if one does not use this.

>without having to wade through dozens of member
>variables. Agreed?

No. I fail to see any good reason to distinguish between a class and a
built-in type. Other than the obvoius and necissary differences (one is
real, on is not), there should nto be a difference between Complex<double>
and double. And usually, C++ is good at seeing to this -- why else would we
have overloaded operators, standard I/O functions for every type (<< and
>>), etc.?

>--- HELP SAVE HYPERCARD: ---
>Details at: http://www.hyperactivesw.com/SaveHC.html
>Sign: http://www.giguere.uqam.ca/petition/hcpetition.html

Or, rewrite it: <http://www.where_is_alain_farmer.com/OpenCard/>
Seriously, I'm going to put up the OC page myself on my ISP's server if
Alain does not get an ASIP userid/password to me...

Reply via email to