kicad-developers team mailing list archive

["Bevan Weiss" <bevan.weiss@xxxxxxxxx>]

I would argue the opposite to this statement:

there is almost never a reason to prefer the explicit sizes

When it comes to code, all assumptions should be documented.  If just writing ‘int’ there are clearly assumptions made (around how big an ‘int’ actually is), which may not hold true across different platforms or different compilers.

 

If the size really doesn’t matter as much as something else, like speed… then there are typedefs available for that also.  e.g. ‘int_fast32_t’, which is guaranteed to be AT LEAST 32-bits long, but may be faster if it will aid performance (compiler dependent of course).  One obvious benefit of this is that it aids the reader in understanding that speed is more important here than the exact bit-width…

 

I can’t see any reason to avoid the use of explicitly-sized types in the code.

 

As a Stackoverflow reference for whether we should or shouldn’t

https://stackoverflow.com/questions/9834747/reasons-to-use-or-not-stdint

stdint being the C99 predecessor to the C++11 cstdint (where it just moves a bunch of pre-existing C header files into C++ std namespace)

 

As noted in the Stackoverflow:

Reference: MISRA-C:2004 rule 6.3."typedefs that indicate size and signedness shall be used in place of the basic types".

 

So if looking at ‘code quality’, there is an internationally accepted guideline that indicates good quality code uses the stdint/cstdint defined types (in place of the ‘basic types’).

 

 

Regards,

Bevan Weiss

 

 

From: Kicad-developers <kicad-developers-bounces+bevan.weiss=gmail.com@xxxxxxxxxxxxxxxxxxx> On Behalf Of Seth Hillbrand
Sent: 21 June 2020 12:53
To: kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] [Proposed Feature] GerbView - Mapping Gerbers w Altium extensions to KiCad PCB layers

 

One of the primary reasons that large software projects use char/int/long instead of explicit integer types is that they are almost always faster than utilizing explicit types.  The compiler and underlying architectures are strongly optimized to the most common types, particularly int, which is pretty much guaranteed to be the fastest way to store and use any integer.  Unless you are flipping bits or optimizing for memory over speed (sometimes the case in embedded), there is almost never a reason to prefer the explicit sizes.

The second reason (particularly for KiCad) is that explicit integer sizes only joined the C++ standard in C++11.  KiCad moved to C++11 in 2016, so all of the code written from 1992-2016 did not have access to them. 

We currently use them in KiCad for exactly these purposes:

- bitmasks and bit-limited operations (hashes, morton codes)
- structured file formats
- u/int64_t when we need to ensure we have 64 bits to avoid overflow when combining ints

As I write this, I am noticing that we do have a fair number of explicit sized integers in contributed code modules (3d-viewer and altium importer specifically).  But we generally avoid them in the core codebase.  I don't think anyone would raise a fuss if you contributed code that contained them but I'd definitely want to know why you are specifying a size.

Best-
Seth

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

 

On 2020-06-20 14:41, Jon Evans wrote:

I have also wondered why many large C++ projects, including KiCad, don't use the explicit integer types. The embedded codebases I've used always do. I've never brought it up before, so I'm also curious to hear if this is just a legacy decision or if there is a reason. 

 

-Jon 

On Sat, Jun 20, 2020, 16:40 Jeff Young <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx> > wrote:

Some answers below:





On 20 Jun 2020, at 06:39, <pjmonty@xxxxxxx <mailto:pjmonty@xxxxxxx> > <pjmonty@xxxxxxx <mailto:pjmonty@xxxxxxx> > wrote:

 

I wanted to add a feature to GerbView that relates to exporting a KiCad PCB file from loaded Gerbers.  I often use "Export to PCBNew..." to recreate boards from Gerbers, and many of them involve Gerbers generated by Protel, the progenitor to Altium.  Since Altium (and Protel) use specific file extensions for specfic layers, it's tedious to manually have to set each Gerber layer to the equivalent KiCad PCB layer.  Every time I use "Export to PCBNew..." I keep thinking how handy it would be if GerbView could recognize the file extensions and offer to map them to the appropriate KiCad PCB layers.  

 

So, I've created a proof of concept that compiles into my local copy of GerbView, and I have a couple of questions: 

 

1 - I made my changes directly in the file select_layers_to_pcb.cpp by adding a new member function to it.  The new function is called from and used within "initDialog()". Is it preferable to create a whole new source file/object for containing the new function (or functions if more are needed), or is it okay to add it directly into this existing file?  Or is this the sort of question best answered when someone is reviewing a submission?

 

Add it directly.





 

2 - In the KiCad source code, I see a lot of text using the macro "_" to provide string translations, but there are also cases where the "wxT" macro (which I don't believe handles translations) is used instead.  Is there a rule of thumb for when to use "_", or is best to just always use it?

 

The translation framework can only handle 7-bit ASCII.  So any characters above that must be broken out and used with the "wxT" macro (as well as anything you don't want translated, such as file tokens or the like).





 

 

3 - The source files I've looked at seem to use "ii" as the default integer index in loops, versus the more traditional "i".  Is this a KiCad thing, or something specific to whatever developer(s) worked in the code I've looked at?

 

It's pretty random over a larger sample of code.  Use either.





 

4 - The source files I've looked at only use the generic "int" as opposed to using more specific types such as "int32_t" or "int8_t".  Is the use of "stdint.h" not allowed/not encouraged?

 

I'll let someone else field this.

 

Cheers,

Jeff.





 

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx> 
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx> 
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

 

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx> 
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp