On Sat, 27 Mar 2004 11:22:05 -0800, "Walter" <walter@digitalmars.com> wrote:

>
>"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:gtua60h5lcbj5lqtnb3as1rph0pfjgg642@4ax.com...
>> There should at least be an "unknown" vendor enum value so that a new
>> vendor can ship before the next revision of phobos comes out with
>> the "current vendor list".
>> If the string vendor name is in there they why even have the enum?
>> If the speed of doing a string compare is that important the user can
>> cache the vendor value somewhere:
>> int isDigitialMars = cmp(std.compiler.name,"Digital Mars D");
>
>That's a good idea, but I think having a two level set of names is a bit klunky.

I'm not sure what you mean by two level... The enum is alreay a redundant piece of information since the name should be a unique identifier.

>> Let's say GDC comes out (not so hypothetical!). What does its compiler.d look like? If it has something like
>>
>>     // Vendor specific string naming the compiler
>>     char[] name = "GNU D Compiler";
>>
>>     // Master list of D compiler vendors
>>     enum Vendor
>>     {
>>         DigitalMars = 1
>>         GDC = 2;
>>     }
>>
>> Then in order for user code that references Vendor.GDC to compile
>> you (meaning DMD) would need to make a release with that enum value.
>> So whenever a new compiler comes out every other compiler needs
>> to make a release with the new enum? hmmm.
>
>Since it doesn't matter what the enum values are for various vendors, the customer can edit the compiler.d to put in any missing ones he needs.

As a library writer I can either use the string to compare *or* I
can rely on an enum value that I have to tell my users to add
to the phobos library if they want my code to compile. Which is
easier to use? I haven't ever needed to edit Microsoft's MSVC
headers just to compile someone's code. It feels icky.

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:htag605oeddmj0u62t14q9csophtfpltgb@4ax.com...
> >Since it doesn't matter what the enum values are for various vendors, the customer can edit the compiler.d to put in any missing ones he needs.
> As a library writer I can either use the string to compare *or* I
> can rely on an enum value that I have to tell my users to add
> to the phobos library if they want my code to compile. Which is
> easier to use? I haven't ever needed to edit Microsoft's MSVC
> headers just to compile someone's code. It feels icky.

Having the string as an alternate is probably a good idea.

Walter wrote:
>>As a library writer I can either use the string to compare *or* I
>>can rely on an enum value that I have to tell my users to add
>>to the phobos library if they want my code to compile. Which is
>>easier to use? I haven't ever needed to edit Microsoft's MSVC
>>headers just to compile someone's code. It feels icky.
> 
> 
> Having the string as an alternate is probably a good idea.

So then you have a string that works always and an enum value that you sometimes have to hack to get it to work properly but that is intended to do the same thing.

What's the sense in having the enum value, then? The string by itself is entirely sufficient!

Walter wrote:
> "Ben Hinkle" <bhinkle4@juno.com> wrote in message
> news:htag605oeddmj0u62t14q9csophtfpltgb@4ax.com...
> 
>>>Since it doesn't matter what the enum values are for various vendors, the
>>>customer can edit the compiler.d to put in any missing ones he needs.
>>
>>As a library writer I can either use the string to compare *or* I
>>can rely on an enum value that I have to tell my users to add
>>to the phobos library if they want my code to compile. Which is
>>easier to use? I haven't ever needed to edit Microsoft's MSVC
>>headers just to compile someone's code. It feels icky.
> 
> 
> Having the string as an alternate is probably a good idea.

Perhaps I'm missing the point of this thread, but it seems to me that requiring the vendor to do twice as much makes it half as likely that they'll get it right.

I trust Ben and David; it's the multi-national corporations I'm wary of.

I say keep the string. Drop the enum -- it's just another thing to go wrong.


-- 
Justin
http://jcc_7.tripod.com/d/

Hauke Duden wrote:

> Walter wrote:
>
>> Having the string as an alternate is probably a good idea.
>
>
> So then you have a string that works always and an enum value that you sometimes have to hack to get it to work properly but that is intended to do the same thing.
>
> What's the sense in having the enum value, then? The string by itself is entirely sufficient!
>
Using enum would help prevent bloat and is more efficient then string in the compiled executable.

I'm thinking about openGL and it's extensions.  Both enums (constants) and strings were used for slightly different purposes.  Like in openGL, I think strings could be used for the dynamic/hardware side of things and enums for the constant vendor things, with some overlap.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:
>> So then you have a string that works always and an enum value that you sometimes have to hack to get it to work properly but that is intended to do the same thing.
>>
>> What's the sense in having the enum value, then? The string by itself is entirely sufficient!
>>
> Using enum would help prevent bloat and is more efficient then string in the compiled executable.

Do you seriously consider one static string for the compiler vendor "bloat"? It's a dozen or so bytes of overhead - if that is too much then any HLL is the wrong choice.

Regarding the efficiency: you can compare the string once on startup and save the boolean (as someone else has already mentioned).

Hauke

Hauke Duden wrote:

> Regarding the efficiency: you can compare the string once on startup and save the boolean (as someone else has already mentioned).
>
> Hauke

But this can't be optimised out.  ie you couldn't use the version statement (if statements can also be-optimised in this way), so therefore you still incur a run-time check.  Therefore as I said, string for runtime and enums for compile time.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Hauke Duden wrote:
>
>> Regarding the efficiency: you can compare the string once on startup and save the boolean (as someone else has already mentioned).
>>
>> Hauke
>
>
> But this can't be optimised out.  ie you couldn't use the version statement (if statements can also be-optimised in this way), so therefore you still incur a run-time check.  Therefore as I said, string for runtime and enums for compile time.

On the other hand, I guess if strings were constants then there's a chance they would be optimised out and you wouldn't need to do all that extra work your talking about.

-- 
-Anderson: http://badmama.com.au/~anderson/

"Walter" <walter@digitalmars.com> wrote in message news:c44knt$15kr$1@digitaldaemon.com...
>
> "Ben Hinkle" <bhinkle4@juno.com> wrote in message news:gtua60h5lcbj5lqtnb3as1rph0pfjgg642@4ax.com...
> > There should at least be an "unknown" vendor enum value so that a new
> > vendor can ship before the next revision of phobos comes out with
> > the "current vendor list".
> > If the string vendor name is in there they why even have the enum?
> > If the speed of doing a string compare is that important the user can
> > cache the vendor value somewhere:
> > int isDigitialMars = cmp(std.compiler.name,"Digital Mars D");
>
> That's a good idea, but I think having a two level set of names is a bit klunky.
>
> > Let's say GDC comes out (not so hypothetical!). What does its compiler.d look like? If it has something like
> >
> >     // Vendor specific string naming the compiler
> >     char[] name = "GNU D Compiler";
> >
> >     // Master list of D compiler vendors
> >     enum Vendor
> >     {
> >         DigitalMars = 1
> >         GDC = 2;
> >     }
> >
> > Then in order for user code that references Vendor.GDC to compile
> > you (meaning DMD) would need to make a release with that enum value.
> > So whenever a new compiler comes out every other compiler needs
> > to make a release with the new enum? hmmm.
>
> Since it doesn't matter what the enum values are for various vendors, the customer can edit the compiler.d to put in any missing ones he needs.

That totally chews.

> > Just use the strings as unique identifiers. The biggest pain
> > about using Java's System.getProperty("java.vendor") is that
> > the strings have to include the version information in the string
> > so it changes from release to release. Since std.compiler has
> > version numbers as ints the string can remain constant from release
> > to release.
>
> Having the version number separate is a good idea <g>.

Why not have two strings - vendorName and vendorVersion. The former is free-form, but fixed from first use for a vendor, and the second has the fixed for "J.N.R"  for maJor, miNor and Revision.

If you need to avoid bloat, but require absolute uniqueness, a UUID is the answer.


"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c4bhgn$2van$1@digitaldaemon.com...
> Hauke Duden wrote:
>
> > Walter wrote:
> >
> >> Having the string as an alternate is probably a good idea.
> >
> >
> > So then you have a string that works always and an enum value that you sometimes have to hack to get it to work properly but that is intended to do the same thing.
> >
> > What's the sense in having the enum value, then? The string by itself is entirely sufficient!
> >
> Using enum would help prevent bloat and is more efficient then string in the compiled executable.
>
> I'm thinking about openGL and it's extensions.  Both enums (constants) and strings were used for slightly different purposes.  Like in openGL, I think strings could be used for the dynamic/hardware side of things and enums for the constant vendor things, with some overlap.
>
> --
> -Anderson: http://badmama.com.au/~anderson/