www.digitalmars.com         C & C++   DMDScript  

D - *sigh*

reply "Johnny Lai" <bl12 uow.edu.au> writes:
Hi!

Well I'm disappointed that people seem to feel that the preprocessor and
templates are not features that are worth having...

I personally miss the preprocessor when I use Java. Otherwise how do we do
code tuned for multiple platforms in 1 source? Or to include debugging code
and removing at will (not just asserts)? Sometimes it's nice to have an
extra level of indirection ^_^.. maybe we need instead is a preprocessor
language that can be applied to any/many language(s) when needed.

And templates! Yes they are complex stuff and I wish they were easier but...
they allow you to do things that you would otherwise be unable to do, or
have to pay dearly for. With templates, apart from the normal usage for
providing type-safe functions, they can be used to implement inheritance.
Using templates to implement inheritance isn't as fully featured as run-time
polymorphism and all that, but they are faster cos they do not need the
vtables (ok it's a small cost). And with templates you can write code to
generate code - statically compiled code, and that's really groovy.
Unfortunately, right now in C++, it is difficult and unintuitive to do, but
it is possible (there's a nice book that discusses some of these things, and
you'll be amazed at what they can get templates to do - Generative
Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).

Well that's just my opinion... One of the reasons why I love C++ is because
I have this feeling of safety when I use it. Basically I know whatever I
want to do, it is possible (ok in very very rare circumstances it probably
isn't).

Oh a brighter note, I think it is nice there's an import. At least there's
none of that header file nested include nightmare... and I like not having
to have another section to define my functions


Johnny
Aug 16 2001
next sibling parent reply "Nathan Matthews" <nedthefed nospam.hotmail.com> writes:
I personally am not a fan of templates, I agree they are powerful but they
can lead to problems.  There is no relationship between set<float> and
set<int> for instance although sometimes you might want a function to
iterate through both types.  To do that you need to templatize the function
and so on, the changes tend to cascade.  I think java has a better more
elegant solution through rtti, a set class holds a set of references to
Objects.  Types are checked on casting.

Having said all this there is 'allways' a trade off beween a 'nice' solution
and the theoretically most efficient solution.  Sometimes people want the
fastest solution and are prepared to make the sacrifice.

On a performance note I wonder if it might be worth letting the user run the
garbage collector if they want to and specify the time its allowed to run.
This would result in at least some of the memory freeing up if it doent
manage to complete and would make the language suitable in systems such as
realtime and computer gaming.

"Johnny Lai" <bl12 uow.edu.au> wrote in message
news:9lgki2$24sf$1 digitaldaemon.com...
 Hi!

 Well I'm disappointed that people seem to feel that the preprocessor and
 templates are not features that are worth having...

 I personally miss the preprocessor when I use Java. Otherwise how do we do
 code tuned for multiple platforms in 1 source? Or to include debugging

 and removing at will (not just asserts)? Sometimes it's nice to have an
 extra level of indirection ^_^.. maybe we need instead is a preprocessor
 language that can be applied to any/many language(s) when needed.

 And templates! Yes they are complex stuff and I wish they were easier

 they allow you to do things that you would otherwise be unable to do, or
 have to pay dearly for. With templates, apart from the normal usage for
 providing type-safe functions, they can be used to implement inheritance.
 Using templates to implement inheritance isn't as fully featured as

 polymorphism and all that, but they are faster cos they do not need the
 vtables (ok it's a small cost). And with templates you can write code to
 generate code - statically compiled code, and that's really groovy.
 Unfortunately, right now in C++, it is difficult and unintuitive to do,

 it is possible (there's a nice book that discusses some of these things,

 you'll be amazed at what they can get templates to do - Generative
 Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).

 Well that's just my opinion... One of the reasons why I love C++ is

 I have this feeling of safety when I use it. Basically I know whatever I
 want to do, it is possible (ok in very very rare circumstances it probably
 isn't).

 Oh a brighter note, I think it is nice there's an import. At least there's
 none of that header file nested include nightmare... and I like not having
 to have another section to define my functions


 Johnny

Aug 16 2001
parent reply "Hendrik Schober" <SpamTrap gmx.de> writes:
"Nathan Matthews" <nedthefed nospam.hotmail.com> wrote:
 I personally am not a fan of templates, I agree they are powerful but they
 can lead to problems.

Pointers are powerfull but they can lead to problems. Exceptions are powerful but they can lead to problems. Macros are powerful, but they can lead to problems. ...
                        There is no relationship between set<float> and
 set<int> for instance

Of course, there is: To implement it by hand, you would write the exactly same code twice.
                       although sometimes you might want a function to
 iterate through both types.

Then you want two functions with exactly the same code that iterate through thier approriate sets. Isn't it amazing that there's a mechanism that allows you to do this by writing the function only once?
                              To do that you need to templatize the function
 and so on, the changes tend to cascade.

Yeah, in that is is like forgetting a 'const' somewhere in a header file. Adding it will yield another place where a 'const' is missing, this forces another 'const'. Such is the benefit of design errors. ;^> (Whenever I entered a project I quickly found myself spending hours adding missing 'const's all over the code. At the end of the day, those who had been in the project for a long time had stopped laughing about me wasting precious time because they were busy fixing their bugs which I found this way.)
                                          I think java has a better more
 elegant solution through rtti, a set class holds a set of references to
 Objects.  Types are checked on casting.

First: If you want to generalize a function within this model, you have to go through the exactly same painful process of generalizing all functions it depends on. Second: Such libraries exist in C++. For many many years. Many many libraries. Yet, STL came and conquered. What do you think why that happened?
 [...]

Schobi -- SpamTrap gmx.de is never read I'm hschober at gmx dot de P.S.: Ich suche einen Job in Berlin.
Aug 16 2001
parent reply "Jason M. Felice" <jfelice cronosys.com> writes:
Hendrik Schober wrote:

 "Nathan Matthews" <nedthefed nospam.hotmail.com> wrote:
 I personally am not a fan of templates, I agree they are powerful but they
 can lead to problems.


C++ Templates suck. They suck solely because it is trying to support the ancient C/C++ cruft. The syntax is horrific and awkward. The old C types is the reason you need to explicitly specify template parameters. The template problem should be solved. I have typed an implementation of a circularly linked list in C so many times that I can disengage my brain and type a whole 150+ lines of code. What's wrong with templates like this: a' max (a' left, a' right) { if (left > right) return left; return right; } In Standard ML, a' would be a type variable (in D, this would probably conflict with the character-quoting operator, but for demonstration purposes...). You are telling the compiler that left and right are of the same type and the function returns the same type. There would be an expansion error if you tried to use max with a set of types that didn't support bool operator > ('a, 'a). You could provide specializations just by explicitly specifying types. I'm not sure that specializations are really necessary. No C++ pointer specialization junk, for sure. If you wanted to do a lot of work on the language but make something really cool, the function should be declared like this: max (left, right) { if (left > right) return left; return right; } If you think about it, if the compiler can't infer a type restriction on the arguments or the return value based on how they are used or returned from the function, there is no reason for there to be one. The compiler can infer that the return type of the function must be the type of left, etc. Okay, back to reality. Think about this: class a' list { void add (a' newelem) { } void remove (a' oldelem) { } int count () { } }; int list i = new int list; i.add(1); i.add(2); Not anywhere near so bad as C++, eh? And we still solve a whole slew of generalized programming issues that we can't otherwise solve. Look at Standard ML and Objective CAML for more info. I've wrote a few programs in both (I do a lot of languages -- sort of my hobby along with compiler/parser theory) -- I _love_ their type system but _hate_ the language syntax. -Jay 'Eraserhead' Felice
Aug 16 2001
parent "Walter" <walter digitalmars.com> writes:
I agree with you. Templates are a great idea, but there's *got* to be a
better way. I intend to find it <g>.

"Jason M. Felice" <jfelice cronosys.com> wrote in message
news:3B7C0A1E.35920B77 cronosys.com...
 Hendrik Schober wrote:

 "Nathan Matthews" <nedthefed nospam.hotmail.com> wrote:
 I personally am not a fan of templates, I agree they are powerful but



 can lead to problems.


C++ Templates suck. They suck solely because it is trying to support the ancient C/C++ cruft. The syntax is horrific and awkward. The old C types is the reason you need to

 specify template parameters.

 The template problem  should be solved.  I have typed an implementation of

 circularly linked list in C so
 many times that I can disengage my brain and type a whole 150+ lines of

 What's wrong with templates like this:

 a' max (a' left, a' right)
 {
      if (left > right) return left;
      return right;
 }

 In Standard ML, a' would be a type variable (in D, this would probably

 with the character-quoting operator, but for demonstration purposes...).

 are telling the compiler that left and right are of the same
 type and the function returns the same type.  There would be an expansion

 if you tried to use max with
 a set of types that didn't support bool operator > ('a, 'a).  You could

 specializations just by
 explicitly specifying types.  I'm not sure that specializations are really
 necessary.  No C++ pointer specialization junk, for sure.

 If you wanted to do a lot of work on the language but make something

 cool, the function should be
 declared like this:

 max (left, right)
 {
    if (left > right) return left;
    return right;
 }

 If you think about it, if the compiler can't infer a type restriction on

 arguments or the return value based on how they are used or returned from

 function, there is no reason for there to be one.  The compiler can
 infer that the return type of the function must be the type of left, etc.

 Okay, back to reality.  Think about this:

 class a' list {
    void add (a' newelem) {
    }
    void remove (a' oldelem) {
    }
    int count () {
    }
 };

 int list i = new int list;
 i.add(1);
 i.add(2);

 Not anywhere near so bad as C++, eh?  And we still solve a whole slew of
 generalized programming issues
 that we can't otherwise solve.  Look at Standard ML and Objective CAML for

 info.  I've wrote a few
 programs in both (I do a lot of languages -- sort of my hobby along with
 compiler/parser theory) -- I _love_
 their type system but _hate_ the language syntax.

 -Jay 'Eraserhead' Felice

Aug 16 2001
prev sibling next sibling parent reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
In article <9lgki2$24sf$1 digitaldaemon.com>, Johnny Lai wrote:
 
 Well I'm disappointed that people seem to feel that the preprocessor
 and templates are not features that are worth having...

Ok, these are reasons to look at. Maybe not valid, but they are there...
 I personally miss the preprocessor when I use Java. Otherwise how do
 we do code tuned for multiple platforms in 1 source? Or to include
 debugging code and removing at will (not just asserts)? Sometimes it's
 nice to have an extra level of indirection ^_^.. maybe we need instead
 is a preprocessor language that can be applied to any/many language(s)
 when needed.

So much in such a small paragraph. I'll try to address these all in sequence. First, using a preprocessor to tune/port source to multiple platforms is a *VERY* bad idea. As someone who as worked at porting various things to many different platforms, I can attest to that. (10+ platforms, 2 huge products, 5.5M+ lines of source) Having said that, an extra level of indirection is very nice to have. It is very usefull in debugging things quickly, and in hacking things up for various purposes. It is however in direct conflict with writing production source. A preprocessor exists with such a goal (at least under *nix), it is called m4. It is not pretty, nor is it easy to learn, but it does do what you asked for...
 And templates! Yes they are complex stuff and I wish they were easier
 but... they allow you to do things that you would otherwise be unable
 to do, or have to pay dearly for. With templates, apart from the
 normal usage for providing type-safe functions, they can be used to
 implement inheritance.  Using templates to implement inheritance
 isn't as fully featured as run-time polymorphism and all that, but
 they are faster cos they do not need the vtables (ok it's a small
 cost). And with templates you can write code to generate code -
 statically compiled code, and that's really groovy.  Unfortunately,
 right now in C++, it is difficult and unintuitive to do, but it is
 possible (there's a nice book that discusses some of these things, and
 you'll be amazed at what they can get templates to do - Generative
 Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).

Templates are an interesting idea. I think that the fundamental problem with templates is that they went about solving the generic programming the wrong way. (Of course, everybody has a different idea on this). The problem is one of the following (in C++): int add2(int x, int y){ return x+y; } long add2(long x, long y){ return x+y; } This is the first type of generic programming. Here two "compatible" types are being done an operation to. In some sense, the exact same code is being produced (at least if int == long) for both of these functions. It would be nice to be able to write the function once, and use it for both (in this case you can, int promotes to long). In one sense, generic programming is about coallescing functions that are the same (at the binary level), or compiling to functions that are a little more generic, and thereby making more functions equivelant, and then collapsing them. The other generic programming idea is one of where you write code in a high-level language, and have the compiler generate different code, which depends on the type(s) within the function. This one is harder to solve in the traditional edit-compile-link-run cycle of these traditional languages. The problem is one of not knowing ahead of time what type(s) are going to be in every possible instantiation of the function. I can see two ways of solving this: 1) Every type is an object, and you generate a generic function, using the base object as the type. In this way the generic function can always be used, but more specialized generated functions (for speed, etc) can also be explicitly generated at compile time. 2) Make the compile-link section be a loop, which loops until there are no undefined symbols (generic functions) left to compile. This breaks the library encapsulation abstraction, as source (of some sort) for the generic libraries would have to be available (user defined types will need a new version of generic routines compiled from library source). Given these constraints, I can see a good reason not to include templates in the current design of the language. Instead forcing the writer of the library (or other sourcecode) to write "generic" functions in a manner more consistent with proceedural languages. This is not always such a bad thing...
 Well that's just my opinion... One of the reasons why I love C++
 is because I have this feeling of safety when I use it. Basically
 I know whatever I want to do, it is possible (ok in very very rare
 circumstances it probably isn't).

Almost any language has this property. -- Tobias Weingartner | Unix Guru, Admin, Systems-Dude Apt B 7707-110 St. | http://www.tepid.org/~weingart/ Edmonton, AB |------------------------------------------------- Canada, T6G 1G3 | %SYSTEM-F-ANARCHISM, The OS has been overthrown
Aug 16 2001
next sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Tobias Weingartner wrote:
 In article <9lgki2$24sf$1 digitaldaemon.com>, Johnny Lai wrote:
 
Well I'm disappointed that people seem to feel that the preprocessor
and templates are not features that are worth having...

Ok, these are reasons to look at. Maybe not valid, but they are there... ...

Well, first, not all preprocessing is at compile time. In this light, most IDE's and aware editors use a form of preprocessing. Not as extensive as if you could say, e.g., "Take all the green words, and move the first letter to the back", but then how often would one want to do this? Of course, it could be quite nice to, e.g., locate all references to green words matching the regexp ..., or that kind of thing. IDE's sometimes provide this kind of facility. Or consider JavaDoc, or Eiffel's short command. These are a sort of preprocessor. The Eiffel short command will even follow up the chains of inheritance while constructing a list of all routines/variables visible to clients of a class. It's a kind of preprocessing. What about anything that builds and maintains a project file? Some of them merely store meta-information, but some of them actively analyze the code to extract the information. Now let's consider compile time preprocessing: Some of the work that this could do is better done by generics. Some of the work that this could do is better done by const variables. Some of the work that this could do is better done by inlining of functions. The only remaining task that I can think of would be better done by an alias construct. It's true that the only form that comes to my mind right now is a preprocessor-ish form: Alias(t_right, "tree->node.right") That sort of thing. I don't want the second argument to be a string, though. That's just the way it appeared in my thoughts (of how to do it with a preprocessor). And I'm not sure that it's a desireable thing for a preprocessor to do. (I just escaped maintaining some C code that was full of the equivalent done with the C preprocessor...this needs careful thought. That was pretty unreadable code.) What are the other reasonable uses of a preprocessor?
Aug 17 2001
prev sibling parent reply a <hursh infonet.isl.net> writes:
Tobias Weingartner wrote:
 
 In article <9lgki2$24sf$1 digitaldaemon.com>, Johnny Lai wrote:
 I personally miss the preprocessor when I use Java. Otherwise how do
 we do code tuned for multiple platforms in 1 source? Or to include
 debugging code and removing at will (not just asserts)? Sometimes it's
 nice to have an extra level of indirection ^_^.. maybe we need instead
 is a preprocessor language that can be applied to any/many language(s)
 when needed.

So much in such a small paragraph. I'll try to address these all in sequence. First, using a preprocessor to tune/port source to multiple platforms is a *VERY* bad idea. As someone who as worked at porting various things to many different platforms, I can attest to that. (10+ platforms, 2 huge products, 5.5M+ lines of source)

If the preprocessor is not the way, what is? I'm not saying we need a text macro preprocessor, but we something I would assume. Where I work we have moved a lot of code to java and we now have to maintain a tree of common code and a tree of platform specific code for each platform. Because of this we can't use straight make either. Java does not provide the platform independence it claims to and I don't have high hopes for a natively compiled language. I must admit that I despise a number of the problems that the preprocessor cause, but conditional compilation for platforms should really be addressed if the language is to be seriously used. Conditional imports would be the absolute minimum, allowing you to hide platform specifics in a module. This could be over kill for issues like filesystem directory separators and the like. Anyhow, you say the preprocessor is bad for multi-platform support. It sounds like you have experience. What would be better? Platform independence is too idealistic. I won't buy that D can deliver it and still be generally useful. Dan
Aug 19 2001
next sibling parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
The Aug 2001 issue of CUJ (I think..the AUG part is pukka) has an article
that discusses the elimination of common uses of preprocessor for such
tasks. (C++ related article.)

He says that (not exact quote, the mag is not in front of me): "using #ifdef
to write multiplatform code does not create platform independant code, but
code that is dependent on multiple platforms!"

Taking his hints, I have found that keeping the common, platform
independant, interface in the .hpp file and having multiple .cpp files, one
for each platform; does simplify the code clutter. The appropriate files are
to be choosen in the makefile during the platform specific build. The
downside is that the number of files increases, but I guess the clear
distiction between the 'interface' and the 'implementation' compensates for
it.


a <hursh infonet.isl.net> wrote in message
news:3B806CC6.FE5992 infonet.isl.net...
 Tobias Weingartner wrote:
 In article <9lgki2$24sf$1 digitaldaemon.com>, Johnny Lai wrote:
 I personally miss the preprocessor when I use Java. Otherwise how do
 we do code tuned for multiple platforms in 1 source? Or to include
 debugging code and removing at will (not just asserts)? Sometimes it's
 nice to have an extra level of indirection ^_^.. maybe we need instead
 is a preprocessor language that can be applied to any/many language(s)
 when needed.

So much in such a small paragraph. I'll try to address these all in sequence. First, using a preprocessor to tune/port source to multiple platforms is a *VERY* bad idea. As someone who as worked at porting various things to many different platforms, I can attest to that. (10+ platforms, 2 huge products, 5.5M+ lines of source)

If the preprocessor is not the way, what is? I'm not saying we need a text macro preprocessor, but we something I would assume. Where I work we have moved a lot of code to java and we now have to maintain a tree of common code and a tree of platform specific code for each platform. Because of this we can't use straight make either. Java does not provide the platform independence it claims to and I don't have high hopes for a natively compiled language. I must admit that I despise a number of the problems that the preprocessor cause, but conditional compilation for platforms should really be addressed if the language is to be seriously used. Conditional imports would be the absolute minimum, allowing you to hide platform specifics in a module. This could be over kill for issues like filesystem directory separators and the like. Anyhow, you say the preprocessor is bad for multi-platform support. It sounds like you have experience. What would be better? Platform independence is too idealistic. I won't buy that D can deliver it and still be generally useful. Dan

Aug 20 2001
parent Dan Hursh <hursh infonet.isl.net> writes:
Rajiv Bhagwat wrote:
 
 The Aug 2001 issue of CUJ (I think..the AUG part is pukka) has an article
 that discusses the elimination of common uses of preprocessor for such
 tasks. (C++ related article.)
 
 He says that (not exact quote, the mag is not in front of me): "using #ifdef
 to write multiplatform code does not create platform independant code, but
 code that is dependent on multiple platforms!"
 
 Taking his hints, I have found that keeping the common, platform
 independant, interface in the .hpp file and having multiple .cpp files, one
 for each platform; does simplify the code clutter. The appropriate files are
 to be choosen in the makefile during the platform specific build. The
 downside is that the number of files increases, but I guess the clear
 distiction between the 'interface' and the 'implementation' compensates for
 it.

I can agree with this, but I have done a number of very small programs for a very heterogeneous environment. If I had to start make them multi-file project because there is no way I would switch to D for them. :-( On another note, I guess I the observation that you aren't writing platform independent code doesn't break may heart. I try to keep as much of my code platform independent as possible, I'm an admin and frankly I don't believe I could accomplish anything meaningful in platform independent code. In many cases the headers you need to include are different on different platforms. I don't honestly see D fixing that. Vendors just seem to be different out of a lack of tangible merit. Dan
 a <hursh infonet.isl.net> wrote in message
 news:3B806CC6.FE5992 infonet.isl.net...
 Tobias Weingartner wrote:
 In article <9lgki2$24sf$1 digitaldaemon.com>, Johnny Lai wrote:
 I personally miss the preprocessor when I use Java. Otherwise how do
 we do code tuned for multiple platforms in 1 source? Or to include
 debugging code and removing at will (not just asserts)? Sometimes it's
 nice to have an extra level of indirection ^_^.. maybe we need instead
 is a preprocessor language that can be applied to any/many language(s)
 when needed.

So much in such a small paragraph. I'll try to address these all in sequence. First, using a preprocessor to tune/port source to multiple platforms is a *VERY* bad idea. As someone who as worked at porting various things to many different platforms, I can attest to that. (10+ platforms, 2 huge products, 5.5M+ lines of source)

If the preprocessor is not the way, what is? I'm not saying we need a text macro preprocessor, but we something I would assume. Where I work we have moved a lot of code to java and we now have to maintain a tree of common code and a tree of platform specific code for each platform. Because of this we can't use straight make either. Java does not provide the platform independence it claims to and I don't have high hopes for a natively compiled language. I must admit that I despise a number of the problems that the preprocessor cause, but conditional compilation for platforms should really be addressed if the language is to be seriously used. Conditional imports would be the absolute minimum, allowing you to hide platform specifics in a module. This could be over kill for issues like filesystem directory separators and the like. Anyhow, you say the preprocessor is bad for multi-platform support. It sounds like you have experience. What would be better? Platform independence is too idealistic. I won't buy that D can deliver it and still be generally useful. Dan


Aug 21 2001
prev sibling next sibling parent reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
In article <3B806CC6.FE5992 infonet.isl.net>, a wrote:
 Tobias Weingartner wrote:
 
 First, using a preprocessor to tune/port source to multiple platforms is
 a *VERY* bad idea.  As someone who as worked at porting various things
 to many different platforms, I can attest to that.  (10+ platforms, 2
 huge products, 5.5M+ lines of source)

If the preprocessor is not the way, what is? I'm not saying we need a text macro preprocessor, but we something I would assume. Where I work we have moved a lot of code to java and we now have to maintain a tree of common code and a tree of platform specific code for each platform. Because of this we can't use straight make either. Java does not provide the platform independence it claims to and I don't have high hopes for a natively compiled language.

Separate files for each platform (or api/feature) is the way to go. It helps in keeping the spagethi code away as more platforms are added. It also helps in coallescing support for platforms as bugs, apis and features migrate into a cohesive mass.
 	I must admit that I despise a number of the problems that the
 preprocessor cause, but conditional compilation for platforms should
 really be addressed if the language is to be seriously used. 

Certainly. However, I believe strongly, that it should be discouraged. How many times do you see '#ifdef __linux', when they really mean to say '#ifdef SVR4'? Most people don't know which standards define which api, giving them "platform" dependant compilation, usually means they make the wrong choice...
 Conditional imports would be the absolute minimum, allowing you to hide
 platform specifics in a module.  This could be over kill for issues like
 filesystem directory separators and the like.

Conditional imports are not necessary. Build libraries to abstract system and API differences. Import libraries, and use their common API.
 	Anyhow, you say the preprocessor is bad for multi-platform support.  It
 sounds like you have experience.  What would be better?  Platform
 independence is too idealistic.  I won't buy that D can deliver it and
 still be generally useful.

Not using preprocessor for multi-platform. It sounds hard, and it can be. It sounds over-kill, and it can be. But really, once you get beyond the 3-4 machine level, a little foresight, and forebearance of the over-kill things will make life a *lot* easier... --Toby.
Aug 20 2001
next sibling parent reply "Brent Schartung" <bschartung home.com> writes:
It just seems to me that all the usually platform-specific bs can go into
the D standard library--that is, threads and semaphores, sockets, maybe
graphics, basic filesystem functions, and then the basic types that seem to
depend on word size, etc.  Also byte-order needs to be addressed in some
instances, maybe have a library call for NetworkByteOrder(...).  (BTW, if D
is the big success we hope it is, and it spreads to some old-school and some
brand-spankin new systems, will 'int', etc be changed to mean 16- or 64-bit
integer??)

My question is this:  Is there anything in the typical platform murk that
can't be handled by an extensive base library?

Another 2 cents,
Brent
Aug 20 2001
next sibling parent reply Russ Lewis <russ deming-os.org> writes:
Brent Schartung wrote:

 My question is this:  Is there anything in the typical platform murk that
 can't be handled by an extensive base library?

For the stuff you mentioned, the technical, under-the-covers stuff of computing, I would guess that a standard library would work well. Such a thing (particularly if it covers threading and synchronization) would be a Good Idea. The trouble, though, comes when you are dealing with the more mundane (but perhaps more important) part of the program - the structure of its user interface. How do you write a class library that works equally well with graphical and text-based user interfaces? If you just deal with graphical ones, do you assume that the window is local (like Mac and Windows) or remote (like X-Windows)? Do you choose a synchronous event model, which will *trash* performance for people connected via a modem or the Internet, or do you choose an asynchronous event model, which will make your program much more complex? Do you recognize and use graphics accelerators, or ignore them? I'm not saying that it can't be done - in fact, I think that it *should* be done. But when you get to that level, things are no longer trivial.
Aug 20 2001
parent reply "Brent Schartung" <bschartung home.com> writes:
What do Qt and GTK do?  Don't they do the 'networked' X-Windows thing?

Sorry, I've never actually dev'd with them!

 - Brent


 The trouble, though, comes when you are dealing with the more mundane (but
 perhaps more important) part of the program - the structure of its user
 interface.  How do you write a class library that works equally well with
 graphical and text-based user interfaces?  If you just deal with graphical

 do you assume that the window is local (like Mac and Windows) or remote

 X-Windows)?  Do you choose a synchronous event model, which will *trash*
 performance for people connected via a modem or the Internet, or do you

 an asynchronous event model, which will make your program much more

 you recognize and use graphics accelerators, or ignore them?

 I'm not saying that it can't be done - in fact, I think that it *should*

 done.  But when you get to that level, things are no longer trivial.

Aug 20 2001
parent Russ Lewis <russ deming-os.org> writes:
Brent Schartung wrote:

 What do Qt and GTK do?  Don't they do the 'networked' X-Windows thing?

 Sorry, I've never actually dev'd with them!

Right, tools exist to develop X-Windows. But how many of those tools can also run on Windows w/o a major code change (or a very complex Windows X Server)?
Aug 21 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
The library can abstract away most common stuff. But it is of necessity then
the lowest common denominator. There will always be a need to access
platform specific functionality for complex system apps.


Brent Schartung wrote in message <9ls3bi$18mn$1 digitaldaemon.com>...
It just seems to me that all the usually platform-specific bs can go into
the D standard library--that is, threads and semaphores, sockets, maybe
graphics, basic filesystem functions, and then the basic types that seem to
depend on word size, etc.  Also byte-order needs to be addressed in some
instances, maybe have a library call for NetworkByteOrder(...).  (BTW, if D
is the big success we hope it is, and it spreads to some old-school and

brand-spankin new systems, will 'int', etc be changed to mean 16- or 64-bit
integer??)

My question is this:  Is there anything in the typical platform murk that
can't be handled by an extensive base library?

Another 2 cents,
Brent

Aug 21 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
Tobias Weingartner wrote in message ...
How many times do you see '#ifdef __linux', when they really mean to say
'#ifdef SVR4'?  Most people don't know which standards define which api,
giving them "platform" dependant compilation, usually means they make the
wrong choice...

That is one of the things I found discouraging about using conditional compilation for OS support. The programmer was always using the wrong one. They'd use _WIN32 when they meant _MSC_VER, they'd use __GCC__ when they meant linux, and on and on. They'd also use the #else clause to mean some (unspecified) default operating system.
Aug 21 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
a wrote in message <3B806CC6.FE5992 infonet.isl.net>...
 I won't buy that D can deliver it and
still be generally useful.

D will likely only be somewhat more platform independent than C is.
Aug 21 2001
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Johnny Lai" <bl12 uow.edu.au> wrote in message
news:9lgki2$24sf$1 digitaldaemon.com...
 Well I'm disappointed that people seem to feel that the preprocessor and
 templates are not features that are worth having...

I expected heat about templates, but less so about the preprocessor.
 I personally miss the preprocessor when I use Java. Otherwise how do we do
 code tuned for multiple platforms in 1 source? Or to include debugging

 and removing at will (not just asserts)? Sometimes it's nice to have an
 extra level of indirection ^_^.. maybe we need instead is a preprocessor
 language that can be applied to any/many language(s) when needed.

I've dealt with much code over the years tuned for multiple platforms with #ifdef's. Inevitably, they turn into a hopeless snarl. I've since reached the conclusion that platform dependencies should be isolated to separate files and then write a new file for the different platforms. Inserting and removing debugging code at will is ably handled with the debug attribute and debug statement. Asserts are not really debug code, but are part of the design by contract stuff.
 And templates! Yes they are complex stuff and I wish they were easier

 they allow you to do things that you would otherwise be unable to do, or
 have to pay dearly for. With templates, apart from the normal usage for
 providing type-safe functions, they can be used to implement inheritance.
 Using templates to implement inheritance isn't as fully featured as

 polymorphism and all that, but they are faster cos they do not need the
 vtables (ok it's a small cost). And with templates you can write code to
 generate code - statically compiled code, and that's really groovy.
 Unfortunately, right now in C++, it is difficult and unintuitive to do,

 it is possible (there's a nice book that discusses some of these things,

 you'll be amazed at what they can get templates to do - Generative
 Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).

Clearly, people like templates a *lot*. I'm going to have to think a lot more about this.
Aug 16 2001
parent reply "Kent Sandvik" <sandvik excitehome.net> writes:
 I've dealt with much code over the years tuned for multiple platforms with
 #ifdef's. Inevitably, they turn into a hopeless snarl. I've since reached
 the conclusion that platform dependencies should be isolated to separate
 files and then write a new file for the different platforms.

Yes, agree. One way we did this in a project was to specify class objects that were global, across the platforms, and the implementation files then had implementations for each platform, included via makefiles. That makes me wonder if this could be done in D in case the header files are gone, and we are dealing with modules, so it would be nice to somehow indicate the implementation detail (or then write multiple modules for each platform...). --Kent
Aug 16 2001
parent reply "Walter" <walter digitalmars.com> writes:
"Kent Sandvik" <sandvik excitehome.net> wrote in message
news:9lho7p$as5$1 digitaldaemon.com...
 I've dealt with much code over the years tuned for multiple platforms


 #ifdef's. Inevitably, they turn into a hopeless snarl. I've since


 the conclusion that platform dependencies should be isolated to separate
 files and then write a new file for the different platforms.

Yes, agree. One way we did this in a project was to specify class objects that were global, across the platforms, and the implementation files then had implementations for each platform, included via makefiles. That makes

 wonder if this could be done in D in case the header files are gone, and

 are dealing with modules, so it would be nice to somehow indicate the
 implementation detail (or then write multiple modules for each
 platform...). --Kent

I think it would fall naturally out of D. A switch to the compiler tells it where to look for the imports for the target platform.
Aug 16 2001
parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Walter wrote:
 
 "Kent Sandvik" <sandvik excitehome.net> wrote in message
 news:9lho7p$as5$1 digitaldaemon.com...
 I've dealt with much code over the years tuned for multiple platforms


 #ifdef's. Inevitably, they turn into a hopeless snarl. I've since


 the conclusion that platform dependencies should be isolated to separate
 files and then write a new file for the different platforms.

Yes, agree. One way we did this in a project was to specify class objects that were global, across the platforms, and the implementation files then had implementations for each platform, included via makefiles. That makes

 wonder if this could be done in D in case the header files are gone, and

 are dealing with modules, so it would be nice to somehow indicate the
 implementation detail (or then write multiple modules for each
 platform...). --Kent

I think it would fall naturally out of D. A switch to the compiler tells it where to look for the imports for the target platform.

I nearly jumped for joy upon seeing D's "debug" attribute. At the risk of getting stomped on for proposing a new keyword, how about adding a "config" attribute, with an identifier: config (MacOSX) { // do OS X specific stuff } config (Win32) { // do Win32 specific stuff } config (PalmOS) { // do PalmOS specific stuff } again, with compiler switches to pass in the identifier?
Aug 16 2001
parent "news.digitalmars.com" <bradeeoh crosswinds.net> writes:
 I nearly jumped for joy upon seeing D's "debug" attribute. At the
 risk of getting stomped on for proposing a new keyword, how about
 adding a "config" attribute, with an identifier:

    config (MacOSX)
    {
       // do OS X specific stuff
    }
    config (Win32)
    {
       // do Win32 specific stuff
    }
    config (PalmOS)
    {
       // do PalmOS specific stuff
    }

 again, with compiler switches to pass in the identifier?

Have nothing incredibly useful to say, but I REALLY like that idea. I was already convinced that with garbage collection, single inheretence + interfaces, and the debug keyword that D is my new language of choice if/when it becomes a reality. Toss in the config keyword, and my Win32 vs Linux woes would be greatly reduced WITHOUT having to use the messy preprocessor, and I would throw Walter a party for the accomplishment personally :)
Aug 17 2001
prev sibling next sibling parent reply "Tim Sweeney" <tim epicgames.com> writes:
 I personally miss the preprocessor when I use Java.

Agreed, but only because of Java's limitations (no templates, etc.), and not because I *want* to use macros.
 And templates! Yes they are complex stuff and I wish they were easier

 they allow you to do things that you would otherwise be unable to do, or
 have to pay dearly for.

Agreed 100%! I would never consider writing a large-scale program in a language without template-style functionality. It's really astounding how much simplification and generality one can attain with templates -- not just talking about the cannonical (and IMO poor) example of "container classes", but for complex related type hierarchies, parser tools, math structures, etc. The stigma of templates being useful just for container classes and a few other isolated cases (which a language could well implement as a special feature) is really unfortunate. I suppose that's because container classes are the next obvious step for a C programmer. But if you spend a few weeks experimenting with languages like Haskell (not useful for practical programming, but a GREAT thing to learn), you come back to C++ templates with a completely new perspective and start writing code in a much more compact and general way! (Here I'm advocating template-style functionality -- I actually think the C++ syntax for templates is pretty kludgy, but that's a minor issue in the grand scheme of things.)
 Unfortunately, right now in C++, it is difficult and unintuitive to do,

 it is possible (there's a nice book that discusses some of these things,

 you'll be amazed at what they can get templates to do - Generative
 Programming by Krzysztof Czarnecki, and Ulrich W. Eisenecker).

Agreed 101%! -Tim
Aug 17 2001
parent reply reiter nomadics.com (Mac Reiter) writes:
On Fri, 17 Aug 2001 21:15:47 -0400, "Tim Sweeney" <tim epicgames.com>
wrote:

Agreed, but only because of Java's limitations (no templates, etc.), and not
because I *want* to use macros.

 And templates! Yes they are complex stuff and I wish they were easier

 they allow you to do things that you would otherwise be unable to do, or
 have to pay dearly for.

Agreed 100%! I would never consider writing a large-scale program in a language without template-style functionality. It's really astounding how much simplification and generality one can attain with templates -- not just talking about the cannonical (and IMO poor) example of "container classes", but for complex related type hierarchies, parser tools, math structures, etc. The stigma of templates being useful just for container classes and a few other isolated cases (which a language could well implement as a special feature) is really unfortunate. I suppose that's because container classes

I know that some of you have read at least some of the Eiffel work, since Design By Contract is built into D. Does anyone here have large scale experience with Eiffel's use of Generic/Parameterized Classes? In my training and what work I have done with the language, they seemed to be very simple to use, but contained enough power to represent inter-class type relationships beyond the simple container class work. I do not, however, have large scale experience, and may have simply not been exposed to their problems. Also, I realize that D is not Eiffel, so even if Eiffel had the perfect genericity system it might not translate directly into D. I only suggest looking at Eiffel references (Object Oriented Software Construction, 2nd Edition by Bertrand Meyer has an EXTENSIVE discussion and analysis) to see if there are any features there that help focus the design. I have recently purchased Digital Mars C++ for evaluation because templates are important to the kind of work I do, and because my current compiler (MSVC -- make sign of the cross, say prayer for salvation of my soul) is almost completely hosed with regards to compiling templates. Rather than posting a huge amount of copied code, I will simply supply a link to a description of Eiffel's genericity system. http://www.eiffel.com/doc/online/eiffel50/intro/language/tutorial-08.html#pgfId-514722 For classes, you simply change: class C into: class C[G] Eiffel does not allow free-standing functions -- all functions are member functions of some class. So any generic/templatized function that you could write would be inside a class that would be made generic in terms of the type(s) you need to use for its members. class C[G,H] containing a member function: filter(G input) : H filter() is a function that takes a type G and returns a type H. You can also tie types together through covariance mechanisms, and much more. Genericity is one of the cornerstones of the Eiffel design. Just a thought. Sorry if it's already been mentioned... Mac Reiter
Jan 11 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Mac Reiter" <reiter nomadics.com> wrote in message
news:3c3f6c4a.26816560 news.digitalmars.com...

 I know that some of you have read at least some of the Eiffel work,
 since Design By Contract is built into D.  Does anyone here have large
 scale experience with Eiffel's use of Generic/Parameterized Classes?
 In my training and what work I have done with the language, they
 seemed to be very simple to use, but contained enough power to
 represent inter-class type relationships beyond the simple container
 class work.  I do not, however, have large scale experience, and may
 have simply not been exposed to their problems.

Well I've read the chapter... it looks pretty much like C++ templates, only template arguments are always types - or am I missing something? Anyways, it'd be great for D to support templates. Very powerful and time-saving feature, it is.
Jan 11 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
B. Meyer has been the inspiration for some of D's features, like DBC. Meyer
has a lot of great ideas, and Eiffel is a great language. The look and feel,
so to speak, of Eiffel, however, just isn't my style <g>.

I've been using DBC in my own code for some time now,  and can attest that
it produces a *real* improvement in productivity and reliability. C, C++,
Java, C#, etc., have all missed the boat on that issue (and on unit tests).

I've shelved the templates in D idea for the moment while I try to get the
compiler into beta quality, but this issue will get addressed.
Jan 11 2002
prev sibling parent reply a <hursh infonet.isl.net> writes:
	I admit that I don't care for the problems that came with the
preprocessor, but it had it's pluses.  Rather that just blast D (since
it looks 'cool' and all) I was curious how I would address conditional
compilation.  I'll consider two cases and I'm curious how they would be
addressed in D.

	First would be a small project.  Say I want to write a wizzle decoder. 
It a basic project that take files contain wizzle encoded data,
de-wizzles it and presents it to the user.  for the most part the
de-wizzling is number crunching but the will inevitably be issues of
dealing with basic system interfaces to get data (files) and present it
(files, a window, audio, idunno).  I C/C++ I would write a file or for
each platform with the code for getting data, and presenting it and use
#ifdefs to select which files I want to #include.  The makefile would
handle compiling the write code.
	How would I do this in D?  Unless I put each implementation in a
separate directory, I would have to give each file a different name, and
hence a different module name.  I would then have to do trick to point
at these different directories, and the organizational overhead is just
seems a bit steep for de-wizzling. ;-)  This also excludes ports to
platforms that don't have hierarchical files systems.  (Loth the
mainframe.)  This also doesn't address the rare few programs that are so
small (even with an #ifdef or two) that they would otherwise fit nicely
into one file.  I guess that is a peeve I have with java.  It tends to
require more file than I feel should be necessary for some smallish
projects.

	Second, say I'm making an OS kernel. I've decide that the world is
ready for Danux.  Now here, having a directory for each platform is
pretty justified even without D's requirements.  My question here has to
do with configuration management.  If you've compiled linux you know
that there are a lot of compile time options.  Let face it, Danux is
going to have to be just as flexible if not more so.  How would I go
about supporting the ability to pass compile time configuration options
into D to tell it what I want compiled and how do I act upon that
information?  
	The first thing that comes to mind is to abuse the debug(identifier)
syntax.  I don't know if it would work though to do imports that way. 
Let's face it though, that is abuse.  I would need to tell the program
which OS modules/drivers/functionality is being supported for this
build.  I would also need to tell it option setting like is a driver
being build statically, or is it a run time loadable.  What should the
max/default sizes for given properties be.  Short of writing a program
that will in turn write my program with the correct options (that would
be a preprocessor wouldn't it?) I don't really know how I would handle
this in D.  Let's face it.  We are not just dewizzling data here.  We
need power.

Dan
Aug 19 2001
next sibling parent reply weingart cs.ualberta.ca (Tobias Weingartner) writes:
In article <3B807834.59635C0C infonet.isl.net>, a wrote:
 
 	First would be a small project.  Say I want to write a wizzle decoder. 
 It a basic project that take files contain wizzle encoded data,
 de-wizzles it and presents it to the user.  for the most part the
 de-wizzling is number crunching but the will inevitably be issues of
 dealing with basic system interfaces to get data (files) and present it
 (files, a window, audio, idunno).  I C/C++ I would write a file or for
 each platform with the code for getting data, and presenting it and use
 #ifdefs to select which files I want to #include.  The makefile would
 handle compiling the write code.
 	How would I do this in D?  Unless I put each implementation in a
 separate directory, I would have to give each file a different name, and
 hence a different module name.  I would then have to do trick to point
 at these different directories, and the organizational overhead is just
 seems a bit steep for de-wizzling. ;-)  This also excludes ports to
 platforms that don't have hierarchical files systems.  (Loth the
 mainframe.)  This also doesn't address the rare few programs that are so
 small (even with an #ifdef or two) that they would otherwise fit nicely
 into one file.  I guess that is a peeve I have with java.  It tends to
 require more file than I feel should be necessary for some smallish
 projects.

Ouch, why would you tie the module name and the import name together? Just because some implementation of displaying data is in linux-display.d and another is in openbsd-display.d, you should still be able to use "import display" in the main program to get whichever was compiled. Think "libraries", linux-diplay.d would be compiled, and put in a library called "display" (traditional unix would use libdisplay.a for a static library).
 	Second, say I'm making an OS kernel. I've decide that the world is
 ready for Danux.  Now here, having a directory for each platform is
 pretty justified even without D's requirements.  My question here has to
 do with configuration management.  If you've compiled linux you know
 that there are a lot of compile time options.  Let face it, Danux is
 going to have to be just as flexible if not more so.  How would I go
 about supporting the ability to pass compile time configuration options
 into D to tell it what I want compiled and how do I act upon that
 information?  

Great. There are a number of good configuration tools out there. I will agree that conditional compilation can make things easier in these cases. However, if properly constructed, a simple "if" statement can be as effective in this case. Since it evaluates to "if(0)", and the compiler removes that part of the code, it is just as if conditional compilation happened.
 	The first thing that comes to mind is to abuse the debug(identifier)
 syntax.  I don't know if it would work though to do imports that way. 
 Let's face it though, that is abuse.  I would need to tell the program
 which OS modules/drivers/functionality is being supported for this
 build.  I would also need to tell it option setting like is a driver
 being build statically, or is it a run time loadable.  What should the
 max/default sizes for given properties be.  Short of writing a program
 that will in turn write my program with the correct options (that would
 be a preprocessor wouldn't it?) I don't really know how I would handle
 this in D.  Let's face it.  We are not just dewizzling data here.  We
 need power.

Write more generic code. Seriously, one of my main problems with open code today is that it is targeted to linux, instead of the broader unix comunity out there. It used to be that windows programs/utilities were the hardest to port to a "standard" unix environment (solaris, *bsd, osf, etc). Today that has been largely replaced with the huge number of linux centric code out there. Code that depends on certain behaviour that the linux api has, rather than following the written standard that exists. --Toby.
Aug 20 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
Sorry to stir this old thread but I just had to make a quick point here:

Great.  There are a number of good configuration tools out there.  I will
agree that conditional compilation can make things easier in these cases.
However, if properly constructed, a simple "if" statement can be as

in this case.  Since it evaluates to "if(0)", and the compiler removes that
part of the code, it is just as if conditional compilation happened.

Think about this hypothetical situation: const int useplatformspecificapi=0; int myfunc() { if (useplatformspecificapi) { import platformspecificapi; // let's assume this module is not available anyway platformspecificapi_function(0); // Undeclared identifier error, most likely return 0; } return 1; } Think about what the compiler will do while parsing myfunc (I'm new to D so if I wrote the above wrong, forgive me). It still has to parse down into there and figure out what platformspecificapi_function(0); means... that means it needs to know if it's a function or whatever. If useplatformspecificapi is 0, the parser will probably generate an "Undeclared identifier" error. I'm sure if one tried one could come up with several more examples where an ordinary parser would fall over. So if statements by themselves aren't the answer, but they *could* be given a technological advance or two. The trick seems to be to lazy-parse sections *after* evaluating any constant expressions in the controlling if clause. I'm not sure I could pull this off but I'm sure it's not beyond the top-notch compiler writers today. BTW I like what I see so far about D. I can only find a few minor flaws in the design, which I'll discuss presently. also I seem to have noticed that at one point the website mentions that in an array declaration, the brackets go with the rest of the typespec instead of the C way where the brackets go after the variable. I think that having the typespec contiguous is superior (especially if you are writing a compiler). However many of the samples on the website seem to be using C syntax for array declarations. So, which is it? Does D declare arrays like this: int myarray[5]; or like this? int[5] myarray; Sean
Oct 16 2001
parent reply "Walter" <walter digitalmars.com> writes:
Sean L. Palmer wrote in message <9qgprk$1lgp$1 digitaldaemon.com>...
Great.  There are a number of good configuration tools out there.  I will
agree that conditional compilation can make things easier in these cases.
However, if properly constructed, a simple "if" statement can be as

in this case.  Since it evaluates to "if(0)", and the compiler removes


part of the code, it is just as if conditional compilation happened.

Think about this hypothetical situation: const int useplatformspecificapi=0; int myfunc() { if (useplatformspecificapi) { import platformspecificapi; // let's assume this module is

available anyway
     platformspecificapi_function(0);   // Undeclared identifier error,

likely
     return 0;
  }
  return 1;
}

Think about what the compiler will do while parsing myfunc (I'm new to D so
if I wrote the above wrong, forgive me).  It still has to parse down into
there and figure out what platformspecificapi_function(0); means... that
means it needs to know if it's a function or whatever.  If
useplatformspecificapi is 0, the parser will probably generate an
"Undeclared identifier" error.  I'm sure if one tried one could come up

several more examples where an ordinary parser would fall over.  So if
statements by themselves aren't the answer, but they *could* be given a
technological advance or two.  The trick seems to be to lazy-parse sections
*after* evaluating any constant expressions in the controlling if clause.
I'm not sure I could pull this off but I'm sure it's not beyond the
top-notch compiler writers today.

It's not that hard if you defer semantic processing until after syntax analysis, which the D spec separates.
also I seem to have noticed that at one point the website mentions that in
an array declaration, the brackets go with the rest of the typespec instead
of the C way where the brackets go after the variable.  I think that having
the typespec contiguous is superior (especially if you are writing a
compiler).  However many of the samples on the website seem to be using C
syntax for array declarations.
So, which is it?

Does D declare arrays like this:

int myarray[5];

or like this?

 int[5] myarray;

Sean

At the moment, both work <g>.
Oct 16 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 It's not that hard if you defer semantic processing until after syntax
 analysis, which the D spec separates.

Cool.
also I seem to have noticed that at one point the website mentions that


an array declaration, the brackets go with the rest of the typespec


of the C way where the brackets go after the variable.  I think that


the typespec contiguous is superior (especially if you are writing a
compiler).  However many of the samples on the website seem to be using C
syntax for array declarations.
So, which is it?

Does D declare arrays like this:

int myarray[5];

or like this?

 int[5] myarray;

Sean

At the moment, both work <g>.

That's pretty slick! What would this do? int[5] myarray[6];
Oct 18 2001
parent reply "Ben Cohen" <bc skygate.co.uk> writes:
In article <9qm7l7$1tjc$1 digitaldaemon.com>, "Sean L. Palmer"
<spalmer iname.com> wrote:

Does D declare arrays like this:

int myarray[5];

or like this?

 int[5] myarray;

Sean

At the moment, both work <g>.

That's pretty slick! What would this do? int[5] myarray[6];

I think you can do something like that in Java, to confuse yourself. (See http://asc.di.fct.unl.pt/~jml/mirror/unmain.html for this and other similar ideas.) Will they always both work (i.e., is that in the spec?)
Oct 18 2001
parent "Walter" <walter digitalmars.com> writes:
Ben Cohen wrote in message <9qm9u5$1utt$1 digitaldaemon.com>...
In article <9qm7l7$1tjc$1 digitaldaemon.com>, "Sean L. Palmer"
<spalmer iname.com> wrote:
 That's pretty slick!  What would this do?
 int[5] myarray[6];


int[5][6] myarray;
Will they always both work (i.e., is that in the spec?)

I'll probably drop the C version.
Oct 18 2001
prev sibling parent reply "Glen Dayton" <dayton timesten.com> writes:
Ada deals with conditional compilation rather nicely -- any "if" statement
with a constant conditional is optimized out at compile time.

C++ behaves the same way.  One of Bjarne Stroup's stated goals in creating
C++ was eliminating the pre-processor.  Thus, instead of writing

#define DOITTHISWAY 1
...
#if DOITTHISWAY
...
#endif


write

const int DOITTHISWAY = 1;

if (DOITTHISWAY) {
...
}


The disadvantage of this method is the lack of ability to define DOITTHISWAY
on the command line of the compiler, but from a configuration management
standpoint, this isn't a disadvantage at all.
Aug 28 2001
next sibling parent "Kent Sandvik" <sandvik excitehome.net> writes:
 The disadvantage of this method is the lack of ability to define

 on the command line of the compiler, but from a configuration management
 standpoint, this isn't a disadvantage at all.

I've been involved in building cross-platform C++ frameworks, and if there's a way to build multiple versions of the sources with compile switches, it makes a big difference versus doing for example shell scripting or perl hacks to move around configuration files around for the various builds. It's doable with perl hacking, but it would be more natural to just specify compilation options directly to the build process. --Kent
Aug 28 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
I am leaning towards using the "if" for conditional compilation. One major
difference between D and C++ usage of it is that in D, the false conditional
would only have to parse, it would not have to be semantically correct.

-Walter


Glen Dayton wrote in message <9mh6em$1rhs$1 digitaldaemon.com>...
Ada deals with conditional compilation rather nicely -- any "if" statement
with a constant conditional is optimized out at compile time.

C++ behaves the same way.  One of Bjarne Stroup's stated goals in creating
C++ was eliminating the pre-processor.  Thus, instead of writing

#define DOITTHISWAY 1
...
#if DOITTHISWAY
...
#endif


write

const int DOITTHISWAY = 1;

if (DOITTHISWAY) {
...
}


The disadvantage of this method is the lack of ability to define

on the command line of the compiler, but from a configuration management
standpoint, this isn't a disadvantage at all.

Aug 29 2001