Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
c++ - Multiple void file pointer definition with new Q.
↑ ↓ ← → E. Trelmar <E._member pathlink.com> writes:
I'm trying to initialize a pointer to a group of pointers in a class, and while
this command worked in other compilers, I get an Error: integer constant
expression expected.
keyx.akeyf = new (void (*[keyx.numf])());
Using a constant in place of keyx.numf removes the error, however, I can't use a
constant in this case, I need a variable.
If anyone can point out the proper syntax I'd appreciate it.
↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:
"E. Trelmar" wrote:
I'm trying to initialize a pointer to a group of pointers in a class, and while
this command worked in other compilers, I get an Error: integer constant
expression expected.
keyx.akeyf = new (void (*[keyx.numf])());
Try:
keyx.akeyf = new ( void * ) [ keyx.numf ];
You can change the code like:
#ifdef __DMC__
keyx.akeyf = new ( void * ) [ keyx.numf ];
#else
keyx.akeyf = new (void (*[keyx.numf])());
#endif
Using a constant in place of keyx.numf removes the error, however, I can't use
a
constant in this case, I need a variable.
If anyone can point out the proper syntax I'd appreciate it.
↑ ↓ ← → E. Trelmar <E._member pathlink.com> writes:
In article <3D08FE45.A0D69045 smartsoft.cc>, Jan Knepper says...
"E. Trelmar" wrote:
I'm trying to initialize a pointer to a group of pointers in a class, and while
this command worked in other compilers, I get an Error: integer constant
expression expected.
keyx.akeyf = new (void (*[keyx.numf])());
Try:
keyx.akeyf = new ( void * ) [ keyx.numf ];
You can change the code like:
#ifdef __DMC__
keyx.akeyf = new ( void * ) [ keyx.numf ];
#else
keyx.akeyf = new (void (*[keyx.numf])());
#endif
Using a constant in place of keyx.numf removes the error, however, I can't use
a
constant in this case, I need a variable.
If anyone can point out the proper syntax I'd appreciate it.
Tried that syntax, got this result:
Error: need explict cast to convert
from: void **
to : void (*C func)()*
I've been trying a wide variety of syntaxes, but I can't find one that doesn't
generate errors.
↑ ↓ ← → Heinz Saathoff <hsaat bre.ipnet.de> writes:
Jan Knepper schrieb...
keyx.akeyf = new (void (*[keyx.numf])());
Try:
keyx.akeyf = new ( void * ) [ keyx.numf ];
Hi Jan, that's not the same! E. Trelmars new expression should result in
a array of pointer to function returning void.
Your Expression would result in ONE void pointer-pointer that is
immediatly indexed with keyx.numf resulting in an uninitialized void
pointer.
Regards,
Heinz
↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:
He wasn't very clear in his example... No typedefs or anything.
In basic the 'new' when wrong because he used different syntax as I tried to
explain:
new ( type* ) [ size ]; instead of new ( type * [ size ] );
I think the latter will not work with DMC++
Jan
Heinz Saathoff wrote:
Jan Knepper schrieb...
keyx.akeyf = new (void (*[keyx.numf])());
Try:
keyx.akeyf = new ( void * ) [ keyx.numf ];
Hi Jan, that's not the same! E. Trelmars new expression should result in
a array of pointer to function returning void.
Your Expression would result in ONE void pointer-pointer that is
immediatly indexed with keyx.numf resulting in an uninitialized void
pointer.
Regards,
Heinz
↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:
So in other words, if he wants to have an array of function pointers...
new ( ( void * ) () ) [ size ];
Might actually work...
However this probably will not work with other compilers...
Because of the 'confusion' about this among the different compilers I prefer to
use a typedef anyways.
Consider this:
typedef char * pchar;
new char [ size ];
new pchar [ size ];
new ( pchar ) [ size ];
new ( char * ) [ size ];
I have no idea why the 'commitee' or who ever is was got such a simple thing
wrong...
new TYPE [ SIZE ];
How much easier could it have been?
I mean, what makes more sense: new ( char * ) [ size ]; or new ( char * [ size ]
);??? <g>
I guess one more reason to go with D!
Jan
Jan Knepper wrote:
He wasn't very clear in his example... No typedefs or anything.
In basic the 'new' when wrong because he used different syntax as I tried to
explain:
new ( type* ) [ size ]; instead of new ( type * [ size ] );
I think the latter will not work with DMC++
Jan
Heinz Saathoff wrote:
Jan Knepper schrieb...
keyx.akeyf = new (void (*[keyx.numf])());
Try:
keyx.akeyf = new ( void * ) [ keyx.numf ];
Hi Jan, that's not the same! E. Trelmars new expression should result in
a array of pointer to function returning void.
Your Expression would result in ONE void pointer-pointer that is
immediatly indexed with keyx.numf resulting in an uninitialized void
pointer.
Regards,
Heinz
↑ ↓ ← → Heinz Saathoff <hsaat bre.ipnet.de> writes:
Jan Knepper schrieb...
So in other words, if he wants to have an array of function pointers...
That's what I expected from his original statement.
new ( ( void * ) () ) [ size ];
Might actually work...
However this probably will not work with other compilers...
... more standard conforming compilers
Because of the 'confusion' about this among the different compilers I prefer to
use a typedef anyways.
This can be helpfull in complex declarations
Consider this:
typedef char * pchar;
new char [ size ];
new pchar [ size ];
new ( pchar ) [ size ];
new ( char * ) [ size ];
I have no idea why the 'commitee' or who ever is was got such a simple thing
wrong...
new TYPE [ SIZE ];
How much easier could it have been?
I mean, what makes more sense: new ( char * ) [ size ]; or new ( char * [ size
]
);??? <g>
I also don't know why the second form of new with new ( type ) is
neccessary and beaving different. Originally I also expected both
declarations the same as you normally can add parenthesis to make things
clearer.
But not everywhere, as in
func(int); // 1
func(int, int); // 2
//...
func(1,2); // 2 called
func((1,2)); // 1 called !?
So sometimes adding parenthesis results in different behaviour.
Regards,
Heinz
I guess one more reason to go with D!
↑ ↓ ← → "Laurentiu Pancescu" <user domain.invalid> writes:
You can try:
void (**p)() = new (void(*)())[100]; // okay with DMC and gcc, but BCC is
buggy here...
The best is:
typedef void (*F)();
F *p = new F[100]; // easy to understand by humans, works with *any*
compiler
In other words, KISS... no offense!
Laurentiu
"E. Trelmar" <E._member pathlink.com> wrote in message
news:aeat4v$v79$1 digitaldaemon.com...
I'm trying to initialize a pointer to a group of pointers in a class, and
this command worked in other compilers, I get an Error: integer constant
expression expected.
keyx.akeyf = new (void (*[keyx.numf])());
Using a constant in place of keyx.numf removes the error, however, I can't
constant in this case, I need a variable.
If anyone can point out the proper syntax I'd appreciate it.
↑ ↓ ← → Heinz Saathoff <hsaat bre.ipnet.de> writes:
Laurentiu Pancescu schrieb...
void (**p)() = new (void(*)())[100]; // okay with DMC and gcc, but BCC is
buggy here...
That should not be ok, because the new-expression end after the last ')'
giving one pointer to pointer to function that is indexed with 100!
Shouldn't work on any compiler. The typedef-ed Version is much better!
New expressions with complicated types are a bit tricky and not so easy
to understand.
Regards,
Heinz
↑ ↓ ← → "Laurentiu Pancescu" <user nowhere.near> writes:
"Heinz Saathoff" <hsaat bre.ipnet.de> wrote in message
news:MPG.1773b49b8e390d589896a2 news.digitalmars.com...
Laurentiu Pancescu schrieb...
void (**p)() = new (void(*)())[100]; // okay with DMC and gcc, but BCC
buggy here...
That should not be ok, because the new-expression end after the last ')'
giving one pointer to pointer to function that is indexed with 100!
Shouldn't work on any compiler. The typedef-ed Version is much better!
Actually, it should: precedence of operator[] is bigger than the precedence
of operator new, so the expression that new sees contains the square
brackets, like "new type[100]". But that's indeed a good proof that just if
you *can* do something, it doesn't mean it's also a good idea to do it...
such code is almost unreadable! I also think the typedef solution is clean
and easy to understand, and it should be always used in such cases.
About BCC: it complains it cannot assign a void(*)() to a void(**)() without
cast. No comment!
New expressions with complicated types are a bit tricky and not so easy
to understand.
That's right! After all, there's a good reason why typedef exists in the
language, and probably ISO-C++ comittee will also add templatized typedefs -
so it shouldn't be considered an obsolete feature. :)
Regards,
Laurentiu
↑ ↓ ← → Heinz Saathoff <hsaat bre.ipnet.de> writes:
Laurentiu Pancescu schrieb...
"Heinz Saathoff" <hsaat bre.ipnet.de> wrote in message
news:MPG.1773b49b8e390d589896a2 news.digitalmars.com...
Laurentiu Pancescu schrieb...
void (**p)() = new (void(*)())[100]; // okay with DMC and gcc, but BCC
buggy here...
That should not be ok, because the new-expression end after the last ')'
giving one pointer to pointer to function that is indexed with 100!
Shouldn't work on any compiler. The typedef-ed Version is much better!
Actually, it should: precedence of operator[] is bigger than the precedence
of operator new, so the expression that new sees contains the square
brackets, like "new type[100]".
I once thought the same but was told that this is not the case (by some
professionals in the german C++ newsgroup). Reading chapter 5.3.4 on the
valid forms of new expression you find
new-expression:
new new-placement_opt new-type-id new-initializer_opt
new new-placement_opt ( new-type-id ) new-initializer_opt
Note the second form with explicit parenthesis. Without the optional
new-initializer the new expression ends at the closing ')'. The usual
higher prceeding of [] does not apply because it can only by applied to
an object in a new expression. The opject is what new returns.
But that's indeed a good proof that just if
you *can* do something, it doesn't mean it's also a good idea to do it...
such code is almost unreadable! I also think the typedef solution is clean
and easy to understand, and it should be always used in such cases.
Right!
The problem is that you can make declarations much easyer with typedefs
but need the original type for accessing the object, as in
typedef void (*FUNC_PTR)();
FUNC_PTR *p = new FUNC_PTR[10]; // table of 10 functions
// ...
(*p[2])(); // call third func in table
About BCC: it complains it cannot assign a void(*)() to a void(**)() without
cast. No comment!
BCC is right here! BTW, my PC-Lint also complains and gives this
messages:
--- Module: ab.cpp
_
void (**p)() = new (void(*)())[100];
ab.cpp 3 Error 64: Type mismatch (initialization) (void (**)(void)
= void (*)(void))
ab.cpp 3 Warning 416: creation of out-of-bounds pointer (100 beyond
end of data) by operator '[' [Reference: file ab.cpp: line 3]
_
void (**p)() = new (void(*)())[100];
ab.cpp 3 Info 815: Arithmetic modification of unsaved pointer
ab.cpp 3 Warning 415: access of out-of-bounds pointer (100 beyond
end of data) by operator '[' [Reference: file ab.cpp: line 3]
ab.cpp 3 Info 831: Reference cited in prior message
New expressions with complicated types are a bit tricky and not so easy
to understand.
That's right! After all, there's a good reason why typedef exists in the
language, and probably ISO-C++ comittee will also add templatized typedefs -
so it shouldn't be considered an obsolete feature. :)
What do you mean with templatized typedefs?
Regards,
Heinz
↑ ↓ ← → "Laurentiu Pancescu" <user nowhere.near> writes:
"Heinz Saathoff" <hsaat bre.ipnet.de> wrote in message
news:MPG.1773f18cf61e8a219896a3 news.digitalmars.com...
new-expression:
new new-placement_opt new-type-id new-initializer_opt
new new-placement_opt ( new-type-id ) new-initializer_opt
Note the second form with explicit parenthesis. Without the optional
new-initializer the new expression ends at the closing ')'. The usual
higher prceeding of [] does not apply because it can only by applied to
an object in a new expression. The opject is what new returns.
Right, thanks! What fooled me is that when you write "new unsigned
int[100]", you get what you'd expect...
But that's indeed a good proof that just if
you *can* do something, it doesn't mean it's also a good idea to do
such code is almost unreadable! I also think the typedef solution is
and easy to understand, and it should be always used in such cases.
About BCC: it complains it cannot assign a void(*)() to a void(**)()
cast. No comment!
BCC is right here!
Yes, it seems so, I tried today with Comeau, and it says the same. And it
also compiles the original syntax:
new (void(*[100])()), just as gcc. So, it seems like another bug in DMC?
New expressions with complicated types are a bit tricky and not so
to understand.
That's right! After all, there's a good reason why typedef exists in
language, and probably ISO-C++ comittee will also add templatized
so it shouldn't be considered an obsolete feature. :)
What do you mean with templatized typedefs?
Something like:
template<typename T>
typedef vector<T> vt;
vt<int> vec_int; // stupid example, and illegal for now...
With current standard, you have to do:
template<typename T>
struct X
{
typedef vector<T> vt;
};
X<int>::vt vec_int;
Stuff like this seems to be used a lot in Loki library (Andrei
Alexandrescu), and I read in CUJ they are serious about adding templatized
typedefs to standard.
Best regards,
Laurentiu
↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:
Yes, it seems so, I tried today with Comeau, and it says the same. And it
also compiles the original syntax:
new (void(*[100])()), just as gcc. So, it seems like another bug in DMC?
DMC++ has been known to be different on this (more sensible I would call it!)
for years!
I questioned this years ago in the Symantec newsgroups and Walter himself
replied with something like:
"We have been known to be different at times"
Jan
↑ ↓ ← → Heinz Saathoff <hsaat bre.ipnet.de> writes:
Jan Knepper schrieb...
Yes, it seems so, I tried today with Comeau, and it says the same. And it
also compiles the original syntax:
new (void(*[100])()), just as gcc. So, it seems like another bug in DMC?
DMC++ has been known to be different on this (more sensible I would call it!)
for years!
Nice said :-)
I questioned this years ago in the Symantec newsgroups and Walter himself
replied with something like:
"We have been known to be different at times"
So what's the difference between different and bug?
Regards,
Heinz
↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:
DMC++ has been known to be different on this (more sensible I would call it!)
for years!
Thanks!
I questioned this years ago in the Symantec newsgroups and Walter himself
replied with something like:
"We have been known to be different at times"
I would not know...
different is different, a bug is a bug... <g>
Jan
↑ ↓ ← → Heinz Saathoff <hsaat bre.ipnet.de> writes:
E. Trelmar schrieb...
keyx.akeyf = new (void (*[keyx.numf])());
Using a constant in place of keyx.numf removes the error, however, I can't use
a
constant in this case, I need a variable.
If anyone can point out the proper syntax I'd appreciate it.
Seems DMC has a problem here. But there is a workaround! I assume that
akeyf is declared like this:
struct {
//... something else
void (**akeyf)();
} keyx;
Instead of
keyx.akeyf = new (void (*[keyx.numf])());
that should be correct you can introduce a typedef:
typedef void (*FUNC_PTR)();
keyx.akeyf = new FUNC_PTR[keyx.numf];
Now DMC compiles!
Regards,
Heinz
↑ ↓ ← → "DigitalMars" <mcmprch soundbeachfinancial.com> writes:
I've been a C programmer, with some C++ exposure...I guess I don't
understand whats wrong with :
keyx.akeyf = new (void (*[keyx.numf])());
Shouldn't that return:
(english parsing logic: (from my C memory))
start innermost : an array, size keyx.numf
go left to parens: of pointers
hit parens: to functions
hit parens: that return void?
Michael
"Heinz Saathoff" <hsaat bre.ipnet.de> wrote in message
news:MPG.1773b308bc716a039896a1 news.digitalmars.com...
E. Trelmar schrieb...
keyx.akeyf = new (void (*[keyx.numf])());
Using a constant in place of keyx.numf removes the error, however, I
constant in this case, I need a variable.
If anyone can point out the proper syntax I'd appreciate it.
Seems DMC has a problem here. But there is a workaround! I assume that
akeyf is declared like this:
struct {
//... something else
void (**akeyf)();
} keyx;
Instead of
keyx.akeyf = new (void (*[keyx.numf])());
that should be correct you can introduce a typedef:
typedef void (*FUNC_PTR)();
keyx.akeyf = new FUNC_PTR[keyx.numf];
Now DMC compiles!
Regards,
Heinz
↑ ↓ ← → Heinz Saathoff <hsaat bre.ipnet.de> writes:
DigitalMars schrieb...
keyx.akeyf = new (void (*[keyx.numf])());
Shouldn't that return:
(english parsing logic: (from my C memory))
start innermost : an array, size keyx.numf
go left to parens: of pointers
hit parens: to functions
hit parens: that return void?
absolute correct! That's what the new expressoin should return, only
that the array is converted to a pointer to the first element of the
allocated array.
Regards,
Heinz
|
|