কেন একজনকে সংকলক সতর্কতাগুলি অক্ষম করতে চান?

Question

এই উত্তর এবং এতে যুক্ত মন্তব্যগুলি #pragmaনির্দেশাবলী ব্যবহার করে বেশ কয়েকটি সংকলক সতর্কতা অক্ষম করার একটি উপায় দেখায় ।

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

Comments

কেউ কেন এটি নিকটস্থ হিসাবে চিহ্নিত করেছে তা নিশ্চিত নয়। আমার কাছে একটি বিশিষ্ট যুক্তিসঙ্গত প্রশ্নের মতো মনে হচ্ছে। +1

@ অ্যালাস্টার পিটস: আমি প্রোগ্রামারগুলিতে মাইগ্রেশনের প্রস্তাব দিয়েছিলাম। আমি আমার ভুল পরে বুঝতে পেরেছি।

— তুগরুল আতেস

হ্যাঁ, সতর্কতা বার্তাগুলি একটি কারণে রয়েছে, তবে এটির ত্রুটি বার্তা না হওয়ার কারণও রয়েছে ।

— সলোমন স্লো

@ জেমস্লারেজ আপনার মন্তব্যে পরিস্থিতি সুন্দরভাবে ফুটে উঠেছে। একটি সতর্কতা হ'ল সংকলকটি আপনাকে বলছে যে কোনও পরিস্থিতি যথাযথভাবে ভুল , যা সম্ভবত সঠিকভাবে বোঝায় । যদি এটি অবশ্যই ভুল ছিল তবে এটি ত্রুটি হবে। যেহেতু কিছু সতর্কতাগুলি মিথ্যা ইতিবাচক হতে পারে, তাই সর্বদা কোড লেখার একটি উপায় থাকা উচিত যা এটি সতর্কতাটিকে সরিয়ে দেয়। দুর্ভাগ্যক্রমে, কখনও কখনও এটি করার জন্য সবচেয়ে ব্যবহারিক উপায় হ'ল একটি প্রাগমা মাধ্যমে; অত: পর নামটা.

— এরিক লিপার্ট

এটি অক্ষম করছে না, লুকিয়ে রয়েছে। আপনার সমস্যাটি এখনও সেখানে থাকবে যে আপনি এটি দেখতে পাবেন না

— সিসির

Answer 1

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

আমি এপিআইয়ের সমস্ত ব্যবহারকারীদের বলার সেরা উপায়টি খুঁজে পেতে পারি যে তারা এই পদ্ধতিটি কল না করা এটিকে অপ্রচলিত হিসাবে চিহ্নিত করা ছিল। তবে, এর অর্থ হ'ল একটি বৈধ ব্যবহারের কেসটি একটি সংকলন সতর্কতা হিসাবে চিহ্নিত করা হয়েছিল।

এরিক লিপার্ট সতর্কতা সম্পর্কে কয়েকটি পোস্ট লিখেছেন যেখানে আপনি সংকলক দল সতর্কতা সম্পর্কে কীভাবে চিন্তা করে সে সম্পর্কে তথ্য পাবেন।

অভ্যন্তরীণ ধরণের অভ্যন্তরীণ ক্ষেত্র

নির্দেশাবলীর সাহায্যে অব্যবহৃত সতর্কতা সহ চিহ্নিত করা হয় না

Answer 2

এখানে কয়েকটি সতর্কতা রয়েছে যেখানে ডকুমেন্টেশনগুলি আপনাকে এগুলি অক্ষম করতে চাইলে কারণগুলি দেয়:

• http://msdn.microsoft.com/en-US/library/4bw5ewxy(v=VS.80).aspx
• http://msdn.microsoft.com/en-US/library/sa4zat99(v=VS.80).aspx
• http://msdn.microsoft.com/en-US/library/9x19t380(v=VS.80).aspx

অন্যান্য উদাহরণগুলির মধ্যে অবনতিযুক্ত পদ্ধতিগুলি ব্যবহার সম্পর্কে সতর্কতা অন্তর্ভুক্ত রয়েছে যদি আপনি জানেন যে আপনি এখনও পুরানো পদ্ধতিটি ব্যবহার করতে চান বা ব্যক্তিগতভাবে কখনও স্থানীয়ভাবে পড়েন না এমন ব্যক্তিগত সদস্য থাকতে চান তবে পরিবর্তে প্রতিচ্ছবি সহ with

আমার অভিজ্ঞতায় সি # এর মতো অন্যান্য ভাষার তুলনায় সতর্কতা অক্ষম করার জন্য কম প্রয়োজন has এটি মূলত কারণ, যেমন এরিক লিপার্ট তাঁর ব্লগে বলেছেন , তারা "কেবলমাত্র সেই পরিস্থিতিতেই সতর্কতা সংরক্ষণের চেষ্টা করেন যেখানে আমরা প্রায় নিশ্চিতভাবেই বলতে পারি যে কোডটি ভাঙ্গা, বিভ্রান্তিকর বা অকেজো।"

