2010-05-24 35 views
6

Tôi đang thực hiện một số phép tái cấu trúc dự án Delphi của mình. Tôi muốn có thể thực hiện thay đổi, sau đó xem tất cả các địa điểm trong dự án bị phá vỡ do thay đổi đó. Tương tự như cách Eclipse liệt kê tất cả các lỗi biên dịch cho một dự án (trong Java).Tìm tất cả các lỗi biên dịch trong dự án Delphi

Trong Delphi, tôi có thể thực hiện thay đổi, sau đó biên dịch lại dự án của tôi, nhưng trình biên dịch dừng lại khi tìm thấy Đơn vị đầu tiên không biên dịch. Tôi phải sửa đơn vị đó, biên dịch lại, sau đó sẽ hiển thị cho tôi lỗi tiếp theo, v.v.

Tôi muốn có thể xem lỗi biên dịch trong dự án cùng một lúc. Sau đó, tôi có thể quyết định xem thay đổi có đáng làm hay không. Ví dụ, nếu thay đổi sẽ yêu cầu sửa chữa bằng tay 50 tệp nguồn riêng biệt, nó không đáng làm. Nhưng nếu nó chỉ phá vỡ 2 tập tin thì đó là một thay đổi dễ dàng để thực hiện.

Có cách nào để thực hiện việc này trong Delphi không? Tôi có thể yêu cầu trình biên dịch tiếp tục ngay cả sau khi tìm một Đơn vị không biên dịch không?

Tôi đang sử dụng Delphi 2010

Trả lời

5

Các đơn vị Delphi, dưới dạng tính năng mô đun, là khái niệm ở mức tương tự với các lọ Java hoặc các hội đồng .NET; chúng biên dịch thành các tệp riêng lẻ. Trong cả Java lẫn .NET, bạn có thể biên dịch các mô-đun phụ thuộc khi bạn có lỗi biên dịch trong mô-đun được tham chiếu.

Lý do chúng chi tiết hơn so với hội đồng .NET ., nợ tiền sử của chúng. Chúng được thiết kế một phần xung quanh kiến ​​trúc x86 phân đoạn; dữ liệu được liên kết với bất kỳ một đơn vị nào không được lớn hơn 64KB. Tương tự như vậy, các đơn vị phục vụ như một bộ phận tự nhiên giữa mã gần và mã xa. Nếu bạn đã quen thuộc với x86 16 bit, bạn sẽ biết rằng con trỏ đến dữ liệu xa cần một giá trị cho phân đoạn cũng như độ lệch, trong khi gần dữ liệu chỉ cần bù đắp. Gọi gần mã cũng nhanh hơn gọi mã xa. Các chương trình cũng nhỏ hơn và ít phức tạp hơn; đơn vị là mức chi tiết hợp lý của mô-đun cho toàn bộ hành vi của hệ thống con. Đây là trường hợp ít hơn nhiều trong ngày hôm nay.

+0

Thú vị. Nói cách khác, nếu tôi có tất cả các lớp học trong một Đơn vị lớn, thay vì đặt mỗi lớp vào một Đơn vị riêng biệt, tôi có thể thấy tất cả các lỗi trong Đơn vị cùng một lúc. Như bạn đã gợi ý, điều này không thực sự thực tế đối với kích thước của các dự án mà chúng tôi làm hôm nay (đã bao giờ?). Tôi chắc chắn chưa bao giờ thấy một cái lọ Java có toàn bộ nguồn của nó trong một tệp .java! – awmross

+0

@awmross: Thú vị, nhưng đồng bằng sai. Eclipse có thể hiển thị tất cả các lỗi trong tất cả các tệp Java. Delphi rõ ràng có thể làm điều đó quá, ít nhất là có lỗi trong phần 'thực hiện' chỉ. Ngay cả các lỗi trong phần 'giao diện' cũng không cản trở việc biên dịch các đơn vị không phụ thuộc vào đơn vị sai. Lý do thực sự có thể là các nhà phát triển Delphi không thấy tính năng này đủ hữu ích. – maaartinus

+0

