www.digitalmars.com         C & C++   DMDScript  

c++ - Multiple void file pointer definition with new Q.

reply 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
next sibling parent reply 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
next sibling parent 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
prev sibling parent reply 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
parent reply 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
parent reply 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
parent 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
prev sibling next sibling parent reply "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


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
parent reply 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
parent reply "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




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!


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
parent reply 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




 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!


 
 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
parent reply "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




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!


 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






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?


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
parent reply 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
parent reply 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
parent Jan Knepper <jan smartsoft.cc> writes:
 DMC++ has been known to be different on this (more sensible I would call it!)
 for years!


 Nice said :-)


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"


 So what's the difference between different and bug?


I would not know...
different is different, a bug is a bug... <g>

Jan
Jun 14 2002
prev sibling parent reply 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
parent reply "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




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
parent 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