Re: compilers, endianness and padding

On 13.05.2013 08:12, James K. Lowden wrote:
  >
  > On Thu, 9 May 2013 00:03:42 -0700 (PDT)
  > Thomas Richter<thor@math.tu-berlin.de> wrote:
  >
  >> (otherwise, please explain me how to serialize a pointer).
  >
  > I'm sorry, but I consider this a trope. Not only is "serializing a
  > pointer" a solved problem in two dozen libraries since, oh, COBRA,
  > but
  >
  > ostream operator<<(ostream, char *)
  >
  > has been, as you well know, defined in namespace std for 25 years.

This does not serialize a pointer. It serializes the object the
pointer points to, which is quite something different.

  > Why do people think pointers can't be serialized?

Because the value of the pointer is specific to the run of the
program. In specific, the above "serialization" cannot distinguish
between two pointers that point to the identical object, and two
pointers that point to similar objects. This can make quite a
difference in program code.

  >> This is the wrong place for it because the philosophy of *this*
  >> language is a different one. It is "do not pay for what you do not
  >> need", and I do not need it. I can write portable I/O just fine
  >> without the help of the language. I use libraries for that.
  >
  > I find it odd that
  >
  > char *s = "hello";
  > cout<< s;
  >
  > works, but
  >
  > struct { char *s; } s = { "hello" };
  > cout<< s;
  >
  > does not.

Of course it works. Supply the right operator for your structure, and
off you go. There is absolutely nothing special about std::string. The
standard committee just choose that it would be considerably more
useful to have already an operator<< for string, whereas they could
not predict how your structures look like and how they should appear
printed on screen (or disk).

  > I do not understand why we accept serialization of built-in types,
  > and resolutely refuse to standardize -- or even support the
  > standardization of -- serialization of user-defined types.

std::string is not "built-in". It is a library solution that is
specified because it is of general use. The structures and classes in
your code are likely of very less general use, but if they are of
*some* general use, they probably have output operators that are
specified in *some* standard. Standard C++ is really what is supposed
to be useful for every user of C++.

  > 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.

  > Suppose they were described as an array of tuples of {type, size,
  > constness}. Then we could serialize abstractly along the lines of
  >
  > struct { ... } foo;
  > for_each(members_of(foo).begin(), ... );
  >
  > The compiler could readily support automatic typing of the
  > members_of elements and supply sufficient metadata to traverse an
  > inheritance/aggregation tree. These are the necessary missing
  > ingredients to a standard serialization library.
  >
  > There need not be any cost. The metadata are required only if
  > referenced. Nothing prevents the optimizer from stripping it away.
  > Nothing prevents the compiler from segregating the metadata
  > somewhere such that it is not loaded into memory unless it's used.

Well, propose a solution. I personally wouldn't care much since I
wouldn't need it, and if I need serialization, I only need a partial
serialization - the above "automation" does not do the right thing if
I have pointers somewhere.

  > But wait, you say. Why is serialization so important? I ask you,
  > why is std::string special?

It isn't special at all. It's a library solution like any other
classes, too. It was just considered to be standardized because it is
quite useful for a large audience.

  > When C++ was young, the liabilities of uninitilalized pointers and
  > null-terminated character arrays in C were widely acknowledged. C++
  > answered them with references (foo_t&) and std::string. The
  > language succeeded by answering the needs of the day.
  >
  > Both language and library were designed when networks were still
  > strange and nonstandard, when people still paid attention to the ISO
  > model and SNA and X.400. Networking was a bespoke business; the
  > problem of transmitting a data structures from one machine to
  > another was hardly standardized at the operating system level, let
  > along between applications. Cfront appeared in 1985; the likes of
  > CORBA not until 1992, NCSA Mosaic in 1993.

....and CORBA is dead nowadays, but provides serialization in - wait -
C++. So where is your problem, you have the solution. (Well, the C++
binding of Corba is awkward, but that's a Corba problem, not a C++
problem).

  > Indeed, when Java arrived in 1995 its main claim to fame other than
  > GC was built-in networking.

Which is also a library solution. Java has the advantage of a very
rich "standard library" because its application domain is narrower
than that of C++. But C++ runs on platforms java does not run on, so
you gain something, and you loose something. I'll certainly not stop
anyone from using Java. Actually, I'm programming a lot in java these
days, but also in C++.

  > Given the networks of the day (primitive), the machines of the day
  > (slower by 6 orders of magnitude), and the experience with C++ at
  > the time (roughly nil) Stroustrup& friends restricted themselves to
  > a single, well understood problem: std::string. To answer my own
  > question, std::string is special because its need was recognized in
  > 1985.

The problem is just that you now assume networking to be part of the
language, but C++ also runs on platforms that have nothing like
that. So it's not there. If you need networking in C or C++, the
solution is to pick *other* standards that solve these problems for
you. C++ does not intent to solve problems like GUIs or
serialization. There are solutions for such problems on the market,
and written down as standards, so where's the problem using them?

  > In 2013, the need for stardardized serialization has become clear.

Not to me. I don't have this problem in my day job. Really. If I had,
I would probably pick a language that solves the problem in a better
way. I use C++ because it is a powerful rich language that allows me
to write fast algorithms with a good structure. If GUIs are my
problem, I pick Java - or probably use a creator for HTML5 documents,
as java applets are also dying out.

  > 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. If
your programs are mostly I/O bound, I would check for programming
languages that offer a higher abstraction level than C++. If most of
your job is writing serialization code, this is even more an indicator
that C++ is the wrong choice for the problem.

Greetings,
    Thomas

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]