"# আমাকে সংজ্ঞা দিন (* এটি)" কি ভাল ধারণা?

19

এই ম্যাক্রোটি কয়েকটি গ্লোবাল শিরোনামে বা আরও ভাল সংকলক কমান্ড লাইন প্যারামিটার হিসাবে সংজ্ঞায়িত করা যেতে পারে:

#define me (*this)

এবং কিছু ব্যবহারের উদাহরণ:

some_header.h:

inline void Update()
{
    /* ... */
}

main.cpp:

#include "some_header.h"

class A {
public:
    void SetX(int x)
    {
        me.x = x;   
        me.Update(); 
    }

    void SomeOtherFunction()
    {
        ::Update();
    }

    /*
        100 or more lines
        ... 
    */

    void Update()
    {
        // ... 
    }

    int x;  
};

সুতরাং কোনও শ্রেণি পদ্ধতিতে যখন আমি কোনও শ্রেণীর সদস্য অ্যাক্সেস করি তখন আমি সর্বদা ব্যবহার করি meএবং কোনও বিশ্বব্যাপী শনাক্তকারী অ্যাক্সেস করার সময় আমি সর্বদা ব্যবহার করি ::। এটি এমন পাঠককে দেয় যা কোডের সাথে পরিচিত নয় (সম্ভবত কয়েক মাস পরে আমি নিজেই) অন্য কোথাও দেখার প্রয়োজন ছাড়াই কী অ্যাক্সেস করা হয় তার স্থানীয়করণ তথ্য। আমি সংজ্ঞা দিতে চাই meকারণ আমি this->কোথাও খুব শব্দ এবং কুরুচিপূর্ণ ব্যবহার করতে পাই । তবে #define me (*this)একটি ভাল সি ++ অনুশীলন হিসাবে বিবেচনা করা যেতে পারে? meম্যাক্রোর সাথে কিছু ব্যবহারিক সমস্যাযুক্ত পয়েন্ট রয়েছে ? এবং আপনি যদি সি ++ প্রোগ্রামার হিসাবে meম্যাক্রো ব্যবহার করে কিছু কোডের পাঠক হয়ে থাকেন তবে আপনি এটি পছন্দ করবেন কি না?

সম্পাদনা করুন: কারণ অনেকে বিতর্ক যুক্তি ব্যবহার করে সুনির্দিষ্টভাবে বিতর্ক করে না me, তবে জেনারালি কনট্রাস্ট এটিকে স্পষ্ট করে দেয়। আমি মনে করি এটি "স্পষ্টতই এটিকে সর্বত্র স্পষ্ট" করার সুবিধা কী তা পরিষ্কার নয়।

"এটিকে সর্বত্র স্পষ্ট করে" এর সুবিধা কী?

কোডটির পাঠক হিসাবে আপনার কাছে যা অ্যাক্সেস করা হয়েছে তা নিশ্চিত এবং আপনি যাচাই করার চেয়ে বিভিন্ন বিষয়গুলিতে মনোনিবেশ করতে পারেন - কিছু দূরবর্তী কোডে - এটি যা অ্যাক্সেস করে বলে মনে হয় তা সত্যিই অ্যাক্সেস করা যায়।
আপনি সুনির্দিষ্টভাবে অনুসন্ধানের ফাংশনটি ব্যবহার করতে পারেন। অনুসন্ধান " this->x" আপনাকে কেবল অনুসন্ধান " x" এর চেয়ে বেশি ফলাফল দিতে পারে
আপনি যখন কোনও সদস্যকে মুছতে বা পুনরায় নামকরণ করছেন, সংকলক নির্ভরযোগ্যতার সাথে আপনাকে এই স্থানে কোথায় ব্যবহার করা হবে তা অবহিত করে। (কিছু বিশ্বব্যাপী ফাংশনটির একই নাম থাকতে পারে এবং আপনি যদি এটিকে স্পষ্টভাবে ব্যবহার না করেন তবে ত্রুটি পরিচয় করিয়ে দেওয়ার সুযোগ উপস্থিত থাকতে পারে)।
আপনি যখন কোডটি রিফ্যাক্ট করছেন এবং সদস্য থেকে অ-সদস্য ফাংশনটি তৈরি করেন (আরও ভাল এনক্যাপসুলেশন করতে পারেন) এটি আপনাকে প্রদর্শিত হবে যা আপনাকে সম্পাদন করতে হবে এবং অ-সদস্য ফাংশন প্যারামিটার হিসাবে দেওয়া ক্লাসের উদাহরণ হিসাবে আপনি সহজেই এটিকে প্রতিস্থাপন করতে পারেন When
সাধারণত আপনি যখন কোড পরিবর্তন করছেন তখন আপনি এটিকে স্পষ্টভাবে ব্যবহার না করার চেয়ে ত্রুটিগুলির আরও বেশি সম্ভাবনা রয়েছে যখন আপনি সর্বত্র এটি পরিষ্কার ব্যবহার করছেন।
স্পষ্টত এটি পরিষ্কার "এম_" এর চেয়ে কম গোলমাল যখন আপনি বাইরে থেকে সদস্যকে পৌঁছে দিচ্ছেন ( object.memberবনাম object.m_member) (এই কাজটি দেখার জন্য @ কাজিকে ধন্যবাদ)
সুস্পষ্টভাবে এটি সমস্ত সদস্যের জন্য সর্বজনীন সমস্যার সমাধান করে - গুণাবলী এবং পদ্ধতিগুলি, যখন "m_" বা অন্যান্য উপসর্গ কেবলমাত্র বৈশিষ্ট্যের জন্য ব্যবহারযোগ্য able

আমি এই তালিকাটি পোলিশ করতে এবং প্রসারিত করতে চাই, যদি আপনি অন্যান্য সুবিধাগুলি সম্পর্কে জানেন এবং আমাকে যেকোন জায়গায় স্পষ্ট করার জন্য ক্ষেত্রে ব্যবহার করতে চান ।

c++

— user3123061
সূত্র

3

আপনার একই নামের সাথে ফাংশন আর্গুমেন্ট এবং সদস্য থাকা এবং সেই সাথে স্পষ্ট "এটি" এড়ানো উচিত।

— pjc50

4

আমার বসের ভিবি কোডটি মনে করিয়ে দেয়। মি মি মি সব জায়গায়। স্বার্থপর মনে হচ্ছে। : p যাইহোক, এখনও পর্যন্ত উত্তরগুলি সব বলে।

— মেটালমাইকস্টার

19

এটি একটি দুর্দান্ত ধারণা! এবং যারা পাইথন পটভূমি থেকে আসে তাদের জন্য কেন #define self (*this)? এমনকি আপনি উভয় ম্যাক্রো মিশ্রিত করতে পারেন এবং ভিবি এবং অন্য পাইথনের অনুকরণকারী কিছু ফাইল রাখতে পারেন। :)

— লক করুন

11

কেন শুধু শুধু সব আউট যান এবং একটি করুন: #include "vb.h", #Include pascal.h, অথবা #include FOTRAN.hএবং আপনার কোডে এটি জমা স্পর্শ পাশে ব্যক্তি আছে TDWTF ।

— ড্যান নীলি

4

ওহ প্লিজ, ঠিক না কেবলমাত্র বৈশিষ্ট্যগুলি ঘোষণা করে আপনি নিজেকে কিছুটা সমস্যা বাঁচাতে পারেন me_x।

— রোবটটি

90

না এটা না.

আপনি যে সবুজ রঙের চারণভূমি ছেড়ে চলে গেছেন এবং আপনি যে ভাষা ব্যবহার করেন সেগুলির প্রচলিত কনভেনশনগুলি অনুসরণ করে প্রোগ্রামারকে মনে রাখুন যিনি এখন থেকে বেশ কয়েক বছর পরে আপনার কোড বজায় রাখবেন। সি ++ এ আপনাকে প্রায় লিখতে হবে না this, কারণ শ্রেণিটি প্রতীক রেজোলিউশন ক্রমে অন্তর্ভুক্ত থাকে এবং যখন একটি চিহ্নটি শ্রেণির স্কোপে পাওয়া যায়, this->তা অন্তর্ভুক্ত থাকে। সবাই যেমন করে ঠিক তেমন লিখবেন না।

