search

zabealbe / can-cicd

Automate the managment of your CAN BUS
Other
5 stars 3 forks source link

Id-Generator guards collisions #34

Closed simoneruffini closed 3 years ago

simoneruffini commented 3 years ago

When two networks are used by and application (let's say ECU) they use two heders-gen headers so every item/name that has the same name is potentially a problem. One of those is the preguard on header files:

#ifndef IDS_H
#define IDS_H

In this status I cannot use the id's of primary and secondary bcause one of them will not be included by the compiler.

Solution: Avoid same name generation on different files, prefix them with the name of the network.

This is not only for this instance but for every name, so maybe ID's to must be prefixed with the network name to avoid collisions

zabealbe commented 3 years ago

Probably the best solution is to prefix the c ids with the network name, thanks c for your inexistent namespaces.

zabealbe commented 3 years ago

An alternative is to use the network merge runtime feature to create a single network from two different ones, however this will return an error if two messages with different properties are present in two different networks.

bonnee commented 3 years ago

Instead of using ifndefs we can just use #pragma once and be done with it. Still, it's better if the filenames reflect the network's name

simoneruffini commented 3 years ago

I'll just prefix every generated name with a short version of the network name so we are sure the will be no collisions.

P.S. namespaces are for pussies

zabealbe commented 3 years ago

fixed with 5fb437bb0830a3ad963ae97b3cd5e471a96f0bde

simoneruffini commented 3 years ago

Thanks. But after some other thinking since C does not have the concept of namespaces (because all functions etc... should be prefixed with the module name), me and @Bonnee think that is better that every variable that will have a define and every function generated with flatcc should be prefixed with the netwrok name.

For example in bms-hv we could have two identical messages (HV_VOLATAGES) both for can1 and for carrellino. This would mean that if the same serialization/deserialization messages appear in flatcc than a compile time error would occur.

zabealbe commented 3 years ago

Ok, you can open a new issue explaining features you would like to see