Have the Embedded world gone ape? 10 years time?

[tggzzz]

Which problems with C99? I've not found any. 

In that case either you haven't looked very hard, or you aren't perceptive, or you are very tolerant. There is at least one other possibility, which I won't mention.

I would be surprised if you still can't see any problems after reading http://yosefk.com/c++fqa/

[c4757p]

Am I missing the part of that about C? All of what's on there seems to be C++-specific, and I agree with most of it.

In that case either you haven't looked very hard, or you aren't perceptive, or you are very tolerant. There is at least one other possibility, which I won't mention.

Stupid? Definitely a possibility. Though out of the choices I'd pick tolerant, I don't really mind a language with a few quirks. Seems every useful language is fairly quirky, anyway. *shrug*

[tggzzz]

Am I missing the part of that about C? All of what's on there seems to be C++-specific, and I agree with most of it.

In that case either you haven't looked very hard, or you aren't perceptive, or you are very tolerant. There is at least one other possibility, which I won't mention.

Stupid? Definitely a possibility. Though out of the choices I'd pick tolerant, I don't really mind a language with a few quirks. Seems every useful language is fairly quirky, anyway. *shrug*

Clearly either you haven't read the FQA or you aren't aware of the significant overlap between C and C++.

I class "stupid" in the "not very perceptive" category.

[c4757p]

Clearly.

[legacy]

Am I missing the part of that about C? All of what's on there seems to be C++-specific, and I agree with most of it.

yes, I do not hate the C++, I simply do not like that it adds to much complexity to the language, too many features, too bloated
while C++14 is the best trade off I can think and use 

I am watching the Go language (never tried in real context) simply because I am impressed, especially by the desire to return to purportedly simpler days of programming. "A common sentiment among Go supporters is that modern languages are too complicated and 'academic', whereas they see Go as a 'working man's' language.

[legacy]

From C-Chimpanzees to Go-Gopher, Google hopes to remake programming with Go

There is a ne iconic mascot over there, born out of habit of enraged apes of flinging their own feces at their object of anger when they fail to catch nuts because their C language sucks (if you haven't experienced this phenomenon first hand consider yourself blessed). A new specie has come, it's a Go- Gopher, smart enough to be able to grow their acorns.
(my humor  )


Go-pher, iconic mascot, referred to golang, a programming language developed at Google in 2007


"The Go Programming Language", Specification, FAQ

Born out of frustration with existing languages and environments for systems (also embedded?) programming when programming had become too difficult, no doubt  Google's Go language is off to a great start, but still has work ahead: Go offers speed, concurrence, and portability, but it's still young and might be too simple, it's currently fully supported on Linux and Darwin/MacOSX and fully integrated in Gcc >=gcc-v4.9(1) as "frontend" connected to the GCC backend. This means that, in the Theory(2), any Go program that you can compile for x86/x86_64 should work on Arm, and besides Linux and Darwin/MacOSX, Go is also "experimentally supported" on FreeBSD and NetBSD, Go is a new language. Although it borrows ideas from existing languages, it has unusual properties that make effective Go programs different in character from programs written in its relatives. A straightforward translation of a C++ or Java program into Go is unlikely to produce a satisfactory result—Java programs are written in Java, not Go. On the other hand, thinking about the problem from a Go perspective could produce a successful but quite different program. In other words, to write Go well, it's important to understand its properties and idioms.


I put emphasis in the above presentation to catch your attention, I'd like to hear some unbiased opinions about


(1) you can try to compile gcc with

Code: [Select]

./configure --languages=C,Go

(2) It seems that the Go team has written two different compilers that implement that spec:

• gc, the first one, is the original compiler, and the go tool uses it by default, I guess that having two different implementations helps ensure that the spec is complete and correct: when the compilers disagree, they fix the spec, and change one or both compilers accordingly, It supports only the most popular processors: x86 (32-bit and 64-bit) and ARM
• gccgo, slower than gc but it supports all the processors that GCC supports. Not all those processors have been thoroughly tested for gccgo, but many have, including { x86/32bit, x86/64bit, SPARC, MIPS, PowerPC }. Gccgo has also been tested on operating systems that the gc compiler does not support, notably Solaris (what about Irix? Aix? who knows?)

[c4757p]

I'm with you on the golang love. I don't think it's suitable for embedded dev right now - it has things like garbage collection pretty strongly built in - but an embedded variant of it, that's something to consider.

Probably not going to happen, and the world probably doesn't need more random variants of languages. But still - it's kinda neat.

[westfw]

but an embedded variant of it

Has there EVER been a successful "embedded variant" of a "modern" programming language?  It's not clear that language-designer types UNDERSTAND embedded (or that any two embedded designers can agree on "requirements" in the first place.

How about just a well-loved embedded string library?  Maybe I'll start a campaign to invent "C with Strings: C||"; hypothesizing that 99% of the horrible C errors "caused by pointers" are actually caused by people having to use pointers to manipulate strings (because there is no good alternative.)

[c4757p]

Has there EVER been a successful "embedded variant" of a "modern" programming language?

I doubt it. Just a brief pipe dream

How about just a well-loved embedded string library?  Maybe I'll start a campaign to invent "C with Strings: C||"; hypothesizing that 99% of the horrible C errors "caused by pointers" are actually caused by people having to use pointers to manipulate strings (because there is no good alternative.)

Yes! C's built-in string processing functions suck.

[nctnico]

If all code should follow a design pattern then programming becomes like being a monkey coloring within the lines.

How do you suggest we distinguish the current state of programming from "monkey coloring within the lines"?

I suggest you study where design patterns originated and why they are regarded as standard operating procedures in engineering disciplines. Programming != engineering, unfortunately. Cue standard jokes about "if buildings were designed by programmers"...

If there is already a solution for the problem you are about to solve then there is no need to re-implement that solution word for word. In other words: design patterns should be something you get from a library or a language construct.

[krish2487]

No it isn't and should not be either.


I apologise for the deviation.
You can have access to all the bricks, mortars, lumber and similar construction equipment and material you want.
They will not give you a building plan (design pattern) which you have to follow. The building design decides the equipment and material and the other details.


Having design patterns built into the libraries, HALs, glue logic or what other name you want to call it, restricts the applications and/or usage of the language itself. It is a recipe for sureshot disaster. Design patterns are language agnostic and languages are design-pattern agnostic.
It is purely dependant on the guy who is writing the code.


There is no one solution fits all in our work. The different solutions stem from different requirements. Hence, the need to have different design patterns applied to every problem set.


Quote from: nctnico on Today at 12:18:56 PM>If there is already a solution for the problem you are about to solve then there is no need to re-implement that solution word for word. In other words: design patterns should be something you get from a library or a language construct.

[tggzzz]

If all code should follow a design pattern then programming becomes like being a monkey coloring within the lines.

How do you suggest we distinguish the current state of programming from "monkey coloring within the lines"?

I suggest you study where design patterns originated and why they are regarded as standard operating procedures in engineering disciplines. Programming != engineering, unfortunately. Cue standard jokes about "if buildings were designed by programmers"...

If there is already a solution for the problem you are about to solve then there is no need to re-implement that solution word for word. In other words: design patterns should be something you get from a library or a language construct.

You don't understand design patterns, in particular their level of abstraction.

I suggest you read the original GoF book, where "Chapter 1 Introduction, page 1" indicates clearly why your statement is not only infeasible but undesirable.

(You don't even have to buy the book, you can see it at http://www.amazon.co.uk/Design-patterns-elements-reusable-object-oriented/dp/0201633612 then click on "look inside" and first pages).

[legacy]

how about just a well-loved embedded string library?  Maybe I'll start a campaign to invent "C with Strings: C||"

I have written a pretty safe-library, called lib_safe_string_v2, you can't be "off by one"
(char_t string[10] …. string[10]='@')

Code: [Select]

/idp.do/src/lib_safe_string_v2# cat lib_safe_string_v2.interface

boolean_t safestring_extract(p_safestring_t p, uint32_t from);
boolean_t safestring_append_ch(p_safestring_t p, char_t ch);
boolean_t safestring_append(p_safestring_t p, char_t msg[]);
boolean_t safestring_let(p_safestring_t p, char_t msg[]);
boolean_t safestring_reverse(p_safestring_t p);
boolean_t safestring_done(p_safestring_t p);
boolean_t safestring_touch(p_safestring_t p);
uint32_t safestring_get_len(p_safestring_t p);
uint32_t safestring_get_i(p_safestring_t p);
boolean_t safestring_new(p_safestring_t p, char_t msg[], uint32_t size);
boolean_t safestring_clean(p_safestring_t p);
uint32_t undefined_string_get_size(char_t msg[]);
boolean_t safestring_show(p_safestring_t p);
boolean_t safestring_register_show_method(p_safestring_t p, p_this_t p_show_method);


[legacy]

a "safe_string" is a struct_type

Code: [Select]

typedef struct
{
    p_char_t p_data;
    uint32_t i;
    uint32_t len;
    uint32_t size;
} safestring_t;

C|| should handle strings this way

[tggzzz]

No it isn't and should not be either.

I apologise for the deviation. You can have access to all the bricks, mortars, lumber and similar construction equipment and material you want.
They will not give you a building plan (design pattern) which you have to follow. The building design decides the equipment and material and the other details.

Having design patterns built into the libraries, HALs, glue logic or what other name you want to call it, restricts the applications and/or usage of the language itself. It is a recipe for sureshot disaster. Design patterns are language agnostic and languages are design-pattern agnostic.
It is purely dependant on the guy who is writing the code.

There is no one solution fits all in our work. The different solutions stem from different requirements. Hence, the need to have different design patterns applied to every problem set.

Quote from: nctnico on Today at 12:18:56 PM>If there is already a solution for the problem you are about to solve then there is no need to re-implement that solution word for word. In other words: design patterns should be something you get from a library or a language construct.

Precisely.

[BloodyCactus]

a "safe_string" is a struct_type

looks very similar to the old bstring library by Paul Hsieh. http://bstring.sourceforge.net/

[legacy]

I started from scratch, I wrote safe_string because I had to support a tokenizer and a parser, and they both had silly bugs, e.g. string  was defined char_t string[10], and the user tried to access the 11th position string[10]='\0'; because he started to count from 1 instead of from 0 it also happened  string[-2] because the user forgot to check the error code that was used as string index

version 3, revision 2, adds new interesting functions, e.g. safestring_winlookahead is very useful for my lib_tokenizer, while safestring_get_Cstring is a toy, used to collect everything is between " and " 

Code: [Select]

boolean_t safestring_is_ahead_left_anything_to_eat(p_safestring_t p, uint32_t ahead);
boolean_t safestring_winlookahead(p_safestring_t p, char_t target[], uint32_t from, char_t win_len);
safestring_ans_t safestring_winlookahead2(p_safestring_t p, char_t target[], uint32_t from, char_t win_len);
boolean_t safestring__register_show_method(p_safestring_t p, p_this_t p_show_method);
boolean_t safestring_extract(p_safestring_t p, uint32_t from);
p_char_t safestring_get_data(p_safestring_t p);
safestring_ans_t safestring_get_ch(p_safestring_t p);
safestring_ans_t safestring_geth_ch(p_safestring_t p, uint32_t i);
void safestring_touch_and_rewind(p_safestring_t p);
void safestring_rewind(p_safestring_t p);
void safestring_reinit(p_safestring_t p);
boolean_t safestring_append_ch(p_safestring_t p, char_t ch);
boolean_t safestring_append(p_safestring_t p, char_t msg[]);
boolean_t safestring_let(p_safestring_t p, char_t msg[]);
boolean_t safestring_reverse(p_safestring_t p);
boolean_t safestring_done(p_safestring_t p);
void safestring_touch(p_safestring_t p);
uint32_t safestring_get_len(p_safestring_t p);
boolean_t safestring_set_i(p_safestring_t p, uint32_t i);
boolean_t safestring_set_i_ahead(p_safestring_t p, uint32_t ahead);
boolean_t safestring_set_i_back(p_safestring_t p, uint32_t back);
uint32_t safestring_get_i(p_safestring_t p);
boolean_t safestring_set_i_next(p_safestring_t p);
boolean_t safestring_new(p_safestring_t p, char_t msg[], uint32_t size);
void safestring_copy_to_array(p_safestring_t p, char_t array[]);
boolean_t safestring_clean(p_safestring_t p);
uint32_t undefined_string_get_size(char_t msg[]);
boolean_t safestring_show(p_safestring_t p);
boolean_t safestring_draft(void);
boolean_t safestring_test(void);
safestring_ans_t safestring_get_Cstring(p_safestring_t p, p_safestring_t b);
safestring_ans_t safestring_get_CIstring(p_safestring_t p, p_safestring_t b, char_t string_markA, char_t string_markB);
boolean_t safestring_remove_sub_quote(p_safestring_t p);


[tggzzz]

I started from scratch, I wrote safe_string because...

Without making any comment on the qualities and merits of your code, I'll note that the C++ world is excessively prone to re-invention of pre-existing wheels. Which IMNSHO is a waste of talent.

Another way of observing something similar is to note that papers describing C++ applications and features tend to refer to other C++ papers. In contrast papers describing language X applications and features tend to refer to papers about many other languages. The conclusion is that the C++ world is relatively inbred/parochicial and doesn't understand the broader scope of what has been achieved and can be achieved relatively easily.

[legacy]

Without making any comment on the qualities and merits of your code, I'll note that the C++

related to strings, the point was
- no license for C++ (we were not allowed to use GNU)
- too many bugs in the C application I was assigned with

I was involved into that fun when I had to support an interpreter included in a product(1) like "ethernet debugger with a built-in C-interpreter (features reduced) that helps you to test your software" (WinRiver sells a similar product, ofcourse more expensive)

the tokenizer had too many bugs, 60% located at a very bad porting from the PC's world   to the embedded's world (when the previous developer believe that being minded with host=target=PC is fine to develop embedded things). The remaining bugs, the 40%, were related to other wicked things (including a very crap tcp/ip stack) 

(1) here on forum I have released my personal sources, e.g. my (toy)filesystem, my little interpreter (university homework), my C++ fixed point overload (my first job task), my MIPS R3K monitor (assembler, hobby), etc, Unfortunately my current job has the Copyright about all the code I write for them =(

[legacy]

corollary: the C language, as-is, has no support for strings, and having directly to deal with array of chars causes too bugs, so we'd better use the divide and impera paradigm, and relegate strings into a library which can be hardly tested and then used

what do you think about that? is it correct? It was my solution-line.

[tggzzz]

corollary: the C language, as-is, has no support for strings, and having directly to deal with array of chars causes too bugs, so we'd better use the divide and impera paradigm, and relegate strings into a library which can be hardly tested and then used

what do you think about that? is it correct? It was my solution-line.

I have no comment about whether it was the best solution for you. My comments are limited to my previous post.

[legacy]

if you're not using the bloated parts of C++, you're not doing it right 

I have read the above sentence and I wonder about the bloated parts of C++ in details

• is C++ bloated about the memory allocation? Does a C++ program eat more memory than a C program ? In my experience, it's False
• is C++ bloated about the CPU use? std::sort vs qsort says "False", is there a better example?
• is C++ bloated because it's "too verbose"? Does it make you to write more and more lines of code to achive  the same purpose ?
• is C++ bloated because it offers too many features?
• etc ...

I am not a fan of C++, I wonder the practical meaning behind  the above sentence 

[westfw]

If you're not using the bloated parts of C++, you're not doing it right 

I have read the above sentence and I wonder

Mostly, it's the "Use the STL features", most of which include dynamic allocation, and very "generalized" code.
Did you look at the example I had included with the original message?  http://programmers.stackexchange.com/questions/48401/learning-c-properly-not-c-with-classes  Their "good example" is about 60% bigger than their "bad example" (compiled for x86 MacOS.) (for significantly shorter source code size.)

In another example, I was helping someone figure out whether their code using Complex numbers would run on an Arduino.  The complex class they are using is 24 bytes, and I can't figure out where the third "double" is...  (but changing all "double" to "float" does reduce the size to 12.)

[legacy]

OK, understood, thank you