 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] san rrcom> wrote:
>> I saw a LOL line on another conversation.
>> > > Having used Ada and C++ extensively,
>> > > I'll take Ada over C++ any day.
>> > Never having used Ada at all, I'll take Ada over C++.
>
> Ada may be a wonderful language, but its lack of recent popularity
> means that the amount of available libraries is probably quite small.
This is true. Even simple things like base64 are not really easily
available. I was just amused at the quote.
> No matter how wonderful a language is, having to reinvent wheels with
> it is a major letdown.
That's why I'm looking at Erlang. Nice industrial libraries to go along
with the "bizarre" language.
> If I had to choose a language other than C++, I'll probably choose Java
> because of the amount of libraries and portability, or C# because it
> sounds a bit better than Java. (Or if efficiency is not an issue, maybe
> I would just go with PHP.)
PHP is really sucky for anything other than what all the libraries are
already written for. :-) It's a good tool to have in the toolbox, but
I'd not write a (say) desktop app in it, or for that matter anything
intended to run longer than a web page hit.
>> It really is amazingly well thought out as a language. Plus they've
>> added generics
>
> I thought templates are evil? ;)
I don't think C# generics are like templates. It's been a while, but I
don't remember even that syntax.
> It still makes be laugh out loud to remember how Java advocates
> fiercely attacked C++ templates. Then, some years later, they added
> some crippled template mechanism to Java (which still doesn't solve
> all the issues).
They didn't change the VM to support it. How good could it be? I think
it was more pre-processor tricks than anything, IIRC.
>> I thought that was the idea behind Vista? Most of it rewritten to .NET?
> Ah, now I understand why it's so large, heavy and slow.
Yep. And not even actually ported. :-)
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Paul Fuller wrote:
> The Program <=> SQL divide is what LINQ targets and seems to
> dramatically advance.
Yeah. That, or OO databases, or whatever the flavor-of-the-week is.
Erlang has its own database stuff, so you can store any value in the
database, indexed by any value. Not SQL, but a decent database.
> I'm not sure how much if any of Vista is actually written in .Net.
Right. Sorry. I hadn't mean to imply it actually *happened*. Just that
that was the idea of it.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> IntegerOrFloat* ptr = whatever;
That's a pointer to a struct. :-)
I know you're joking, but that's the sort of quibble people make when
distinguishing references from pointers from addresses.
> The point was not whether it has public and private sections, but
> whether you can implement something the class uses somewhere else than
> in the class declaration, completely invisible to the rest of the program.
Um, yes. I'm not sure what you mean, tho.
How can it be "completely invisible to the rest of the program" and
still be useful?
You can implement private methods that only the class can call and which
are invisible to any code not in the class defining the method, if
that's what you mean. You can even put it in a separate file all by itself.
> That was not my point. My point was that it's nice that I can put some
> implementations in a separate file, which reduces the clutter of the
> class declaration.
C# has "partial classes". That's what it's for. In practice, code
generators put generated code in one file and leave the other for you to
futz with.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Basically, there are any number of people who say "fast is better than
>> correct" because they've never built programs where incorrectness costs
>> money or lives.
>
> Oh, garbage collection is the Holy Grail of programming which, magically,
> makes programs "correct". Yeah. ;)
No, but it solves all kinds of nasty problems, just like the speed
penalty of array bounds checking does.
>> You can't accidentally declare the function taking a float in the
>> headers and an integer in the body and have mysterious type crashes at
>> runtime in spite of your static typing.
>
> C# doesn't check at compile time that all your types match?
It does. I was speaking of C or C++. If you only have one declaration
matching a given type to a given variable, then they can't get out of sync.
Ada gives you separate headers from bodies, but you have to actually
compile the headers, and you have to compile every header before its
body, and you can't refer to a header that was compiled after yours
were, so basically the language is required to enforce that the two
don't get out of sync.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> You can't accidentally declare the function taking a float in the
> headers and an integer in the body and have mysterious type crashes at
> runtime in spite of your static typing.
C++ won't let you do that, either.
It won't give a compiler error as overriding the function is allowed;
but it WILL give you a linker error, as the correct implementation is
not found anywhere.
--
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> Darren New wrote:
>> You can't accidentally declare the function taking a float in the
>> headers and an integer in the body and have mysterious type crashes at
>> runtime in spite of your static typing.
>
> C++ won't let you do that, either.
Really?
So if I have a class declared as
A.h:
class A { int X; float Y; }
A.c:
void makeAlpha(A* alpha) {
alpha.X = 27;
alpha.Y = 82.3;
}
B.c:
void useAlpha() {
A alpha;
makeAlpha(&alpha);
printf("%d\n", alpha.X);
}
And I compile A.c, then change A.h to put the member variables in the
opposite order, then compile B.c, and link the results together, you're
telling me the C++ standard tells me that shouldn't link?
I'm impressed.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> And I compile A.c, then change A.h to put the member variables in the
> opposite order, then compile B.c, and link the results together, you're
> telling me the C++ standard tells me that shouldn't link?
>
> I'm impressed.
Actually, I think I misunderstood what you said before. Anyway, with
the example you cite, any modern IDE would notice that A.h had changed
and recompile A.c. I have no idea what would happen if you forced it to
link against the old version, but probably the crashes you mentioned.
However, I really have to question the validity of your grief... after
all, explicitly linking against an out of date binary is bound to cause
trouble for you no matter what.
--
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> However, I really have to question the validity of your grief... after
> all, explicitly linking against an out of date binary is bound to cause
> trouble for you no matter what.
Well, yes. That's why Ada, for example, mandates that the compiler check
for that sort of thing.
The original question was "what's the benefit of not having separate
headers". That's one of the benefits - you don't even have to check if
the binary is out of date. Unless you have object code for headers,
there's no good way of checking whether the header has been changed
since the body has been changed, or whether the version of the header
you're using matches the version of the body.
Does C++ still choke if one source file has "extern int X;" and the
other has "float X;" as globals? Certainly C has no concept of "this is
a header" at compile time. Some compilers might try to make up for that
fact, but it's not part of the language.
If your compiler takes type declarations out of the object files instead
of the source code for types that you aren't actively compiling, I can't
see any good reason to manually maintain two versions of the declarations.
Eiffel's IDE even has functions to make "short" and "flat" and
"short/flat" declarations from the code. ("Short" being just the
signatures, and "flat" being code as if no inheritance was involved.)
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > IntegerOrFloat* ptr = whatever;
> That's a pointer to a struct. :-)
A union is not a struct. The 'ptr' truely points directly to either an
integer or a float, at the exact same memory location. There's no need
to calculate memory offsets.
> You can implement private methods that only the class can call and which
> are invisible to any code not in the class defining the method, if
> that's what you mean. You can even put it in a separate file all by itself.
If that's so, what's this talk about C# forcing you to implement everything
inline? I thought that meant you *can't* implement any part of a class in
a separate file.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> IntegerOrFloat* ptr = whatever;
>
>> That's a pointer to a struct. :-)
>
> A union is not a struct.
My bad. I understood, I just mispoke.
> The 'ptr' truely points directly to either an
> integer or a float,
No, it points to the union. The integer and the float are both at the
same *address*, but the pointer points to a *union*. :-)
Consider the difference between "pointer arithmetic" and "address
arithmetic". If ptr points to an integer, then ptr++ should change its
address by sizeof(int), right?
Again, it's nitpicking, but it's the kind of language-lawyering that
language designers babble about.
> at the exact same memory location. There's no need
> to calculate memory offsets.
Right. That's *address* arithmetic, tho. You can have different types of
pointers all pointing to the same address, *because* the difference
between "pointer" and "address" is whether it has a type. (At least in
most language design discussions.)
>> You can implement private methods that only the class can call and which
>> are invisible to any code not in the class defining the method, if
>> that's what you mean. You can even put it in a separate file all by itself.
>
> If that's so, what's this talk about C# forcing you to implement everything
> inline? I thought that meant you *can't* implement any part of a class in
> a separate file.
Err, no. It's called a "partial class". I believe perhaps the first
version of C# didn't have that?
// File A1.cs
partial class A {
void alpha(...) { ... }
}
// File A2.cs
partial class A {
void beta(...) { ... }
}
As I said, mostly used for code generators to stay out of your way.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
