www.digitalmars.com         C & C++   DMDScript  

D - std.compiler.Vendor

reply "Matthew" <matthew stlsoft.org> writes:
This seems like a mistake.

It would require any new vendor(s) to contact all existing vendors to
coordinate on a new number? What if the other vendors are out for the
day/week/month, or are playing tricky practices?

Better not to rely on this, but rather have a number based on a UUID, or a
domain name. (All vendors are going to have a domain name, aren't they?)
Mar 26 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew stlsoft.org> wrote in message
news:c40tfj$1ds2$1 digitaldaemon.com...

 This seems like a mistake.

 It would require any new vendor(s) to contact all existing vendors to
 coordinate on a new number? What if the other vendors are out for the
 day/week/month, or are playing tricky practices?


I recommend they use their trademarked name, which legitimate vendors try to
make as unique and unconfusing as possible. There's nothing really stopping
one vendor from masquerading as another, but they will probably earn the
condemnation of the D user community for doing so.


 Better not to rely on this, but rather have a number based on a UUID, or a
 domain name. (All vendors are going to have a domain name, aren't they?)


UUID's are fine for computers, but are very unfriendly to type in. Domain
names tend to be trademarked names.
Mar 26 2004
parent reply "Matthew" <matthew stlsoft.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:c41p0k$2ps1$1 digitaldaemon.com...

 "Matthew" <matthew stlsoft.org> wrote in message
 news:c40tfj$1ds2$1 digitaldaemon.com...

 This seems like a mistake.

 It would require any new vendor(s) to contact all existing vendors to
 coordinate on a new number? What if the other vendors are out for the
 day/week/month, or are playing tricky practices?


 I recommend they use their trademarked name, which legitimate vendors try


to

 make as unique and unconfusing as possible. There's nothing really


stopping

 one vendor from masquerading as another, but they will probably earn the
 condemnation of the D user community for doing so.


How can anyone use a name in an enum?


 Better not to rely on this, but rather have a number based on a UUID, or




a

 domain name. (All vendors are going to have a domain name, aren't they?)


 UUID's are fine for computers, but are very unfriendly to type in. Domain
 names tend to be trademarked names.
Mar 26 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew stlsoft.org> wrote in message
news:c4236o$a3o$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:c41p0k$2ps1$1 digitaldaemon.com...

 "Matthew" <matthew stlsoft.org> wrote in message
 news:c40tfj$1ds2$1 digitaldaemon.com...

 This seems like a mistake.

 It would require any new vendor(s) to contact all existing vendors to
 coordinate on a new number? What if the other vendors are out for the
 day/week/month, or are playing tricky practices?


 I recommend they use their trademarked name, which legitimate vendors




try

 to

 make as unique and unconfusing as possible. There's nothing really


 stopping

 one vendor from masquerading as another, but they will probably earn the
 condemnation of the D user community for doing so.


 How can anyone use a name in an enum?


I don't understand what you mean.
Mar 26 2004
parent reply Vathix <vathix dprogramming.com> writes:
Walter wrote:

 "Matthew" <matthew stlsoft.org> wrote in message
 news:c4236o$a3o$1 digitaldaemon.com...
 

"Walter" <walter digitalmars.com> wrote in message
news:c41p0k$2ps1$1 digitaldaemon.com...


"Matthew" <matthew stlsoft.org> wrote in message
news:c40tfj$1ds2$1 digitaldaemon.com...


This seems like a mistake.

It would require any new vendor(s) to contact all existing vendors to
coordinate on a new number? What if the other vendors are out for the
day/week/month, or are playing tricky practices?


I recommend they use their trademarked name, which legitimate vendors




 
 try
 

to


make as unique and unconfusing as possible. There's nothing really


stopping


one vendor from masquerading as another, but they will probably earn the
condemnation of the D user community for doing so.


How can anyone use a name in an enum?


 
 
 I don't understand what you mean.
 


I think he means this:

// Master list of D compiler vendors
enum Vendor
{
    DigitalMars = 1
}
// Which vendor we are
Vendor vendor = Vendor.DigitalMars;


Say I make a D compiler, I would have to tell all the other vendors to 
add me to the enum..


-- 
Christopher E. Miller
Mar 26 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Vathix" <vathix dprogramming.com> wrote in message
news:c42god$vp0$1 digitaldaemon.com...

 Walter wrote:

 "Matthew" <matthew stlsoft.org> wrote in message
 news:c4236o$a3o$1 digitaldaemon.com...


"Walter" <walter digitalmars.com> wrote in message
news:c41p0k$2ps1$1 digitaldaemon.com...


"Matthew" <matthew stlsoft.org> wrote in message
news:c40tfj$1ds2$1 digitaldaemon.com...


This seems like a mistake.

It would require any new vendor(s) to contact all existing vendors to
coordinate on a new number? What if the other vendors are out for the
day/week/month, or are playing tricky practices?


I recommend they use their trademarked name, which legitimate vendors




 try


to


make as unique and unconfusing as possible. There's nothing really


stopping


one vendor from masquerading as another, but they will probably earn








the

condemnation of the D user community for doing so.


How can anyone use a name in an enum?



 I don't understand what you mean.


 I think he means this:

 // Master list of D compiler vendors
 enum Vendor
 {
     DigitalMars = 1
 }
 // Which vendor we are
 Vendor vendor = Vendor.DigitalMars;


 Say I make a D compiler, I would have to tell all the other vendors to
 add me to the enum..


Ah, I see now. I think the vendors would be willing to cooperate on this
issue.
Mar 26 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
 I think he means this:

 // Master list of D compiler vendors
 enum Vendor
 {
     DigitalMars = 1
 }
 // Which vendor we are
 Vendor vendor = Vendor.DigitalMars;


 Say I make a D compiler, I would have to tell all the other vendors to
 add me to the enum..


Ah, I see now. I think the vendors would be willing to cooperate on this
issue.


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");

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. 

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.

-Ben
Mar 27 2004
next sibling parent Raiko <phantom2023 hotmail.com> writes:
It's a really bad idea to expect any business to cooperate with 
competition :).

As was said, a string compare would work better because it doesn't rely 
on any cooperation.


Ben Hinkle wrote:

I think he means this:

// Master list of D compiler vendors
enum Vendor
{
    DigitalMars = 1
}
// Which vendor we are
Vendor vendor = Vendor.DigitalMars;


Say I make a D compiler, I would have to tell all the other vendors to
add me to the enum..


Ah, I see now. I think the vendors would be willing to cooperate on this
issue.


 
 
 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");
 
 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. 
 
 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.
 
 -Ben
Mar 27 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.


 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>.
Mar 27 2004
next sibling parent larry cowan <larry_member pathlink.com> writes:
There seems to be some confusion here in some of the posts.  This is a library
module which can be overridden by your own as Walter suggests below.  There
never was any need for vendors to put out new versions of their compiler to keep
up.  If it's extended to include D software vendors in general, there are still
a lot of options open since any new vendor could put an overriding version in
their own release while they wait to be included in the standard module.
There isn't in nearly all cases even any need for a non-vendor user to compile a
modified version.  This could however, if strings are used for everything and
all software types vs each compiler are registered, become a rather huge module
quickly.  Enum of vendors and use of that for a support info matrix or for
(in)compatibility vectors would help a lot.     

In article <c44knt$15kr$1 digitaldaemon.com>, Walter says...

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


 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>.
Mar 27 2004
prev sibling next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
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.
Mar 29 2004
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Mar 29 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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!
Mar 29 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Mar 30 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Mar 30 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Mar 30 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Mar 30 2004
prev sibling parent "Matthew" <matthew stlsoft.org> writes:
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/
Mar 30 2004
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
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/
Mar 29 2004
prev sibling parent reply "Matthew" <matthew stlsoft.org> writes:
"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.
Mar 30 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


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.

  


Why does vendorVersion have to be a string? Can't it be a number or a 
struct of 4 (3) bytes? ie

struct
{
byte J;
byte N;
byte R;
byte O; //Other
}

Its easy to convert numbers to strings but not the other way round.

-- 
-Anderson: http://badmama.com.au/~anderson/
Mar 31 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
J Anderson wrote:


 Matthew wrote:


 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.

  


 Why does vendorVersion have to be a string? Can't it be a number or a 
 struct of 4 (3) bytes? ie

 struct
 {
 byte J;
 byte N;
 byte R;
 byte O; //Other
 }

 Its easy to convert numbers to strings but not the other way round.


Actually you could probably have:

struct versionNumber
{
byte J;
byte N;
byte R;
byte O; //Other such as different flavours
char [] toString {...} //Converts to dot format

-- 
-Anderson: http://badmama.com.au/~anderson/
Mar 31 2004