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

I'll look into adding a switch for you.

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!

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

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

"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."

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."
>
>

"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>.

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?

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?