attn cpp coders

[johnjohn]

Anyway, C++, D, or Rust are already quite advanced languages, IMO not a good choice to start learning programming with.
But it seems you already figured that out yourself.

If I may recommend you some things, my advice was:

1. Get a copy of the K&R "The C Programming Language", second edition (1988)
2. Take the chance to learn parallel the usage of the debugger (lldb if you use clang, which I think you do) Some say, printf is all the debugging you need. Others say, a debugger is all you need. I say you need both, and will learn which to choose when.
3. If not already done yet also parallel learn a version control system.

Well, hello there, Sir Maturin. We haven't crossed paths in quite some time. It's nice to hear from you

I actually looked at Rust last year and my conclusion is that someone had the idea to turn JavaScript into a compiled programming language. I swear that it is alot like JavaScript - and i hate JavaScript. I would rather learn Java than Rust. After i have learned C and Cpp, i will also look at Java.

I have a copy of The C Programming Language second edition. Excellent reference. I also have gdb and valgrind and i make use of them often.

you mentioned version control system but i had to search the web to make sure that i have the correct definition (version as in my software program version 1.0 or version control as in keeping copies of new versions and old versions?)

i currently work with the file named "mymath49.c" so yes, i save versions anytime that i make a change to the software. I keep copies of my code throughout its lifespan because i've lost code before and it made me cry I started maintaining versions when i crossed into intermediate php skill level.

one thing that i notice about C language: it is blazing fast! fast compilation and fast execution. Very impressive. But also, it has alot of cages and handcuffs. I am always trying to figure out ways to break out of cages and remove the handcuffs but i think that this point-of-view is solely based upon learning PHP (scripting language) instead of a true programming language. I have to rewire my brain now because alot of my PHP tricks absolutely do not work in C.

 

[Maturin]

We haven't crossed paths in quite some time. It's nice to hear from you

Thanks. I don't post unless I can say something useful to something - or at least what I think useful was.
I was still here all the time and also watching "your FreeBSD career" from "Windows guy 'no terminal but GUI only for me, thanks!'" over "terminal is great!" to "...I now start programming on C++ and C" . Very good! Exemplary.
I'm for sure not the only one loving it to see some one new comes to FreeBSD, being convinced to give it a shot, then digs into it, starts to love it, digging into it even deeper,...finding her/his own path.

But back to topic:

I actually looked at Rust last year and my conclusion is that someone had the idea to turn JavaScript into a compiled programming language. I swear that it is alot like JavaScript

