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

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.

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)?

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

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.

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

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.

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

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

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
DOITTHISWAY
>on the command line of the compiler, but from a configuration management standpoint, this isn't a disadvantage at all.
>
>

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

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