क्या नए मानक संस्करणों के साथ C ++ में कभी भी मौन व्यवहार में बदलाव आया है?

Question 1

(मैं बात साबित करने के लिए एक उदाहरण या दो की तलाश कर रहा हूं, सूची नहीं।)

क्या कभी ऐसा हुआ है कि C ++ मानक (जैसे 98 से 11, 11 से 14 आदि) में बदलाव ने मौजूदा, सुव्यवस्थित, परिभाषित-व्यवहार उपयोगकर्ता कोड के व्यवहार को बदल दिया - चुपचाप? नए मानक संस्करण के साथ संकलन करते समय कोई चेतावनी या त्रुटियों के साथ?

टिप्पणियाँ:

मैं मानकों-अनिवार्य व्यवहार के बारे में पूछ रहा हूं, कार्यान्वयनकर्ता / संकलक लेखक विकल्पों के बारे में नहीं।
कम ने कोड से वंचित किया, बेहतर (इस प्रश्न के उत्तर के रूप में)।
मुझे संस्करण पहचान जैसे कोड से मतलब नहीं है #if __cplusplus >= 201103L।
मेमोरी मॉडल से जुड़े उत्तर ठीक हैं।

Question 2

की वापसी प्रकार string::dataसे परिवर्तन const char*करने के लिए char*17 C ++ में यही निश्चित रूप से एक फर्क कर सकता है

void func(char* data)
{
    cout << data << " is not const\n";
}

void func(const char* data)
{
    cout << data << " is const\n";
}

int main()
{
    string s = "xyz";
    func(s.data());
}

थोड़ा संघर्ष हुआ लेकिन यह कानूनी कार्यक्रम अपने उत्पादन को C ++ 14 से C ++ 17 में बदल देगा।

Question 3

का जवाब इस सवाल से पता चलता है कि कैसे एक वेक्टर एक एकल का उपयोग कर आरंभ size_typeमूल्य सी ++ 03 और सी ++ 11 के बीच अलग व्यवहार हो सकता है।

std::vector<Something> s(10);

C ++ 03 डिफ़ॉल्ट प्रकार Something- तत्व का एक अस्थायी ऑब्जेक्ट बनाता है और उस अस्थायी से वेक्टर में प्रत्येक तत्व की प्रतिलिपि बनाता है।

C ++ 11 डिफ़ॉल्ट रूप से वेक्टर में प्रत्येक तत्व का निर्माण करता है।

कई (अधिकांश?) मामलों में ये परिणाम बराबर अंतिम स्थिति में होते हैं, लेकिन ऐसा कोई कारण नहीं होता है। यह Somethingडिफॉल्ट / कॉपी कंस्ट्रक्टर्स के कार्यान्वयन पर निर्भर करता है ।

देखिये यह विरोधाभासी उदाहरण :

class Something {
private:
    static int counter;

public:
    Something() : v(counter++) {
        std::cout << "default " << v << '\n';
    }

    Something(Something const & other) : v(counter++) {
        std::cout << "copy " << other.v << " to " << v << '\n';
    }

    ~Something() {
        std::cout << "dtor " << v << '\n';
    }

private:
    int v;
};

int Something::counter = 0;

सी ++ 03 डिफ़ॉल्ट-निर्माण होगा एक Somethingसाथ v == 0तो कॉपी-निर्माण से अधिक है कि एक दस। अंत में, वेक्टर में दस ऑब्जेक्ट होते हैं जिनके vमान 10 के माध्यम से 1 होते हैं, समावेशी।

C ++ 11 प्रत्येक तत्व को डिफ़ॉल्ट-निर्माण करेगा। कोई नकल नहीं की जाती है। अंत में, वेक्टर में दस ऑब्जेक्ट होते हैं जिनके vमान 0 से 9, समावेशी होते हैं।

Question 4

मानक में एनेक्स सी [भिन्न] में परिवर्तन को तोड़ने की एक सूची है । इन परिवर्तनों में से कई मौन व्यवहार परिवर्तन को जन्म दे सकते हैं।

