 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> In C, you declare a pointer to a structure without defining the layout
> of the structure. C allows this, because it assumes all pointers are the
> same size and have a unified alignment requirement and can all live in
> the same kinds of registers and things like that.
>
> Then in your code file, you define the structure. Creating an object
> involves allocating the structure and returning the opaque pointer to
> it. Using the object requires passing the opaque pointer back in.
>
> No implementation details are visible at all.
good ol' abstract data types. I still enjoy Haskell's powerful algebraic
datatypes, higher-order functions, currying and concise coding a lot more.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> In C, you declare a pointer to a structure without defining the layout
> of the structure.
Ah, yes. I believe Borland's TurboPascal allows this too. (There's a
type just called "Pointer", which you then have to cast to something
else before you can use it.) Good luck with figuring out how big the
data structure in question is... (But then, presumably the module that
uses this thing will handle all creation and destruction.) Also fun, you
how cannot have an array of this thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> good ol' abstract data types.
That's not an abstract data type. It's merely a hidden implementation.
> I still enjoy Haskell's powerful algebraic
> datatypes, higher-order functions, currying and concise coding a lot more.
*That* is way closer to an abstract data type. :-) And yah, I'm not
condoning it as better. Merely as possible.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 wrote:
> (But then, presumably the module that
> uses this thing will handle all creation and destruction.)
Well, yes, that's the idea. That's one way it's better than C++'s
mechanism, which requires you to (for example) recompile every client if
you change the layout of the private bits of the class.
> Also fun, you
> how cannot have an array of this thing.
You can't have an array of pointers, or an array of the things? That
seems odd if the former.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Orchid XP v7 wrote:
>> (But then, presumably the module that uses this thing will handle all
>> creation and destruction.)
>
> Well, yes, that's the idea. That's one way it's better than C++'s
> mechanism, which requires you to (for example) recompile every client if
> you change the layout of the private bits of the class.
>
>> Also fun, you how cannot have an array of this thing.
>
> You can't have an array of pointers, or an array of the things? That
> seems odd if the former.
No, the latter; you can't have an array who's elements are a particular
type since the compiler won't know how big it is.
(Notice that Haskell has no such limitation; you can expose no
implementation information to THE PROGRAMMER whilst this information IS
still exposed to THE COMPILER. Indeed, you can even define rewrite rules
on the code in your library, so clients of the library actually have
their code transparently rewritten, and the clients don't need to know
this...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> No, the latter; you can't have an array who's elements are a particular
> type since the compiler won't know how big it is.
Right. Not unusual in compiled languages, that.
> (Notice that Haskell has no such limitation; you can expose no
> implementation information to THE PROGRAMMER whilst this information IS
> still exposed to THE COMPILER.
So, I can have a module that changes the size of the objects it works
with, and the compiled code of the caller doesn't have to see that?
I.e., to make this happen, does the caller need the source code to my
module? Or can I compile that module, give you the executable (or
library), and you can allocate the right size object without knowing it?
Cause, like, doing that when you're distributing library sources is
pretty easy.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Invisible wrote:
>> No, the latter; you can't have an array who's elements are a
>> particular type since the compiler won't know how big it is.
>
> Right. Not unusual in compiled languages, that.
Indeed.
>> (Notice that Haskell has no such limitation; you can expose no
>> implementation information to THE PROGRAMMER whilst this information
>> IS still exposed to THE COMPILER.
>
> So, I can have a module that changes the size of the objects it works
> with, and the compiled code of the caller doesn't have to see that?
No.
If your code calls my module, and my module changes internally, you will
have to recompile your code. You don't need to *change* your source code
in any way, just recompile it.
The optimiser performs moderately extensive cross-module optimisations.
[My code might get inlined into yours. My types (which you, the
programmer, can't see the representation for) might get unboxed into CPU
registers during tight inner loops in your code. My module might define
transformation rules that rewrite parts of your program when you compile
it. And you don't have to care about any of this...]
> I.e., to make this happen, does the caller need the source code to my
> module? Or can I compile that module, give you the executable (or
> library), and you can allocate the right size object without knowing it?
Suppose I write some module named "Banana". In order to compile your
code against my module, you will need to possess either
* The source code ("Banana.hs")
* The object code ("Banana.o") + the interface file ("Banana.hi")
As long as you have one or the other, you can compile against my code.
So yes, I can write Banana.hs, compile it (thus generating Banana.o and
Banana.hi) and give you the latter files (which are both binary). You
won't have my source code, but you can still compile against it.
Indeed, the compiler ships with compiled base libraries, and doesn't
*provide* source code unless you download it seperately. (Which is just
as well, because it's quite large and takes a while to compile...)
(As an aside, in order to use the object code file, you'll need to be
using the exact same compiler version as me. On the same platform,
obviously.)
> Cause, like, doing that when you're distributing library sources is
> pretty easy.
Um... I'm not sure exactly which statement you're trying to make.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>> Right. Not unusual in compiled languages, that.
> Indeed.
OK, all the stuff you described is pretty much SOP for compiled modular
languages (for everything but C++, that is).
Ada, for example, won't even let you link against the .o file if you
compiled against a corresponding .hi file that was compiled more
recently than the .o file. So you can't even mix-and-match
representations incorrectly.
> Um... I'm not sure exactly which statement you're trying to make.
I meant that making it such that you can "hide" the representation from
the programmer and do all that fancy stuff, but then require the source
files of the declarations (a la C++) is a pretty easy thing to do. Much
harder to allow (say) inlining of already-compiled code.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Invisible wrote:
>>> Right. Not unusual in compiled languages, that.
>> Indeed.
>
> OK, all the stuff you described is pretty much SOP for compiled modular
> languages (for everything but C++, that is).
>
> Ada, for example, won't even let you link against the .o file if you
> compiled against a corresponding .hi file that was compiled more
> recently than the .o file. So you can't even mix-and-match
> representations incorrectly.
>
>> Um... I'm not sure exactly which statement you're trying to make.
>
> I meant that making it such that you can "hide" the representation from
> the programmer and do all that fancy stuff, but then require the source
> files of the declarations (a la C++) is a pretty easy thing to do. Much
> harder to allow (say) inlining of already-compiled code.
>
I'm probably missing something... can't you do it with .o + .h in C++?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> I'm probably missing something... can't you do it with .o + .h in C++?
The .h file is source code, hence revealing the internal layout of your
objects. And the functions you want to inline are presented in source.
And you can't be sure the .h matches the .o.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
