2011-10-12 35 views
6

Là một nhà phát triển thư viện, tôi muốn ngăn người dùng thư viện của mình (Windows, MSVC) liên kết đến cấu hình sai (không liên kết thư viện gỡ lỗi với các chương trình phát hành của họ và ngược lại).Ngăn chặn việc sửa lỗi và giải phóng thư viện

Có thể cảnh báo người dùng trong thời gian biên dịch mà anh ta nên liên kết đến cấu hình đúng của thư viện không?

EDIT

Cả gỡ lỗi và phát hành phiên bản nên có sẵn để cho phép các nhà phát triển Windows để gỡ lỗi các ứng dụng của họ. Vì vậy, cả hai phiên bản gỡ lỗi và phát hành của thư viện của tôi sẽ có sẵn.

Tôi đang đặt câu hỏi này bởi vì rất nhiều sự hỗ trợ cho các nhà phát triển Windows mới bắt đầu là do chúng trộn lẫn gỡ lỗi và phát hành mã, và nhận được lỗi thời gian chạy khó gỡ lỗi.

+0

Tại sao bạn muốn khách hàng gỡ lỗi thư viện của mình? Bạn đang cung cấp mã nguồn với nó? Thiết kế API của bạn để cài đặt trình biên dịch không thành vấn đề. COM ABI là một ví dụ điển hình. –

+0

Nếu bạn tạo một lib tĩnh thay vì dll, bạn phải thêm phiên bản gỡ lỗi theo bất kỳ cách nào. Khác không ai có thể tạo ra một phiên bản gỡ lỗi ở tất cả. – Totonga

Trả lời

0

Bạn có thể thêm chỉ thị #warning nhưng tôi không khuyến khích bạn thực hiện điều đó. Bạn nên phân phối đến phiên bản thư viện khác với hai tên khác nhau.

Dưới đây là một gợi ý cho vấn đề của bạn:

myLib.h // Release Version 
myLibd.h // Debug Version 

Làm nó như vậy, nó sẽ buộc người dùng phải chăm sóc khi họ sẽ thiết lập các ứng dụng với thư viện của bạn (kể từ khi thiết lập phải bằng tay) .

Bạn cũng có thể thêm ghi chú trong README hoặc INSTALL, hầu hết người dùng đọc nó khi họ muốn thiết lập liên kết trên MSVC.

Bạn cũng có thể kiểm tra giá trị macro DEBUG và NDEBUG trong chương trình của mình. (Với một khẳng định trong quá trình khởi tạo thư viện của bạn

4

Câu hỏi hay, tôi luôn giả định rằng các nhà phát triển sử dụng thư viện của tôi sẽ liên kết đến phiên bản chính xác. ? cho công chúng Tại sao không nên cả debug của họ và phát hành các phiên bản liên kết với thư viện phát hành của bạn

Bất kể, tôi nhìn thấy một cách để làm điều này bằng cách xuất một số biểu tượng cho mỗi cấu hình:

//header: 
class DLLIMPEXP Dummy 
{ 
    static int x; 
    virtual void dummy(); 
} 
//cpp 
#ifdef DEBUG 
int Dummy::x = 0; 
void Dummy::dummy() 
{ 
} 
#endif 

Như bạn có thể xem, biểu tượng của bạn sẽ chỉ được xuất nếu mô đun của bạn được biên dịch trong DEBUG. Cố gắng liên kết với lib trong bản phát hành m ode từ mô-đun thứ ba sẽ dẫn đến lỗi liên kết. Bạn có thể có một cái gì đó tương tự cho trường hợp ngược lại.

Tôi không đề nghị bạn làm điều này mặc dù, tôi sẽ thay tài liệu hoặc chỉ phân phối phiên bản phát hành của mô-đun của tôi.

+0

Khá thú vị. Bạn đã cho tôi một ý tưởng: thêm hàm không được nội tuyến IsReleaseVersion() sẽ nằm trong thư viện. Và thêm vào kiểm tra nội tuyến xây dựng (sẽ được bao gồm trong phía ứng dụng) để kiểm tra phiên bản của nó. – Phong

+0

Tôi vừa chỉnh sửa câu hỏi để trả lời một số câu hỏi của bạn. Điều này sẽ kích hoạt lỗi liên kết chỉ khi người dùng cố gắng sử dụng biểu tượng đó trong mã của riêng mình. Hơn nữa, tôi muốn người dùng nhận được một thông điệp rõ ràng nói với họ "bạn không liên kết đến thư viện phù hợp". – Mourad

+0

@Mourad: bạn có thể đặt tên biểu tượng bị thiếu là PleaseUseReleaseVersionOfXxxLibrary, tương tự như vậy PleaseUseDebugVersionOfXxxLibrary. –

1

Có hai khía cạnh khác nhau ở đây:

  • vấn đề không tương thích
  • vấn đề hiệu suất

Nếu nó là một vấn đề về hiệu suất, sau đó lựa chọn vẫn còn nên họ, họ có thể muốn gỡ lỗi.

Nếu đó là vấn đề không tương thích, một điều đơn giản là thay đổi không gian tên cho phiên bản gỡ lỗi, để biểu tượng bị xáo trộn khác nhau.

#ifdef NDEBUG 
    namespace project { 
#else 
    namespace project { namespace debug { 
#endif 

// content 

#ifdef NDEBUG 
    } 
#else 
    } 
    using namespace debug; 
    } 
#endif 

Bằng cách làm tổ trong một không gian tên debug, bạn thay đổi mangling trong những biểu tượng (mặc dù, biên soạn-khôn ngoan, nó không thay đổi bất cứ điều gì). Điều này thực sự ngăn chặn liên kết một thư viện được biên soạn dựa trên phiên bản gỡ lỗi với phiên bản phát hành (và do đó giải quyết sự không tương thích sớm hơn thay vì gặp sự cố bí ẩn).

Tuy nhiên, tôi sẽ thúc giục bạn đặt trước một nhóm lớp học cụ thể (nặng).

Có thể, thông thường, để có thể cung cấp các giao diện tương thích ở cả chế độ Gỡ lỗi và Phát hành, để khách hàng có thể trao đổi nóng tại thời điểm tải.

0

Thêm mã này vào tiêu đề của lib của bạn

tên khác nhau với nhiều loại khác nhau

#ifndef _DLL 
// C runtime as dll 
# ifdef _DEBUG 
# pragma comment(lib, "MyLibD.lib") 
# else 
# pragma comment(lib, "MyLib.lib") 
# endif 
#else 
// C runtime statically 
# ifdef _DEBUG 
# pragma comment(lib, "MyLibSD.lib") 
# else 
# pragma comment(lib, "MyLibS.lib") 
# endif 
#endif 

con đường khác nhau với nhiều loại khác nhau

#ifndef _DLL 
// C runtime as dll 
# ifdef _DEBUG 
# pragma comment(lib, "debug/dynamic/MyLib.lib") 
# else 
# pragma comment(lib, "release/dynamic/MyLib.lib") 
# endif 
#else 
// C runtime statically 
# ifdef _DEBUG 
# pragma comment(lib, "debug/static/MyLib.lib") 
# else 
# pragma comment(lib, "debug/static/MyLib.lib") 
# endif 
#endif 

sau đó bạn chỉ cần thêm đường dẫn đến lib vào trình liên kết của bạn và bạn không còn nữa le để trộn nó lên.

+1

Điều này thường không được coi là thực hành tốt (chỉ định thư viện trong mã), nhưng đó là giải pháp vì vậy tôi sẽ không downvote . –

+0

Nếu bạn phát triển một lib tĩnh và không phải là một dll tôi sẽ luôn luôn prefere này. Có rất nhiều lợi thế và tránh được các lỗi mà tôi sẽ không quan tâm vì lý do triết học. – Totonga

Các vấn đề liên quan