an equivalent to C++'s #if #else #endif

Propose new features and changes
User avatar
jeeswg
Posts: 4785
Joined: 19 Dec 2016, 01:58
Location: UK

an equivalent to C++'s #if #else #endif

30 Jun 2018, 07:53

- Inspired by C++'s #ifXXX/#else/#endif directives, you could have something like this (and I would be happy with different names):

Code: [Select all] [Download] GeSHi © Codebox Plus

#IncorporateIf (A_AhkVersion < "2")
#NoEnv
#IncorporateIfEnd
- The script above would use #NoEnv only in AHK v1, in AHK v2 the line would be invisible.
- #Include can do a lot of this, but perhaps people might like this idea also.
User avatar
Flipeador
Posts: 950
Joined: 15 Nov 2014, 21:31
GitHub: Flipeador
Location: Argentina
Contact:

Re: an equivalent to C++'s #if #else #endif

30 Jun 2018, 08:00

Why this two-way compatibility mania? Can't you just think v2 as a "different language"?. What you propose is disgusting.
It is like (in v2):

Code: [Select all] [Download] (Untitled.ahk)GeSHi © Codebox Plus

#IncorporateIf (A_AhkVersion < "2")
++ asd + asd+ sd asd~@~ ; valid due to "#IncorporateIf"
#IncorporateIfEnd

This would just be unnecessary work for the syntax parser.
#NoEnv does not exist in v2 and therefore is an error. As it should be. We can't make part of the code valid when in reality it is not.


Edit: Putting this aside, adding the #if directives could be interesting, but you should propose something serious, a good reason or example of use, and not this you have written.
Windws 1♂ Pro 64-Bits I make scripts for AHKv2 (my v2 compiler) & WIN_7+ Spanish Argentina SublimeText 3 & AHKv2
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: an equivalent to C++'s #if #else #endif

30 Jun 2018, 09:23

Relying on #If a lot is one of the major reasons C and C++ lost to Java.
Cross-Compatability using #If is one of the worst things I can imagine.
What you propose is disgusting.
I agree.
Recommends AHK Studio
User avatar
jeeswg
Posts: 4785
Joined: 19 Dec 2016, 01:58
Location: UK

Re: an equivalent to C++'s #if #else #endif

30 Jun 2018, 16:32

- @Flipeador: IMO two-way compatibility is the best use for this. For example, I could right now release all the scripts that I share on the forum as AHK v2-ready, but yet they would work on AHK v1 also. (The custom backported functions would be contained within a special block.)
- The same principle applies within different versions of AHK v1.0/v1.1/v2.
- I would welcome any examples for more general use, if you can think of some.

- @nnnik: Do you have any evidence for this?
Relying on #If a lot is one of the major reasons C and C++ lost to Java.
guest3456
Posts: 2358
Joined: 09 Oct 2013, 10:31

Re: an equivalent to C++'s #if #else #endif

30 Jun 2018, 17:02

https://autohotkey.com/v2/

AutoHotkey v2 aims to improve the usability and convenience of the language and command set by sacrificing backward compatibility.


just stop.

User avatar
jeeswg
Posts: 4785
Joined: 19 Dec 2016, 01:58
Location: UK

Re: an equivalent to C++'s #if #else #endif

30 Jun 2018, 17:59

- @guest3456: What's your point? Look at the OP, I didn't intend to discuss two-way compatibility in any detail, I used it as an example. (Fundamentally the idea is that of an internal #Include, where the files are within the script itself.) Can you suggest other possible uses?

- Anyhow, it's not just about two-way compatibility. A_ComSpec was added to AHK v1.1.28. The proposal gives a way to do something like: try global A_ComSpec := ComSpec. I've wanted something like that since I started using AutoHotkey, to be able to use forwards compatible code that wouldn't crash in newer versions. Also, I would genuinely like to hear of other use cases.

- Your use of the quote ignores any nuance. These are equally true:
- AutoHotkey v2 aims, to an extent, to minimise the number of AutoHotkey v1.1/v2 two-way compatibility issues. There is a large amount of continuity. It is already reasonably straightforward (currently with a few ugly workarounds) to write two-way compatible code.
- AutoHotkey v1.1 aims, to an extent, to facilitate writing code that is forwards compatible with AutoHotkey v2. (E.g. see the changelogs for v1.1.27 and v1.1.28.)

Changes & New Features
https://autohotkey.com/docs/AHKL_ChangeLog.htm#v1.1.27.00
Changes & New Features
https://autohotkey.com/docs/AHKL_ChangeLog.htm#v1.1.28.00
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: an equivalent to C++'s #if #else #endif

01 Jul 2018, 00:26

There are no other uses than "solving" compatability issues.
Java is mostly used because it is compatible with almost any system without using #if. #if creates more work for developers because the developer needs to write both sides of the branch. In an extreme case it's the entire script.
That's unreadable, difficult to maintain, a lot of extra work and it doesn't even fit into AutoHotkeys language design.

You want to hear about other uses - compatability issues are the only use.
Recommends AHK Studio
lexikos
Posts: 6040
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: an equivalent to C++'s #if #else #endif

01 Jul 2018, 03:13

#if in C and C++ is a preprocessing directive. Preprocessing is already feasible. In fact, the (perpetually?) unfinished next release of Ahk2Exe supports limited forms of the directive already, with ;@Ahk2Exe-IgnoreBegin...;@Ahk2Exe-IgnoreEnd equivalent to #if !A_IsCompiled...#endif and /*@Ahk2Exe-Keep...*/ equivalent to #if A_IsCompiled...#endif. Evaluation of a constant expression, such as what C's #if allows, is also feasible; multiple methods of expression evaluation have been demonstrated over the years.

#if creates more work for developers because the developer needs to write both sides of the branch.
The extra work is put in only to achieve something that otherwise wouldn't be feasible, or would be achieved by some other means with (perhaps) even more work. #if does not create more work; writing one or both branches of the #if is just part of the work done to achieve some goal.

For instance, having #if in C++ does not create more work for me. Having multiple build configurations which utilize #if - ANSI/Unicode x86/x64 exe/SC - creates more work. Without #if it wouldn't be worthwhile, and you would have only Unicode 32-bit exe (or perhaps the original ANSI build).

As should be evident if you consider how AutoHotkey itself uses #if, there are more uses to it than just supporting multiple versions of AutoHotkey. An author could use it for whatever purpose they want.

It should be obvious that it is not necessary to write both sides of the branch, just as it is not necessary when using if (expression). #ifdef or #ifndef is oftentimes used without #else.

While I recognize the utility of #if/#ifdef, I personally have no interest in implementing it at this time.

AutoHotkey v2 aims, to an extent, to minimise the number of AutoHotkey v1.1/v2 two-way compatibility issues.
Compatibility is mainly a side-effect of a number of other factors, such as the value I put in reusing familiar constructs rather than requiring new ones to be learned, the cost of change being greater than the cost of doing nothing, and general resistance to change where the value of that change is unclear.
AutoHotkey v1.1 aims, to an extent, to facilitate writing code that is forwards compatible with AutoHotkey v2.
Each and every new release aims to improve the program in some way. It is only natural that at least some of the changes which can be made to both versions are made, as long as I have any motivation to work on v1.1.
User avatar
nnnik
Posts: 3067
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: an equivalent to C++'s #if #else #endif

01 Jul 2018, 04:03

The extra work is put in only to achieve something that otherwise wouldn't be feasible, or would be achieved by some other means with (perhaps) even more work. #if does not create more work; writing one or both branches of the #if is just part of the work done to achieve some goal.
other languages use better mechanisms - any mechanism is better than a huge else if ladder.

For instance, having #if in C++ does not create more work for me. Having multiple build configurations which utilize #if - ANSI/Unicode x86/x64 exe/SC - creates more work. Without #if it wouldn't be worthwhile, and you would have only Unicode 32-bit exe (or perhaps the original ANSI build).
It creates more work than a better way to create compatability across version - For example by providing proper APIs that dont rely on any specific implementation.

As should be evident if you consider how AutoHotkey itself uses #if

AutoHotkeys current #if is very different from C++ #if to the point where I would say that they are only related by name.

there are more uses to it than just supporting multiple versions of AutoHotkey. An author could use it for whatever purpose they want.
The main uses of #if with their better alternatives:
  1. Different code versions in the same source (like script v1.3 and script v1.5 in the same source)
    It might be better not to do this at all - however if you really want to achieve this use modular designs with dynamic function calls or replaceable objects instead of fixed connections
  2. Support different target machines (like CPUs that support x64 or x86 SSE or IA32 a GPU with CUDA or....)
    In an interpreted language it is not neccessary to know this ahead of launching the script and to do this at runtime refer to 1
  3. Support for multiple target interpreters/language versions
    For this it's better to leave a version tag in program somewhere and make the target interpreter switch to that version automatically.
  4. Debug versions
    for debugging unit tests have shown to be the most popular solution


It should be obvious that it is not necessary to write both sides of the branch, just as it is not necessary when using if (expression). #ifdef or #ifndef is oftentimes used without #else.

That doesn't change anything there are still 2 paths that can be taken even if there is no #else (go inside the #if/don't go inside the #if). You need to ensure that both sides are valid which is the actual work, not the typing.
Afterwards you also need to update both paths to ensure that they are maintained with the rest of the script.

Also AutoHotkey has a few differencies between the compiled and uncompiled version. One example is exception.
Another is FileInstall. The issue with FileInstall is created by hackish developers who follow undocumented implementation rules though.

Anyways what Im trying to say is that there are better options than #If for these problems and that implementing #if might cause more issues then it solves.
Especially when removing #if at a later date. I personally wouldn't use it - though I might not make an effort by avoiding code that uses it (though I'm undecided on that one).
Recommends AHK Studio
Helgef
Posts: 3096
Joined: 17 Jul 2016, 01:02
Contact:

Re: an equivalent to C++'s #if #else #endif

01 Jul 2018, 12:28

Neither

Code: [Select all] [Download] GeSHi © Codebox Plus

try global A_ComSpec := ComSpec

nor

Code: [Select all] [Download] (Untitled.ahk)GeSHi © Codebox Plus

#if cond
global a_comspec := comspec
#endif

can work, you are missing #define.

Return to “Wish List”

Who is online

Users browsing this forum: No registered users and 3 guests