Apa kemampuan baru yang ditambahkan oleh literal yang ditetapkan pengguna ke C ++?

C ++ 11 memperkenalkan user-defined literal yang akan memungkinkan pengenalan sintaks literal baru berdasarkan literal yang ada ( int, hex, string, float) sehingga jenis apapun akan dapat memiliki presentasi literal.

Contoh:

// imaginary numbers
std::complex<long double> operator "" _i(long double d) // cooked form
{ 
    return std::complex<long double>(0, d); 
}
auto val = 3.14_i; // val = complex<long double>(0, 3.14)

// binary values
int operator "" _B(const char*); // raw form
int answer = 101010_B; // answer = 42

// std::string
std::string operator "" _s(const char* str, size_t /*length*/) 
{ 
    return std::string(str); 
}

auto hi = "hello"_s + " world"; // + works, "hello"_s is a string not a pointer

// units
assert(1_kg == 2.2_lb); // give or take 0.00462262 pounds

Pada pandangan pertama ini terlihat sangat keren tapi saya bertanya-tanya bagaimana ini benar-benar berlaku, ketika saya mencoba berpikir untuk memiliki sufiks _ADdan _BCmembuat tanggal saya menemukan itu bermasalah karena pesanan operator. 1974/01/06_ADpertama akan mengevaluasi 1974/01(sebagai ints polos ) dan hanya kemudian 06_AD(untuk mengatakan apa-apa Agustus dan September harus ditulis tanpa 0alasan oktal). Ini dapat diatasi dengan membuat sintaks 1974-1/6_ADagar urutan evaluasi operator berfungsi tetapi kikuk.

Jadi yang menjadi pertanyaan saya adalah ini, apakah Anda merasa fitur ini akan membenarkan dirinya sendiri? Apa literal lain yang ingin Anda definisikan yang akan membuat kode C ++ Anda lebih mudah dibaca?

Sintaks yang diperbarui agar sesuai dengan konsep akhir pada Juni 2011

Inilah kasus di mana ada keuntungan menggunakan literal yang ditentukan pengguna alih-alih panggilan konstruktor:

#include <bitset>
#include <iostream>

template<char... Bits>
  struct checkbits
  {
    static const bool valid = false;
  };

template<char High, char... Bits>
  struct checkbits<High, Bits...>
  {
    static const bool valid = (High == '0' || High == '1')
                   && checkbits<Bits...>::valid;
  };

template<char High>
  struct checkbits<High>
  {
    static const bool valid = (High == '0' || High == '1');
  };

template<char... Bits>
  inline constexpr std::bitset<sizeof...(Bits)>
  operator"" _bits() noexcept
  {
    static_assert(checkbits<Bits...>::valid, "invalid digit in binary string");
    return std::bitset<sizeof...(Bits)>((char []){Bits..., '\0'});
  }

int
main()
{
  auto bits = 0101010101010101010101010101010101010101010101010101010101010101_bits;
  std::cout << bits << std::endl;
  std::cout << "size = " << bits.size() << std::endl;
  std::cout << "count = " << bits.count() << std::endl;
  std::cout << "value = " << bits.to_ullong() << std::endl;

  //  This triggers the static_assert at compile time.
  auto badbits = 2101010101010101010101010101010101010101010101010101010101010101_bits;

  //  This throws at run time.
  std::bitset<64> badbits2("2101010101010101010101010101010101010101010101010101010101010101_bits");
}

Keuntungannya adalah pengecualian run-time dikonversi menjadi kesalahan waktu kompilasi. Anda tidak bisa menambahkan pernyataan statis ke bitet ctor yang mengambil string (setidaknya bukan tanpa argumen templat string).

Pada pandangan pertama, tampaknya itu adalah gula sintaksis sederhana.

Tetapi ketika melihat lebih dalam, kita melihat itu lebih dari gula sintaksis, karena memperluas opsi pengguna C ++ untuk membuat tipe yang ditentukan pengguna yang berperilaku persis seperti tipe bawaan yang berbeda. Dalam hal ini, "bonus" kecil ini adalah tambahan C ++ 11 yang sangat menarik untuk C ++.

Apakah kita benar-benar membutuhkannya di C ++?

Saya melihat beberapa kegunaan dalam kode yang saya tulis dalam beberapa tahun terakhir, tetapi hanya karena saya tidak menggunakannya dalam C ++ tidak berarti itu tidak menarik untuk pengembang C ++ lainnya .

Kami telah menggunakan dalam C ++ (dan dalam C, saya kira), literal yang ditentukan compiler, untuk mengetikkan bilangan bulat sebagai bilangan bulat pendek atau panjang, bilangan real sebagai float atau double (atau bahkan double panjang), dan string karakter sebagai karakter normal atau lebar karakter .

Di C ++, kami memiliki kemungkinan untuk membuat tipe kami sendiri (yaitu kelas), dengan kemungkinan tidak ada overhead (inlining, dll.). Kami memiliki kemungkinan untuk menambahkan operator ke tipenya, agar mereka berperilaku seperti tipe bawaan yang serupa, yang memungkinkan pengembang C ++ untuk menggunakan matriks dan bilangan kompleks secara alami seperti yang akan mereka miliki jika ini telah ditambahkan ke bahasa itu sendiri. Kami bahkan dapat menambahkan operator cor (yang biasanya merupakan ide yang buruk, tetapi kadang-kadang, itu adalah solusi yang tepat).

Kami masih melewatkan satu hal untuk berperilaku tipe pengguna sebagai tipe bawaan: literal yang ditentukan pengguna.

Jadi, saya kira itu adalah evolusi alami untuk bahasa, tetapi untuk selengkap mungkin: " Jika Anda ingin membuat suatu jenis, dan Anda ingin agar berperilaku sebanyak mungkin sebagai jenis bawaan, berikut adalah alat-alatnya. .. "

Saya kira itu sangat mirip dengan keputusan .NET untuk membuat setiap primitif sebuah struct, termasuk boolean, integer, dll., Dan memiliki semua struct berasal dari Object. Keputusan ini sendiri menempatkan .NET jauh di luar jangkauan Java ketika bekerja dengan primitif, tidak peduli berapa banyak hacking tinju / unboxing yang akan ditambahkan Java ke spesifikasinya.

Apakah ANDA benar-benar membutuhkannya di C ++?

Pertanyaan ini untuk ANDA jawab. Bukan Bjarne Stroustrup. Bukan Herb Sutter. Bukan apa pun anggota komite standar C ++. Inilah sebabnya mengapa Anda memiliki pilihan dalam C ++ , dan mereka tidak akan membatasi notasi yang berguna untuk tipe bawaan saja.

Jika Anda membutuhkannya, maka itu adalah tambahan selamat datang. Jika Anda tidak, baik ... Jangan menggunakannya. Anda tidak akan dikenakan biaya.

Selamat datang di C ++, bahasa tempat fitur opsional.

Bengkak??? Tunjukkan kompleksmu !!!

Ada perbedaan antara kembung dan kompleks (pun intended).

Seperti yang ditunjukkan oleh Niels di Apa kemampuan baru yang ditambahkan oleh literal yang ditetapkan pengguna ke C ++? , bisa menulis bilangan kompleks adalah salah satu dari dua fitur yang ditambahkan "baru-baru ini" ke C dan C ++:

// C89:
MyComplex z1 = { 1, 2 } ;

// C99: You'll note I is a macro, which can lead
// to very interesting situations...
double complex z1 = 1 + 2*I;

// C++:
std::complex<double> z1(1, 2) ;

// C++11: You'll note that "i" won't ever bother
// you elsewhere
std::complex<double> z1 = 1 + 2_i ;

Sekarang, tipe C99 "komplek ganda" dan tipe C ++ "std :: complex" dapat dikalikan, ditambahkan, kurangi, dll., Menggunakan operator yang berlebihan.

Namun di C99, mereka hanya menambahkan tipe lain sebagai tipe bawaan, dan dukungan operator berlebih bawaan. Dan mereka menambahkan fitur literal bawaan lainnya.

