C want to do simple graphics in C with libplot unix standard library.

Some use compiled because of library stability over longer periods.
A weak argument, but an argument. Source libraries (such as used by Python and Perl) are also quite stable; I've been running a 10-year old program that is using a 15-year old Python->BerkeleyDB interface, and it is (unfortunately) still working. Unfortunately, because I need a swift kick in the behind to force me to renovate that program from scratch (not just to use modern libraries, there are also lots of design decisions that are no longer appropriate to the requirements).

Type checking ? Could be, when you don't pass void pointers.
You can get around type checking in compiled languages easily. Any time you see the string "void*", you just got around it. Matter-of-fact, in straight C programming (not C++), there is actually darn little type checking for structures, since so many things have to be cast to void*. Sure, you get type checking for int versus float versus pointer, but that's typically not where the mistakes come from.

And you can enable type checking in Python. I use it all the time. Most of the time I appreciate it, because it does catch bugs. But I don't love it, since it occasionally it gets between me and the simple or elegant solution. Duck typing is really a good thing, and strict type checking prevents it.

I didn't want to use the word fetish, but I think I did!
I think that's exactly the worry I have here. Wanting to program in straight C "just because" is idiotic if the goal is to be a good programmer, or an effective programmer, or create good programs. It is a fine hobby, as is building gothic cathedral models out of nothing but match sticks. It can even be a teaching tool for understanding how older programming languages work. But in production, it can only be a fetish.

Something like this: DB (sqlite!) => Statistical Analysis => Graph (on windows).
Depending on your work environment, you don't need to learn any programming for this, or perhaps just a tiny amount of superficial python or R. There are integrated data analysis environments that have database interfaces, built-in IDEs, and built-in graphing tools. I used them all the time at work. Unfortunately, I can't give a recommendation for ones (since the one I use at work is proprietary), but I've heard that Jupyter is very good. Using tools like this, people who know very little programming and are really not software engineers can do analysis and graphs within a few hours.

Where's the root? Why do you think C is the root? What about Intel Instruction sets and registers? There's also GPU, FPU and Intel Instruction Set Extensions e.g. SIMD, SSE(2|3|4), AVX(2|512) so forth and so on! Where is the limit?
There is something to be said for learning how to program in (binary) assembly, where you write a small program, turn it yourself into hex codes, type in the hex numbers, and see it run. About 40 years ago, I used to do a lot of that ... until we got an assembler and editor. It's something that people should try once, to understand computers better. And to appreciate all the tooling that we have today.

In the same fashion, everyone who is a carnivore should at some point in their life go into the forest with a rifle, and go from a happy and living game animal all the way to a dinner, by themselves. To understand where those hamburgers and roasts really come from: from something like bambi. And shooting it isn't the hard part; taking it apart and removing all the bits that are not a delicious dinner is much more difficult. BUT: Having done it once, it is not necessary to repeat the operation frequently, the lesson has been learned.
 
  • Like
Reactions: a6h
You can get around type checking in compiled languages easily
Exactly. For example:

c.c
C:
#include <stdio.h>
int
main()
{
        double d = 10;
        /* short h = d;  will produce the correct result i.e.
            10.000000       10
            but:
        */
        short h = *(short *)&d;
        printf ("%f\t%hd\n", d, h);
        return 0;
}

# cc -Werror -Weverything c.c will produce no error (-Werror flag turn warnings into errors )
# ./a.out
Code:
10.000000       0
 
Hello Friends,
i have checked out the XCB Library and there are currently compiling problems on two computers. 64bit/32bit
here i want to answer why i work with compiled languages.
it's because i want to make a standalone executable of my program.

for graphics i think i dive to Xlib direct approach because it definetly works until compilation process.

if xcb does not work only cairo remains. not for me.
 
one more just for the compiler.

yes , xcb works. I have the compiler arguments ready to run.

so i take XCB and Xlib DIRECT for simple graphics programming.

(not cairo) he he he
 
Exactly. For example:

c.c
C:
#include <stdio.h>
int
main()
{
        double d = 10;
        /* short h = d;  will produce the correct result i.e.
            10.000000       10
            but:
        */
        short h = *(short *)&d;
        printf ("%f\t%hd\n", d, h);
        return 0;
}

# cc -Werror -Weverything c.c will produce no error (-Werror flag turn warnings into errors )
# ./a.out
Code:
10.000000       0
This is 'undefined behavior' according to the standard, from c89 on.
As you know just because you can do something in C doesn't mean it's 'defined'. Eg, a common one:
sprintf(array,"%s added.",array);
 
  • Like
Reactions: a6h
It is a misconception that a language prevent you to do bad things.
I merely can guide.

In the posted code it's pretty much down to the standard being unrealistic anyways. Alot of times unions simply don't cut it. I'd really like to see a standardized version of __attribute__((__may_alias__)) in a way so that it can also be used on the fly and not just on the original type definition. I am not sure how beneficial the aliasing restriction really is to optimization anyways but from my experience it's pretty rare for code to actually break because of violating it so it might also be a possibility to just remove the restriction in general (i figure even with an official may_alias keyword there would probably still be a lot of code that simply passes -fno-strict-aliasing) and rather add a restrict like keyword to tell the compiler that something is not going to alias.
 
hi,
i have a clear vision.
use the unix weapons to do things.
first application i will do is a mighty copy master tool.
full screen and with huge beams.
the style i will use for myself for copying things.
as a one click executable.

altogether i can say that NOMADBSD reacting very good.
the original compiler instruction of the XCB manual are not used because the system modified the arguments
to it's own style ones. Then compiling works good.

it's surprising if the compiling line to type in is longer than the screen , some text goes to next line and that does not work.
copy and paste in CMD then works.
thus i am aware that the arguments fits in one line on screen.
 
This threat is forked in two branches. One is Team OP, singing the same song embellished with different notes; the other is Team The Rest.
I gave up.
 
I gave up.

Yes, it's probably best this way. There is not much of a constructive discussion to be had in relation to the original topic and while there have been a couple very good posts the thread in general just keeps on getting more and more weird...
 
  • Like
Reactions: a6h
I kind of like it as some bizarre ancient manifesto. The sort of stuff that people dig up centuries later and base arbitrary religions upon:

freebsd_manifesto.jpg
 
Most compilers and platforms do result in that. It is a wrap-around but it is still undefined behaviour. The program terminating instead could still be a possible outcome and still suggests a valid compiler.

The fact it is a large positive number is because in a signed type, half of the possible values are reserved for negative numbers which the unsigned type just uses as the higher values.

A common mistake I see from my students is reverse iterating using an unsigned type:

Code:
// Bad
for(size_t i = nums.size() - 1; i >= 0; i--)
{
  std::cout << nums.at(i) << std::endl;
}

Because size_t is unsigned, -1 would instead be a large number and the loop never terminates because it is always >= 0.
 
If it is the expected behavior of the programmer it is ok. If the programmer had safety in mind because of the naming unsigned it isn't.
 
hi,

here is a compiled executable from the XCB Manual. 64bit

wanna probe ? no problem. have make a.zip

gotta have "fear" to start executable. cannot see how good it works.

thanks.
 
What's in that ZIP file? .EXE or .COM?
Please don't post Executables (*) here.
(*) a.out, COFF, ELF, COM, EXE, PE, etc.
 
hello , .exe

ok. i will never upload UNIX . exe

should i erase the upload please give here a short statement.
no problem.
 
Back
Top