Comments

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

— গ্রেগ জ্যাকসন

আমি এক্সেলে প্রচুর ম্যাক্রো প্রোগ্রামিং করেছি এবং অটো সেভ, অটো প্রস্থান, বিজ্ঞপ্তি ইত্যাদির মতো বিভিন্ন কারণে আমাকে সতর্কতাগুলি অক্ষম করতে হয়েছিল অবশ্যই এই সতর্কতাগুলির বিষয়ে আপনি না থাকতে পারেন ...

— ডেভ মেস

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

— মাহমুদ হোসাম

@ মাহমুদ আমি প্রায়শই জেনেরিকের সাথে এমনকি দূরবর্তীভাবে জটিল কিছু করার সময় নিজেকে "চেকড" সতর্কতাগুলি ছাড়িয়ে যেতে দেখি। তবে হাস্যকর সতর্কবাণী সামনে - আমার উত্তর সম্পাদনা করা জাওয়াকে সি ++ এর সাথে লম্পট করা সম্ভবত অন্যায়।

— আইসিআর

@ আইসিআর জাভা সংগ্রহগুলিতে ধরণের সুরক্ষা প্রদানের জন্য জেনেরিকের ব্যবহার প্রয়োগ করে, কেউ কেউ এটিকে একটি সীমাবদ্ধতা হিসাবে দেখেন, আমি এটিকে একটি বৈশিষ্ট্য হিসাবে মনে করি, এটি লেখার কোডটিকে কিছুটা বেদনাদায়ক করে তোলে, তবে এটি জীবন বাঁচায় এবং হ্যাঁ, সি ++ সংকলক আউটপুট এটি এসটিএল বা টেমপ্লেট সহ যে কোনও বিষয় এলে কিছুটা ভীতিজনক।

— মাহমুদ হোসাম

Answer 3

সি এর একটি উদাহরণ যা আমি নিয়মিত রূপগুলির মুখোমুখি হই:

int doSomething(int argument1)
{
#ifdef HARDWARE_TYPE_A
    performAction(argument1);
#else
    displayNotSupportedMessage();
#endif
}

যুক্তিটি কেবল কয়েকটি প্ল্যাটফর্মগুলিতেই প্রাসঙ্গিক, তবে যেগুলির সাথে এটি প্রাসঙ্গিক নয় সেগুলি সম্পর্কে আমার সংকলক অভিযোগ করবে এবং যেহেতু আমার সতর্কবার্তা ত্রুটিগুলিতে রূপান্তরিত হয়েছে এটি এটি নির্মাণে বাধা দেবে।

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

Answer 4

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

Answer 5

আমি এম্বেড করা কাজ করি এবং মনে হয় মনে হয় দু'একটি সময় আমি যখন সতর্কতাগুলি অক্ষম করেছিলাম কারণ আমি এমন কিছু কাজ করছিলাম যা সংকলকের কাছে অকেজো মনে হয়েছিল, তবে হার্ডওয়্যারটিতে বাস্তবে যার বাস্তব-প্রভাব ছিল effects

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

Answer 6

সংকলক সতর্কতাগুলি নির্বাচন করে অক্ষম করার বেশ কয়েকটি কারণ রয়েছে এমনকি এমন প্রকল্পগুলির জন্য যা সর্বোত্তম অনুশীলনের জন্য প্রচেষ্টা করে।

• বিভিন্ন সংকলক (বা একই সংকলকগুলির বিভিন্ন সংস্করণ) :
  সংকলকরা সূক্ষ্মতার সাথে বিভিন্নভাবে সতর্কতাগুলি পরিচালনা করে। মিথ্যা-ইতিবাচক সতর্কতা দেওয়া যা অন্য সংকলকগুলিকে প্রভাবিত করে না। এক্ষেত্রে এই সংকলকগণের জন্য সতর্কতাটি অক্ষম করা বুদ্ধিমান হতে পারে, বৈধ কোডটি সম্পাদন না করে একটি মিথ্যা-পজিটিভ সতর্কবার্তাটি শান্ত করার পরিবর্তে কেবলমাত্র কিছু নির্দিষ্ট সংকলককেই প্রভাবিত করে, বিশেষত পুরানো সংকলকগুলির জন্য যা শেষ পর্যন্ত কোনওভাবেই অসমর্থিত হয়ে পড়ে।
• উত্পন্ন কোড সহ:
  কোড হাইজিন সম্পর্কিত কিছু সতর্কতা (ডেড কোড, শর্তাধীন বিবৃতিগুলির সদৃশ বডি, প্রকারের সীমা অতিক্রমকারী তুলনা) নিরাপদে উপেক্ষা করা যেতে পারে যেহেতু তারা নিরীহ এবং সংকলক তাদের অপ্টিমাইজ করবে।
  কোড তৈরি করা যা এই ক্ষতিকারক সতর্কতাগুলিকে বাড়ায় না অবশ্যই অবশ্যই এটি একটি বিকল্প, তবে এর পরে এর মূল্যটি আরও বেশি সমস্যা হতে পারে।