যদি আপনি প্রায়শই বিভ্রান্ত হন যা কোন চিহ্নগুলি শ্রেণির ক্ষেত্র থেকে আসে তবে সাধারণ পদ্ধতির সদস্যদের জন্য সাধারণ নামকরণের পদ্ধতি ব্যবহার করা হয় (ক্ষেত্র এবং কখনও কখনও ব্যক্তিগত পদ্ধতি; আমি এটি সর্বজনীন পদ্ধতির জন্য ব্যবহার করি নি)। প্রচলিত বেশী সঙ্গে suffixing অন্তর্ভুক্ত _বা prefixing m_বা m।

— জান হুডেক
সূত্র

12

"সি ++ এ, আপনাকে প্রায়শই এটি লিখতে হবে না" এটি প্রশ্নের সম্পূর্ণরূপে সম্পর্কিত নয় convention কিছু লোক (আমার মতো) thisস্পষ্টভাবে এটি স্পষ্ট করে লিখতে লিখতে পছন্দ করেন যে পদ্ধতিটি ভেরিয়েবল স্থানীয় নয়। এখানে প্রশ্নটি ম্যাক্রোর meঅস্তিত্ব থাকা উচিত কিনা তা নয়, thisএমন কিছু যা ব্যবহার করা উচিত।

— মেহরদাদ

8

@ মেহরদাদ: কারণ ওপি স্পষ্টতই বলেছে যে তিনি এর me.পরিবর্তে ব্যবহার করছেন this->। যেহেতু কোনও প্রয়োজন this->নেই me.এবং সুতরাং ম্যাক্রোর কোনও প্রয়োজন নেই।

— মার্টিন ইয়র্ক

11

@ লোকিআস্তারি: প্রশ্নটির কিছুই কিছুই অপরিবর্তিতভাবে ওপিকে ইঙ্গিত দিচ্ছে যে this->"প্রয়োজনীয়" কিনা তা ভেবে । আসলে, ওপি বলছে this->যে এটি প্রয়োজনীয় নয় সত্ত্বেও তিনি ব্যবহার করছেন। প্রশ্নটি পরিবর্তেme. ব্যবহার করা উচিত কিনা সে সম্পর্কে this->, যা এই উত্তরটি আসলে উত্তর দেয় না।

— মেহরদাদ

4

@ মেহরদাদ: তবে কেবল হ্যাঁ বা না দেওয়া খুব বিরক্তিকর উত্তর দেয়। সুতরাং ব্যাখ্যাগুলি সাধারণত কীভাবে উত্তরটি পৌঁছায় তা ব্যাখ্যা করার ক্ষেত্রে বেশ কার্যকর হয় ( কীভাবে উত্তর দেওয়া যায় তা দিয়ে ঘেরাও করা হয় )। উপসংহারটি ব্যবহার করা নয় কারণ ওপির ব্যবহার সম্পর্কে শুরু করার জন্য ভুল দৃষ্টিভঙ্গি রয়েছে thisএবং এইভাবে একটি সম্পূর্ণ সুষম উপসংহার অর্জনের জন্য সেই বিষয়টিতে একটি আলোচনার প্রয়োজন।

— মার্টিন ইয়র্ক 1

1

কেবল "না, এটি একটি খারাপ অভ্যাস" বলার পরিবর্তে কেন ব্যাখ্যা করার জন্য +1।

— ব্যবহারকারী 253751

42

সুতরাং, আপনি একটি নতুন ভাষা তৈরি করতে চান। তারপরে এটি করুন, এবং সি ++ পঙ্গু করবেন না।

এটি না করার বিভিন্ন কারণ রয়েছে:

প্রতিটি সাধারণ কোডিং স্ট্যান্ডার্ড ম্যাক্রোগগুলি এড়াতে পরামর্শ দেবে ( এই কারণেই )
এই জাতীয় ম্যাক্রোগুলির সাথে কোড বজায় রাখা আরও কঠিন। সি ++ এ প্রোগ্রামিং করা প্রত্যেকেই কী thisতা জানে এবং এই জাতীয় ম্যাক্রো যুক্ত করে আপনি আসলে একটি নতুন কীওয়ার্ড যুক্ত করছেন। সবাই যদি তাদের পছন্দসই কিছু পরিচয় করিয়ে দেয়? কোড দেখতে কেমন হবে?
কিছু বিশেষ ক্ষেত্রে বাদে আপনার ব্যবহার করা (*this).বা একেবারেই ব্যবহার করা উচিত নয় this->( এই উত্তরটি দেখুন এবং "এটি>>" অনুসন্ধান করুন)

আপনার কোডটি ভিন্ন নয় #define R return, যা আমি প্রকৃত কোডে দেখেছি। কারণ? কম টাইপিং!

সামান্য বিষয় বন্ধ যাওয়া, কিন্তু এখানে আমি বিন্দু 3 (ব্যবহার করবেন না প্রসারিত করতে যাচ্ছি (*this).বা this->কোন ক্লাসে)।

সবার আগে, (*this).বা this->অবজেক্টটির সদস্য ভেরিয়েবল বা ফাংশন অ্যাক্সেস করতে ব্যবহৃত হয়। এটি ব্যবহার করা অর্থহীন এবং এর অর্থ আরও বেশি টাইপ করা। এছাড়াও, এই জাতীয় কোড পড়া আরও কঠিন, কারণ এখানে আরও পাঠ্য রয়েছে। এর অর্থ আরও কঠোর রক্ষণাবেক্ষণ।

সুতরাং, আপনি ব্যবহার করতে হবে যেখানে ক্ষেত্রে কি this->?

(ক) যুক্তির নামটি দুর্ভাগ্যজনকভাবে বেছে নিন।

এই উদাহরণে, this->প্রয়োজনীয়, যেহেতু যুক্তিটির সদস্য ভেরিয়েবলের একই নাম রয়েছে:

struct A {
  int v;
  void foo( int v ) {
    this->v =v;
  }
};

(খ) কখন টেমপ্লেট এবং উত্তরাধিকার সাথে ডিল (দেখুন এই )

এই উদাহরণটি সংকলন করতে ব্যর্থ হবে, কারণ সংকলকটি কোন ভেরিয়েবলের vঅ্যাক্সেসের নাম হিসাবে জানে না ।

template< typename T >
struct A {
  A(const T& vValue):v(vValue){}

  T v;
};

template< typename T >
struct B : A<T>
{
    B(const T& vValue):A<T>(vValue){}

    void foo( const T & newV ) {
      v = newV;
    }
};

— BЈовић
সূত্র

1

"সুতরাং, আপনি একটি নতুন ভাষা তৈরি করতে চান so তবে এটি করুন, এবং সি ++ পঙ্গু করবেন না।" - আমি একমত নই সি এবং সি ++ এর একটি প্রধান শক্তি হ'ল তাদের নমনীয়তা। ওপিকে সি ++ পঙ্গু করছে না, কেবল তার নমনীয়তা সহজ করার জন্য একটি নির্দিষ্ট উপায়ে তার নমনীয়তাটি ব্যবহার করে।

— ব্যবহারকারী 253751

2

ঠিক আছে তাঁর পক্ষে যা সহজ, তা সবার জন্যই শক্ত। আপনি যখন একটি দলে কাজ করেন, কোডে এই জাতীয় বাজে কথাগুলি রাখলে আপনি খুব অনুকূল হন না।

— BЈовић

2

আপনার উত্তর "সংজ্ঞায়িত করা খারাপ" থেকে আলাদা নয়।

— মিস্টার লিস্টার

7

