Mieszanie C i C++

[ᕦ( ͡° ͜ʖ ͡°)ᕤ]

Zanim napiszę następną linijkę kodu, chciałbym wiedzieć - czy mieszanie C i C++ jest jakkolwiek akceptowalną praktyką? Z jednej strony zawsze używam char*, strcpy/strcat/strlen, printf, fopen, gardzę szablonami i overloaded operatorami, lecz z drugiej strony lubię czasem użyć std::unique_ptr, std::unordered_map lub jakichś std::sort czy innych.

Czy powinienem trzymać się jednego 'języka', czy można te dwa ze sobą mieszać?

 

@Sopelek997

[Pancake]

Teoretycznie nie powinno sie uzywac raw pointerow w c++ (albo smart pointery albo referencje). Strcpy/srtcat/strlen masz w std::stringu, unikniesz wszelkich problemow i bolaczek z zabawa z tablicami. Jesli uwazasz fopen za praktyczny to chyba nigdy nie korzystales z dogodnosci fstreamu. Co do templejtow... uzywasz void* i castujesz? Nie bez powodu w kazdym obiektowym jezyku sa templejty / "typy generyczne".

[Vesim]

Najlepiej zdecyduj czy chcesz pisac w obiektowym C czy C++, a template? One sa OP

#include <iostream>

template<std::uint8_t value>
struct byte {
    static inline bool check(std::uint8_t v)
    {
        return v == value;
    }
};
template<std::uint8_t value>
using b = byte<value>;

template<std::uint8_t value>
struct rnibble {
    static inline bool check(std::uint8_t v)
    {
        return (v & 0x0F) == value;
    }
};
template<std::uint8_t value>
using r = rnibble<value>;

template<std::uint8_t value>
struct lnibble {
    static inline bool check(std::uint8_t v)
    {
        return (v & 0xF0) == value;
    }
};
template<std::uint8_t value>
using l = lnibble<value>;

struct skip {
    static inline bool check(std::uint8_t v)
    {
        return true;
    }
};
using s = skip;

template<class Pattern, class... Tail>
struct pattern : pattern<Tail...> {
    static inline bool check(std::uint8_t* bytes)
    {
        return Pattern::check(*bytes) && pattern<Tail...>::check(bytes + 1); 
    }
};

template<class Pattern>
struct pattern<Pattern> {
    static inline bool check(std::uint8_t* bytes)
    {
        return Pattern::check(*bytes);
    }
};

template<class Pattern>
void* pattern_scan(void* address, std::size_t size)
{
    for (auto i = reinterpret_cast<std::uint8_t*>(address); i < address + size; ++i)
        if (Pattern::check(i)) 
        	return i;
        	
    return nullptr;
}

uint8_t mem[] = { 0x10, 0x10, 0x98, 0x31, 0x5F };

int main()
{
	using test_pattern = pattern<b<0x10>, l<0x10>, s, s, r<0x0F>>;
	std::cout << pattern_scan<test_pattern>(mem, 5) << std::endl;
	    
    using test_pattern2 = pattern<byte<0x10>, lnibble<0x10>, skip, skip, rnibble<0x0F>>;
    std::cout << pattern_scan<test_pattern2>(mem, 5) << std::endl;
    
    return 0;
}

https://goo.gl/KxxSfR

wydajniejszego pattern scannera chyba nie zrobisz

[Pancake]

Variadic templates Najbardziej fajoski ficzur w c++11

[Sopelek997]

W dzisiejszych czasach praktycznie wszystko co mógłbyś chcieć napisać 'w stylu C' (bo funkcje takie jak qsort, fabs, bsearch na przykład są zgodne ze standardem C++ i dostępne w odpowiednich bibliotekach, tylko pytanie czy to jest dobry wybór?) da się kilka razy lepiej napisać korzystając z ficzerów C++.

 

char*, strcpy/strcat/strlen

 

std::string + algorithm

 

printf

 

to akurat ma swoje zalety i przewagę nad strumieniami. Czasem się przydaje, nie widzę nic złego w odpowiednim korzystaniu z tego.

 

fopen

 

fstream

 

gardzę szablonami

To źle, bo to potężne narzędzie. Wszystkie klasy z std:: jakie wymieniłeś z tego korzystają.

 

overloaded operatorami

 

To jest kwestia opinii. Operator overloading to nic innego jak danie możliwości użycia innej składni to wywoływania metod/funkcji. Nie wpływa na funkcjonalność programu.

 

 

 

Teoretycznie nie powinno sie uzywac raw pointerow w c++ (albo smart pointery albo referencje).

 

raw pointery nie są złem wcielonym, można ich bez problemu używać w miejscach (a nawet wskazane jest. Tutaj wrapper jest bez sensu) gdzie nie jest się właścicielem obiektu i nie może się w żadnym wypadku nim być (tzn jest się jakby obserwatorem)

[Pancake]

Dlatego napisałem teoretycznie - ilość naleciałości w C++ ze starego C powoduje ze raw pointery nigdy nie odejdą do lamusa

[MistrzMaster]

@Sopelek997

można ich bez problemu używać w miejscach (a nawet wskazane jest. Tutaj wrapper jest bez sensu) gdzie nie jest się właścicielem obiektu i nie może się w żadnym wypadku nim być (tzn jest się jakby obserwatorem)

 

Dodam(jeżeli ktoś nie wie) że do tego też został stworzony "smart pointer", tzn "weak_ptr", tylko że jeśli chcemy coś z niego odczytać, musimy najpierw użyć lock(który tworzy shared_ptr, pośrednio dzięki temu mamy pewność, że ta zawartość na którą wskazuje ten wskaźnik nie została już usunięta, a jeśli została to i tak nie wywali nam programu, co stałoby się gdybyśmy używali raw pointera)

[Sopelek997]

Dodam(jeżeli ktoś nie wie) że do tego też został stworzony "smart pointer", tzn "weak_ptr", tylko że jeśli chcemy coś z niego odczytać, musimy najpierw użyć lock(który tworzy shared_ptr, pośrednio dzięki temu mamy pewność, że ta zawartość na którą wskazuje ten wskaźnik nie została już usunięta, a jeśli została to i tak nie wywali nam programu, co stałoby się gdybyśmy używali raw pointera)

 

To właśnie to nie jest do końca to o co mi chodzi. Bo to wymaga tego, że "object is managed by std::shared_ptr". A my właśnie tego nie chcemy.

 

Osobiście jestem wielkim przeciwnikiem używania std::shared_ptr, bo w 99.9% przypadków jest on używany jedynie z lenistwa. Prawie wszędzie da się wydzielić dokładnie jedno miejsce gdzie jest/mógłby być taki obiekt zaalokowany, a wtedy wystarczy std::unique_ptr do jego trzymania i raw pointery w innych miejscach