|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David H. Burns wrote:
> much available code was written before XP and apparently the API functions
> have changed. But then I read that Microsoft Visual Whatever version 8.0 is
> incompatible with Version 7.0 .... One seems trapped.
No need to feel trapped. Its fully backward compatible. And
available for free, too. And if you don't like it you can use
C++ Builder. Or MinGW. Or Linux. But you won't get around
learning how to program with whatever you choose ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin wrote:
> But you won't get around
> learning how to program with whatever you choose ;)
I can program--or at least once I could: in Basic, (and VB not "net"),
Z-80 assembly, and C --oh yes, I fulfilled the language requirement for
my MS
by writing a "substantial program" in Turbo Pascal (they shouldn't have
let me
get away with it, they should made me pass a reading test in a "foreign"
human language!) Programming itself is not difficult! But ....well
anything else
I might say along this line would most certainly be off topic.
The question is not whether to learn to programming, but whether to spend
a long time learning to use tools which are now available. I might better
spend that time using Pov-Ray itself (in which many beautiful things can be
done)and also with Visual Basic 4.0 (which has only the bare trappings of
OOP).
I need to learn to do a smiley face.
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> The question is not whether to learn to programming, but whether to spend
> a long time learning to use tools which are now available. I might better
> spend that time using Pov-Ray itself (in which many beautiful things can be
> done)and also with Visual Basic 4.0 (which has only the bare trappings of
> OOP).
Unless you intend to completely give up programming, try to dig the OOP concepts
- there's virtually no way around them these days. I guess even POV-Ray's SDL
will move towards OOP in the future.
And I'm perfectly sure it's for the better. I know of no better tool yet to
manage software complexity.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> And I'm perfectly sure it's for the better. I know of no better tool yet to
> manage software complexity.
Metaprogramming trumps OO hands down. :-)
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > And I'm perfectly sure it's for the better. I know of no better tool yet to
> > manage software complexity.
>
> Metaprogramming trumps OO hands down. :-)
I'd consider that a quite orthogonal programming techniqe: The output can be
smalltalk just as well as it can be assembler code. (Strictly speaking, *all*
programming these days constitutes metaprogramming: Only very few modern
computers provide interfaces to enter machine programs manually ;))
Likewise, metaprogramming can be used to implement OOP paradigms in a language
that does not support them natively. Actually, that's how C++ started: The first
C++ compilers generated C code.
But yes, metaprogramming does raise OO to the best of its potential: Reflection
rules! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You guys have lost me. I'm just one of the laity and haven't been initiated
into the priesthood of programmers and it's mysteries.
(Smile)
David
clipka wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> And I'm perfectly sure it's for the better. I know of no better tool yet to
>>> manage software complexity.
>> Metaprogramming trumps OO hands down. :-)
>
> I'd consider that a quite orthogonal programming techniqe: The output can be
> smalltalk just as well as it can be assembler code. (Strictly speaking, *all*
> programming these days constitutes metaprogramming: Only very few modern
> computers provide interfaces to enter machine programs manually ;))
>
> Likewise, metaprogramming can be used to implement OOP paradigms in a language
> that does not support them natively. Actually, that's how C++ started: The first
> C++ compilers generated C code.
>
> But yes, metaprogramming does raise OO to the best of its potential: Reflection
> rules! :)
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Likewise, metaprogramming can be used to implement OOP paradigms in a language
> that does not support them natively. Actually, that's how C++ started: The first
> C++ compilers generated C code.
I don't think my use of the term metaprogramming matches your use of the
term metaprogramming. Simply writing in a language the computer doesn't
natively understand isn't metaprogramming in the sense I meant it.
> But yes, metaprogramming does raise OO to the best of its potential: Reflection
> rules! :)
That's closer. When the structures of the program code itself are
manipulable from inside the program, that's metaprogramming. When a language
(like C) makes it harder to metaprogram than to just brute-force the code
you want to implement, you're lacking something.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> That's closer. When the structures of the program code itself are
> manipulable from inside the program, that's metaprogramming. When a language
> (like C) makes it harder to metaprogram than to just brute-force the code
> you want to implement, you're lacking something.
Sure. But without OO concepts embedded in the "metaprogrammed" language, your
choice of metaprogramming patterns is probably limited to code generation. For
more generic manipulation you need a generic manipulation interface - which is
an example of polymorphism, one of the key paradigms of OOP.
So what you consider metaprogramming, I'd consider "OOP deluxe" :)
(Um... sorry for hijacking this topic :})
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Sure. But without OO concepts embedded in the "metaprogrammed" language, your
> choice of metaprogramming patterns is probably limited to code generation.
Rerouted to off-topic.
Generally, you meta-program in OO as you need it. See Tcl, FORTH, Lisp, etc.
OO is really just a subset of closures, for that matter.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
For the record, I have not been able to find the
.../windows/pvdisplay.cpp file
in the 3.6 source, but at this point, I doubt if it would be any help. I
played
around with some of the files, but ran into Internet Explorer version error.
when I tried compiling them. Information on the internet from about 10 years
ago didn't help me to correct them. But I'm sure that individual code
would not
compile anyway. I think I have exhausted that approach. I may later try to
describe the kind of feature I would like to see added to Pov-Ray and
submit it for consideration. But first I need to play around and see if
Pov-Ray
already has what I want.
David
clipka wrote:
> If you want to find out how POV-Ray for Windows does the thing, the point to
> start your excursion is probably the .../windows/pvdisplay.cpp file.
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |