هل تؤدي إرجاع المرجع إلى التجزئة المعلنة في الروتين الفرعي إلى تسرب الذاكرة؟

Question

يستخدم بياناتي؛ أدناه حسنًا أم يجب أن أتحول إلى بياناتي $={}; ?

#!/usr/bin/perl -wT
use strict;
use JSON;

sub makeJson {
        my %data;

        $data{kib} = 1;
        $data{games} = {
                0 => [],
                1 => [qw(a b c d e)],
        };

        return \%data;
}

my $x = makeJson();
print encode_json($x) . "\n";

أنا في حيرة من أمري لأن -

إذا ميك جيسون () يسمى عدة مرات - و بياناتي؛ تم تخصيصه في المكدس ثم يتم إرجاع هذا العنوان - أليس هذا بمثابة تسرب للذاكرة أو ربما ليس "تسربًا" ولكنه "مشكلة"؟لأنه ستكون هناك ذاكرة مخصصة في المكدس، والتي لا تزال مرجعية وبالتالي لا يمكن إلغاء تخصيصها.

وفي غير ذلك:إذا كان لدي روتين فرعي يُرجع مرجع التجزئة، وهو الأفضل للاستخدام بياناتي؛ (أسرع، لأنه تم تخصيصه مسبقًا بواسطة المترجم؟) أو بياناتي $={}; ?

Answer 1

بيرل ليس C.

هذه هي الإجابة الفعلية على سؤالك، لكنني سأتوسع قليلاً.

Perl ليس C حيث أن Perl لا يحتوي على متغيرات تلقائية.لديها متغيرات معجمية وديناميكية وهذا كل شيء.

Perl ليس لغة C حيث أن Perl يقوم بإدارة الذاكرة لذا لا يتعين عليك (في الغالب) القيام بذلك.في غياب المراجع الدائرية، لن يحدث تسرب للذاكرة.

لغة Perl ليست لغة C، حيث أن تكلفة كونها لغة مفسرة تهيمن على معظم حسابات الأداء، وبالتالي فإن التحسين الدقيق للتجزئات مقابل التجزئة يكون دائمًا غير ذي صلة.

استخدم أي بناء يعبر بشكل طبيعي عن نيتك.ولا يسرب أي منهما الذاكرة أكثر من الآخر؛ أمدال يمكن أن تقلق بشأن الاختلافات الصغيرة في الأداء.بيرل ليس C.

Answer 2

لا تمتلك لغة Perl (والعديد من اللغات المترجمة الأخرى) مفهوم المكدس مثل اللغات المترجمة.لديها قواعد النطاق بدلا من ذلك.لذلك فإن Perl قادر على ضمان عدم حدوث أي تسرب للذاكرة.

في الواقع، حتى لو كان لديه نفس مفهوم المكدس، فسيقوم فقط بإرجاع عنوان يصبح غير صالح.