kicad-developers team mailing list archive

[Seth Hillbrand <seth@xxxxxxxxxxxxx>]

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> wrote: 
> Some answers below:
> 
> On 20 Jun 2020, at 06:39, <pjmonty@xxxxxxx> <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
> 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
> 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
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp