Używanie/mieszanie C w kodzie C ++?

Powtarzam im, że jeśli wiesz, co robisz, usuniesz nowe i zwolnisz przydział malloc, C nie stanowi problemu.

Prawda; jeśli jesteś wyjątkowo ostrożny i upewniasz się, że ręcznie posprzątałeś, nie stanowi to problemu. Ale czy naprawdę masz czas na co? Każde wywołanie

new

może wyrzucić

std :: bad_alloc

.

Jest zawsze

czy łapiesz

każdy

wyjątek, który można zgłosić i ręcznie wyczyścić wszelkie zasoby?
Zaryzykowałbym sugestię, że odpowiedź na to pytanie brzmi „nie”, ponieważ pisanie tego rodzaju kodu jest bardzo żmudne i trudno mieć absolutną pewność, że napisany w ten sposób kod jest poprawny, nawet w przypadku rzadkich błędów.
Jeśli odpowiedź brzmi tak, dlaczego spędzasz tyle czasu na martwieniu się o zarządzanie zasobami? Idiomy C ++, takie jak zarządzanie zasobami ograniczone zakresem (SBRM; bardziej znane jako pozyskiwanie zasobów to inicjalizacja (RAII)) i biblioteki, takie jak biblioteka szablonów standardowych, istnieją, aby pomóc Ci łatwiej pisać poprawny kod. Po co robić coś trudnego, gdy tego nie potrzebujesz?

Czy należy TYLKO używać 100% C ++ podczas programowania w C ++?

Tak, chociaż jeśli istnieje biblioteka C, która robi to, co chcesz, lub jeśli masz starszy kod C, którego chcesz użyć, możesz oczywiście użyć tego kodu; tylko bądź ostrożny. Często najczystszym sposobem na współdziałanie z kodem C jest napisanie wokół niego otoki C ++.

Jestem głęboko przekonany, że twoje pytanie nie ma w ogóle nic wspólnego z C lub C ++. Twoje pytanie dotyczy handlu z wątpliwą wydajnością ze względu na bezpieczeństwo. Tak, C mógłby być bardziej wydajny. Ale o ile bardziej skuteczne? A ile za to zapłacisz? Musisz odpowiedzieć na te pytania. W większości przypadków narzut string vs const char * nie jest zauważalny. Jeśli tworzysz aplikację o niezwykle krytycznym znaczeniu dla wydajności, dlaczego nie zakodować jej w C w pierwszej kolejności?

Jestem autentycznie zaskoczony polaryzacją w odpowiedziach i komentarzach do nich.
Moim zdaniem odpowiedź jest dość prosta:

Pisząc projekt w C ++, używaj C ++, unikaj C (i rodziny) i trzymaj się biblioteki standardowej i STL. Zapewnij jednolity interfejs C ++ (w końcu to projekt C ++!)
Korzystając z zewnętrznego projektu w C, który okazuje się być napisany w C, możesz go oczywiście użyć. (patrz przykłady poniżej)

Dwa proste przykłady:

• Napisz program/bibliotekę w C ++, która wykonuje obliczenia naukowe. Zdecydowanie użyłbym GSL (GNU Scientific Library) i jest napisana w C. Jest tylko kilka zastrzeżeń (takich jak wyspecjalizowane inicjowanie i darmowe funkcje dla określonych struktur i funkcji w GSL), które można połknąć w

  std :: unique_ptr

  typedef. Występuje również problem obsługi błędów: sprawdzanie kodów błędów można w razie potrzeby/chęci przenieść do mechanizmu wyjątków lub można przechowywać kody błędów zawarte w funkcjach obliczeniowych. GSL ma sposób na dostosowanie obsługi błędów, myślę, że niektóre inne biblioteki C mają tę funkcjonalność.
• Pisanie programu w C ++ przy użyciu Win32 API, które jest okropnie oparte na C. Mówię o lekkim używaniu API, takim jak czytanie plików w katalogu, sprawdzanie, czy plik istnieje i tak dalej, a nie ciężkie GDI + lub inne rzeczy. Lubię pakować wszystkie funkcje C, które zapewnia Win32 API, w ładne funkcje w stylu C ++, prawdopodobnie z niezbędnymi wyjątkami i zwracaniem

  std :: string

  zamiast przekazywania

  char * <!-- bufor kodu--> jako argument. 

Rozumiem, że oba przykłady są całkiem odpowiednie ... małe ... ale wydaje mi się, że wyrażają one dość ogólną ideę.

Tak, mieszanie C i C ++ jest złe, żaden powód nie ma nic wspólnego z wydajnością ani bezpieczeństwem:
To zły powód do konserwacji:

* Programista C ++ oczekuje, że cały kod będzie zachowywał się jak C ++.

* programista C oczekuje, że cały kod będzie zachowywał się jak C.
Więc mieszając C ++ i C, naruszasz oczekiwania obu programistów co do tego, jak powinno działać.

Najlepsze pytanie brzmi: po co używać C? Wydajność? Po pierwsze, uważam, że nie ma mierzalnej różnicy w wydajności programu o tej samej funkcji. Po drugie, będziesz musiał sprofilować i udowodnić, że C ++ działa wolniej w twoim konkretnym przypadku. Po trzecie, rezygnujesz z ogromnej ilości bezpieczeństwa aplikacji, używając C zamiast C ++.

Odpowiedź oczywiście brzmi: wszystko zależy od okoliczności.
Zazwyczaj chcesz uniknąć pomieszania rzeczy, które mogą powodować zamieszanie, co może później prowadzić do trudnych do znalezienia błędów. To, że „wiesz, co robisz” nie oznacza, że ​​następna osoba, która dotknie Twojego kodu, będzie wiedziała, co robiłeś. Jeśli tworzysz kod, z którego będziesz korzystać tylko Ty, to

prawdopodobnie

ok, ale rzadko.
Używanie C do poprawy wydajności jest w porządku, jeśli jesteś ostrożny. Ale powinieneś to zrobić tylko wtedy, gdy potrzebujesz wydajności. Przedwczesna optymalizacja niskiego poziomu to dzieło diabła.
Bardzo rzadko zdarza się, że użycie funkcji char * zamiast std :: string daje zauważalną korzyść w zakresie wydajności i jest warte kłopotów z zarządzaniem pamięcią tylko wtedy, gdy jest to naprawdę.

ponowne przemyślenie argumentu o std :: string versus char *.
std :: string nie będzie wolniejszy niż char * (dla char * heap); wiele implementacji jest znacznie szybszych, ponieważ używają prywatnej puli pamięci. W każdym razie niezawodność std :: string znacznie przewyższa (mało prawdopodobne) trafienie perf

Czy używanie C w C ++ jest złe?

chociaż subiektywne pytanie: moim zdaniem bardzo uważaj, aby unikać używania c w programach c ++.

Wiele osób powiedziało mi, że używanie C w C ++ jest złe, ponieważ nie jest tak bezpieczne i wymaga większego zarządzania pamięcią. Powtarzam im, że jeśli wiesz, co robisz, usuniesz nowe i zwolnisz przydział malloc, C nie stanowi problemu.

ponownie wprowadzasz wady i niebezpieczeństwa, które c ++ został zaprojektowany, aby przezwyciężyć, i nie jest tak, jak to się robi w programach c ++.
Zwykle używam kodu sprawdzającego/odrzucającego/przepisującego, który wprowadza bazy kodów, np. „C z funkcjami c ++” lub „c ++ z funkcjami c”. Posunąłem się nawet do zmiany malloc, free itp., Aby potwierdzić w głównych przestrzeniach nazw (między innymi).

Obecnie jestem na forum, na którym istnieje kontrowersja wokół std :: string kontra char *. Niektórzy twierdzą, że przydzielanie prostego bloku pamięci char * jest bardziej wydajne i tak długo, jak go zwolnisz, wszystko w porządku. Z drugiej strony są ludzie, którzy twierdzą, że std :: string jest lepszy, ponieważ nie ma zarządzania pamięcią, ale jest mniej wydajny.

istnieje więcej opcji reprezentacji łańcucha w języku c ++ niż std :: string.
moim zdaniem całkowicie dopuszczalne jest tworzenie nowej klasy będącej stringiem i służącej do określonego celu lub następującą po dodatkowych kontraktach (w razie potrzeby). częścią kontraktów takich reprezentacji ciągów jest (oczywiście), że zarządzają one własnymi zasobami za pomocą

new []/delete []

podczas używania sterty.
jeśli wydajność jest tak ważna, a

std :: string

nie jest idealnym rozwiązaniem dla konkretnego zadania, to c ++ jest wystarczająco potężny, aby wyrazić swój zamiar w tych konkretnych przypadkach, tworząc wyspecjalizowany interfejs w języku c ++. istnieje wiele przypadków, w których jest to dopuszczalne (IMO), ale nie zawsze warte czasu. w każdym razie łatwiej jest nim zarządzać niż integrować c idiomy/style/dangers z programami C ++.

Więc główne pytanie brzmi: czy mieszanie C/C ++ jest złe? Czy powinieneś używać TYLKO 100% C ++ podczas programowania w C ++?

najlepiej jest tworzyć rozwiązania obiektów wielokrotnego użytku do własnych potrzeb. niebezpieczeństwa w powyższym przykładzie można całkowicie hermetyzować (jeśli ta optymalizacja jest naprawdę warta czasu) i napisać przy użyciu idiomów języka C ++ bez poświęcania wydajności i lepszej konserwacji.

W konkretnym przypadku

string

versus

const char *

, powinieneś użyć samego

const char *

dla wszystkich zmiennych zawierających

stałe łańcuchowe

(i

tylko

stałe typu string), konwertując je na

string

tylko wtedy, gdy przechodzisz do interfejsu API, który wymaga

string

. Robienie tego konsekwentnie może wyeliminować ogromną liczbę globalnych konstruktorów, nie powoduje problemów z alokacją pamięci (ponieważ stałe łańcuchowe są stałe, stałe dane), a IMO faktycznie sprawia, że ​​kod jest bardziej przejrzysty - widzisz

const char *

, wiesz, że będzie to stała łańcuchowa.

Jeśli mówisz o technikach, ostrożnie powiedziałbym, że wykonanie wszystkich powyższych czynności jest w porządku.
Pisanie programów w C ++ przy użyciu technik organizacji programów w stylu C może prowadzić do wielu problemów z utrzymywalnością. Ogólnie rzecz biorąc, programista ignoruje wiele zalet, jakie zapewnia język zorientowany obiektowo. Tylko dlatego, że większość składni C jest poprawna w C ++ i wiele metod kodowania jest przenośnych, nie oznacza to, że powinieneś robić je w C ++.
Jednak korzystanie z funkcji C i innych rzeczy nie stanowi problemu, o ile używasz ich ostrożnie. W niektórych przypadkach musisz.

Prosta odpowiedź brzmi:

profil

; określić, co działa najlepiej w

Twój przypadek

i używaj go mądrze!

Cóż, znalazłem się w dziwnej sytuacji. Pracuję na systemie, który powinien być w C ++ (używany jest kompilator C ++ i używany jest termin C ++), ale wszystko jest napisane w C. Jest to bardzo frustrujące, ponieważ dochodzi do tego, że Muszę używać „udowodnienia” C ++ lepiej niż C, chociaż programujemy w C ++. To było prawdziwe piekło, kiedy wprowadziłem std :: string. Moim zdaniem wszystko zaczyna być teraz zagracane (mieszanie C i C ++). Istnieją rzadkie przypadki obsługi błędów. W rzeczywistości myślę, że mogę policzyć 3 ogólnosystemowe instrukcje try-catch. Kod jest niechlujny, wycieki pamięci są zauważalne, a znalezienie błędu to igła w stogu siana. Istnieją setki wierszy kodu, które można zastąpić funkcjami C ++. Powiedziałbym, że pisanie kodu jest wydajniejsze, czystsze i łatwiejsze do zrozumienia.
Z mojego doświadczenia wynika, że ​​tak, oczywiście można mieszać C i C ++. Możesz robić, co chcesz, ale utrzymanie, debugowanie i ustalenie, co się dzieje, staje się wyzwaniem. Łatwo jest powiedzieć, że zamierzasz wyczyścić alokacje pamięci, ale być może ktoś inny używa Twojego kodu i tego nie robi. Może zapomniałeś o tym i straciłeś godziny na szukanie głupich błędów, zamiast wykorzystać ten czas na coś produktywnego. Myślę, że nawet nie powinno być kłótni. Kiedy robisz C ++, zrób C ++. Kiedy robisz C, zrób C.