www.digitalmars.com         C & C++   DMDScript  

c++ - void * and C++ - aaggh!

reply John Jameson <John_member pathlink.com> writes:
Hi Walter

Great to see that DM is still going strong.

We've been using Symantec 7.5 for years (and Zortech before that) to develop our
Proteus product line and whilst I've got the DM CD, we never had a strong reason
to port - till now.

That reason is long doubles, which I want to use in our SPICE simulator to get
better accuracy. So I gave it all a whirl, and things were looking good - all
our code compiled with only minor changes.

Execept that I then ran into what I think is the 'long double backwards branch'
bug which you fixed in V8.41. My CD was 8.33, so I thought lets up date to the
latest version. Recompiling the offending file fixed the comparison bug, but
then when I came to recompile the rest of the project I've hit a huge snag.

It is that you've disallowed implicit casting of VOID * to other types, also in
V8.41. We have alot (100,000 lines ) of legacy code that makes such casts and
this one reason why I've shied from porting to VC++ or other, newer, compilers.

Please, please, pretty please, can we have a compiler switch to turn this error
off, as then I can use the latest DM compiler without going through all that
code to add explicit casts!

Yours hopefully...
John Jameson
Jul 14 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
I'll look into adding a switch for you.
Jul 14 2005
parent reply John Jameson <John_member pathlink.com> writes:
In article <db7bjr$10ia$2 digitaldaemon.com>, Walter says...

I'll look into adding a switch for you.


You are a STAR :-)

Whilst we're at this, the other thing that seems to have changed is the ability
to implicitly cast 'char **' to 'const char **'. I would have thought that this
was perfectly reasonable, but evidently the newer language standard says no.

Best Regards
John
Jul 15 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"John Jameson" <John_member pathlink.com> wrote in message
news:db7v0e$1tqv$1 digitaldaemon.com...

 In article <db7bjr$10ia$2 digitaldaemon.com>, Walter says...

I'll look into adding a switch for you.


 You are a STAR :-)

 Whilst we're at this, the other thing that seems to have changed is the


ability

 to implicitly cast 'char **' to 'const char **'. I would have thought that


this

 was perfectly reasonable, but evidently the newer language standard says


no.

I think you may have to give up on that one. The const rules are completely
wacky, and an endless source of "it works this way on this compiler, and
that way on another."
Jul 15 2005
parent reply John Jameson <John_member pathlink.com> writes:
Hi Walter

Well, I can work round the const one more easily - I just mentioned it because
the behaviour had changed from 8.33 to 8.43 and it broke some other bits of our
code. If push comes to shove I can just de-const some function parameters and
that will solve most of it.

Mind you, if your view is that the rules are wacky and everyone does it
differently then why change it, especially as char ** to const char ** is
entirely safe?

Cheers,
John



In article <db8t54$2msa$1 digitaldaemon.com>, Walter says...

"John Jameson" <John_member pathlink.com> wrote in message
news:db7v0e$1tqv$1 digitaldaemon.com...

 In article <db7bjr$10ia$2 digitaldaemon.com>, Walter says...

I'll look into adding a switch for you.


 You are a STAR :-)

 Whilst we're at this, the other thing that seems to have changed is the


ability

 to implicitly cast 'char **' to 'const char **'. I would have thought that


this

 was perfectly reasonable, but evidently the newer language standard says


no.

I think you may have to give up on that one. The const rules are completely
wacky, and an endless source of "it works this way on this compiler, and
that way on another."
Jul 16 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"John Jameson" <John_member pathlink.com> wrote in message
news:dbb5dd$1nhj$1 digitaldaemon.com...

 Hi Walter

 Well, I can work round the const one more easily - I just mentioned it


because

 the behaviour had changed from 8.33 to 8.43 and it broke some other bits


of our

 code. If push comes to shove I can just de-const some function parameters


and

 that will solve most of it.

 Mind you, if your view is that the rules are wacky and everyone does it
 differently then why change it, especially as char ** to const char ** is
 entirely safe?


It's wacky because it's an endless series of special cases. Trying to adjust
those special cases with a switch makes it even wackier <g>.
Jul 16 2005
prev sibling parent reply Christof Meerwald <cmeerw web.de> writes:
On Sat, 16 Jul 2005 14:25:49 +0000 (UTC), John Jameson wrote:

 Mind you, if your view is that the rules are wacky and everyone does it
 differently then why change it, especially as char ** to const char ** is
 entirely safe?


But it's not entirely safe, here is an example:

#include <stdio.h>

const char const_data[] = "hello world";

int main()
{
  char *c;
  // explicit cast required (because it's not safe)
  const char **ptr = (const char **) &c;
  *ptr = const_data;

  c[0] = 'H'; // modifying const data
  printf("%s\n", c);

  return 0;
}


bye, Christof

-- 
http://cmeerw.org
mailto:cmeerw at web.de                       xmpp:cmeerw at cmeerw.org

...and what have you contributed to the Net?
Jul 16 2005
parent John Jameson <John_member pathlink.com> writes:
Must admit that's both cleverly observed and logically correct, albeit in what
is a somewhat unlikely scenario.

But no wonder everyone gets confused trying to understand (let alone implement)
the rules! Makes me appreciate somewhat more why Walter has gone where he has
with 'D'.

Regards
John



In article <newscache$j9nqji$mz9$1 msgid.cmeerw.org>, Christof Meerwald says...

On Sat, 16 Jul 2005 14:25:49 +0000 (UTC), John Jameson wrote:

 Mind you, if your view is that the rules are wacky and everyone does it
 differently then why change it, especially as char ** to const char ** is
 entirely safe?


But it's not entirely safe, here is an example:

#include <stdio.h>

const char const_data[] = "hello world";

int main()
{
  char *c;
  // explicit cast required (because it's not safe)
  const char **ptr = (const char **) &c;
  *ptr = const_data;

  c[0] = 'H'; // modifying const data
  printf("%s\n", c);

  return 0;
}


bye, Christof

-- 
http://cmeerw.org
mailto:cmeerw at web.de                       xmpp:cmeerw at cmeerw.org

...and what have you contributed to the Net?
Jul 17 2005
prev sibling next sibling parent reply Anuj Goyal <Anuj_member pathlink.com> writes:
Gah :) as a c++ developer you know this is going to bite you.  Better to take 10
of your developers and spend a day or two doing the right thing.  You will be
very very happy in the end.

We spent 6 months figuring out howto do proper parallel builds with jam (make
just doesn't cut it) and now we can reap the benefits of a truly parallel build
with proper dependency checking. Our builds went from 8 hours of serial build
hell to 10 minutes of happiness.


It is that you've disallowed implicit casting of VOID * to other types, also in
V8.41. We have alot (100,000 lines ) of legacy code that makes such casts and
this one reason why I've shied from porting to VC++ or other, newer, compilers.

Please, please, pretty please, can we have a compiler switch to turn this error
off, as then I can use the latest DM compiler without going through all that
code to add explicit casts!
Jul 15 2005
parent reply John Jameson <John_member pathlink.com> writes:
As a small company, we don't have 10 developers. Let alone 10 developers to
spare for a largely pointless exercise...

Firstly, all those casts would just make the code less readable, to no benefit.

Why on earth should I have to write

CHAR *p = (CHAR *)malloc(n)

let alone

CHAR *p = static_cast<CHAR *>malloc(n)

if we were being really pure :-)

Oh, and don't then tell me I should be using 'new', because there is no realloc
mechanism available with new, so then we would have to (a) change the logic of
the code (leading to lots of potential bugs and breakages) and (b) lose
efficiency, none of this benefitting the usability of the application one jot.

Also, since SPICE was originally written in 'C', we have no choice but to blend
C++ and C code within the application so we can't do 'pure' C++.

Of course, I'm asking for a switch here, not to revert the behaviour permanently
so it's not like it will spoil the compiler for the purists out there.

Walter, of course, is a star and understands/sympathizes with my situation
rather better, I think :-)



In article <db7om3$1om0$1 digitaldaemon.com>, Anuj Goyal says...

Gah :) as a c++ developer you know this is going to bite you.  Better to take 10
of your developers and spend a day or two doing the right thing.  You will be
very very happy in the end.

We spent 6 months figuring out howto do proper parallel builds with jam (make
just doesn't cut it) and now we can reap the benefits of a truly parallel build
with proper dependency checking. Our builds went from 8 hours of serial build
hell to 10 minutes of happiness.


It is that you've disallowed implicit casting of VOID * to other types, also in
V8.41. We have alot (100,000 lines ) of legacy code that makes such casts and
this one reason why I've shied from porting to VC++ or other, newer, compilers.

Please, please, pretty please, can we have a compiler switch to turn this error
off, as then I can use the latest DM compiler without going through all that
code to add explicit casts!
Jul 15 2005
parent "Walter" <newshound digitalmars.com> writes:
"John Jameson" <John_member pathlink.com> wrote in message
news:db7u01$1t2d$1 digitaldaemon.com...

 Oh, and don't then tell me I should be using 'new', because there is no


realloc

 mechanism available with new,


There's one bug I fixed with D <g>.
Aug 20 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"John Jameson" <John_member pathlink.com> wrote in message
news:db5ke4$2jf1$1 digitaldaemon.com...

 Please, please, pretty please, can we have a compiler switch to turn this


error

 off, as then I can use the latest DM compiler without going through all


that

 code to add explicit casts!


Done, it's in the beta section now.
Jul 20 2005
parent john jameson <john_member pathlink.com> writes:
Many, many thanks for that. Have now got large chunks of our codebase ported and
so far no serious problems. Making literal strings const char * (v 8.44) is a
minor nuisance but the amount of broken code there is proving manageable.

Thanks once again for adding the switch.

John.

In article <dbna40$1h17$1 digitaldaemon.com>, Walter says...

"John Jameson" <John_member pathlink.com> wrote in message
news:db5ke4$2jf1$1 digitaldaemon.com...

 Please, please, pretty please, can we have a compiler switch to turn this


error

 off, as then I can use the latest DM compiler without going through all


that

 code to add explicit casts!


Done, it's in the beta section now.
Jul 25 2005