That forces everything to be virtual.

But yeah it would work unless you wanted to have data in the public interface.

What I want really is to be able to avoid having to use pImpl pattern as is necessary to really hide the guts of a class in C++.  This may already be mostly possible in D;  probably is.

Sean

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:agq3mj$b41$1@digitaldaemon.com...
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message
> news:aglttj$uan$1@digitaldaemon.com...
> <SNIP>
> >
> > If you ask me (and you didn't) I'd want to be able to completely hide
any
> > private members from other code.  Other code shouldn't even know the
> private
> > members exist.  Which means you need to be able to specify them from
> outside
> > the externally visible declaration.
> >
> > // visible interface
> >
> > class Foo_public : private Foo_private
> > {
> >     void GoForIt();
> > }
> >
> > // hidden somewhere
> >
> > protected except(Foo_public)
> > class Foo_private
> > {
> >     int myprivateint; // nobody can see this but Foo_public
> > }
> >
> <SNIP>
> >
> > Sean
> >
>
>
> So use interfaces:
>
>
> interface IFoo
> {
>    void GoForIt();
> }
>
> class Foo: Object, IFoo
> {
>    int myprivateint;
>
>    void GoForIt()
>    {
>       printf ("myprivateint==%d\n", myprivateint);
>    }
> }
>
>
> Then you only need to publish the interface and
> can keep everything else private.
>
>
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> _________________________________________________
> Remove _XYZ from my address when replying by mail
>
>
>
>

>
> If you ask me (and you didn't) I'd want to be able to completely hide any private members from other code.  Other code shouldn't even know the
private
> members exist.  Which means you need to be able to specify them from
outside
> the externally visible declaration.

Yes, I never understood why C++ kept privates visible in the header. D automatically generates a header file, perhaps they could be removed from that.  If it is useful to have a private member listing, they could be placed in another file.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agq42d$bb6$1@digitaldaemon.com...
> That forces everything to be virtual.
>

In D all method pointers are already virtual aren't they?


> But yeah it would work unless you wanted to have data in the public interface.
>
> What I want really is to be able to avoid having to use pImpl pattern as
is
> necessary to really hide the guts of a class in C++.  This may already be mostly possible in D;  probably is.
>
> Sean

Yeah, when I first learned that private fields need to be in the .h file in C++ I thought it really sucked too!

They should have something like

int CMyClass::myfield;

in the .cpp files, where CMyClass would be a class declared in a header file included by the .cpp file. This should also go for methods. If they only exist in the .cpp file, they are automatically private.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Hello.

> Yes, I never understood why C++ kept privates visible in the header. D automatically generates a header file, perhaps they could be removed from that.  If it is useful to have a private member listing, they could be placed in another file.

I don't understand all of you. Private data *must* be visible to the world, because compilers must know how much memory to allocate for your classes. C++ does not use reference symantics, neither does Ada. But Ada allows you to define everything you want to be private in the private section of the package (and in C++, like I've shown, something that should be private has to be public, and that is not good). Of course, nonvirtual private procedures can (and should) be declared in the body of the package, i.e., the world wan't know anything. Virtual procedures must be in the spec to know how many slots does your type occupy in the v-table.

About exceptions: my example was not good. I did not meant that you should pass line & column no of exception. The exception was named EBadToken, and it was a part of some hypotetical lexical parser. LineNo and ColNo were just information that could be called FooData and BarData. The names do not matter.

I said that was not a proposal because that was not a complete exception model. A proposal is something I think is suitable for the language, or at least one of the ways something might be implemented. And my code was just an example, to start a subject of exceptions.

I think the idea of having numerous allocation methods is rather good. Again, first, look thru Ada Rationale - Ada has a convinient model of storage pools. I don't say D's "allocation methods" should look like Ada storage pools, but before creating something yourself, it's better to look through the existent implementations, determine what you like and what you don't like.

On Sat, 13 Jul 2002 22:36:45 +0200, "OddesE" <OddesE_XYZ@hotmail.com> wrote:

>Toyotomi, it sounds like you might *love* C#.
>I had a look at it and it's pretty nice! The
>language looks a lot like C/C++, but the
>environment starts to look more and more like
>Delphi. They have a great class library and
>the visual development environment is good too,
>some things that were seriously lacking in
>MSVC. By the way, what about Borland C++ Builder?
>Would that be something for you?

I've written a C# ftp client for transferring and syncing ~50k real estate images daily. I don't want to hear arguments about C#'s compiled-ness, but it is like Java, and it is not like a self sufficient C/C++/Delphi app. The runtime and memory use is insanely larger, and it will never be the same thing.

In order of frequency I use Delphi, C++ Builder & Visual Studio... However, after that are a slew of other languages and tools.

"Andrey Tarantsov" <andreyvit@nvkz.kuzbass.net> wrote in message news:agschk$2idc$1@digitaldaemon.com...
> Hello.
>
> > Yes, I never understood why C++ kept privates visible in the header. D automatically generates a header file, perhaps they could be removed
from
> > that.  If it is useful to have a private member listing, they could be placed in another file.
>
> I don't understand all of you. Private data *must* be visible to the
world,
> because compilers must know how much memory to allocate for your classes.

An intelligent compiler can append the private members from the body file before compliation. Java does this. From a users point of view, private's is just space junk because they can't use it. Ada had the same problem.

>Of course, nonvirtual private procedures can (and should) be declared in
the body of the package.

When would you ever get a virtual private?

"Andrey Tarantsov" <andreyvit@nvkz.kuzbass.net> wrote in message news:agschk$2idc$1@digitaldaemon.com...
> Hello.
>
> > Yes, I never understood why C++ kept privates visible in the header. D automatically generates a header file, perhaps they could be removed
from
> > that.  If it is useful to have a private member listing, they could be placed in another file.
>
> I don't understand all of you. Private data *must* be visible to the
world,
> because compilers must know how much memory to allocate for your classes. C++ does not use reference symantics, neither does Ada. But Ada allows you to define everything you want to be private in the private section of the package (and in C++, like I've shown, something that should be private has to be public, and that is not good). Of course, nonvirtual private procedures can (and should) be declared in the body of the package, i.e., the world wan't know anything. Virtual procedures must be in the spec to know how many slots does your type occupy in the v-table.

They should get such information from the linker.  Code generation should go after link step.  Or the compiler and linker could be otherwise integrated. You need this for templates anyway.

> About exceptions: my example was not good. I did not meant that you should pass line & column no of exception. The exception was named EBadToken, and it was a part of some hypotetical lexical parser. LineNo and ColNo were
just
> information that could be called FooData and BarData. The names do not matter.
>
> I said that was not a proposal because that was not a complete exception model. A proposal is something I think is suitable for the language, or at least one of the ways something might be implemented. And my code was just an example, to start a subject of exceptions.
>
> I think the idea of having numerous allocation methods is rather good. Again, first, look thru Ada Rationale - Ada has a convinient model of storage pools. I don't say D's "allocation methods" should look like Ada storage pools, but before creating something yourself, it's better to look through the existent implementations, determine what you like and what you don't like.

If to allocate an object you had to call some kind of per-class allocator instead of just requesting memory from wherever you want, this would be solved nicely.  Is the extra flexibility really worth it?  Perhaps a class could have multiple potential allocator pools (system memory, fast memory, or fixed sized preallocated buffer slot)

Sean

"Toyotomi" <kaishaku13@hotmail.com> wrote in message news:e7j4ju49poihi6br27eqsgi4hv7vdl256s@4ax.com...
> I've written a C# ftp client for transferring and syncing ~50k real estate images daily. I don't want to hear arguments about C#'s compiled-ness, but it is like Java, and it is not like a self sufficient C/C++/Delphi app. The runtime and memory use is insanely larger, and it will never be the same thing.
>
> In order of frequency I use Delphi, C++ Builder & Visual Studio... However, after that are a slew of other languages and tools.


Well, you certainly seem to have a lot more experience
with it than me. I guess I was misinformed. Sorry about
that. So there really *is* a gap in the market for D. I
thought of C# as D's biggest competitor, because I
thought you could straight compile your programs too.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ah1b24$1iko$1@digitaldaemon.com...
> "Toyotomi" <kaishaku13@hotmail.com> wrote in message news:e7j4ju49poihi6br27eqsgi4hv7vdl256s@4ax.com...
> > I've written a C# ftp client for transferring and syncing ~50k real
estate
> > images daily. I don't want to hear arguments about C#'s compiled-ness,
but
> > it is like Java, and it is not like a self sufficient C/C++/Delphi app. The runtime and memory use is insanely larger, and it will never be the same thing.
> >
> > In order of frequency I use Delphi, C++ Builder & Visual Studio... However, after that are a slew of other languages and tools.
>
>
> Well, you certainly seem to have a lot more experience
> with it than me. I guess I was misinformed. Sorry about
> that. So there really *is* a gap in the market for D. I
> thought of C# as D's biggest competitor, because I
> thought you could straight compile your programs too.
>

You can "straight compile your programs", but I'm told that COM makes it slow. I'll b't there's still a JITC still working on some of the compoents.

> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> _________________________________________________
> Remove _XYZ from my address when replying by mail
>
>
>

"anderson" <anderson@firestar.com.au> wrote in message news:agjp40$195r$1@digitaldaemon.com...
> --I wonder what Walter opinion on D looking like pascal more then C++ is?
> > > Although Walters previous pascal compiler experiance my shine though
the
> > cracks.
> Although Walters previous pascal compiler experiance may shine though the cracks.
> > What did you mean?
> I simply mean (Walter correct me if I'm wrong) is that Walters written a pascal compiler before and elements of that may show in D.

It's true that the first compiler I wrote was for a Pascal subset, way back in 1980 or so. While Pascal is not my favorite language, it does have a nice feature I tried to carry into D - that of being able to separate the lexical, syntactic, and semantic phases of compilation. This is a crucial feature for reducing a complicated language into managable pieces, for easy understanding and implementation.