Dalam C ++, mereka hanya menggunakan fitur bahasa yang ada, melihat bahwa fitur literal adalah evolusi alami dari bahasa, dan dengan demikian menambahkannya.

Di C, jika Anda memerlukan peningkatan notasi yang sama untuk tipe lain, Anda kurang beruntung sampai lobi Anda menambahkan fungsi gelombang kuantum (atau titik 3D, atau tipe dasar apa pun yang Anda gunakan di bidang pekerjaan) ke Standar C sebagai tipe bawaan berhasil.

Di C ++ 11, Anda bisa melakukannya sendiri:

Point p = 25_x + 13_y + 3_z ; // 3D point

Apakah kembung? Tidak , perlu ada di sana, seperti yang ditunjukkan oleh bagaimana kedua kompleks C dan C ++ membutuhkan cara untuk mewakili nilai kompleks literal mereka.

Apakah desainnya salah? Tidak , ini dirancang seperti setiap fitur C ++ lainnya, dengan ekstensibilitas dalam pikiran.

Apakah hanya untuk keperluan notasi? Tidak , karena bahkan dapat menambahkan keamanan jenis ke kode Anda.

Misalnya, mari kita bayangkan kode berorientasi CSS:

css::Font::Size p0 = 12_pt ;       // Ok
css::Font::Size p1 = 50_percent ;  // Ok
css::Font::Size p2 = 15_px ;       // Ok
css::Font::Size p3 = 10_em ;       // Ok
css::Font::Size p4 = 15 ;         // ERROR : Won't compile !

Maka sangat mudah untuk menerapkan pengetikan yang kuat untuk penugasan nilai.

Apakah ini berbahaya?

Pertanyaan bagus. Bisakah fungsi-fungsi ini di-namespace? Jika ya, maka Jackpot!

Bagaimanapun, seperti semua hal lainnya, Anda dapat bunuh diri jika alat digunakan secara tidak benar . C sangat kuat, dan Anda bisa menembak kepala Anda jika Anda menyalahgunakan senjata C. C ++ memiliki senjata C, tetapi juga pisau bedah, taser, dan alat apa pun lainnya yang akan Anda temukan di toolkit. Anda bisa menyalahgunakan pisau bedah dan membuat darah Anda mati sendiri. Atau Anda dapat membuat kode yang sangat elegan dan kuat.

Jadi, seperti setiap fitur C ++, apakah Anda benar-benar membutuhkannya? Ini adalah pertanyaan yang harus Anda jawab sebelum menggunakannya dalam C ++. Jika tidak, Anda tidak perlu membayar apa-apa. Tetapi jika Anda benar-benar membutuhkannya, setidaknya, bahasa tersebut tidak akan mengecewakan Anda.

Contoh tanggal?

Kesalahan Anda, menurut saya, adalah Anda menggabungkan operator:

1974/01/06AD
    ^  ^  ^

Ini tidak dapat dihindari, karena / sebagai operator, kompiler harus mengartikannya. Dan, AFAIK, itu hal yang baik.

Untuk menemukan solusi untuk masalah Anda, saya akan menulis literal dengan beberapa cara lain. Sebagai contoh:

"1974-01-06"_AD ;   // ISO-like notation
"06/01/1974"_AD ;   // french-date-like notation
"jan 06 1974"_AD ;  // US-date-like notation
19740106_AD ;       // integer-date-like notation

Secara pribadi, saya akan memilih integer dan tanggal ISO, tetapi itu tergantung pada kebutuhan ANDA. Yang merupakan inti dari membiarkan pengguna menentukan nama literalnya sendiri.

Ini sangat bagus untuk kode matematika. Dari pikiran saya, saya dapat melihat penggunaan untuk operator berikut:

deg untuk derajat. Itu membuat penulisan sudut absolut jauh lebih intuitif.

double operator ""_deg(long double d)
{ 
    // returns radians
    return d*M_PI/180; 
}

Ini juga dapat digunakan untuk berbagai representasi titik tetap (yang masih digunakan di bidang DSP dan grafik).

int operator ""_fix(long double d)
{ 
    // returns d as a 1.15.16 fixed point number
    return (int)(d*65536.0f); 
}

Ini terlihat seperti contoh yang bagus bagaimana menggunakannya. Mereka membantu membuat konstanta dalam kode lebih mudah dibaca. Ini adalah alat lain untuk membuat kode tidak dapat dibaca juga, tetapi kami sudah memiliki begitu banyak penyalahgunaan alat yang satu lagi tidak banyak merugikan.

UDL diberi spasi nama (dan dapat diimpor dengan menggunakan deklarasi / arahan, tetapi Anda tidak dapat secara eksplisit menyebutkan spasi seperti literal 3.14std::i), yang berarti ada (semoga) tidak akan ada satu ton bentrokan.

Fakta bahwa mereka dapat benar-benar templated (dan constexpr'd) berarti Anda dapat melakukan beberapa hal yang cukup kuat dengan UDL. Penulis Bigint akan sangat senang, karena mereka akhirnya dapat memiliki konstanta besar yang sewenang-wenang, dihitung pada waktu kompilasi (melalui constexpr atau templat).

Saya hanya sedih bahwa kita tidak akan melihat beberapa literal yang berguna dalam standar (dari tampilannya), seperti suntuk std::stringdan iuntuk unit imajiner.

Jumlah waktu pengkodean yang akan disimpan oleh UDL sebenarnya tidak terlalu tinggi, tetapi keterbacaan akan sangat meningkat dan semakin banyak perhitungan dapat digeser ke waktu kompilasi untuk eksekusi yang lebih cepat.

Izinkan saya menambahkan sedikit konteks. Untuk pekerjaan kami, literal yang ditentukan pengguna sangat dibutuhkan. Kami bekerja pada MDE (Model-Driven Engineering). Kami ingin mendefinisikan model dan metamodel dalam C ++. Kami sebenarnya menerapkan pemetaan dari Ecore ke C ++ ( EMF4CPP ).

Masalahnya muncul ketika mampu mendefinisikan elemen model sebagai kelas di C ++. Kami mengambil pendekatan untuk mengubah metamodel (Ecore) menjadi templat dengan argumen. Argumen template adalah karakteristik struktural dari tipe dan kelas. Sebagai contoh, kelas dengan dua atribut int akan menjadi sesuatu seperti:

typedef ::ecore::Class< Attribute<int>, Attribute<int> > MyClass;

Namun, ternyata setiap elemen dalam suatu model atau metamodel, biasanya memiliki nama. Kami ingin menulis:

typedef ::ecore::Class< "MyClass", Attribute< "x", int>, Attribute<"y", int> > MyClass;

TETAPI, C ++, atau C ++ 0x tidak mengizinkan ini, karena string dilarang sebagai argumen untuk templat. Anda dapat menulis nama char oleh char, tetapi ini diakui berantakan. Dengan literal yang ditentukan oleh pengguna, kita dapat menulis sesuatu yang serupa. Katakanlah kita menggunakan "_n" untuk mengidentifikasi nama elemen model (saya tidak menggunakan sintaks yang tepat, hanya untuk membuat ide):

typedef ::ecore::Class< MyClass_n, Attribute< x_n, int>, Attribute<y_n, int> > MyClass;

Akhirnya, memiliki definisi tersebut sebagai templat membantu kita banyak untuk merancang algoritma untuk melintasi elemen model, transformasi model, dll. Yang benar-benar efisien, karena informasi jenis, identifikasi, transformasi, dll. Ditentukan oleh kompiler pada waktu kompilasi.

Bjarne Stroustrup berbicara tentang UDL dalam pembicaraan C ++ 11 ini , pada bagian pertama tentang antarmuka yang kaya tipe, sekitar 20 menit.

Argumen dasarnya untuk UDL mengambil bentuk silogisme:

1. Tipe "Trivial", yaitu tipe primitif bawaan, hanya dapat menangkap kesalahan tipe sepele. Antarmuka dengan tipe yang lebih kaya memungkinkan sistem tipe untuk menangkap lebih banyak jenis kesalahan.

2. Jenis kesalahan jenis yang dapat ditangkap oleh kode yang diketik dengan kaya berdampak pada kode nyata. (Dia memberi contoh Mars Climate Orbiter, yang terkenal gagal karena kesalahan dimensi dalam konstanta penting).

3. Dalam kode nyata, unit jarang digunakan. Orang tidak menggunakannya, karena menimbulkan runtime compute atau memori overhead untuk membuat tipe kaya terlalu mahal, dan menggunakan kode unit templat C ++ yang sudah ada sebelumnya sangat jelek sehingga tidak ada yang menggunakannya. (Secara empiris, tidak ada yang menggunakannya, meskipun perpustakaan telah ada selama satu dekade).

4. Oleh karena itu, untuk membuat insinyur menggunakan unit dalam kode nyata, kami membutuhkan perangkat yang (1) tidak menimbulkan overhead runtime dan (2) tidak dapat diterima secara nasional.

Mendukung pemeriksaan dimensi waktu kompilasi adalah satu-satunya pembenaran yang diperlukan.

auto force = 2_N; 
auto dx = 2_m; 
auto energy = force * dx; 

assert(energy == 4_J); 

Lihat misalnya PhysUnits-CT-Cpp11 , perpustakaan kecil header C ++ 11, C ++ 14 saja untuk analisis dimensi waktu kompilasi dan manipulasi serta konversi unit / kuantitas. Lebih sederhana daripada Boost . Unit , tidak mendukung literal simbol satuan seperti m, g, s, awalan metrik seperti m, k, M, hanya bergantung pada pustaka C ++ standar, hanya SI, kekuatan dimensi yang tidak terpisahkan.

Hmm ... Saya belum memikirkan fitur ini. Sampel Anda dipikirkan dengan baik dan tentu saja menarik. C ++ sangat kuat seperti sekarang, tetapi sayangnya sintaks yang digunakan dalam potongan kode yang Anda baca terkadang terlalu rumit. Keterbacaan adalah, jika tidak semua, maka setidaknya banyak. Dan fitur seperti itu akan diarahkan untuk lebih mudah dibaca. Jika saya ambil contoh terakhir Anda

assert(1_kg == 2.2_lb); // give or take 0.00462262 pounds

... Saya ingin tahu bagaimana Anda mengekspresikannya hari ini. Anda akan memiliki kelas KG dan LB dan Anda akan membandingkan objek implisit:

assert(KG(1.0f) == LB(2.2f));

Dan itu akan berhasil juga. Dengan tipe yang memiliki nama atau tipe yang lebih panjang yang Anda tidak memiliki harapan memiliki konstruktor yang bagus untuk menulis adapter, mungkin ini merupakan tambahan yang bagus untuk pembuatan dan inisialisasi objek implisit on-the-fly. Di sisi lain, Anda sudah dapat membuat dan menginisialisasi objek menggunakan metode juga.

Tapi saya setuju dengan Nils tentang matematika. Fungsi trigonometri C dan C ++ misalnya membutuhkan input dalam radian. Saya pikir dalam derajat, jadi konversi implisit yang sangat singkat seperti Nils diposting sangat bagus.

Pada akhirnya, ini akan menjadi gula sintaksis, tetapi akan memiliki sedikit efek pada keterbacaan. Dan mungkin akan lebih mudah untuk menulis beberapa ekspresi juga (sin (180.0deg) lebih mudah untuk menulis daripada dosa (deg (180.0)) .Dan kemudian akan ada orang yang menyalahgunakan konsep tersebut. Tetapi kemudian, orang yang suka menggunakan bahasa harus menggunakan bahasa yang sangat restriktif daripada sesuatu yang ekspresif seperti C ++.

Ah, posting saya pada dasarnya tidak mengatakan apa-apa kecuali: itu akan baik-baik saja, dampaknya tidak akan terlalu besar. Jangan khawatir. :-)

Saya tidak pernah membutuhkan atau menginginkan fitur ini (tetapi ini bisa menjadi efek Blub ). Reaksi brengsek saya adalah lumpuh, dan cenderung menarik bagi orang yang sama yang berpikir bahwa itu keren untuk membebani operator + untuk operasi apa pun yang bisa ditafsirkan sebagai penambahan.

C ++ biasanya sangat ketat tentang sintaks yang digunakan - kecuali preprocessor tidak ada banyak yang dapat Anda gunakan untuk mendefinisikan sintaks / tata bahasa kustom. Misalnya kita dapat membebani operatos yang sudah ada, tetapi kita tidak dapat mendefinisikan yang baru - IMO ini sangat selaras dengan semangat C ++.

Saya tidak keberatan beberapa cara untuk kode sumber yang lebih khusus - tetapi titik yang dipilih tampaknya sangat terisolasi bagi saya, yang paling membingungkan saya.

Bahkan penggunaan yang dimaksudkan dapat membuat lebih sulit untuk membaca kode sumber: satu huruf mungkin memiliki efek samping luas yang sama sekali tidak dapat diidentifikasi dari konteksnya. Dengan simetri ke u, l dan f, sebagian besar pengembang akan memilih satu huruf.

Ini juga dapat mengubah pelingkupan menjadi masalah, menggunakan huruf tunggal di namespace global mungkin akan dianggap praktik yang buruk, dan alat yang seharusnya menggabungkan perpustakaan lebih mudah (ruang nama dan pengidentifikasi deskriptif) mungkin akan mengalahkan tujuannya.

Saya melihat beberapa manfaat dalam kombinasi dengan "otomatis", juga dalam kombinasi dengan perpustakaan unit seperti boost unit , tetapi tidak cukup untuk mendapatkan pujian ini.

Namun saya ingin tahu, ide pintar apa yang kita miliki.

Saya menggunakan literal pengguna untuk string biner seperti ini:

 "asd\0\0\0\1"_b

menggunakan std::string(str, n)konstruktor sehingga \0tidak akan memotong tali menjadi dua. (Proyek ini melakukan banyak pekerjaan dengan berbagai format file.)

Ini juga membantu ketika saya std::stringmenolak untuk pembungkus std::vector.

Garis kebisingan dalam hal itu sangat besar. Juga mengerikan untuk dibaca.

Biarkan saya tahu, apakah mereka beralasan bahwa penambahan sintaks baru dengan jenis contoh? Misalnya, apakah mereka memiliki beberapa program yang sudah menggunakan C ++ 0x?

Bagi saya, bagian ini:

auto val = 3.14_i

Tidak membenarkan bagian ini:

std::complex<double> operator ""_i(long double d) // cooked form
{ 
    return std::complex(0, d);
}

Bahkan jika Anda akan menggunakan sintaks-i dalam 1000 baris lain juga. Jika Anda menulis, Anda mungkin menulis 10.000 baris hal lain di sepanjang itu juga. Terutama ketika Anda mungkin masih akan menulis sebagian besar di mana-mana ini:

std::complex<double> val = 3.14i

'auto' -keyword dapat dibenarkan, hanya mungkin. Tapi mari kita ambil C ++ saja, karena ini lebih baik daripada C ++ 0x dalam aspek ini.

std::complex<double> val = std::complex(0, 3.14);

Ini seperti .. sesederhana itu. Bahkan mengira semua kurung std dan runcing hanya timpang jika Anda menggunakannya di mana-mana. Saya tidak mulai menebak apa sintaks yang ada di C ++ 0x untuk mengubah std :: complex di bawah complex.

complex = std::complex<double>;

Itu mungkin sesuatu yang langsung, tapi saya tidak percaya itu sesederhana itu di C ++ 0x.

typedef std::complex<double> complex;

complex val = std::complex(0, 3.14);

Mungkin? > :)

Pokoknya, intinya adalah: menulis 3.14i bukannya std :: complex (0, 3.14); tidak menghemat banyak waktu secara keseluruhan kecuali dalam beberapa kasus super khusus.