एक उदाहरण:

int f(const char*); // #1
int f(bool);        // #2

int x = f(u8"foo"); // until C++20: calls #1; since C++20: calls #2

Question 5

हर बार वे मानक पुस्तकालय में नए तरीके (और अक्सर फ़ंक्शन) जोड़ते हैं जो ऐसा होता है।

मान लीजिए कि आपके पास एक मानक पुस्तकालय प्रकार है:

struct example {
  void do_stuff() const;
};

बहुत साधारण। कुछ मानक संशोधन में, एक नई विधि या ओवरलोड या किसी भी चीज के आगे जोड़ा जाता है:

struct example {
  void do_stuff() const;
  void method(); // a new method
};

यह मौजूदा C ++ कार्यक्रमों के व्यवहार को चुपचाप बदल सकता है।

ऐसा इसलिए है क्योंकि इस तरह की विधि मौजूद होने पर C ++ के सीमित प्रतिबिंबन क्षमता का पता लगाने के लिए पर्याप्त है, और इसके आधार पर अलग-अलग कोड चलाते हैं।

template<class T, class=void>
struct detect_new_method : std::false_type {};

template<class T>
struct detect_new_method< T, std::void_t< decltype( &T::method ) > > : std::true_type {};

यह नए का पता लगाने के लिए सिर्फ एक अपेक्षाकृत सरल तरीका है method, तरीकों के असंख्य हैं।

void task( std::false_type ) {
  std::cout << "old code";
};
void task( std::true_type ) {
  std::cout << "new code";
};

int main() {
  task( detect_new_method<example>{} );
}

जब आप कक्षाओं से तरीकों को हटाते हैं तो ऐसा ही हो सकता है।

जबकि यह उदाहरण सीधे तौर पर एक पद्धति के अस्तित्व का पता लगाता है, परोक्ष रूप से होने वाली इस तरह की बात कम ही हो सकती है। एक ठोस उदाहरण के रूप में, आपके पास एक सीरियलाइज़ेशन इंजन हो सकता है जो यह तय करता है कि अगर किसी चीज को कंटेनर के रूप में क्रमबद्ध किया जा सकता है यदि वह चलने योग्य है, या यदि उसके पास डेटा-टू-रॉ-बाइट्स और एक आकार के सदस्य हैं, तो एक पसंद किया जाता है। अन्य।

मानक जाता है और .data()एक कंटेनर में एक विधि जोड़ता है , और अचानक प्रकार बदलता है जो इसे क्रमांकन के लिए उपयोग करता है।

सभी सी ++ मानक कर सकते हैं, अगर यह फ्रीज नहीं करना चाहता है, तो इस तरह का कोड बनाना है जो चुपचाप टूट जाता है दुर्लभ या किसी भी तरह अनुचित है।

Question 6

ओह लड़के ... लिंक cpplearner प्रदान की है डरावना ।

अन्य लोगों में, C ++ 20 ने C ++ स्ट्रक्चर्स की C- शैली संरचना की घोषणा को अस्वीकार कर दिया।

typedef struct
{
  void member_foo(); // Ill-formed since C++20
} m_struct;

यदि आपको उस तरह की संरचना लिखना सिखाया गया था (और "सी के साथ सी" सिखाने वाले लोग बिल्कुल सिखाते हैं) तो आप खराब हैं ।

Question 7

यहाँ एक उदाहरण है कि C ++ 03 में 3 प्रिंट करता है लेकिन C ++ 11 में 0 है:

template<int I> struct X   { static int const c = 2; };
template<> struct X<0>     { typedef int c; };
template<class T> struct Y { static int const c = 3; };
static int const c = 4;
int main() { std::cout << (Y<X< 1>>::c >::c>::c) << '\n'; }

व्यवहार में यह परिवर्तन विशेष हैंडलिंग के कारण हुआ था >>। C ++ 11 से पहले, >>हमेशा सही शिफ्ट ऑपरेटर था। C ++ 11 के साथ, >>एक टेम्पलेट घोषणा का भी हिस्सा हो सकता है।

