From: thor@math.tu-berlin.de
On 16.05.2013 14:40, James K. Lowden wrote:
> On Mon, 13 May 2013 23:41:14 -0700 (PDT)
> Thomas Richter wrote:
>
>> > The minimum I would like to see is the ability to iterate over the
>> > members of a structure.
>>
>> Again, I typically don't need that, but it would include some
>> overhead. For example, the structure layout would likely need to be
>> stored somewhere at run time. I don't need this overhead. But if you
>> do, I'm sure a library solution is feasible which does that.
>
> Really? Name one.
You already did. CORBA does solve the problem nicely. Probably "inverse"
from the way you want it because you first have to write the IDL and not
the C++ classes, but anyhow, it'll do. The C++ mapping is awkward, but
there's supposed to be a new one probably this year, or maybe already
last year. I'm no longer actively using Corba, but it does its job.
If I had the same problem, I would probably write my "classes to be
serialized" in a restricted C++ dialect, then write a yacc or bison code
to parse that, and generate the necessary code automatically. All that
would go into a makefile, so the make architecture would ensure that
everything you need is built as you go.
Or I would pick java right away, which has such things built in.
In either way, I don't need it in C++, and it would be a burden for C++
to add it because it is a service that is adding complexity without much
benefit for everyone. It is a specific solution for a very specific problem.
> The compiler does not supply the information that a library would need
> to execute generic serialization. That is why every serialization
> library used by C++ requires the buffers to be externally defined.
See above, you can supply everything you need just with a bit of
handwork that can be automated.
>> > We spend far too much time today dealing with I/O, recreating by
>> > hand the very metadata discarded by the compiler. With support
>> > from the compiler, C++ could provide easy, standard, robust,
>> > efficient, reliable I/O for user-defined types of arbritrary
>> > complexity. Until then, we'll party on like it's 1985.
>>
>> I would rather say, you picked the wrong tool for the job in first
>> place. I don't know what you do or which types of problems you want to
>> solve, but C++ does not sound like the solution for your problem.
>
> I think it's safe to say I understand the problem I'm trying to solve
> better than you do.
So may it be, but may I then ask why you pick C++ instead of, say, Java?
>> If your programs are mostly I/O bound, I would check for programming
>> languages that offer a higher abstraction level than C++.
>
> I pretty much have to use C++, because I'm writing, um, C++ libraries.
So why do you write C++ libraries if you need to solve database
problems? These are typically I/O bound in my experience, and you don't
need the low-level control C++ offers.
> I didn't say the programs were I/O bound. I am saying they're I/O
> awkward. That matters because any useful computation requires input
> and output.
That is so general that it applies to every program. Actually, a program
without output is pretty much useless, I would say.
>> > Why do people think pointers can't be serialized?
>>
>> In specific, the above "serialization" cannot distinguish
>> between two pointers that point to the identical object, and two
>> pointers that point to similar objects.
>
> Pointers are nothing more than offsets, counters from zero into linear
> memory. To write them out and read them back in requires only to
> encode and decode them. If it couldn't be done, "marshalling" wouldn't
> be part of our working vocabulary.
Sorry, but how is that supposed to work? If I de-serialize two objects,
how can one ensure that they have the same offset they had when they
were serialized? You can't, so it won't work. You need to find some
abstract description of the graph described by the pointers, and this is
problem-dependent and cannot be solved by just "following the pointers".
>> The problem is just that you now assume networking to be part of the
>> language
>
> No. The problem is you're looking through the wrong end of the
> telescope. You seem to think the problem is unimportant and can be
> solved with a library. It cannot, and it matters.
That depends on your problem domain. The problem actually *is*
unimportant for most C++ users, which is exactly why it is not part of
the language. It is a problem for a specific application domain, but as
I already pointed out above, *if* you want to solve it with C++, there
are enough tools around to do that job for you. But as I also pointed
out, I probably won't pick C++ in first place for that. I would use code
other people had written already, in another language that is better
adapted to the problem. You seem to believe that most problems are
database and serialization problems, but they aren't. Honestly, I
believe you're holding the telescope the wrong way. (-;
> We have typeof and sizeof and offsetof. We do not have, say, memberof
> or nameof or parentof or childof.
In terms of inheritance, it should be possible to do that by language
means and template magic, but I never tried. In terms of "pointers", it
cannot be solved by the language in first place. C++ has no language
means to identify a tree as a tree, and to serialize it as a tree just
by seeing two pointers. Essential information is missing for that. For
example, that there are no circles in the graph.
> We have, in short, incomplete
> ad hoc access to program metadata. Without complete access to that
> data, it impossible to do many things that can be done in Java or
> Smalltalk or Python.
But then, what is your problem, I ask you again. Why don't you do such
things in Java, smalltalk or python? Every language has its natural
application domain, and the type of problems you describe neither
require the low-level support of C++, nor does C++ provide language
features for that. You can built them, and you can invent tools to
support the compiler in your built-chain to support them, but the pure
fact that you need to should tell you that it's the wrong tool for the job.
> Many people wrongly assume that's because C++ is compiled. It's not.
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