@ মিঃলিস্টার আমার উত্তর হ'ল "বোকা সংজ্ঞাগুলি খারাপ"। প্রশ্নের ম্যাক্রোটি ব্যবহার করার জন্য মূup় এবং আমি যেমন দেখিয়েছি, একেবারেই প্রয়োজন নেই। কোড ভালো এবং আরও ভাল ছাড়া হয় *this.এবংthis->

— BЈовић

1

@ মেহার্ডাদ কি এখনও সদস্য ভেরিয়েবলগুলিতে উপসর্গ এবং প্রত্যয় যুক্ত করা হচ্ছে? আমি ভেবেছিলাম যে ক্লিন কোডের মতো বইগুলি "স্থির" ছিল । প্রাক-সি ++ 11 এর this->মতোই কার্যকর auto। অন্য কথায়, এটি কেবল কোড শোনায়।

— BЈовић

26

আমি এটি না করার পরামর্শ দিই। এটি এমন পাঠককে দেয় যা আপনার ম্যাক্রোর সাথে পরিচিত না যখনই তিনি এটি দেখেন একটি বড় " ডাব্লুটিএফ "। কোনও বাস্তব প্রয়োজন ছাড়াই সাধারণভাবে গ্রহণযোগ্যদের উপর "নতুন সম্মেলনগুলি" আবিষ্কার করার সময় কোডটি আরও পাঠযোগ্য হয় না।

এটি-> সর্বত্র ব্যবহার করা খুব শোরগোল এবং কুরুচিপূর্ণ

আপনার কাছে এটি সম্ভবত মনে হতে পারে, কারণ আপনি কীওয়ার্ডটি ব্যবহার করে ভাষাগুলিতে প্রচুর প্রোগ্রামিং করেছেন me(ভিজ্যুয়াল বেসিক, আমার ধারণা?)। তবে বাস্তবে এটি কেবল অভ্যস্ত হয়ে উঠার বিষয় - this->এটি খুব ছোট, এবং আমি মনে করি অভিজ্ঞ অভিজ্ঞ সি ++ প্রোগ্রামাররা আপনার মতামতের সাথে একমত নন। এবং উপরের ক্ষেত্রে, উভয়ই ব্যবহার this->বা ব্যবহার meযথাযথ নয় - সদস্য ফাংশনের অভ্যন্তরে ডেটা সদস্যদের অ্যাক্সেস করার সময় আপনি এই কীওয়ার্ডগুলি ফেলে রেখে অল্প পরিমাণে বিশৃঙ্খলা পান।

আপনি যদি চান যে আপনার ব্যক্তিগত সদস্যের ভেরিয়েবলগুলি স্থানীয় লোকদের থেকে আলাদা করা যায় তবে তাদের m_সাথে একটি উপসর্গ হিসাবে কিছু লিঙ্ক যুক্ত করুন বা প্রত্যয় হিসাবে একটি আন্ডারস্কোর যুক্ত করুন (তবে আপনি এখানে দেখতে পাচ্ছেন , এমনকি এই সম্মেলনটি অনেক লোকের জন্য "খুব গোলমাল")।

— ডক ব্রাউন
সূত্র

12

_প্রত্যয় করা উচিত ; উপসর্গ হিসাবে এটি স্ট্যান্ডার্ড লাইব্রেরি এবং বিক্রেতা এক্সটেনশনের অভ্যন্তরীণ প্রতীকগুলির জন্য সংরক্ষিত।

— জানু হুডেক

4

@ জানহুদেক কেবল তখনই এটি শুরু হয় __(দুটি আন্ডারস্কোর) বা আন্ডারস্কোরের পরে একটি মূলধনী অক্ষর। লোয়ার কেস লেটারের পরে একটি একক আন্ডারস্কোর ঠিক আছে, যতক্ষণ না এটি বিশ্বব্যাপী নেমস্পেসে না থাকে।

— এরিক ফিন

1

@ এরিকফিন: আমি দুটি নিয়ম এক সাথে মিশিয়েছি। দুটি আন্ডারস্কোর বা আন্ডারস্কোরের পরে মূলধন বর্ণটি অভ্যন্তরীণ প্রতীকগুলির জন্য এবং একক আন্ডারস্কোরের পরে নিম্ন-অক্ষরের অক্ষর হয় সিস্টেম-নির্দিষ্ট এক্সটেনশনের জন্য। অ্যাপ্লিকেশনগুলির ব্যবহারও করা উচিত নয়।

