وحید نصیری وحید نصیری
مطالب
اضافه شدن پشتیبانی از unsigned right shift به C# 11
به C# 11، عملگر جدیدی به شکل <<< و به معنای unsigned right shift اضافه شده‌است که ... در زبان جاوا از نگارش ابتدایی آن حضور داشته‌است. اما ... چرا از این لحاظ بین این دو زبان، تفاوت وجود داشته‌است؟


مفهوم عملگر شیفت در #C

عملگر شیفت به سمت راست و یا <<، عددی را به تعداد بیت مشخص شده (x >> count)، به سمت راست منتقل می‌کند و دو نوع دارد:
الف) شیفت به راست منطقی
برای مثال اگر عدد 12 را به صورت باینری نمایش دهیم، به صورت زیر خواهد بود:
00000000 00000000 00000000 00001100
و اگر آن‌را به اندازه‌ی یک بیت به سمت راست هدایت کنیم، که با 1 <<< 12  نمایش داده می‌شود:
00000000 00000000 00000000 00000110
به عدد 6 خواهیم رسید.
در این حالت همواره فرض می‌شود که عدد مدنظر، unsigned است.

ب) شیفت به راست ریاضی
شیفت به راست ریاضی، دقیقا مانند شیفت به راست منطقی است؛ مانند مثال زیر که عدد 1001  باینری را دو بیت به سمت راست منتقل می‌کند:
uint e = 0b_1001;
Console.WriteLine($"Before: {Convert.ToString(e, toBase: 2),4}");
// Before: 1001

uint f = e >> 2;
Console.WriteLine($"After:  {Convert.ToString(f, toBase: 2).PadLeft(4, '0'),4}");
// After:  0010
اما ... بجای اینکه همانند شیفت به راست منطقی، سمت چپ را با صفر پر کند، آن‌را با «با ارزش‌ترین بیت یا همان بیت علامت» پر می‌کند. یعنی در اینجا بیتی که بیانگر مثبت و منفی بودن عدد است، حفظ می‌شود. یعنی این نوع شیفت، با اعداد signed هم کار می‌کند.
برای مثال نمایش باینری عدد منفی 2,147,483,552-  به صورت زیر است:
10000000 00000000 00000000 01100000
و اگر آن‌را چهار بیت به سمت راست هدایت کنیم (یعنی 4 << 2,147,483,552 -)، به عدد 134,217,722- می‌رسیم که معادل عدد باینری زیر است:
11111000 00000000 00000000 00000110
به این ترتیب با شیفت به راست ریاضی، علامت عدد منفی حفظ شده‌است. مثالی دیگر:
int x = -8;
Console.WriteLine($"Before: {x,11}, hex: {x,8:x}, binary: {Convert.ToString(x, toBase: 2),32}");
// Before: -8, hex: fffffff8, binary: 11111111111111111111111111111000

int y = x >> 2;
Console.WriteLine($"After  >>: {y,11}, hex: {y,8:x}, binary: {Convert.ToString(y, toBase: 2),32}");
// After  >>: -2, hex: fffffffe, binary: 11111111111111111111111111111110

int z = x >>> 2;
Console.WriteLine($"After >>>: {z,11}, hex: {z,8:x}, binary: {Convert.ToString(z, toBase: 2).PadLeft(32, '0'),32}");
// After >>>:  1073741822, hex: 3ffffffe, binary: 00111111111111111111111111111110


سؤال: در زبان جاوا، عملگر <<< به معنای unsigned right shift است؛ اما چنین عملگری در زبان #C تا نگارش 11 آن وجود ندارد؛ چرا؟!

پاسخ: چون زبان جاوا، فاقد نوع‌های داده‌ای توکار unsigned integers است (^)؛ برخلاف #C از نگارش یک آن. حتی به ظاهر، این امکان در Java 8 اضافه شده‌است، اما در حقیقت با نوع‌های int و long، فقط مانند اینکه unsigned هم می‌توانند باشند، رفتار می‌کند (^). البته نوع char در زبان Java، تنها نوع unsigned واقعی است.
همانطور که عنوان شد، در زبان #C فقط کافی است بر روی unsigned types مانند ulong, uint, ushort، عملگر << را بکار برد تا به  unsigned right shift جاوا رسید (به همین جهت عملگر اضافه‌تری برای آن ارائه نشده بود). البته باید دقت داشت که در اینجا عملگر << کار پر کردن MSB یا «با ارزش‌ترین بیت یا همان بیت علامت» را هم با صفر انجام می‌دهد؛ حتی اگر MSB مقدار دهی شده باشد (چون این کاری است که << بر روی unsigned types انجام می‌دهد).
تا پیش از C# 11 اگر نیاز به کار بر روی signed types جهت رسیدن به نتیجه‌ی عملگر <<< وجود داشته باشد (انجام شیفت منطقی؛ یعنی صرفنظر کردن از نوع علامت عدد)، می‌توان از متدهای الحاقی زیر استفاده کرد که ابتدا آن‌ها را به نمونه‌های unsigned تبدیل می‌کند و کار شیفت را انجام می‌دهد و سپس نوع اصلی را بازیابی می‌کند:
public static int UnsignedRightShift(this int signed, int places)
{
    unchecked
    {
        var unsigned = (uint)signed;
        unsigned >>= places;
        return (int)unsigned;
    }
}

public static long UnsignedRightShift(this long signed, int places)
{
    unchecked
    {
        var unsigned = (ulong)signed;
        unsigned >>= places;
        return (long)unsigned;
    }
}
‫۱ سال و ۹ ماه قبل، چهارشنبه ۹ آذر ۱۴۰۱، ساعت ۱۴:۱۵
وحید نصیری وحید نصیری
مطالب
برنامه نویسی امن به زبان C

اگر سخنان بزرگان برنامه نویسی را مطالعه کرده باشید، یکی از موارد این بود:
" هیچگاه از gets و sprintf استفاده نکنید، در غیر اینصورت شیاطین به زودی به سراغ شما خواهند آمد! (FreeBSD Secure Programming Guidelines) "
به عبارت دیگر استفاده از توابع کتابخانه‌های استاندارد زبان C ، بدون ملاحظات لازم (یا همان برنامه نویسی کلاسیک به زبان C )، منشاء بسیاری از حملات Buffer overrun است، زیرا اکثر این توابع اندازه‌ی بافر یا رشته‌ی ورودی را بررسی نمی‌کنند.
برای رفع این مشکلات که هنوز که هنوز است قربانی می‌گیرد! ، The Safe C Library پدید آمده است. این کتابخانه بر اساس استاندارد ISO TR24731 تهیه گردیده و در آن یک سری توابع مکمل، جهت بالا بردن امنیت‌ برنامه‌های تهیه شده به زبان C مطابق استاندارد ISO/IEC 9899:1999 معرفی شده است.

برای مثال مطابق استاندارد ISO/IEC JTC1 SC22 WG14 N1172 ، تابع نا امن memcpy با تابع امن زیر باید جایگزین شود:
errno_t  memcpy_s(void *dest, rsize_t dmax, const void *src, rsize_t smax)

مستندات آن‌را در فایل safe_lib_html.tar پس از دریافت کتابخانه می‌توانید مشاهده نمائید.

همچنین اخیرا به عنوان مکمل این مجموعه، یک کتابخانه‌ی ریاضی امن نیز تهیه شده است.

پ.ن.
شبیه به همین مورد در اینترفیس پلاگین‌های IDA-Pro در نگارش‌های اخیر آن اعمال شده است و برنامه نویس را وادار می‌کند که از نمونه‌های معادل امن در آن محیط استفاده کند.
//pro.h
// We forbid using dangerous functions in IDA Pro
#ifndef USE_DANGEROUS_FUNCTIONS
#if defined(__BORLANDC__) && (__BORLANDC__ < 0x560  || __BORLANDC__ >= 0x580) // for BCB5 (YH)
#include <stdio.h>
#endif
#undef strcpy
#define strcpy          dont_use_strcpy            // use qstrncpy
#define stpcpy          dont_use_stpcpy            // use qstpncpy
#define strncpy         dont_use_strncpy           // use qstrncpy
#define strcat          dont_use_strcat            // use qstrncat
#define strncat         dont_use_strncat           // use qstrncat
#define gets            dont_use_gets              // use fgets
#define sprintf         dont_use_sprintf           // use qsnprintf
#define snprintf        dont_use_snprintf          // use qsnprintf
#define wsprintfA       dont_use_wsprintf          // use qsnprintf
#endif
برای مطالعه بیشتر: The Safe C Library

