@ChrisH

Quote:

ChrisH wrote: @ChaosLord Quote: I have not ever switched to E simply because of no way to run a serious debugger on the Amiga version. FWIW, debugging PortablE programs is easier on AmigaOS4 than other OSes, because the GrimReaper will report the exact line number where the crash occurred in the (intermediate) C++ code. You can then examine that code (which includes any comments), and it is usually pretty obvious what the corresponding line in your PortablE code is. (It may also be possible to do something similar with some versions of AROS.) Just make sure you compile PortablE code with the DEBUG switch. It's only just occurred to me, but it ought to be possible to have an automatic (C++ to PortablE) line number converter, so that you never even need to examine the intermediate C++ code. If there was demand, then I should be able to add this pretty easily...

Using the #line directive allows any transpiler to cause source level debuggers to "just work" with the actual correct line number of the actual correct original source file.

Of course the underlying compiler must support #line directive but I am sure GCC does. SASC supports #line directives too. Transpilers FTW!

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

I am reading an interesting book about the C programming language. It actually admits to some of its horrible flaws.

It has the following sentence:
Quote:

That's why C++ is so disappointing: it does nothing to address some of the most fundamental problems in C,

I figured this much out already. This is why I never took C++ seriously all these decades, until now.


Quote:

and its most important addition (classes) builds on the deficient C type model.

Sadly, I do not understand what that means?
Can someone explain me?
Or point me to more books that explain the problems of C++ ?

Most C and C++ books I have read are written by total fanbois and contain lots and LOTS of stupid advice, marketing speak, outrageous negative lies against other languages, etc.

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

@ChaosLord

Quote:

Quote: and its most important addition (classes) builds on the deficient C type model. Sadly, I do not understand what that means? Can someone explain me? Or point me to more books that explain the problems of C++ ?

You can find opposition to anything in computing with a Google search like
"X Considered Harmful"
due to the original classic article, "GoTo Considered Harmful".

Some just ranting, some more thought out like this:
C++ Considered Harmful

Tom

Last edited by tbreeden on 16-Jul-2013 at 02:52 PM.

@ChaosLord

I'm surprised reading your posts that you can't find a good C++ book.

Kamelito

@Hypex Quote:

Wow this looks like a big update. Thanks for your continuing work.

Supporting dynamic GUI lists in a portable yet fairly efficient fashion was the biggest work by far, but I think fairly successful. Thanks for the encouragement!

Quote:

BTW what chance is there to compile a PortabE module into an .o file for use with linking to other .o files compiled from C?

Do you mind if I ask for what kind of usage? Then I might be able to give a better answer.

I've never tried, but *in general* there would probably be a lot of difficulties due to things like:
* If you really meant C (rather than C++), then PortablE uses C++ & I'm not sure if you can mix C++ objects with C objects (probably difficult at very least). Although I plan to switch to plain C at some point.
* PortablE auto-initialises a lot of stuff at the start of the main() procedure, and auto-cleans-up a lot of stuff at the end of the main() procedure.
* For speed PortablE uses it's own memory allocator (although I could explain how to disable this), so if you wish to deallocate (etc) it's stuff then you would normally have to take care.
* Procedure/etc names may be "mangled" (so you have to find out what the names are in the C code & this may change when modules change).
* In the future (especially when I move PortablE from C++ to plain C) it will have special procedure & method calling conventions, which may complicate things.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChaosLord

Quote:

ChaosLord wrote: @Hypex Quote: Hypex wrote: @ChrisH Wow this looks like a big update. Thanks for your continuing work. BTW what chance is there to compile a PortabE module into an .o file for use with linking to other .o files compiled from C? +9 this would be a great feature. Also to allow linking to C++ compiled code. Since PortablE is a transpiler shouldn't it be able to actually compile C sources and C++ sources? As long as the C code is contained in its own separate files I think PortablE should pass it on to the underlying compiler. As long as the C++ code is contained in its own separate files I think PortablE should pass it on to the underlying compiler. This would allow me to use 200,000 lines of code I already wrote, instantly, without having to laboriously rewrite it all into E in one big gulp before seeing any results.

In order to do what was proposed, you have to convert the header that tells what all the external references are. See here. The only added step is that when you compile the C++ source, you have to output the code to an object file and then do a separate link stage with the desired object files before the one that PortablE just created.

If you're about to ask why this isn't more streamlined, it's because PortablE has multiple backends. The easiest backend to set-up on a Classic Amiga is to use AmigaE as the PortablE backend instead of GCC, for example.

@ChaosLord Quote:

All I care about is a language that lets me write beautiful code.

Then C++ will never be the right language even if it does support some nice things.

Quote:

But as a C++ Newbling I am not (yet) aware off any new dumb crap that C++ added. Has anyone written an article to explain all the dumb C++ OOP stuff that was added into C++ and how it makes more sense in PortablE or AmigaE or #?E ?

http://cshandley.co.uk/CppConsideredHarmful.html

Quote:

Since PortablE is a transpiler shouldn't it be able to actually compile C sources and C++ sources? As long as the C code is contained in its own separate files I think PortablE should pass it on to the underlying compiler. As long as the C++ code is contained in its own separate files I think PortablE should pass it on to the underlying compiler. This would allow me to use 200,000 lines of code I already wrote, instantly, without having to laboriously rewrite it all into E in one big gulp before seeing any results.

While using PortablE code into C/C++ projects may be very difficult, using C/C++ code in PortablE projects is "EASY"! Quite simply because PortablE was designed to allow you to use standard C code (think AmigaOS header files & libraries).

OK, there is a fair bit you should learn to create an E module that allows direct access to the C code, but (1) the manual work for doing this is well documented (under the "Advanced usage" chapter), and (2) I have a program which automates a lot (not all) of the work.

Last edited by ChrisH on 17-Jul-2013 at 09:49 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

BTW what chance is there to compile a PortabE module into an .o file for use with linking to other .o files compiled from C?

Quote:

Do you mind if I ask for what kind of usage? Then I might be able to give a better answer.

I donno why he asked but here is why I want the ability to mix and match .obj files from different languages:

1. Because I have been doing it for decades. Mixing up code written in C & asm mostly. But Oberon and other languages work too.

2. I code a great big gigantic game and sometimes ppl like to help me code but every single person wants to use a different language. I have no problem with that as long as it can physically work. If Hypex writes me up some code he would much much much rather use E.

So if I could link in some E code into my project which uses Slink (from SASC) that would be great.

I want E to succeed and take over the world. But its asking a lot of ppl to translate gigantic 100,000 lines of code here, 200,000 lines there all into E at once. It would be friendly if ppl could switch to E a bit here and a bit there by contributing to existing projects that are currently compiled with a C compiler.




Quote:

... Although I plan to switch to plain C at some point.

OMG!!! Are you really smart enuff to do such a thing?!?? HOLY CRAP!

Quote:

* PortablE auto-initialises a lot of stuff at the start of the main() procedure, and auto-cleans-up a lot of stuff at the end of the main() procedure.

We are just talking about some low-level code being compiled in E into some kind of .obj file and linked into code compiled with (C|C++) so it won't matter what happened in main, I don't think.


Quote:

* In the future (especially when I move PortablE from C++ to plain C) it will have special procedure & method calling conventions, which may complicate things.

OMG you are serious aren't you!?! That would be so awesome!!!!
Then I could transpile PortablE with my SASC compiler and get to use my super duper Source Level Debugger with chrome wheels, turbocharger and retractable wings!

I thought all that object-oriented stuff in E sorta required you to use a C++ compiler?

You actually know how to translate all that OOP stuff all the way down into C?
Ok now that I think about it there were various opensource Objective C transpilers that compiled Object Oriented C down into plain C. So that probably covers a big hunk of C++ right there.

Are there any opensource C++ to C transpilers available?

I found Commeau C++ for AmigaOS which is a closed source C++ to C transpiler for Amiga. But it stopped being supported like 20 years ago. The reason I am learning C++ right now is because I am planning to use that transpiler.

In the olden days I wanted to switch to E but I dared not because I did not want my code to be trapped on the Amiga. I want my code to portable to other systems when the need arises. I don't like feeling trapped.

But then you rescued us with PortablE (or at least pulled us out of the quicksand).

But many years have passed and now I have new questions...

What was your initial reason for wanting to switch from transpiling to C instead of C++?

Doesn't using a C++ compiler give you certain advantages?
Like ppl could just plug in free opensource C++ code into their projects and it should all link together?
Like you could make use of the Templates feature of C++ for free?

I have not used Templates yet. But I respect them as a good idea. More importantly, sometimes I find free code on the net that says it requires them for certain features. I don't like feeling left out of some fancy features so it makes me want to use the Template version. My SASC does not do Templates. This makes me want to upgrade to C++. Does E have templates?

I read pretty much your whole (awesome) instruction manual online a couple of weeks ago but in the meantime I read a ton of other instruction manuals for C and C++ and C# and Oberon compilers and other things and now everything is a jumbled mess in my brain.


I hate the C language and hate the C syntax. The C langauge is broken. To keep my sanity I have decided to treat C as a type of assembly language. Its primitive but it works on every system. I write in a proper language and compile down to C which is then compiled down to asm on whichever cpu.

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

@ChaosLord Quote:

I thought all that object-oriented stuff in E sorta required you to use a C++ compiler?

No, just makes it easier . I've written OOP programs in plain C, which is messy but does work. Methods can be implemented as function pointers stored as struct members. Inheritance complicates things, but is possible.

PortablE's OOP is already quite different (in details) from C++ OOP, so it already has to do a lot of work to make C++ behave correctly.

Quote:

What was your initial reason for wanting to switch from transpiling to C instead of C++?

C++ features are almost entirely useless for PortablE, as it already generates plain C for almost everything. Even OOP RTTI is implemented from scratch, rather than using C++'s poor RTTI. C++ is ONLY used for exceptions & basic OOP.

Reasons for wanting to scrap C++:

1. The Amiga's C++ implementation (on OS3/4/MOS/AROS) cannot handle exceptions & some other stuff in a multi-threaded environment (which is equivalent to launching a new process on the Amiga due to shared memory). I have been able to work-around this, but it adds complexity & overhead.

2. C++'s run-time increases executable size by 50-100KB (I forget).

3. C is more widely supported than C++.


Quote:

Doesn't using a C++ compiler give you certain advantages? Like ppl could just plug in free opensource C++ code into their projects and it should all link together? Like you could make use of the Templates feature of C++ for free? I have not used Templates yet. But I respect them as a good idea. More importantly, sometimes I find free code on the net that says it requires them for certain features. I don't like feeling left out of some fancy features so it makes me want to use the Template version. My SASC does not do Templates. This makes me want to upgrade to C++. Does E have templates?

With luck I may still support C++ as a back-end, when I switch to C, so hopefully people can still use C++ code if they want (but this hasn't happened yet to my knowledge).

C++'s Templates are a horrible horrible kludge (although fits with C/C++ philosophy), unnecessarily horribly complex, and I suspect fundamentally flawed due to C's type system (see my C++ Considered Harmful article), at least I couldn't get it to do something very basic when I tried 10 years ago.

A longer-term goal is to add Generics to PortablE, which are a more elegant & properly type-checked OOP version of Templates. Java has Generics, but it's usage is still too complex for many common cases (I have a better idea how to do it).

Last edited by ChrisH on 17-Jul-2013 at 10:57 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

P.S. PortablE's development has been stalled for about 6 months, due to personal issues, but will hopefully continue at 'full speed' now.

That said, please do NOT use PortablE on the basis of planned features, because I cannot promise when anything will be done. It's will only be done

Last edited by ChrisH on 17-Jul-2013 at 11:06 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

http://cshandley.co.uk/CppConsideredHarmful.html

I read everything you wrote. A lot of the OOP stuff is way over my head since I have not learned that much C++ yet.

I have bookmarked it and made a note to go back and keep rereading the article and following the links to what others have written.

Most of the stuff that you wrote, I agree with.


But I simply don't agree with your argument against overloading.

The fact that some ppl abuse overloading is not a reason to take it away from everyone.

I want to use a language with proper string handling.

That means the + = NotEqual GE LE operators must work on real strings. Anything else is retarded. (The dumb forum software is choking on math symbols so I had to write them using letters.)


C++ lets me (by jumping thru a bunch of hoops) set up a situation where I can have real strings that actually work the way strings are supposed to work. This is only possible because of overloading.

Yes some ppl do stupid things with overloading in their programs. That is THEIR PROBLEM, not mine. Why should I get punished for some idiot's problem?

A real language has proper string handling built-in. If it does not have it built-in then it must allow it. Allowing it requires overloading.

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

@ChrisH

Quote:

ChrisH wrote: @ChaosLord Quote: I thought all that object-oriented stuff in E sorta required you to use a C++ compiler? No, just makes it easier . I've written OOP programs in plain C, which is messy but does work. Methods can be implemented as function pointers stored as struct members.

Ahhh yes I actually have done that before and its in my code. It works. But its messy as you say. Needs some syntax sugar

Quote:

Inheritance complicates things, but is possible.

I have not got to a point where I want to inherit anything.

I am not a hardcore OOP guy. I just see that maybe it could help me organize things in gigantic projects a bit better.

Quote:

PortablE's OOP is already quite different (in details) from C++ OOP, so it already has to do a lot of work to make C++ behave correctly.

It is always difficult to make any C or C++ compiler behave correctly



Quote:

What was your initial reason for wanting to switch from transpiling to C instead of C++?

Quote:

C++ features are almost entirely useless for PortablE, as it already generates plain C for almost everything. Even OOP RTTI is implemented from scratch, rather than using C++'s poor RTTI.

Well that is awesome!


Quote:

C++ is ONLY used for exceptions & basic OOP.

Yeah I never thought up how to simulate the exception handling that all the other languages have but C lacks...


Quote:

Reasons for wanting to scrap C++: 1. The Amiga's C++ implementation (on OS3/4/MOS/AROS) cannot handle exceptions & some other stuff in a multi-threaded environment

What?!? My game uses multiple threads! (I call them tasks). Does that mean I am not supposed to use C++ for my game compiling?

My subtasks are tiny and are not going to cause any errors. I would only want exception handling in my main super-gigantic task. Does someone out there think C++ exception handling would work ok in my situation?


Quote:

(which is equivalent to launching a new process on the Amiga due to shared memory). I have been able to work-around this, but it adds complexity & overhead. 2. C++'s run-time increases executable size by 50-100KB (I forget).

Not good for writing small efficient cli commands.

But for my game coding its not that big of a deal. Just a small deal

Quote:

3. C is more widely supported than C++.

Yeah they have C compilers for everything in the universe.


Quote:

Doesn't using a C++ compiler give you certain advantages? Like ppl could just plug in free opensource C++ code into their projects and it should all link together? Like you could make use of the Templates feature of C++ for free? I have not used Templates yet. But I respect them as a good idea. More importantly, sometimes I find free code on the net that says it requires them for certain features. I don't like feeling left out of some fancy features so it makes me want to use the Template version. My SASC does not do Templates. This makes me want to upgrade to C++. Does E have templates?

Quote:

With luck I may still support C++ as a back-end, when I switch to C, so hopefully people can still use C++ code if they want (but this hasn't happened yet to my knowledge).

I hope you can make it work with SASC! If u r not familiar with SASC I can tell you the secret compiler options to use for best performance.


Quote:

C++'s Templates are a horrible horrible kludge (although fits with C/C++ philosophy), unnecessarily horribly complex, and I suspect fundamentally flawed due to C's type system (see my C++ Considered Harmful article), at least I couldn't get it to do something very basic when I tried 10 years ago.

Just so you know, I have no desire to actually use Templates. (yet).
I looked at some examples and they were really complicated looking so I decided I would hafta study them later.

Supposedly Templates are turing complete and can be used to generate anything before compilation begins. This means I could use it (theoretically) to fix flaws in the C language. I donno how but it seems like somehow it should be possible.


Quote:

A longer-term goal is to add Generics to PortablE, which are a more elegant & properly type-checked OOP version of Templates. Java has Generics, but it's usage is still too complex for many common cases (I have a better idea how to do it).

Ok sounds kewl! I donno anything about generics either.

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

@ChaosLord
Overloading is not the only way 'natural' string support could be added to a suitably customisable language. And overloading has the major disadvantage that not only can it be badly abused, but there is a huge temptation to do so... I won't argue further about this off-topic subject in this thread.

FWIW, I would like to add 'natural' string support to PortablE, but I have yet to work out how I could do so in a decent fashion. I don't know how C++ can be made to do it, but I would have thought it'd require garbage collection (which PortablE does not support).

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Don't worry about the strings thing to much. When the time comes I can explain you the whole deal how to implement it into the language without any garbage collection. I don't want to distract you from your current todo list.


One thing that has always annoyed me about C and C++ was that they banned nested functions. Even though Basic and Comal and various other languages had these features back in the 80's and every compiler writer knows how to compile such code into his target asm.

So anyway I just dug thru your manual and the old AmigaE manual and could not find any mention of nested functions. Is there any possible way to have nested functions when your language depends on a C compiler?

I can't think up any way ottomh to implement Nested functions into a language that transpiles down to C/C++. Seems impossible.

Nested functions are such a totally groovy feature. They really help organize your code and they keep functions and variables private the way they should be. C makes to many things have gigantic scope. Things that can work with reduced scope should be coded with reduced scope. Nested functions are totally logical and intuitive.

I was using nested functions since 1987 in True Basic. I have read that they were in wide use years before in Pascal or some other languages that I never really used.

If you have any magic spells that could trick an ANSI C compiler into supporting nested functions it would be a helluva trick.

Ok I am starting to think up how to do it. The transpiler could secretly pass a pointer to any vars that are referenced in the parent function! And then secretly rewrite the way the vars are used so that they access the var in the parent function!

The transpiler will keep track internally of which vars are in scope and which are not. I guess you already do that?

The above method is Idea #1.

Nested functions are all about reducing the scope of labels. They reduce the scope of function names so that child functions are known only to their parents and siblings. But they also allow a child function to access the parent functions variables.

Different languages have different rules about things.

If you have never used nested functions before then you could read the instruction manual for COMAL online or the manual for True Basic. I mention those because they are very well-written. But I am sure there are lots of others.

C allows nested BLOCKS. You just start a function:

FUNCTION
int a,b,c;
blah();

// suddenly create a nested block of vars
{
int a,b; // We now have a new a and b but we keep using the c from the parent block!
a=b*c;
}

END_FUNCTION

The trouble is there is no way to CALL the nested block as a function! GRRR!

Maybe you could simulate it with a Label: !


FUNCTION
int a,b,c;
blah();

...

MyFirstNestedFunction(); // This line gets replaced by transpiler with
// goto MyFirstNestedFunction();

MyFirstNestedFunctionReturn: // This line gets inserted by the transpiler

DoMoreStuff();
return;

// suddenly create a nested block of vars
MyFirstNestedFunction:
{
int a,b; // We now have a new a and b but we keep using the c from the parent block!
a=b*c;
Return; // This return gets changed by the Transpiler into
}
// "goto MyFirstNestedFunctionReturn:"

END_FUNCTION

goto saves the day!

Above is Idea #2

The above method automagically solves all the variable scope and function scope things perfectly! I think! I am assuming you know how to do the "Parameter Passing Magic" in the above idea for nested functions that take parameters?

I think this lets us have basic nested functions. From this base we can later add extra fancy features like maybe
EXPORT var
// Parent functions do this to allow children to touch the parent's vars

IMPORT var
// Child functions do this to get access to the parent's vars

Its been soooooooooooooooooooooo long since I was allowed to code parent/child functions that I can't remember how important Import/Export model is. If we leave it out then how bad is that really? I can't remember.

Stuff to think about!

If you are interested in implementing this then I can go read a bunch of instruction manuals to get ideas.

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

@ChrisH

Re:Exceptions in C

I think the C++ exception handler is just a wrapper for setjmp.h so if you're looking to implement exceptions in C, that would be a good place to look. I don't know if the stack unrolling will be needed, but you probably know how exception handlers work.

Re: C headers in C++
To use C headers and object files in C++ you wrap the header with:

extern "C" {
...
}

This is to disable the name-mangling so that the identifiers referenced in the object file will coincide with those in the source.

Re: My advice
I don't know everything about C++ but I have used some C++ code in LLVM to try to get it to work with code that was generated in LLVM Bitcode and the LLVM IR it generates.

@ChrisH

Quote:

P.S. PortablE's development has been stalled for about 6 months, due to personal issues, but will hopefully continue at 'full speed' now.

Wow, maybe I was too busy to notice but I didn't see any stall in PE development

_________________
Philippe 'Elwood' Ferrucci
Sam460 1.10 Ghz
AmigaOS 4 betatester
Amiga Translator Organisation

@Hypex Quote:

BTW what chance is there to compile a PortabE module into an .o file for use with linking to other .o files compiled from C?

Having given this more thought, I realised that most of the issues with doing this should disappear once I make some planned changes (but as usual: no promises about when (or even if) it will be done!).

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChaosLord
I'd like to discuss nested functions, and implementing 'natural' strings, but this thread is not the place to do it (off-topic), so I will PM you.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChaosLord

Quote:

Datz cause ur cheating and using one o dem dere newfangled OS4 thingamajig machines

How do you mean? EDBG broke on OS4, it's a 68K debugger.

ILLEGAL 68K traps are broken on OS4 so I had to patch the source code for the compiler and debugger to get it to work.

Quote:

I need source level debugging for Classic Amigas.

That's what EDBG is.

Quote:

Now u understand why I love CPR debugger so much. CPR has been kicking ass since the early-mid 90s.

Yep!

Quote:

Since PortablE is a transpiler shouldn't it be able to actually compile C sources and C++ sources?

It has a NATIVE keyword so I think it can do that.

Quote:

Yeah I never thought up how to simulate the exception handling that all the other languages have but C lacks...

With E I read somewhere that using the automatic exceptions was a bad idea and to check and generate the exception yourself. But I always liked the automatuic way and my code looked neater. I also made sure it worked as it should.

However, with C I have no automatic mechanism, so I do it myself. When I open a resource I check the result and IF failed it THEN calls my Error() routine.

Saves my from the triangle effect of checking one call after another and then the following code with freeing calls one after the other.

Last edited by Hypex on 28-Jul-2013 at 04:12 PM.
Last edited by Hypex on 28-Jul-2013 at 03:36 PM.

@tbreeden

Quote:

due to the original classic article, "GoTo Considered Harmful".

Yes goto was considered bad style and broke structure. However, when the compiler puts ASM JMP instructions in the code I think it becoems a moot point. For example Amiga compilers have a bad habit of converting a pefectly structured FOR into a WHILE. That means the code jumps to the end, does a loop check and jumps back ot the front. This is unneeded. The code should run through the loop and check at the end following the program code. Bad code practice.

They wanna stop telling me to use goto then compilers should learn how to write logical and efficent machine code first!