As a year-long C# programmer i got used to it's way of namespacing and wonder if there is a chance or way to have something similar in Arduino - if not hardcoded then maybe through conventions...
See... in C# libraries are (basically) written in a hirachical order. For example is Console.writeline() part of "System.IO". As is File() and other IO stuff. Window.alert() (showing a messagebox) is in "System.Windows" and so on.
As for arduino i would like to see something similar. My proposal would be to implement something like:
Core
- IO
-- Serial
--- Hardware
--- Software
-- Analog
-- Digital
- Math
- Random
- Time
Libraries
- LCD
-- LiquidCrystal
- EEPROM
- Physical
-- Stepper
-- Servo
-- Motor
- "My own"
-- "stuff"
...
With such a namespace system in Place library programmers could finally end up having similar conventions for naming classes and functions and the user would have ways to identify and find certain code.
Of course this is in some aspect overfluent, yet i think that the benefits of this would lie in the code enforced simplification and harmonization of libraries or rather their interface.
Also it would be possible to make the IDE make a list of libraries and to include the libs needed by the namespaces included...
It is possible to do so, you would have to rewrite some of the libraries (if not all). C++ allows for namespaces.
The problem I find with this is that you will be linking too much code at compile time. There's no point to link to, say, the serial library if you are not using it. That makes your binary bigger than what it should be.
I thought about the linking thing, and from what i know you can link as much as you want - if the functions arent used the linking wont happen.. and anyway. I think it'd be doable to not link Core.IO.Serial if you only use Core.IO.Digital (for example). I even think that if Arduino would go this way linking could be faster (as only things are linked you really use) as well as maybe memory saving..
Also one benefit - in my opinion, could be that Libraries, Core and 3rd Party, are possible to be 'written' according to the namespaces. This would possibly lead to more files, but to files which are smaller and more easily editable/patchable
I am not sure I follow you here. Perhaps the concept of namespace is different in C# as it is from C++.
You will be doing stuff like:
#include "WProgram"
using namespace digital;
using namespace serial;
// more code
I don't see how this would be any different from the current system, other than having the ability to do things like digital::digitalWrite(2, LOW); which can get confusing at times, and given that in digital there are three main functions, using digital::function() can be done easier by just adding the namespace and then just calling function() directly.
in C# you wouldnt use the #include statement... think of the 'using' thing as a way to tell the compiler which Library to use instead of only which namespace.
For example:
using Core.IO.digital;
using Core.IO.Serial.Hardware;
using Libraries.Expanders.TLC8574;
Would tell the compiler to read the hardwareserial.cpp/.h, Print.c/.h as well as wiring_digital.c/.h (not wiring_analog.c/.h) as well as some fictional Library i have in my Library folder.
One major advantage here would be, for me at least, that you could have several files in your library folder with the same name wich is nice when trying to write a new version of a ib or testing something.
I know this is a very straight forward idea, prone to be ignored anyway, but if IDE and using statements could be connected the way i have in mind (and certainly havent made clear in my text... i know me) then this would be some major evolution...
The problem is, as it is, the environment uses C with some libraries (such as hardware serial) written in C++. You must then abide to the syntax of these languages and cannot create your own. C# is a language that is compiled to bytecode and run inside a virtual machine, much like Java is (that is pretty much how all .NET languages work). C/C++ do not work like that, they are compiled into machine code, and binaries are run according to the platform, they are given a stack and a heap, and manage these by themselves. There's no garbage fairy in C/C++, you must do your own cleanup all the time, unlike other languages.
The using statement in C++ tells the compiler which namespace to use:
#include <iostream>
using std::cout; // use cout function from namespace std
void main(){
cout << "Hello World\n";
}
Which can be written:
#include <iostream>
using namespace std; // include entire namespace
void main(){
cout << "Hello World\n";
}
All those snippets do the same thing, prints "Hello World" to the screen and it exits. From this example, I hope you can see how C++ namespaces work. If you see an advantage over the current way of doing things now, go for it. I started a project of porting all C++ libraries to C because I find them to be badly written (the old servo library serves as an example of that). So there, hope this helps.
i'm not quite sure we talk about the same thing.
See, the IDE(!) uses not exactly the AVR-C that could be written by hand and uploaded with other means, we have setup() and loop() instead of main(), certain core libraries are included by default and so on. So we already use a derived version of AVR-C.
My suggestion was to add another change to this by adding 'namespaces'.
Namespaces, as they are already used in C++ might be the wrong name as they conjure up a certain image that is not what i have primarily in mind.
My 'Hirachy' (to use an other name) would serve the purpose of #include but with the big advantage of being structured.
The current code converter of the ide, turning setup(), loop() and so into 'real' AVR-C could then sort out whats behind the using statements and include the appropiate libraries at compile time into the generated code.
With having this 'hirachy' at hand the programmer would have a far superior way of telling the linker what to use and what not - as of today, from what i know, hardwareserial is linked always, no matter if you need it or not - as are other libraries.
So.. this 'hirachy' would be a major task for implementation as someone would have to define what would be essentially needed to build a program (and hence had to go into 'Core' - and what is needed for Core.IO.Serial.Hardware (e.g.)) and how the current core libraries had to be split up to work.
Essential would also be that the current syntax would still have to be available, but i think that once this 'hirachy' would be in place many users would like/love to use it as it would give especially beginners a whole new experience in coding and others the feeling of having a structured framework..
create a new file with the first line being #include "WProgram.h"
code.c
// stuff in code.c
#include "WProgram.h"
append code.c with whatever you had in code.pde
// stuff in code.c
#include "WProgram.h"
// stuff that was in code.pde
append code.c with main.cxx, which is found under hardware/cores/arduino
// stuff in code.c
#include "WProgram.h"
// stuff that was in code.pde
int main(void)
{
init();
setup();
for (;;)
loop();
return 0;
}
compile and link to core library and whatever other libraries were used by means of avr-gcc/avr-g++, which places you at using a C/C++ compiler.
For details, check the Makefile under hardware/cores/arduino
In other words, you are falling back to C/C++ code in the end, the IDE just hides away the main() function. You can dump away the IDE and write standard C/C++ code and it will work just fine as long as you know how to link it. You cannot override the syntax of basic C/C++ keywords, that is not how a programming language works. Like I said before, you can implement whatever you want within the scope of the language, if you want to rewrite the runtime libraries to use namespaces, go for it, there are no obstacles stopping you from doing this, however, you will not be able to redefine how using works in C++. You cannot redefine the behaviour of a language without changing the compiler, and then you will end up with something that is not the language you started with.
The main benefit of namespaces is to prevent the clash names in a project. This is important in large projects that have components that come from multiple developers and third parties.
But most of the Arduino reusable code is in the form of libraries implemented using C++ classes so already incorporates the namespace scope rules built into C++.
If the problem you addressing is more about clarifying the nature or purpose of a library rather than preventing name clash, would not a simple and effective solution be to improve the documentation where necessary.