‫۱۵ سال و ۸ ماه قبل، چهارشنبه ۱۲ فروردین ۱۳۸۸، ساعت ۱۹:۱۵
وحید نصیری وحید نصیری
مطالب
‫دریافت کل یک مخزن SVN به کمک برنامه نویسی

تمام قابلیت‌های موجود در SVN به کمک برنامه نویسی هم قابل دسترسی هستند. برای مثال تهیه خروجی از یک مخزن SVN به همراه تمامی فایل‌ها و ساختار آن. SVN به زبان C نوشته شده است و API آن نیز مبتنی بر همین زبان است اما یک سری محصور کننده برای استفاده از آن در سایر زبان‌های برنامه نویسی هم موجود است. برای مثال معروفترین آن‌ها جهت استفاده به کمک دات نت فریم ورک کتابخانه‌ی SharpSVN است. پس از دریافت و افزودن ارجاعی به اسمبلی آن، چند سطر ذیل کار دریافت یک مخزن SVN را به صورت تمام و کمال انجام خواهد داد:

using SharpSvn;
...
using (var sc = new SvnClient())
{
 var target = SvnTarget.FromUri(new Uri("http://someproject.googlecode.com/svn/trunk/"));
 var finalSaveToDir = "somepath ..."; //Note: this path should not exist
 sc.Export(target, finalSaveToDir);
}

نمونه‌ای از کاربردها:
- راه اندازی یک سایت برای دریافت ساده‌تر مخازن کد برای مثال Google-code یا source forge و امثال آن.

‫۱۳ سال و ۹ ماه قبل، سه‌شنبه ۲۶ بهمن ۱۳۸۹، ساعت ۰۳:۳۳
حسن قاسمی هریس حسن قاسمی هریس
نظرات نظرسنجی‌ها
با توجه به آخرین نگارش‌های موجود Angular و React، انتخاب شما برای انجام یک پروژه بزرگ کدام است؟
همه فریمورک‌های ذکر شده جزو فریم ورک‌های پر طرفدار هستند (البته عمر کم Blazor رو باید در نظر گرفت). دلیلم برای انتخاب Blazor، یکپارچه بودن با فریم ورک دات نت، امکان اشتراک کد‌های برنامه با کد‌های کلاینت و پشتیبانی و سرمایه گذاری خوب مایکروسافت هستش. بنده در تیم توسعه دو پروژه بزرگ بیمه ای بودم که کل پروژه با Angular کار شد. Angular فریم ورک کاملی هستش ولی با وجود استفاده از Type Script  باز هم به علت ماهیت این زبان، نمی‌تونه ویژگی‌های زبانی مثل #C رو داشته باشه. مثلاً شما یک کلاس تعریف می‌کنید برای نگاشت داده ای که از سرور دریافت می‌کنید. شما می‌تونید هر داده ای رو با هر شکلی و هر فیلدی از سمت سرور ارسال کنید در هر صورت اون داده به کلاس شما نگاشت می‌شه بدون هیچ خطایی. اگر دیباگ هم انجام بدید متوجه میشید اون فیلدهایی که هم نام بودن مپ شدن ولی کلاس شما عملاً یک آبجکت دیگه هست که حتی نمی‌تونید به اون آبجکت دسترسی داشته باشید چون داده ارسالی بدون توجه به نوع کلاس شما، نگاشت شده. (احتمالاً نتونستم دقیق توضیح بدم) این مشکل یکی از مشکلاتی هستش که توی پروژه بزرگ دردسر ساز می‌شه و دلیلش هم بحثی هستش که مربوط به زبان فریم ورکه. هر چند حجم بالای برنامه Blazor رو نمیشه فراموش کرد ولی بنظرم فعلاً برای برنامه‌های داخلی یک سازمان یا برنامه ای که برای کاربران، ارزش انتظار و دانلود برنامه وجود داره، انتخاب خیلی خوبی هست.
‫۱ سال و ۱ ماه قبل، یکشنبه ۸ مرداد ۱۴۰۲، ساعت ۱۲:۳۱
پرهام دستغیب پرهام دستغیب
پروژه‌ها
ادغام، اضافه کردن و جدا کردن صفحات PDF
این پروژه ساده را به صورت Windows Form Application و با زبان Python ساختم. می‌تواند مثالی باشد برای کسانی که میخواهند پایتون را در ویندوز یاد بگیرند و اجرا کنند. اگر کسی پروژه را امتحان کرد، خوشحال خواهم شد خطا‌ها و اشکالات را اینجا اعلام کند.
  1. ادغام چند فایل PDF به صورت فایل واحد (Merging)
  2. اضافه کردن یک فایل PDF به یک فایل موجود (Appending)
  3. جدا کردن صفحات دلخواه از یک فایل و ذخیره آنها در یک فایل جدا (Splitting)
