Hi,

today I had to write some unittests for the googletest framework. For one of the tests I had to read binary files, and fed their contents to some code for testing. In D this is really simple:

import std.file;
auto inbuffer = cast(byte[]) read("MyTestVectorData.bin");

In C++ this simple task expands to the following self-written code:

    // Lots of includes needed to compile this code
    std::vector<uint8_t> readFile(const char* filename)
    {
        // open the file:
        std::ifstream file(filename, std::ios::binary);
        // Stop eating new lines in binary mode!!!
        file.unsetf(std::ios::skipws);
        // get its size:
        std::streampos fileSize;
        file.seekg(0, std::ios::end);
        fileSize = file.tellg();
        file.seekg(0, std::ios::beg);
        // reserve capacity
        std::vector<uint8_t> vec;
        vec.reserve(fileSize);
        // read the data:
        vec.insert(vec.begin(),
                   std::istream_iterator<uint8_t>(file),
                   std::istream_iterator<uint8_t>());
        return vec;
    }
    /* ... somewhere else below, then and finally ... */
    auto myFilebuffer = readFile("Foo.bin");

I have problems to understand, why everything really useful is not part of STDL. Or why is whitespace skipping some default and must be unset? Or why is there no simple wrapper to query the file size instead of doing old-fashion seek-around? Or ...

So, if you need an example, why C++ simply s***s and D just rocks, use this... ;-)

Regards
  Carsten

On Wednesday, 16 March 2022 at 09:19:19 UTC, Carsten Schlote wrote:

Regards
  Carsten

You're right on the fact that D std is better for that but apparently there were shorter c++ alternatives (just searched "stdc++ read file in vector")

std::vector<uint8_t> vec readFile(const char* filename)
{
  std::vector<uint8_t> vec;
  if (FILE *fp = fopen("MyTestVectorData.bin", "r"))
  {
    char buf[1024];
    while (size_t len = fread(buf, 1, sizeof(buf), fp))
    {
      v.insert(vec.end(), buf, buf + len);
    }
    fclose(fp);
  }
  return vec;
}

or

std::vector<uint8_t> readFile(std::string filename)
{
  std::ifstream instream(filename, std::ios::in | std::ios::binary);
  std::vector<uint8_t> data((std::istreambuf_iterator<char>(instream)),
     std::istreambuf_iterator<char>());
  return data;
}

On Wednesday, 16 March 2022 at 11:20:45 UTC, user1234 wrote:

There's also a clear difference in the philosophy of the two languages.

D aims a lot to be general purpose, C++ aims to be flexible and usable in all areas, even low-level or obscure systems.

Thus D standard library makes a lot of decisions and assumptions for the users and locks users within those guidelines mostly.

C++ doesn't make a lot of decisions or assumptions about the user, everything is mostly left up to the user to decide how they want to do a specific thing.

So if you want total control and freedom, then you'll end up with something like what C++ offers anyway.

On Wednesday, 16 March 2022 at 11:20:45 UTC, user1234 wrote:

Regards
  Carsten

If you can assume that the file isn't modified then use std::filesystem::file_size to obtain the size, allocate a buffer and use C-api to read the file in one go.

On Wednesday, 16 March 2022 at 11:56:33 UTC, bauss wrote:

There is nothing stopping C++ from implementing a read function similar to D and it can coexist together with the existing interface. I think it is some kind of tradition preventing the standard library to be user friendly. Many companies use Qt-core (despite they don't use any GUI part of it) instead because that library is more usable .

Also the idea that std::istreambuf_iterator() is a good name for an end iterator further proves that point. There must be another better name for it though.

On Wednesday, 16 March 2022 at 11:20:45 UTC, user1234 wrote:

Thanks for the proposals. I used the more C-ish one for my cleanup ;-)

On Wednesday, 16 March 2022 at 11:56:33 UTC, bauss wrote:

In BetterC mode or with GC disabled you can use D for low-level as well.

The phobos library is perfectly tuned to support every-days work, D scripts (!) and tools. I use Dlang a lot for scripting and build tools. This is more or less impossible in C/C++ as nearly everything useful is missing in libc and the stdc++ libraries.

So everyone is reinventing the wheel for even the most simplest things. This is surely no advantage.

As said, in BetterC mode you can create bare-bine code as well. But with most important D language features still available.

On Thursday, 17 March 2022 at 07:38:52 UTC, Carsten Schlote wrote:

I'm not siding with C++ lol... I'm just stating why it's different.

Obviously I prefer D over C++, otherwise I'd be active elsewhere.

On Thursday, 17 March 2022 at 07:38:52 UTC, Carsten Schlote wrote:

Sure, but there are D and C++ have different cultures, and actually C++ has multiple cultures (and so does D, even if the scale is much smaller).

So in C++ you have the original 80s/90s C++ culture of making C more high level, where the somewhat annoying stream concept comes from. That abstraction is mostly useful for prototyping (and that applies to most of the containers too)… but as computers have become more powerful C++ has become less and less sensible for higher level programming and other options such as Java, C# and TypeScript has eaten into application areas that used to be done in C++. When you do lower level programming in C++ you usually use the platform APIs and even the C-API is considered too abstract and limited. So, what you usually would do is that you encapsulate the platform specific code in you application and translate that limited platform dependent code to new platforms as you expand.

While it is tempting to think that is possible to create a portable file API, it actually isn't. The only reason that it seems possible is that POSIX has historically been a target for common operating systems for personal use. However, when you go diskless and use cloud file systems you are in a field where you have to do things differently. Which means major rewrites if your application assume a conventional file system. That said, the "read whole file at once" and "write whole file at once" probably is the most portable abstraction, but you also need to deal with other aspects of a file system than that (like transactional aspect or archiving/journaling features)… so abstractions are problematic and their usefulness is limited in time.

In D you have at least two different cultures, those that use D as a native higher level language/scripting language and those that use D as a C++ replacement. The more expansive standard library of D enables more scripting like programming, although there are areas where the more limited C++ standard library is more complete.

In short, C++ has aimed for minimalistic standard library and D has aimed for a Python-like standard library. There are advantages and disadvantages in both approaches and what makes most sense depends on the usage scenario.