rắc rồi việc truyền tham số cho toán tử delete

[Kijuto Riddle]

C++ cho phép chồng toán tử cho new và delete, nhưng hình như delete không có dạng có tham số, nghĩa là chỉ có một toán tử delete duy nhất được sử dụng. Trong các ebook Kijuto đọc (C++ The Complete Refrence) nói rất sơ sài và kiểu 'chỉ tay năm ngón'. Còn nói là delete cũng có thể có tham số, nhưng trong định nghĩa trong MSDN thì delete chỉ có 1 prototype duy nhất. Trong ebook có nói còn có cả phiên bản no_throw của delete, nhưng Kijuto đã thử cài chồng cái delete(nothrow) và thấy là nó không bao giờ được gọi, luôn luôn là toán tử delete thông thường cho dù mình viết lệnh

delete(nothrow) <any_pointer>;

.
Kijuto dùng GCC nhưng nghĩ cái MSDN cũng đúng cho GCC phần lớn.
Có ai có kinh nghiệm hay thông tin gì về việc cái trồng toán tử delete có tham số, cụ thể là có thể dùng cùng một lúc nhiều phiên bản delete thì xin giúp đỡ.

[imweasel]

tôi nghĩ bạn có thể dùng macro #define cho mục đích này
ví dụ:

#define function(_x_, _y_) \
           if(_x_) { \
           delete _y_;} \
           else { \
           .... }

[Kijuto Riddle]

chắc imweasel không hiểu Kijuto rồi.
Cài chồng hàm new/delete chỉ thay đổi được về thao tác cấp phát và giải phóng bộ nhớ, còn các thao tác gọi đến destructor của objects thì không thao tác được. Cũng bởi vì mình không thể gọi được destructor của objects nên mới sinh ra rắc rối phức tạp.
Nếu mà dùng cái marco của imweasel thì thà dùng luôn một hàm riêng để giải phóng kiểu khác thường, còn delete thì vẫn delete kiểu bình thường co phải hơn không.

[bete]

Thân gửi Kịuto:

http://66.102.7.104/search?q=cache:d.../manuali/C%2B%
2BNotes/cplus009.htm+c+overload+delete+extra+parameter&hl= en

(nhưng hình như không có cái mà bạn muốn
Có lẽ bạn nên thử "delete [] p;" (dĩ nhiên trước đó mình phải overload delete[]()) thay vì "delete p;"

Bạn có thể nói rõ thêm 1 chút trong trường hợp nào bạn muốn pass thêm tham số khi gọi delete !?)

-thân

[Kijuto Riddle]

Thân gửi bete:

Có lẽ bạn nên thử "delete [] p;" (dĩ nhiên trước đó mình phải overload delete[]()) thay vì "delete p;"

Trời đất, thế thì delete mảng thì ngồi khóc à. Kijuto nói delete là nói ẩn dụ, bao gồm cả delete lẫn delete[].

Bạn có thể nói rõ thêm 1 chút trong trường hợp nào bạn muốn pass thêm tham số khi gọi delete !?)

Thật ra truyền tham số chỉ là cái cớ, ý Kijuto là muốn dùng một lúc hai kiểu cấp phát bộ nhớ cơ. Đối với new thì không có gì khó khăn, nhưng delete thì tịt, các vị tiền bối viết trình biên dịch C không nghĩ là có thằng dở hơi biết bơi lại thích giải phóng bộ nhớ bằng hai cách. Nhưng kể cũng lạ là cho phép người ta sử dụng nhiều kiểu new một lúc mà lại không cho delete nhiều kiểu, không biết là do Kijuto dở hơi hay các vị tiền bối hơi bị đãng trí bác học.
Ví dụ mình dùng một new để new bình thường, một new khác để lấy một vùng nhớ lớn hơn yêu cầu một chút để dùng cho mục đích cụ thể (hơi bị oái ăm à?), thì delete lại không phân biệt được. Tạm thời mình phải dùng một biến global/static integer để làm cờ phân biệt, trước khi gọi delete thì ++ cái biến lên, sau đó thì khi hàm delete (đã được cài chồng) sẽ kiểm tra cờ để quyết định sẽ delete như thế nào cho hợp lý. Nếu mà không có nhiều hàm delete thì cách này đúng là cách duy nhất.

[bete]

Thân gửi Kijuto: tui thấy làm như bạn là được rồi đó.

Tui nghĩ thêm 1 chút: giả sử mình có class A => thêm vô 1 trường 'extraInfo' để lấy thêm 1 chút bộ nhớ như bạn muốn => không cần cài chồng delete. Nếu class A là có sẵn, không sửa được => thêm class AA là lớp bao của A (AA = A + extraInfo). Có điều làm như vậy sẽ ảnh hưởng tới mọi đối tượng thuộc class AA: đối tượng nào cũng tốn thêm 1 chút vùng nhớ => khi nào muốn xin đúng vùng nhớ thì xài class A, khi nào muốn xin thêm thì xài class AA.

Còn nếu thấy phiền phức thì mình có thể chỉ thêm 1 byte 'ha***traMem' vô class A (hoặc class AA) mà thôi: khi new nếu thấy ha***traMem là true thì xin thêm vùng nhớ, thấy là false thì xin đúng vùng nhớ. Và phải cài chồng lại delete: khi thấy ha***traMem là true thì trả lại "dư" 1 chút, khi thấy là false thì trả lại đúng. Nhưng làm nhưng vậy vẫn tốn thêm 1 byte cho mọi đối tượng

Còn làm như bạn thì chỉ tốn thêm 1 byte cho toàn bộ chương trình. Có điều phải nhớ tăng giảm cho đúng để tránh "xin đúng mà trả dư" hoặc "xin dư mà trả đúng" (nếu làm như 2 cách trước thì khi delete không lo về chuyện lầm lẫn này)

(tui chưa bao giờ thử cài chồng new/delete => cũng muốn thử qua 1 chút cho biết )

(có gì sai sót xin các bạn chỉ giúp, cám ơn rất nhiều)

-thân

[Kijuto Riddle]

Thân gửi bete:
Đúng là sợ rắc rối nên không muốn nói kỹ, sợ lại phải giải thích nhiều. Không ngờ càng nói mập mờ lại càng phải nói nhiều hơn.
Thật ra là Kijuto đang định phát triển một bộ thư viện sử dụng một GarbageCollector bằng phương pháp đếm tham chiếu (refrence count). Kijuto đã tham khảo nhiều loại kiểu refrence count của các bộ thư viện tiền bối, thì thấy có nhiều bất tiện. Phương pháp của bete chính xác là phương pháp RC (Refrence Count) của bộ thư viện OpenTop. Nhưng đối với mỗi lớp lại phải kèm theo một cái wrapper thì hơn bị phiền hà (theo ý của Kijuto), (cái OpenTop nó còn ép chỉ cho dùng wrapper) hơn nữa nếu dùng 2 loại lớp cho một kiểu đối tượng thì sẽ phải dùng virtual method/class, mà động đến liên kết động thì phải tránh xa nếu không cần thiết (để đảm bảo perfoment). Còn nếu ép người ta chỉ dùng wrapper thì cũng dở vì không mềm dẻo, nhiều khi phát triển các ứng dụng đổi hỏi tốc độ cao là rất bất tiện.
Chính vì vậy, Kijuto đang sử dụng một phương pháp RC mà hack hơn sâu vào trong cách quản lý bộ nhớ một chút. Đó là khi cấp phát, thì cấp thừa ra 4 byte = 1 int để sử dụng làm biến đếm. Như vậy, đối với bất kỳ lớp đối tượng nào, thậm chí là các kiểu dữ liệu cơ bản đều có thể dùng cái RC này.
+ Ưu điểm:
* Mềm dẻo 1: tất cả các lớp, do mình phát triển hay copy từ cái chỗ khỉ gió nào trên net đều sử dụng được.
* Mềm dẻo 2: có thể tùy ý lựa chọn có nên dùng RC hay không. Cụ thể, chỉ có những data mà dùng chung giữa các đối tượng/module thì mới dùng, các data không đòi hỏi chia sẻ sẽ dùng như bình thường.
* Mềm dẻo 3: có thể convert một data từ dạng dùng RC thành dạng bình thường và ngược lại.
* Thừa kế: Tất cả các ưu điểm "khét tiếng" mà một garbage collector có được.
* Bảo toàn: Không hề mất bất cứ ưu điểm về tốc độ thực thi của ngôn ngữ C/C++
- Nhược điểm:
* Thật ra là để thu được tất cả các ưu điểm trên thì đòi hỏi kĩ năng + kiến thức khá về quản lý bộ nhớ. Vì vậy đối với các newbie thì các ưu điểm: Mềm dẻo 2 và 3 có thể không nên sử dụng. Nhưng dù sao thì chỉ thế cũng đã hơn khối thằng RC khác rồi (he he). Dù sao (lại dù sao) thì cung cấp cho người phát triển tất cả khả năng để lựa chọn vẫn hơn là gò ép người ta phải hi sinh sự tiện dụng hay tốc độ của ứng dụng.
* Khách quan 1: chính là lý do mà cái Thread này sinh ra và còn sống đến giờ. Tời giờ vẫn phải sử dụng biến cờ để kiểm tra, vì vậy thao tác cấp phát bộ nhớ sẽ slow đi một tý xíu, tuy nhiền cũng chẳng đáng bao nhiêu so với thời gian để cấp phát và giải phóng bộ nhớ. Và Kijuto cũng đưa ra một giải pháp để giải quyết cái này, đó cung cấp hai lựa chọn để biên dịch:
1) Dùng cờ để kiểm tra (a litter slower).
2) Không dùng cờ, coi như chỉ có một cách để new và delete, luôn cấp phát chỗ chống để cho biến đếm, còn có dùng hay không thì tùy, cần RC thì đếm, không thì bỏ (a litter faster).
Khi biên dịch mà thấy ứng dụng nhanh/chậm không đúng yêu cầu thì sẽ đổi lại tham số biên dịch, cái nào tốt hơn thì dùng (happiness for all).

Cho đến nay, phương pháp này vẫn chạy tốt, và không có vấn đề gì. chỉ trừ cái toán tử delete độc đoán đáng ghét

[bete]

Thân gửi Kijuto: đề tài rất hay(phân tích ưu nhược điểm sắc bén); và ăn tiền ở chỗ "thậm chí là các kiểu dữ liệu cơ bản đều có thể dùng cái RC này" !!! Sẽ ráng coi kỹ hơn về mấy cái này để học hỏi thêm
Tìm được 1 giải pháp như Kijuto là quá tốt rồi, Kijuto cứ từ từ mà sửa cho nhanh/tiện hơn thôi mà !!! Chúc thành công

(Đọc bài toán của Kijuto mà liên tưởng đến Smart Pointers)

-thân

[imweasel]

ý tưởng Kijuto rất hay, đề nghị cung cấp thành một lib với đầy đủ doc cho anh em dùng ( nếu non-comm hoặc open-source) B-)

[Kijuto Riddle]

Thân gửi everyone:

(Đọc bài toán của Kijuto mà liên tưởng đến Smart Pointers)

Smart Pointers là gì nhỉ, bete có thể cung cấp rõ hơn không? Hơn bận nên ngại google lắm!

ý tưởng Kijuto rất hay, đề nghị cung cấp thành một lib với đầy đủ doc cho anh em dùng ( nếu non-comm hoặc open-source) B-)

Khi đã hoàn thiện được phần core, Kijuto sẽ open-source và kêu gọi mọi người cùng phát triển. Kijuto sẽ không open dưới liscence của GPL, nghĩa là ai dùng thì không cần phải Open-source trở lại, non-comm dùng thỏa mái, comm thì xem xét, có thể là cần một cái gật đầu thì mới được dùng cho comm . And no money at all.
Tổng quan về thư viện thì Kijuto sử dụng Java conversion (ai cũng công nhận là nó tốt). Vì định hướng là phát triển một bô thư viện tốc độ cao (cái mà Java hi sinh hơi bị nhiều) nên chỉ dùng Java conversion chứ không copy toàn bộ thiết kế của Java, nên những ai thích một Java-clone version thì có thể tự phát triển lấy từ phần core.
Dự kiến chỉ có package java.io.* của Java là được copy hoàn toàn. Vì sao???: Vì package java.io.* nổi tiếng tiện dụng và hơn nữa, các thao tác về stream hầu hết là bị thắt cổ trai về tốc độ ở đầu cuối (disk access, network transfer...) vì vậy không cần phải lo lắng về tốc độ của package này (phát triển package này là dễ nhất, chỉ việc code y nguyên theo thiết kế của java ).
Nói thêm một câu, định hướng của Kijuto là để phát triển game, thế cho nên, "performent is everything".