نحوه اجرا: 
  1. در صورت نصب امکانات پایتون برای ویژوال استودیو مثل سایر پروژه‌های دات نت قابل اجرا و دیباگ است.
  2. از طریق خط فرمان  و دستور ipy که در ادامه مثالی میزنم.
  3. من خودم از طریق یک برنامه کنسول ساده پروژه را خارج از محیط توسعه اجرا میکنم که در ادامه مثالی میزنم.
 اجرا از خط فرمان:
  ipy C:\\PdfTools\\PdfTools.py

اجرا از برنامه کنسول: 
var process = new Process();
var startInfo = new ProcessStartInfo
      {
            WindowStyle = ProcessWindowStyle.Hidden,
            FileName = "CMD.exe",
            Arguments = "/C ipy C:\\PdfTools\\PdfTools.py"
      };
process.StartInfo = startInfo;
process.Start();
نکته: در صورتی که بخواهید از برنامه کنسول برای اجرا استفاده کنید آیکن‌های برنامه باید در پوشه Debug وجود داشته باشند! 

‫۶ سال و ۲ ماه قبل، چهارشنبه ۱۷ مرداد ۱۳۹۷، ساعت ۲۰:۰۹
وحید نصیری وحید نصیری
مطالب
لینک‌های هفته‌ی دوم بهمن

وبلاگ‌ها ، سایت‌ها و مقالات ایرانی (داخل و خارج از ایران)

ASP. Net

طراحی و توسعه وب

PHP

سی شارپ

عمومی دات نت

ویندوز
(ایکاش بجای تمام این‌کارها یک سیستم ساده‌تر توسعه‌ی پلاگین برای آن طراحی می‌کردند ... یا به عبارتی یکی از مهم‌ترین دلیل‌های اقبال مردم به فایرفاکس را به صورت بسیار کم رنگی دارد)


مسایل اجتماعی و انسانی برنامه نویسی

متفرقه
‫۱۵ سال و ۱۰ ماه قبل، پنجشنبه ۱۰ بهمن ۱۳۸۷، ساعت ۰۳:۴۵
وحید نصیری وحید نصیری
مطالب
C# 8.0 - پیشنیاز و روش راه اندازی
پیشنیاز کار با C# 8.0

هرچند بسیاری از قابلیت‌های C# 8.0 در خود کامپایلر #C پیاده سازی شده‌اند، اما برای مثال قابلیتی مانند «پیاده سازی پیش‌فرض اینترفیس‌ها» نیاز به یک runtime جدید دارد که به همراه NET Core 3.0. ارائه می‌شود. بنابراین NET Full 4x. شاهد پیاده سازی C# 8.0 نخواهد بود. همچنین یک سری از قابلیت‌های C# 8.0 وابسته‌ی به NET Standard 2.1. و  netcoreapp3.0  هستند؛ مانند نوع‌های جدید System.IAsyncDisposable و یا System.Range. به همین جهت است که برای کار با C# 8.0، حتما نیاز به نصب NET Core 3.0. نیز می‌باشد و به روز رسانی کامپایلر #C کافی نیست.


چه نگارش‌هایی از Visual Studio از NET Core 3.0. پشتیبانی می‌کنند؟

مطابق مستندات رسمی موجود، یک چنین جدولی در مورد نگارش‌های مختلف NET Core. و نگارش‌های ویژوال استودیوهایی از که از آن‌ها پشتیبانی می‌کنند، وجود دارد:

.NET Core SDK .NET Core Runtime Compatible Visual Studio MSBuild Notes
2.1.5nn 2.1 2017 15 Installed as part of VS 2017 version 15.9
2.1.6nn 2.1 2019 16 Installed as part of VS 2019
2.2.1nn 2.2 2017 15 Installed manually
2.2.2nn 2.2 2019 16 Installed as part of VS 2019
3.0.1nn 3.0 (Preview) 2019 16 Installed manually

بنابراین فقط VS 2019 است که قابلیت پشتیبانی از NET Core 3.0. را دارد. به همین جهت اگر قصد دارید با ویژوال استودیو کار کنید، نصب VS 2019 برای کار با C# 8.0 الزامی است.


فعالسازی C# 8.0 در ویژوال استودیو 2019

در زمان نگارش این مطلب، NET Core 3.0. در حالت پیش‌نمایش، ارائه شده‌است. به همین جهت جزء یکپارچه‌ی VS 2019 محسوب نشده و باید جداگانه نصب شود:


- برای این منظور ابتدا نیاز است آخرین نگارش NET Core 3.0 SDK. را دریافت و نصب کنید.
- سپس از منوی Tools | Options، گزینه‌ی Projects and Solutions را انتخاب و در ادامه گزینه‌ی Use previews of the .NET Core SDK را انتخاب کنید.
- پس از آن، این SDK جدید NET Core. به صورت زیر قابل انتخاب خواهد بود:


البته انتخاب شماره SDK صحیح به تنهایی برای کار با C# 8.0 کافی نیست؛ بلکه باید شماره‌ی زبان مورد استفاده را نیز صریحا انتخاب کرد:


برای اینکار بر روی پروژه کلیک راست کرده و گزینه‌ی Properties آن‌را انتخاب کنید. سپس در اینجا در برگه‌ی Build، بر روی دکمه‌ی Advanced کلیک کنید تا بتوان شماره نگارش زبان را مطابق تصویر فوق انتخاب کرد. در اینجا بجای C# 8.0 (beta)، گزینه‌ی unsupported preview را نیز می‌توانید انتخاب کنید.

یک نکته: خلاصه‌ی تمام این مراحل، منوها و تصاویر، همان تنظیمات فایل csproj است که در ادامه بررسی می‌کنیم.


فعالسازی C# 8.0 در VSCode

مدت‌ها است که برای کار با NET Core. نیازی به استفاده‌ی از نگارش کامل ویژوال استودیو نیست. همینقدر که VSCode را به همراه افزونه‌ی #C آن نصب کرده باشید، می‌توانید برنامه‌های مبتنی بر NET Core. را بر روی سیستم عامل‌های مختلفی که NET Core SDK. بر روی آن‌ها نصب شده‌است، توسعه دهید.
پشتیبانی ابتدایی از C# 8.0، با نگارش v1.18.0 افزونه‌ی #C مخصوص VSCode ارائه شد. بنابراین هم اکنون اگر آخرین نگارش آن‌را نصب کرده باشید، امکان کار با پروژه‌های NET Core 3.0 و C# 8.0 را نیز دارید.
بنابراین در اینجا به صورت خلاصه:
- ابتدا باید NET Core 3.0 SDK. را به صورت جداگانه‌ای دریافت و نصب کنید.
- سپس آخرین نگارش افزونه‌ی #C مخصوص VSCode را نیز نصب کنید.
- در آخر، یک پوشه‌ی جدید را ایجاد کرده و در خط فرمان دستور dotnet new console را صادر کنید. این دستور بر اساس آخرین شماره نگارش SDK نصب شده، یک پروژه‌ی جدید کنسول را ایجاد می‌کند که ساختار فایل csproj آن به صورت زیر است:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>
</Project>
همانطور که مشاهده می‌کنید، TargetFramework را به آخرین SDK نصب شده، تنظیم کرده‌است (معادل دومین تصویر این مطلب). مرحله‌ی بعد، تنظیم شماره نگارش زبان آن است. برای این منظور یکی از دو حالت زیر را می‌توان انتخاب کرد:
- یا معادل همان گزینه‌ی unsupported preview در تصویر سوم این مطلب:
<Project Sdk="Microsoft.NET.Sdk"> 
   <PropertyGroup> 
      <OutputType>Exe</OutputType> 
      <TargetFramework>netcoreapp3.0</TargetFramework> 
      <LangVersion>preview</LangVersion> 
   </PropertyGroup>
 </Project>
- و یا تعیین صریح شماره نگارش C# 8.0 (beta) به صورت زیر:
<Project Sdk="Microsoft.NET.Sdk"> 
   <PropertyGroup> 
      <OutputType>Exe</OutputType> 
      <TargetFramework>netcoreapp3.0</TargetFramework> 
      <LangVersion>8.0</LangVersion> 
   </PropertyGroup>
</Project>

یک نکته: در اینجا نمی‌توان LangVersion را به latest تنظیم کرد؛ چون C# 8.0 هنوز در مرحله‌ی بتا است. زمانیکه از مرحله‌ی بتا خارج شد، مقدار پیش‌فرض آن دقیقا latest خواهد بود و ذکر صریح آن غیر ضروری است. انتخاب latest در اینجا به latest minor version یا همان نگارش C# 7.3 فعلی (آخرین نگارش پایدار زبان #C در زمان نگارش این مطلب) اشاره می‌کند.



Rider و پشتیبانی از C# 8.0

Rider 2019.1 نیز به همراه پشتیبانی از C# 8.0 ارائه شده‌است و می‌تواند گزینه‌ی مطلوب دیگری برای توسعه‌ی برنامه‌های مبتنی بر NET Core. باشد.


نصب NET Core 3.0 SDK. و عدم اجرای برنامه‌های پیشین

یکی از مزایای کار با NET Core.، امکان نصب چندین نوع مختلف SDK آن، به موازت هم است؛ بدون اینکه بر روی یکدیگر تاثیری بگذارند. البته این نکته را باید درنظر داشت که برنامه‌های NET Core. بدون وجود فایل مخصوص global.json در پوشه‌ی ریشه‌ی آن‌ها، همواره از آخرین نگارش SDK نصب شده، برای اجرا استفاده خواهند کرد. اگر این مورد بر روی کار شما تاثیرگذار است، می‌توانید شماره SDK مورد استفاده‌ی برنامه‌ی خود را قفل کنید، تا SDKهای جدید نصب شده، به عنوان SDK پیش‌فرض برنامه‌های پیشین، انتخاب نشوند. بنابراین ابتدا لیست SDKهای نصب شده را با دستور زیر پیدا کنید:
> dotnet --list-sdks
سپس برای پروژه‌های قدیمی خود که فعلا قصد به روز رسانی آن‌ها را ندارید، یک فایل global.json را به صورت زیر‌، در ریشه‌ی پروژه تولید کنید:
> dotnet new globaljson --sdk-version 2.2.300
> type global.json
در اینجا 2.2.300 یکی از شماره‌هایی است که توسط دستور dotnet --list-sdks یافته‌اید و پروژه‌ی قبلی شما بر اساس آن کار می‌کند.
‫۵ سال و ۴ ماه قبل، دوشنبه ۶ خرداد ۱۳۹۸، ساعت ۱۸:۰۵