Question 8

ट्रिग्राफ गिरा दिया

स्रोत फ़ाइलों को एक भौतिक वर्ण सेट में एन्कोड किया गया है जिसे कार्यान्वयन-परिभाषित तरीके से स्रोत वर्ण सेट में मैप किया गया है , जो मानक में परिभाषित है। मूल चरित्र सेट द्वारा आवश्यक मूल रूप से विराम चिह्न के सभी भौतिक वर्ण सेटों से मैपिंग को समायोजित करने के लिए, भाषा ने ट्रिग्राफ परिभाषित किया- तीन सामान्य वर्णों के अनुक्रम जिन्हें एक कम सामान्य विराम चिह्न वर्ण के स्थान पर उपयोग किया जा सकता है। इन्हें संभालने के लिए प्रीप्रोसेसर और कंपाइलर की आवश्यकता थी।

सी ++ 17 में, ट्रिग्राफ हटा दिए गए थे। इसलिए कुछ स्रोत फ़ाइलों को नए संकलक द्वारा स्वीकार नहीं किया जाएगा, जब तक कि उन्हें पहली बार किसी अन्य भौतिक चरित्र सेट से भौतिक चरित्र सेट से अनुवादित नहीं किया जाता है, जो कि एक-से-एक स्रोत स्रोत सेट पर मैप करता है। (व्यवहार में, अधिकांश कंपाइलरों ने केवल ट्रिग्राफ की व्याख्या को वैकल्पिक बना दिया है।) यह एक सूक्ष्म व्यवहार परिवर्तन नहीं है, लेकिन एक ब्रेकिंग परिवर्तन पूर्व-स्वीकार्य स्रोत फ़ाइलों को बाहरी अनुवाद प्रक्रिया के बिना संकलित होने से रोकता है।

पर और अधिक अड़चनें `char`

मानक निष्पादन चरित्र सेट को भी संदर्भित करता है , जिसे कार्यान्वयन परिभाषित किया गया है, लेकिन इसमें कम से कम संपूर्ण स्रोत वर्ण सेट और कम संख्या में नियंत्रण कोड होने चाहिए।

C ++ मानक charको संभवतः-अहस्ताक्षरित अभिन्न प्रकार के रूप में परिभाषित किया गया है जो निष्पादन वर्ण सेट में प्रत्येक मान को कुशलता से दर्शा सकता है। भाषा के वकील से प्रतिनिधित्व के साथ, आप तर्क दे सकते हैं कि charकम से कम 8 बिट होना चाहिए।

यदि आपका कार्यान्वयन इसके लिए एक अहस्ताक्षरित मान का उपयोग करता है char, तो आप जानते हैं कि यह 0 से 255 तक हो सकता है, और इस प्रकार हर संभव मूल्य के भंडारण के लिए उपयुक्त है।

लेकिन अगर आपका कार्यान्वयन एक हस्ताक्षरित मूल्य का उपयोग करता है, तो इसके पास विकल्प हैं।

ज्यादातर दो-पूरक का उपयोग करेगा, charन्यूनतम -128 की सीमा 127 को देगा। यह 256 अद्वितीय मूल्य है।

लेकिन एक अन्य विकल्प था साइन + परिमाण, जहां एक बिट यह बताने के लिए आरक्षित है कि संख्या नकारात्मक है और अन्य सात बिट्स परिमाण को दर्शाते हैं। यह char-127 से 127 तक की सीमा देगा , जो केवल 255 अद्वितीय मान है। (क्योंकि आप -0 का प्रतिनिधित्व करने के लिए एक उपयोगी बिट संयोजन खो देते हैं।)

मुझे यकीन नहीं है कि समिति ने स्पष्ट रूप से इसे एक दोष के रूप में निर्दिष्ट किया है, लेकिन यह इसलिए था क्योंकि आप मानक से एक गोल-यात्रा की गारंटी देने के लिए मानक पर भरोसा नहीं कर सकते unsigned charथे charऔर वापस मूल मूल्य को संरक्षित करेंगे। (व्यवहार में, सभी कार्यान्वयनों ने किया क्योंकि वे सभी हस्ताक्षरित अभिन्न प्रकारों के लिए दो के पूरक का उपयोग करते थे।)

केवल हाल ही में (C ++ 17?) राउंड-ट्रिपिंग सुनिश्चित करने के लिए निश्चित किया गया शब्द था। यह ठीक है, अन्य सभी आवश्यकताओं के साथ char, प्रभावी रूप से charबिना स्पष्ट रूप से हस्ताक्षर किए दो के पूरक को अनिवार्य रूप से बताता है (भले ही मानक अन्य हस्ताक्षरित अभिन्न प्रकारों के लिए संकेत + परिमाण प्रतिनिधित्व की अनुमति देता है)। सभी हस्ताक्षरित अभिन्न प्रकारों के लिए दो के पूरक का उपयोग करने की आवश्यकता के लिए एक प्रस्ताव है, लेकिन मुझे यह याद नहीं है कि क्या इसे सी ++ 20 में बनाया गया था।

तो यह जो आप देख रहे हैं उसके विपरीत की तरह है क्योंकि यह पहले से ~~गलत रूप से~~ अनुमानित कोड को पूर्वव्यापी तय करता है।

Question 9

मुझे यकीन नहीं है कि आप इसे कोड को सही करने के लिए एक परिवर्तन को मानेंगे, लेकिन ...

C ++ 11 से पहले, कंपाइलरों को अनुमति दी गई थी, लेकिन आवश्यक नहीं है, कुछ परिस्थितियों में प्रतियों को कॉपी करने के लिए, तब भी जब कॉपी कंस्ट्रक्टर के पास अवलोकन दुष्प्रभाव होते हैं। अब हमने कॉपी इलीगेशन की गारंटी दी है। व्यवहार अनिवार्य रूप से कार्यान्वयन से परिभाषित आवश्यक हो गया।

इसका मतलब है कि आपके कॉपी कंस्ट्रक्टर साइड इफेक्ट पुराने संस्करणों के साथ हो सकते हैं, लेकिन नए के साथ कभी नहीं होंगे । आप तर्क दे सकते हैं कि सही कोड कार्यान्वयन-परिभाषित परिणामों पर निर्भर नहीं होना चाहिए, लेकिन मुझे नहीं लगता कि ऐसा कहना बिलकुल गलत है।

Question 10

स्ट्रीम से डेटा (संख्यात्मक) पढ़ने और विफल होने पर व्यवहार, c ++ 11 के बाद से बदल दिया गया था।

उदाहरण के लिए, किसी स्ट्रीम से पूर्णांक पढ़ना, जबकि इसमें पूर्णांक शामिल नहीं है:

#include <iostream>
#include <sstream>

int main(int, char **) 
{
    int a = 12345;
    std::string s = "abcd";         // not an integer, so will fail
    std::stringstream ss(s);
    ss >> a;
    std::cout << "fail = " << ss.fail() << " a = " << a << std::endl;        // since c++11: a == 0, before a still 12345 
}

चूँकि c ++ 11 पढ़े गए पूर्णांक को 0 पर सेट करेगा जब यह विफल हुआ; c ++ <11 पर पूर्णांक नहीं बदला गया था। कहा कि, gcc, यहां तक कि जब मानक वापस c ++ 98 (-std = c ++ 98) के लिए हमेशा मजबूर किया जाता है, तो संस्करण 4.4.7 के बाद से कम से कम नया व्यवहार दिखाता है।

(Imho पुराने व्यवहार वास्तव में बेहतर था: मान को 0 में क्यों बदला जाए, जो स्वयं मान्य है, जब कुछ भी नहीं पढ़ा जा सकता है?)

संदर्भ: https://en.cppreference.com/w/cpp/locale/num_get/get देखें

क्या नए मानक संस्करणों के साथ C ++ में कभी भी मौन व्यवहार में बदलाव आया है?

ट्रिग्राफ गिरा दिया

पर और अधिक अड़चनें char

पर और अधिक अड़चनें `char`