www.digitalmars.com Home | Search | C & C++ | D | DMDScript | News Groups | index | prev | next
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.
Jun 13 2002
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.

Jun 13 2002
→ 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.
Jun 13 2002
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
Jun 14 2002
↑ ↓ 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

Jun 14 2002
↑ ↓ 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


Jun 14 2002
↑ ↓ → 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!

Jun 14 2002
"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.

Jun 13 2002
↑ ↓ 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
Jun 14 2002
↑ ↓ "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
Jun 14 2002
↑ ↓ 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
Jun 14 2002
↑ ↓ "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
Jun 14 2002
↑ ↓ 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
Jun 14 2002
↑ ↓ 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
Jun 14 2002
↑ ↓ → 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
Jun 14 2002
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
Jun 14 2002
↑ ↓ "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

Jun 14 2002
↑ ↓ → 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
Jun 14 2002