@maaartinus - Tôi không nghĩ đó là một câu hỏi về việc nó không được xem là hữu ích, nhiều hơn rằng nó được xem là đang sử dụng * ít hơn *. ví dụ. bất kỳ C# deveoper nào sẽ cho bạn biết rằng khi bạn có một lỗi biên dịch trong một assembly trong một giải pháp mà thường dẫn đến một chuỗi các lỗi do kết quả của assembly đó không có sẵn. Vì vậy, bạn bắt đầu với hơn 200 lỗi được sửa, nhưng nếu bạn sửa lỗi biên dịch đầu tiên, ** tất cả ** 200 lỗi được giải quyết. Vậy những dấu hiệu có ý nghĩa thực sự được cung cấp bởi những lỗi 200+ -1 đó? Dịp khi> 1 lỗi là hữu ích có thể tồn tại, nhưng rất ít và xa giữa. – Deltics

5

Không có cách nào để làm điều đó với trình biên dịch Delphi, nhưng nếu bạn đang cân nhắc thực hiện một thay đổi phá vỡ một số phần của giao diện công cộng của một đơn vị, bạn có thể sử dụng các công cụ refactoring rằng đi kèm với IDE để tìm tất cả các tham chiếu đến bất kỳ thứ gì bạn sắp thay đổi trước khi bạn thay đổi nó, nó sẽ cung cấp cho bạn thông tin mà bạn đang tìm kiếm.

+1

Tôi rất thích sử dụng các công cụ tái cấu trúc cho việc này. Thật không may họ không làm việc trên các dự án khác nhau trong cùng một nhóm dự án. Họ tái cấu trúc trong cùng một Dự án, nhưng bất kỳ Đơn vị nào trong các dự án khác sử dụng Đơn vị đó sẽ không bị thay đổi. – awmross

+0

@awmross: Ah. Bạn đã không đề cập đến các nhóm * dự án * trong câu hỏi của bạn. –

+1

Tôi đang sử dụng D2009 và sử dụng Refactorings. Theo như tôi có thể nói họ đang làm việc trên các dự án trong một nhóm dự án (miễn là bạn có nhóm mở tất nhiên). Khi tôi đổi tên một lớp hoặc phương thức trong một đơn vị chia sẻ, tất cả các tham chiếu của nó được thay đổi trong tất cả các dự án. Phải thừa nhận rằng, tôi chủ yếu sử dụng "đổi tên" refactorings ... Không biết về những người khác. –

0

Trình biên dịch Delphi đã được cố gắng để biên dịch càng nhiều càng tốt.
Thật không may, rất thường xuyên, một lỗi là đủ quan trọng để ngăn chặn trình biên dịch để di chuyển qua các lỗi vì nó không thể làm cho một giả định như những gì mã nên được nó nếu được compilable.

Hơn nữa, rất thường xuyên, lỗi mà trình biên dịch có thể cung cấp sau khi lỗi 1 gặp phải không đáng tin cậy và thậm chí có thể biến mất sau khi lỗi thứ nhất đã được sửa. (được chứng kiến ​​bởi tất cả các dòng nguệch ngoạc màu đỏ xuất hiện và biến mất khi bạn nhập)

Tuy nhiên trình biên dịch cung cấp tất cả các gợi ý và cảnh báo (được gọi là lỗi cho một số trình biên dịch khác).

+1

Tôi không chắc chắn điều này là không thể, xem xét các ngôn ngữ khác quản lý để làm điều đó. Có lẽ có một cái gì đó về Delphi (ngôn ngữ) mà làm cho nó không thể xây dựng một trình biên dịch mà thực hiện điều này. – awmross

+0

Delphi có một trình biên dịch đơn. Đây là lý do tại sao nó quá nhanh, nhưng cũng là lý do tại sao một số lỗi chỉ là thiết bị đầu cuối. Như tôi đã nói, nó có thể trong một số trường hợp tìm thấy nhiều hơn 1 lỗi. –

0

Bạn có thể sử dụng Ctrl-Shift-Enter để xem tất cả các lần xuất hiện của biến, thuộc tính, phương thức hoặc bất kỳ hiện tại nào nằm dưới con trỏ. Với thông tin đó, bạn có thể quyết định thực hiện các thay đổi của mình hay không.

Than ôi, với phiên bản hiện tại, tính năng này không hoạt động đáng tin cậy như thường lệ.

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