clindh@Stride.COM (Christer Lindh) (06/10/88)
Does anyone know this? I can't find this
information in the C++ book, but I may have missed something:
1)
I want to define overloads to a function Print (used for a interface
to curses), it can either take;
a) one character,
b) a character pointer, or
c) a character pointer *and* a variable number of other arguments
(because I don't want to call the function that uses varargs
unless it needs to be printed with printf)
I came up with this:
// class-definitions and stuff
public:
void Print(char c) { waddch (w,c); }
void Print(char* s) { waddstr(w,s); }
void Print(char* ...); // Function that uses varargs
// end of class
But GNU C++ can't distinguish between the two last declarations, it
thinks that is ambigious. I tried it on AT&T C++ as well, and this
example compiles, but if I remove the first line ( Print(char c) ),
it fails with "two declarations of Print()"! Bug or feature??
The definition for ellipis (r.8.4, C++ Programming Language):
"the number of arguments is known to be *equal to or
greater* than the number of argument types specified"
but what I want is a type of ellipsis that means:
"the number of arguments is known to be *greater*
than the number of argument types specified"
Is there anyway to do this ? I've tried Print(char *, ...) which
makes sense to me but that gave the same result.
2)
In an inline function with variable number of arguments, is there a
way to reference the variable part, ie how can I pass them on to the
function that knows about varargs ? I would like to do something
like this:
// class definitions ...
void Print(char* fmt ... ) { wprintw( w, fmt, ... ); }
^
|
I want to put the rest of
the arguments here, but how
do I name them ?
// end of class
I don't want to mess with varargs in the in-line code as wprintw()
knows how to deal with variable number of arguments. I want:
Print("Foo %d %d %d\n", 1, 2, 3);
to be expanded to this inline code:
wprintw( this->w, "Foo %d %d %d\n", 1, 2 3);
It can't be done with the standard C preprocessor, but I hope C++ is
better.
--
clindh@stride.COM :: The Fittest Shall Survive
Stride Product Group, R&D :: Yet The Unfit May Live.
MicroSage Computer Systems, Inc. ::
Reno, NV, (702) 322-6868 :: We Must Repeat ! english@stromboli.usc.edu (Joe English) (11/28/88)
In the Book, section 8.5.1 (Static Members), p. 275, it states:
"No initializer can be specified for a static member, and __it cannot
be of a class with a constructor__." I'm not sure if I'm parsing this
sentence correctly: does it mean that a class with a constructor can
have no static members? Also, if no initializer can be specified,
where and how does a static member get initialized?
Second question: if automatic temporary objects are created when
necessary and are destroyed at the first opportunity (like when a
function returns a class object), how does the compiler know when the
object is no longer needed? For example, is the following correct:
(What I want to happen is for the addresses of the (automatic) frobs
created by the calls to frob::frob(int) to be stored in v, and for the
frobs themselves to *remain intact* for the life of the function.)
class frob {
...
public:
frob(int) {...}
};
class frobpvector { // a vector of pointers to frobs
frob *list[MAX];
frob **next;
public:
frobpvector() { next = list; }
void append(frob&);
};
void frobpvector::append(frob& f) { *next++ = &f; }
void diddle()
{
frobpvector v;
v.append(frob(1)); // frob(1) returns a temporary
// ...
v.append(frob(2)); // frob(2) should be a *different* frob
// ... do stuff with the frobs pointed to in v
}
In other words, if an automatic temporary object is passed to a
function as a reference parameter, _is the space allocated to that
temporary object guarranteed to not be overwritten in the current
scope_?
This is probably in TFM, but I cannot for the life of me find where it
is explicitly stated. I need to know for sure, or else I will have to
rethink an important class interface.
BTW, Zortech C++ seems to be doing (what I feel is) the right thing
here.
/|/| "How do you convince your dermatologist
-----< | | that you're being sexually responsible?
O \|\| english%lipari@oberon.usc.edu (Joe English)shap@polya.Stanford.EDU (Jonathan S. Shapiro) (11/29/88)
In article <13683@oberon.USC.EDU> english@stromboli.usc.edu (Joe English) writes: > In the Book, section 8.5.1 (Static Members), p. 275, it states: >"No initializer can be specified for a static member, and __it cannot >be of a class with a constructor__." I'm not sure if I'm parsing this >sentence correctly: does it mean that a class with a constructor can >have no static members? Also, if no initializer can be specified, >where and how does a static member get initialized? I believe that what this means is that if I say: class Fred { static Member member; ... } where Member is also a class, then Member is not permitted to have a constructor. It is my vague recollection that this may have been relaxed to a lesser restriction: that Member can have a constructor that takes no arguments. Could someone confirm or deny this last bit? Bjarne? > Second question: if automatic temporary objects are created when >necessary and are destroyed at the first opportunity (like when a >function returns a class object), how does the compiler know when the >object is no longer needed? For example, is the following correct: > >[... much of example deleted ...] > >void diddle() > >{ > frobpvector v; > > v.append(frob(1)); // frob(1) returns a temporary > // ... > v.append(frob(2)); // frob(2) should be a *different* frob > > // ... do stuff with the frobs pointed to in v > >} I do not know quite what the scoping rules are for temporaries. I believe that GNU G++, for example, attempts to reuse the space and to peephole them out of existence when possible. In any case, I read "destroyed at the first opportunity" to mean "destroyed as soon as possible." My general reaction to this is that functions that accept an object reference are not entitled to assume that the object continues to exist after the function call. This means that the scope of the temporary above is free to be the temporal scope of the function call itself, and the compiler is free to destroy the object after the function call returns. If the fropvector wants to ensure that it retains a copy of the object, than in C++ it is necessary to make a copy. It also seems to me that if my understanding is correct, then applying foo(X&) to a temporary is for exactly this reason an unreasonable thing to do, and ought to be a compiler error. The compiler ought to apply foo(X), which presumably is smart enough to understand that the behavior must be copying. Until someone indicates what the correct behavior is, the safest bet is to modify your function to read: void diddle() { frobpvector v; Frob f1(1), f2(2); v.append(f1); v.append(f2); ... } As a side observation, this sort of detail is the kind of thing that compilers routinely get wrong or abuse in their optimization phases. It is therefore not a real good thing to rely on. Further, instantiating the temporaries explicitly makes it easier on the reader - it is now obvious that they are temporaries. Jonathan S. Shapiro AT&T Bell Laboratories
mwg@inxsvcs.UUCP (Phil Blecker) (11/29/88)
In article <13683@oberon.USC.EDU>, english@stromboli.usc.edu (Joe English) writes: > > In the Book, section 8.5.1 (Static Members), p. 275, it states: > "No initializer can be specified for a static member, and __it cannot > be of a class with a constructor__." That means that a static member of a class can be an instance of a class. But the static member's class cannot define a constructor. The class containing the static member CAN have a constructor. For instance: class has_constructor { int i; public: has_constructor( int j ) : i( j ) {} }; class no_constructor { int i; public: }; class static_member { static has_constructor h; // won't compile static no_constructor n; // will compile: n.i is uninitialized static int i; // will compile: i is uninitialized public: static_member(); }; Static members are initialized the same way any other static uninitialized data is during startup (usually [hopefully?] to all 0's). > > Second question: if automatic temporary objects are created when > necessary and are destroyed at the first opportunity (like when a > function returns a class object), how does the compiler know when the > object is no longer needed? > This is implementation dependent. When space is allocated automatically, it will not be overwritten during the scope of the object: that is guaranteed. Many compilers allocate space on the stack for ALL automatic objects declared when the function is entered, regardless of their scope (the function's stack space is not enlarged dynamically during the execution of a function). It is up to the compiler to create code that makes sure the object is only referred to within its proper scope. There may be other cases I can't think of right now, but automatic objects must at least be destroyed at the end of the block in which they are declared, or before a return statement causes the function to be exited (or before exiting if the function returns implicitly). If a class has a destructor, then this means that each instance's destructor will be called after calculating the value the return statement will return, but before the function is exited. It also means that the destructor is called before a block ends. So, a function which allocates many automatic objects and has many return statements will have many lines of code code to destroy the automatics (once before each return) if you're using a compiler that translates to C code (actual compilers might use another method that produces far less code). > > (What I want to happen is for the addresses of the (automatic) frobs > created by the calls to frob::frob(int) to be stored in v, and for the > frobs themselves to *remain intact* for the life of the function.) > There's no problem with this, although the method you used only works by accident in my opinion: > > v.append(frob(1)); // frob(1) returns a temporary > Basically what you have done is created a frob instance within the scope of a block that is a function call. Technicaly, the object should only exist for as long as it takes to call v.append(), and then be destroyed. Since there is no destructor associated with a frob, destroying the object does nothing; and since most compilers allocate space for the object when the function is entered, and deallocate the space when the function is exited, you are left with a side-effect that the object still exists even though it should have been destroyed. You can dramatically see the effects of this unless you put your code inside a loop. The compiler I have interprets the code you supplied as indicating that you have allocated actual stack space for only 2 frob objects, which are constantly reinitialized (by calling the frob constructor) because of the fact that a function call can be considered as block. In this case your vector would end up getting many, many pointers to the same 2 frob objects which are hanging around much longer than they should due to the implementation of the compiler. Thus the value of the objects pointed to in your array will vary depending on the current number of iterations through the loop; probably not what you expected. It would probably be better to use new to allocate the frobs, and design an interface that expects ~frobpvector to delete the frobs stored in the vector. Either that or at least include a warning to users of frobpvector. Just to make all these words easier to understand, I wrote an example using the code you originally supplied: class frob { int i; public: friend ostream &operator<<( ostream &o, frob &f ) { return o << f.i; } frob(int j) : i(j) {} ~frob() { cout << "~" << i << " "; } }; const int MAX=8; class frobpvector { // a vector of pointers to frobs frob **next; public: frob *list[MAX]; frobpvector() { next = list; } void append(frob&f) { *next++ = &f; } }; int main() { frobpvector v; for ( int i = 0; i < 6; ) { v.append(frob(i++)); v.append(frob(i++)); frob **next = v.list; for ( int j = i; j--; ) { cout << *(*next++) << " "; } cout << "\n"; } return 0; } and got the following (which is what I expected to happen): ~1 ~0 0 1 ~3 ~2 2 3 2 3 ~5 ~4 4 5 4 5 4 5 Note that the destructor is called twice each iteration of the loop (right after v.append()), and that the same memory space is used over and over again. I put the destructor in to graphically show that the space is only guaranteed to exist during the scope of the v.append() function. But the compiler, rather than dynamically allocating space on the stack, allocates space only once (which makes a lot of sense to me -- dynamically allocating stack space would be an extremely inefficient use of a CPU's time in this or any other case -- that's what new and delete are for -- to give the programmer control over dynamically allocated memory). If frob contained pointers to something, this could cause incredible havoc (especially is the pointers were to memory from new). If you really want to do things the way you showed, allocate the frob objects before the call to v.append(): frob f1( 1 ); v.append( f1 ); That will extend the scope to the block in which f1 is declared, which must be the entire block in which v is to be used. Hope that clears things up a bit -- it wasn't easy to describe briefly. If you have any further questions, feel free to contact me via e-mail or by phone (+1 818-243-3053). -- Phil Blecker none of my ideas belong to me and uunet!inxsvcs!mwg i can't see anything wrong with that