— জান হুডেক

@ জানহুদেক সিস্টেম-নির্দিষ্ট এক্সটেনশনের নিয়ম সম্পর্কে অবগত ছিলেন না। যদিও আপনার মন্তব্যের জন্য কিছু প্রসঙ্গ সরবরাহ করার জন্য আমি আমার পূর্ববর্তী মন্তব্যটি ছেড়ে দেব।

— এরিক ফিন

2

@ জানহুদেক: লোয়ারकेস সিস্টেম-নির্দিষ্ট এক্সটেনশনের জন্য? আপনি কি সি ++ স্ট্যান্ডার্ডের অংশটি একটি রেফারেন্স পোস্ট করতে পারেন যা এটি নির্দেশ করে?

— মেহেরদাবাদ

18

দয়া করে এটি করবেন না! আমি একটি বৃহত কোড বেসটি মোকাবিলার চেষ্টা করছি যেখানে টাইপিং সংরক্ষণের জন্য ম্যাক্রোগুলি পুরো জায়গা জুড়ে রয়েছে। আমার কাছে এটি পুনরায় সংজ্ঞায়িত করার জন্য খারাপ জিনিসটি হ'ল প্রিপ্রসেসর এটিকে যেখানেই এটি প্রতিস্থাপন করবে যেখানে এটি সুযোগে নেই / প্রয়োগ হয় না, উদাহরণস্বরূপ একটি স্বতন্ত্র ফাংশন, আপনার সহকর্মী কোয়েলেজে স্থানীয় কোথাও আমাকে অন্য কোথাও বলা যেতে পারে .. । (গুলি) সে ডিবাগিং খুশি হবে না ... আপনার ম্যাক্রোগুলি শেষ হবে যা আপনি সমস্ত স্কোপে ব্যবহার করতে পারবেন না।

— truschival
সূত্র

6

না!

কেউ যদি সেই শিরোনাম # অন্তর্ভুক্ত করে, আপনার কৌশলটি জানে না এবং অন্য কোথাও তাদের ফাইলটিতে তাদের "ভিজ্যুয়াল" নামে একটি পরিবর্তনশীল বা ফাংশন থাকে তবে যে বিভ্রান্তি ঘটবে তা কল্পনা করুন। যেগুলি অনির্বচনীয় ত্রুটি বার্তা মুদ্রিত হবে তা দ্বারা তারা ভয়াবহভাবে বিভ্রান্ত হবে।

— ল্যারি গ্রিটজ
সূত্র

অনুশীলনে, তারা সম্ভবত তাদের আইডিই দিয়ে "আমাকে" বাড়াতে এবং সংজ্ঞাটি দেখতে পাবে।

— ব্যবহারকারী 253751

2

@ এমমিবিস: বাস্তবে, তারা সম্ভবত "এই ছদ্মবেশটি কে লিখেছিল?" এর মতো কিছু বলার সম্ভাবনা রয়েছে। : পি

— সিএইচও

@ এমমিবিস: আমি যে শীর্ষস্থানীয় কোডারগুলির সাথে কাজ করি তাদের বেশিরভাগ মাউস ব্যবহার করে না - এটি খুব ধীর।

— জেবিআরউইলকিনসন

প্রকৃতপক্ষে: এটি একটি শিরোনামে কাঁপানো আসল সমস্যা। আপনি যদি এটি আপনার সিপিপি ফাইলে ব্যবহার করেন তবে আমি কোনও সমস্যা দেখছি না। যদি মান হিসাবে প্রাগমা ধাক্কা থাকত তবে আমি কীভাবে এটি শিরোনামে করব তা পরামর্শ দিচ্ছি, তবে আমরা তা করি না। আমি বলার পরে বলুন. # নির্ধারণগুলি বিশ্বব্যাপী।

— জোশুয়া