I cannot say anything about that, since I glimpse at Rust by now just very shallowly, and I never learned neither Java nor JavaScript, since without even knowing at least the latter one to me is for programming webpages, and that's not what I'm doing. But there are always similarities between almost all programming languages, since most languages (the serious to take ones, not some experimental or 'joke' languages like e.g. Brainfuck) are started to do something better the existing ones are bad at or do not provide at all, orientating at what there already is. So of course there are similarities. The heritage tree (second picture down on the right side on Wikipedia:ALGOL gives a rough idea how it "all started" (not quite true, since there is at least one other tree issued from lisp.) And most of the times somebody presents a new programming language (not seldom self advertised as "now this one will solve all our programming issues - but it's not finished yet; in fact I just started on that...") I look at it and think, 'how this look like C again.' There have been many attempts to produce a better C. Most were not really convincing.
But programming languages do not only differ only by their syntax, that's more superficial. You need also to grasp their "philosophy" (for lack of a better word), and if you're not only learning programming languages by pure curiosity but going to be interested in really to do some serious programming - maybe join some open source project, maybe FreeBSD - you also need to learn which programming languages are used in which projects.
Could go more into details here, but there are many others by far way more experienced programmers on a professional level here could tell you better than me.

About version control there are some, and you better take at least a closer look yourself at their introduction, to understand what they are doing and what they are for. The most popular and by far most used one is of course git
Like a few others personally I use SVN, which maybe a good start for get into versioning control at all, because it's less complex than git, but it needs a central server running the repo. And if you're going to collaborate one day with others it's almost certain you need to use git anyway.
But there are others of course, like Fossil or Mercurial, which I do have no experience at all with, but others here do.
Anyway, reading for yourself a bit about versioning control enlightens you more than I write long posts.
However

currently work with the file named "mymath49.c" so yes, i save versions anytime that i make a change to the software.

That's exactly the point you better start using a VCS. This suggests you already have at least 49 files somewhere somehow stored. With a versioning control system instead you would have only mymath.c. The VCS stores all the former versions for you, provides the possibility to jump between any version anytime, and gives you a list of which versions there are, and what their core point in difference is (see writing comments at the end of this post.)

As long as you only work on single files, for doing a beginners class or just writing a very small experimental program, there is no problem. But once you say 'I could (re)use this program or that function a bit modified for something else', the chaos starts. Having programs consisting of more than one file, start creating libraries, and at the latest, when you are not working alone on some files anymore, trying to have different versions/modifications/derivates/states all as copies of files - some are in a useful state, some may be useful later for something else, but most are just in some in between "solved something but not really useful yet" state... to be "organized" in several directories ... this "system" reveals quickly its limits: chaos is predetermined.
When there is a total mess, and it's just a question of time when there will be chaos, you are confronted with the choice what to do now - happened to myself many years ago: Stop frustrated with programming at all, what was a pity, because you had so much fun and the problem ain't lacking of programming skills, but because in the lack of organization. Or to start all over again, or bite the bullet, and clean up the mess. Neither way is nice. And your programs don't have to become large to get there.
So better learn and start ASAP how to organize and prevent the mess by using a versioning control system.

Versioning Control System: learn what they are for, what they do, use the rich expertise of this forums to get more input, help and other points of view than just by me.
Then pick one, learn its basic usage, and integrate it as soon as possible as a part of your programming processes, because it is part of any serious programming beyond beginners classes.
Learning to use a VCS is not done alone by learning the usage of its UI. You need to learn at least two things you cannot learn by books or any other text or explanation by others:
When is a change worth to become a commit. And write short but catchy commit comments, so to see later quickly which was the core point of which version. This you can only learn by doing it yourself.

I'm pretty sure you will be very glad if you started on using VCS soon.

 

[johnjohn]

I absolutely love FreeBSD and i still feel the same way. The forum is really helpful, so i am definitely thankful for this place. You have also helped me early on, so i still remember your advice. And you continue to offer advice, which i also appreciate. Thank you for taking time to reply, Maturin. You are a good member of this forum

Version control is very important and learning the concept is imperative when working with other coders/programmers. I allready understand the reasoning. My project is beginning to expand and i feel the control pressure allready. I am designing my calculator to handle three scenarios: console mode only, gui and console output only (so that one may use the calculator via other languages such as php to get the output/answer only). I'm also building the program to handle various languages and user settings. A bit too much for a beginner but i'm learning as i go.

I fully intend to contribute to FreeBSD in the future (once i become skilled enough with C/C++). FreeBSD is great! I'm happy to leave Windows behind me and i've met alot of nice people in this forum, so win-win.

 

[johnjohn]

hey, i found a way to divide digits and 10 without math, bit shifting, logarithms or other math related tricks. I finished coding 2 and i works and it is fast! I do not research math related stuff, so i wonder if algorithms like mine exist? i have spent days hammering out data on paper and it has paid off. My calculator is coming along well and my coding skills are getting better.

i've attached some screen shots of my divison by two algorithm, including a googol divided by two. I am quite happy with the fruits of my labor. Too bad we can't make money with stuff like this. LOL. Anyway, i wonder what tools exist to test the speed/execution time, cpu cycles and ram usage of a c program in FreeBSD. Any suggestions? something like Valgrind.

 

[Maturin]

Anyway, i wonder what tools exist to test the speed/execution time, cpu cycles and ram usage of a c program in FreeBSD.

First of all congratulations. You are getting deeper, and having fun at it. Keep on!

Exact measurement of speed/execution time is kind of a bit tricky.

You can use the time.h in C:

#include <stdio.h>
#include <time.h>

int main () {
 
/* other code */

    printf("start: %d\n", clock());
/*
....code to be measured ....
*/
    printf("end: %d\n", clock());

/* other code */

return 0;
}

To get more detailed information how long a part of your code exactly needs, you better use the debugger.
You can use getrusage(2) to get RAM usage. But also here the debugger can help.

Just to measure how long a program runs on your system is not always meaningful.
When you place some code before the second printf that uses to run a couple of seconds, and then run the same object code a couple of times, you will not receive the same outcome every time.

Explanation:
You are using a time sharing OS. So you're not running your prog directly on the CPU ("bare metal"), but let the OS handle this job. Doesn't matter if you're using FreeBSD, Linux, Windows or whetever - the principal is always the same:

Running a prog on an OS works this way: You tell the OS, 'Hey! Run this!' Then the OS (not going into details now) needs to see, when to fit it into its schedule, where to slip it between all the other jobs it currently does. Of course, under normal cicumstances (you are not currently building world parallel, which made your machine being already pretty near 100% load) there is way more capacity left to just execute such a small piece of software you ask for en passant. And since you are the user, you get a higher priority for the jobs you ask for than the OS's jobs running in background when there is nothing else to do. But anyway it needs some CPU time to run, needs to slip in somewhere, needs to be loaded, and then executed, when there is time for it.

As the user infront of a machine you don't recognize anything of that. At least you shall not. (Except of course the program takes a while to run, e.g. counts a million times from zero to ten thousand, but that's not the point here) If then those are the so called 'lags'. Commonly known, when your are killed on a virtual battlefield because the internet connection had a lag, and your game froze for a few tenth seconds. But it's also, when you realize your mousepointer is not running smoothly or something like that. It's when your machine's load is over 100% its capacity: The OS gets problems to schedule enough CPU time for all the tasks asked to be done.
A modern time sharing OS has a bunch of jobs to do. Even organizing all the jobs is a job of its own. The point is, at least the jobs according directly with the user's interaction (UI) are all (shall be) done so damnd fokkin' quickly, that for a human it seems they are all happening at the same time, or at least fast enough he does not recognize any delay, or seldom and short he's not disturbed by it.
Anyway, and that's the core point, there are delays, constantly many, many delays. Most of the times they are too short for a human to be recognized, so his work at the machine feels smooth.
<[begin side track]>
There is a neuropsychological limit of perception. Since there is not only a very large difference between seeing, hearing, feeling a touch with your fingertips or with your toes, but also between individual humans, to give a general number for it is not actually correct. But to give a rough idea which for many practical applications is not complete bogus, one could say anything shorter than app. 30 ms is recognized by a human as "immediately", not recognized there is a delay at all.
For a modern CPU 30 ms is a small eternity - you can do a lot many things in that time.
<[end side track]>
When you let a program run on an OS, supposed it's a very small C program doing just some short calculations with pregiven values (named "c" here), and there is no waiting for user interaction, the time line would look like something like this:
[.................................- wait for the OS to begin execution -........................................][c][...............................- wait for and then printf("%d\n", result); - ..................................]
And this all happens in milliseconds, at least significantly below one second.

Point is, all that scheduling by the OS, wait to fit in, wait for to run it in most of the times is by far way more than short enough, so the user is not disturbed in his workflow on an "office machine" ("personal computer"). But those times are not always have the exact same length, are not predictable, and like in the example above, can exceed the actual execution time of a small prog by several times (even if not recognized.)
Plus, modern CPUs do such things like code prediction, and running pieces of code parallel.

So, exact time measurement - 'how many clock cycles does this part of code needs to be executed on the CPU?' - is not trivial to answer.
The debugger can help you on that. Knowing the machine code of a certain part of code gives the number of clock cycles needed, those computed with the frequency gives the time.

As long as you don't really need to deal with exact timing, e.g. having to control some fast technical process, or need to speed up your software, because it runs to slow to meat some real time requirements (producing lags), then just do what the majority does: Don't bother much, and simply rely on the machine will run it fast enough.