Odpověď na názor

Proc pouzivas memcpy() pro praci se stringy? :) :) :) K tomu je urcen strncpy(), nicmene po nacerpani zkusenosti programatori preferuji napr.:

#include <glib.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    GString *buf = g_string_new("aaaa");
    puts(buf->str);
    g_string_free(buf, true);
    return EXIT_SUCCESS;
}

v C++ to vypada pro zmenu:

#include <iostream>
#include <cstdlib>

using namespace std;

int main(void)
{
    string str("aaaa");
    cout << str << endl;
    return EXIT_SUCCESS;
}

Tyto priklady jsou prilis trivialni - nelze z nich posoudit nic. Co se treba podivat jake nechutne hacky jsou ve wrapperech C socketu pro C++? Nebo spinavosti v GTK2 -> Gtkmm ? Linus ma pravdu a vi o cem mluvi.

V rozsahlem projektu jsou objekty pritezi a proto treba takovy Mozilla Firefox / Mozilla XUL / GIMP / OpenGL / Xorg X11 Server / Gnome / Linux jsou vsechny v C.

Implicitne predpokladam, ze C++ je oblibenejsi mezi uzivateli Windows, Objekty jsou skutecne jen ty berlicky, ktere maji pomoci programovat i lidem, nemajicim na to bunky, asi jako M$ chce, aby si uzivatel predstavil "Muj pocitac" misto hard disku, dvd-vypalovacky, usb disku, etc. protoze by tomu nerozumel. Pokud se k tomu dostane uzivatel, ktery ale znalosti ma, pouze bude zmaten a iritovan kvuli nadmerne abstrakci.

Objekty usiluji o totez, je to myslenka vedouci M$ napr. k typedefum pro veskere standardni datove typy, kvuli kterym je programovani pro Windows hruza. Kdyz ji nekdo pretrpi, uz nechce zazit neco podobneho NIKDY vice a proto radeji zustava kvuli WinAPI u Windows.

A pak prisla jeste vetsi hruza - .NET :) Misto aby M$ C++ podporoval, chysta se od WinAPI *zcela* upustit a vsude mit jen .NET. Budoucnost C++ ve Windows neni svetla, budoucnost C v UNIX-like OS naopak je a vice zmrsene interfaces, nez v C++ vidime u M$ jen tak nenalezneme. Tam bych prave srovnaval kod, ne u trivialit pro praci se stringy, kde ji jeden jazyk ma built-in a druhy ji includuje z glib.