• বাহ্যিক কোডের জন্য সতর্কতা:
  সম্ভবত আপনি একটি সুপরিচিত কিউসোর্ট বা এমডি 5 চেকসাম বাস্তবায়ন ব্যবহার করেন যা আপনার প্রকল্পের অন্তর্ভুক্ত। কোডটি অনেক প্রকল্পের দ্বারা ব্যবহৃত হয় এবং এটি ভাল কাজ করার জন্য পরিচিত, তবুও কিছু পিক সতর্কতা থাকতে পারে যা আপনার নিজের কোডের জন্য সাধারণত সংশোধন করে।
  বাহ্যিক কোড যাইহোক, এটা কম ঝামেলা শুধু সতর্কবার্তা নিষ্ক্রিয় করতে (অভিমানী তার স্পষ্টভাবে হতে পারে হয় নিরীহ)।
• সিস্টেম শিরোলেখ দ্বারা সতর্কতা:
  উদাহরণস্বরূপ জিসিসি / বিড়ম্বনাটি সমর্থন করার পরেও -isystem, এমন কিছু ক্ষেত্রে রয়েছে যখন সিস্টেম শিরোনামগুলির মধ্যে পার্থক্য সতর্কতাগুলি উপেক্ষা করতে পারে (সম্ভবত কোনও ফাংশনটিতে একটি সিস্টেমে স্বাক্ষরিত রিটার্ন মান রয়েছে তবে অন্যটি নয়), -Wsign-compareসতর্কবার্তা ট্রিগার করে।
  সিস্টেমের শিরোনামগুলিতে ম্যাক্রো সংজ্ঞায়িত করা হতে পারে অন্য কোনও ক্ষেত্রে, ম্যাক্রোগুলি সংশোধন করার জন্য আপনি নিজের কোডটিতে অনুলিপি করতে পারেন তবে তৃতীয় পক্ষের লাইব্রেরি থেকে ম্যাক্রোগুলি বজায় রাখার বিষয়ে চিন্তা না করার জন্য সমস্ত বিষয়ই ভাল বিবেচনা করা হয়েছিল ... সুতরাং এটি আরও ভাল সতর্কবার্তাটি শান্ত করার জন্য (সম্ভবত ম্যাক্রো উদ্বোধনকারী একটি কাস্ট মিস করে -Wsign-conversion)।
• স্টাব কোডে অব্যবহৃত সতর্কতা:
  আপনি অব্যবহৃত প্যারামিটার সম্পর্কে সতর্ক করতে পারেন, তবে কেবল একটি স্টাবের মধ্যে একটি সম্পূর্ণ লাইব্রেরি স্টাব করার সময় কেবল স্টাব ফাংশন রয়েছে - এটি (void)arg1; (void)arg2; (void)arg3; ...প্রতিটি স্টাব ফাংশনের শরীরে জোর করাতে সহায়ক নয় ।
  এক্ষেত্রে কেবল দমন করা ভাল -Wunused-parameter।

লক্ষ্য করুন এই সব উদাহরণ, তার ধারণা ছিল সতর্কবার্তা নিষ্ক্রিয় না বাস্তব বাগ লুকিয়ে যাচ্ছে, যেমন: -Wredundant-decls, -Wunused-parameter, -Wdouble-promotion, সম্ভবত -Wpedantic... এবং আপনি কি জানেন যে আপনি কি করছেন!

Answer 7

বৈধ বা না, এটি কখনও কখনও বিল্ড সার্ভারে "ত্রুটি হিসাবে সতর্কতাগুলি হিসাবে বিবেচনা করুন" নির্দেশনা বাইপাস করার জন্য করা হয়।

তা ছাড়া আমি আর কোনওটির কথা ভাবতে পারি না। অক্ষম সতর্কতাগুলি সাধারণত "কুৎসিত হ্যাক্স" এর লক্ষণ ...

Answer 8

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

ইতিমধ্যে, আমাদের এটি সংকলন করা দরকার, এবং আমরা "সতর্কতাগুলি ত্রুটিগুলি" বিকল্পটি চেয়েছিলাম, তাই আমরা কয়েকটি সতর্কতা দমন করেছি।

Answer 9

বর্তমানে, আমি কখনও উপেক্ষা করা একমাত্র সতর্কতা

  warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)  

মাইক্রোসফ্ট সি -+ স্পেসিফিকেশন বাস্তবায়ন করে না (ডকুমেন্টেশন এমনকি বলে যে তারা না!) এবং ফাংশনগুলিকে নির্দিষ্ট থ্রো ঘোষণা করার অনুমতি দেয় এবং সমস্ত ফাংশন কেবল নিক্ষেপ করতে পারে () অথবা নিক্ষেপ (...), অর্থাৎ কিছুই বা কিছুই নয়।

হেল্পভিউয়ার ১.১ থেকে:

 A function is declared using exception specification, which Visual C++ accepts but does not implement. Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications.